(toppers-users 2814) Re: TINETをM32Cで動作させようとしていますがnservが途中でとまります

[ABE Tsukasa <abe at jo tomakomai-ct ac jp>]

エレクトロフレックス 市川様

苫小牧高専、情報工学科の阿部です。

>現在JSP-1.4.3＋TINET-1.4をM32C/87(ルネサスのスタータキット)にてPPPで
>動作させようとしています。
>何点か変更の後、WWWでの通信の確認を行っていますがうまく行きません。
>どのあたりを確認すればよろしいのでしょうか。
>なお、コンパイラはHEWの物を使用しています。

まず、申し訳ありませんが、一応 PPP をサポートはしていますが、
テスト環境を、うまく構築できなかった関係で、TINET-1.4 では、
PPP の試験ができませんでした。

>ハードウェアはLinuxのPPPサーバとM32Cマイコンボードをシリアル直接接続しています。
>
>現象としては
>tinet_cpu_config.h において NUM_MPF_NET_BUF_IF_PDU 2 の時コンソール上は
>
>PPP/IPCP] up, Local IP Addr: 192.168.1.21, Remote IP Addr: 192.168.1.31.
>[WWW:04]     connected:       8, from: 21.1.168.192.53890
>
>でとまっていてブラウザに変化はありません。パケットは
>
>PC  →syn    →M32C
>M32C→ack,syn→PC
>PC  →ack    →M32C
>PC  →ack    →M32C  GET /〜
>PC  →ack    →M32C  =0.5CRLFAccept-〜
>M32C→ack    →PC    GET /〜のack（=0.5CRLFAccept-〜受信中に送信）
>PC  →ack    →M32C  =0.5CRLFAccept-〜
>M32C→ack    →PC    =0.5CRLFAccept-〜のack
>
>でPPP通信が終わってしまいます。但しLCPのエコーのREQ、ACKは継続しています。
>この状態のときM32CからのTCPのウインドウが最後以外が0200hで最後が016dhと
>変化しています。

H8/3048F（16MHz）で、テストしていたときと、似ていますね。
H8/3048F の割り込み応答が遅いのが原因と思われるのですが、
フレームの CRC エラーが頻繁に発生していました。
このため、再送セグメントがうまく届かないようです。

>tinet_cpu_config.h において NUM_MPF_NET_BUF_IF_PDU 3〜6 ですと
>1回はindex.htmlがPC上に送られるのですが、2回目にindex.htmlを表示させようとすると
>
>[PPP/IPCP] up, Local IP Addr: 192.168.1.21, Remote IP Addr: 192.168.1.31.
>[WWW:04]     connected:       5, from: 21.1.168.192.35963            ←1回目
>[WWW:04]     send:               index.html, len: 1227, time: 2 [ms]
>[WWW:04]     finished:        5
>[WWW:04]     connected:       6, from: 192.168.1.31.35964            ←2回目
>[WWW:04]     send:               index.html, len: 1227, time: 1 [ms]
>20 messages are lost.
>[NET BUF] E_ID, ID=185.
>E_ID reported by `rel_net_buf(cep->rwbufq)' in line 877 of `tcp_subr_cs.c'.
>[NET BUF] E_ID, ID=86.
>E_ID reported by `rel_net_buf(cep->rwbufq)' in line 877 of `tcp_subr_cs.c'.
>[NET BUF] E_ID, ID=192.
>E_ID reported by `rel_net_buf(cep->rwbufq)' in line 877 of `tcp_subr_cs.c'.
>[NET BUF] E_ID, ID=192.
>E_ID reported by `rel_net_buf(cep->rwbufq)' in line 877 of `tcp_subr_cs.c'.
>[NET BUF] E_ID, ID=168.
>E_ID reported by `rel_net_buf(cep->rwbufq)' in line 877 of `tcp_subr_cs.c'.
>[NET BUF] E_PAR, ID=1.
>E_PAR reported by `rel_net_buf(cep->rwbufq)' in line 877 of `tcp_subr_cs.c'.
>[NET BUF] E_ID, ID=31.
>
>のようになります。（2回目のsend:以降はいつも同じでは有りません）

ネットワークバッファの ID 部分を破壊しているようで、
TINET の内部処理問題のようです。

なお、ウィンドバッファの省コピー機能を使っているようですが、
この場合、ネットワークバッファを多く使います。
使わないように設定して、テストはできるでしょうか?

>1回目のパケットは異常なく2回目のパケットではindex.hlmlのメッセージを含む
>パケットの送信元アドレスが間違ったものになっており、PCは受信できず、
>M32Cもackが帰ってこないので待ったまま（FIN＿WAIT1）になります。
>メモリーの内容が壊れているようですが何処から見て行けば良いのか判らない状況です。
>
>以上ですがアドバイスを頂けないでしょうか。
>よろしくお願いします。
>
>なお以下のような変更も行っています。
>
>ppp_hdlc.cのHDLC_putoctet (UB octet){}では
>// if ((octet < 0x20 && ((1 << octet) & lcp_remote_ack_cfg.ACCM)) ||
> if ((octet < 0x20 && (((UW)1 << octet) & lcp_remote_ack_cfg.ACCM)) ||
>とキャストしないと必要な長さのシフトが行われませんでした。
>
>ppp_fsm.c、ppp_lcp.c、ppp_upap.cではヘッダ長さのバイトオーダが逆で
>長さチェックの部分で引っかかり、
>たとえば
>  hdr = GET_PPP_CP_HDR(input);
>    hdr->len = (hdr->len >> 8) + ((hdr->len & 0x00ff) << 8); // 追加
>のようにしてとりあえず動かしています。

int のサイズ問題と、バイトオーダ問題ですね。
こちらでも変更しておきます。

あまり参考にならないようですが、
よろしくお願いいたします。

--
.\" 苫小牧工業高等専門学校 情報工学科 教授 阿部 司
.\" 〒059-1275 北海道苫小牧市字錦岡443番地
.\" E-mail: abe at jo tomakomai-ct ac jp  TEL/FAX: 0144-67-8937