続・uIPでUDP

前回(http://d.hatena.ne.jp/yasunoxx/20090901/1251800058)
の続き

ここまでのあらすじ：
・オプティマイズ社製品(http://www.itplaza.co.jp/opti/spi_ether/spi_ether.htm)で
　ARMとENC28J60で稼働実績がある(と思われる)uIP-0.9を
　CQ-STARM基板で動かすべくゴニョゴニョしているぞ
・ある程度ハードルが高いと予想していたので
　TCPサポートは諦めてUDPを動かす事を主眼に置く
　(UDPがマトモに動けばTCPもなんとかなるだろうという読み)
　。。。ここまでハードルが高いとは思ってなかったんだけどね
・uIP-1.0のサンプルコードdhcpc.cを使ってDHCPが動く所までは漕ぎ着けた
　だがしかし

ここまでにやったこと：
・enc28j60.cのデバイスに近い部分(read()とかwrite()とか)を
　STM32でムリヤリ動くようにした
※各レジスタへのアクセスが正常にできるようになるまでは
　誰も助けてはくれない(愚痴
※SPIを全二重で使う時に
　少し考えれば解る事に気付くのに時間がかかった
※メモリをケチるとDHCPが動かないという事に気付くまでに
　ほんの少し時間がかかった
※DHCPのパケットサイズがどのくらいあるかは
　RFCを読めば解る。。。
・DHCP discoverからackまではbroadcastでイイので
　グローバル変数でフラグ(broadcastかunicastかを設定する)を用意し
　uip_process()内部でunicast前提になっている所を
　そのフラグでバイパスする改造を行った
※その結果
　DHCPでローカルIPアドレスを設定できるようになった

そして現在ハマっている事：
・UDP unicastをどう動かしたらイイのか解らない
※uip_udp_new()で送信ポートを開き
　uip_udp_bind()で受信ポートを開くのは
　DHCPで動作を確認できている(しかし前述の問題がある
※何も考えずに動かしたら
　DHCP discover送信時のdestination MAC addressが
　初期化されていない配列(uip_bufの先頭6バイト)のまま
　送出されていた
　とりあえずDHCPを動かさないといけないので
　uip_init()内部でuip_buf先頭6バイトを0x0FFで埋めるようにした
・でもコレっておかしいんじゃないか？
　DHCPのdiscoverからackまではイイとして
　renewal(実装されていない)はunicastじゃなければいけない

今思っている事：
・とにかくuip_process()の記述が汚い
　→読み切れないからTCPサポートは後回しにした
・ARP受信とIP broadcast受信した時の処理が重い
・uip_arp.cでARPテーブルの更新が出来てないんじゃないのか？
　(パケットの送受信はuip_arp.cの中でやっているのは押さえた)
・そもそもUDPでunicastのパケットを単発で出そうという時に
　相手先のIPアドレスしか分からないのだから
　ARPテーブル自動参照かARP requestによる補完は
　必要なんじゃないのか？
　(ここまでARP受信はしているけど
　ARP requestが出た事は一度も観測できていない
　→ARP機能がちゃんと動いているのか？という疑惑)
・そもそもuIPにおいて
　UDPでunicastのパケットを送信するには
　どうするのが正しいのか？
・uip_bufはUDP層からは不可侵だと思っているので
　uip_arp.cかuip_process()内部で決着するしかないだろう
※この部分に対しても誰も助けてくれない(愚痴2
※オープンソースの流儀が分かっていない職場なので
　現状のソースは公開できないけど
　別のカタチでfeedbackしようと思っている

参考にさせて頂いているページ：
mones2(http://wiki.monaos.org/index.php?mones2)