嵌まりどころをひとつ
レジュメにあるalloc_skb関数
これを使ってsk_buffを確保するよりはそのwrapperのdev_alloc_skbを使ったほうがよさげ
前者で確保した時にdev->hard_headerの呼び出し時点で確実にかなり根の深いsystem panicを引き起こす模様
駄目元でこちらにしてみると嘘のように安定して動作
恐らくはalloc_skbとdev_alloc_skbの間に何らかの重要な処理が隠されている模様
デバイスドライバの側では基本的にwrapperのより安全な関数を選択すべきであるという好例かもしれない
レジュメも, そしてこの文も真偽の程は完全に定まっているとは言えないので過信する事なかれという教訓もまた其処に厳然として在るのである
とりあえず一通り書き終える
今のところsystem panicに陥るような落とし穴は全てふさいでいるつもりではあるが, なぜかパケットの到着を認識できない
考えられる原因は色々在って, でも, これ以上書く事あるのかなぁ…パケットのヘッダがおかしいからそもそもパケットが認識できないとか演習用特別仕様関数, 演習仕様カーネルにだけ存在する, 多分正常に動作するはずのものなのだろうけど…oe_registerが怪しいとか, それはもう数え上げるとキリが無いほどに色々あるわけで上手く断定できないのである
因みに聖狐は何故か実験をeth1とloでやっていて, eth0を使っていません
なぜなら不要なパケットを全体に流しうるブリッジ接続のインタフェースを使いたくないから
暫くはVMwareホスト内の仮想LANの砂箱の中でしっかりやりたいなぁ…
明日は東京最終日
何とかeditの簡便性とかを考えてVMware内ではなくホストから同じeth1を通してsshでttyを増やして必要に応じてマウスでCopy and PasteをしているのでIPのPacketを一瞬たりとも殺すわけにはいかないのである上手くパケットをハックして通信を実現したいなぁ…と思ってみたり
謎だったこと: テスト用プログラムが2つ目のVMで正常動作しなかったこと
解決策: 1つ目の環境をMAC設定以外(Disk Image etc.)を上書きその後, IP設定(/etc/sysconfig/network-scripts/下)だけ修正無理矢理Copy
今気付いたこと: 2つ目の環境ではmknodで/dev/foxを作っていなかったことに原因があるのでは…
それでも気になること: ファイルオープンに失敗して止まる筈の所を通過している,. device is busyの時にはちゃんと止まっていた筈なのに…だとしても解せないscanfとかが明らかに失敗しているっぽい, 原因OSはもう消しちゃったから検証できないけど…動作が在ること
Comments (0):
8月2日から管理人・Sacred Foxこと聖狐は地元北海道に帰省します
この文のUPは執筆日の翌日その前日に当たる1日なのでこれが最後の更新になると思われ…
少なくとも更新頻度はがた落ちしますし, 場合によっては帰省中全く更新できなくなるかもしれません
こちらに戻ってくるのはまぁ8月下旬ぐらいになるとは思うのですが, 全く決めておりませんので何時になるか分かりません
取り敢えずは暫しのお別れになりそうです
別に構いやしないのでしょうが…
Comments (0):