Re: [lwip-users] Is something wrong in netconn_accetp() api ??

[Jonathan Larmour]

yihect wrote:
>  Hi, Jonathan, thanks a lot for your reply.
>  
>  The netconn_recv() can return none-zero netbuf ptr now. But the http
> demo can't work yet.
>  
>  Debugging network program seems tool difficult. The client tool, IE in
> my windows, will send several ethernet frames to my bf531 box
> continuously. That makes me difficult to debug, because several network
> chip interrupts raise up, and the program will goes here and there in
> multi_tasks environment like uCOS.. oh, that makes headache to me.
>   So, my question is: is there some simple tools for protocol stack
> debugging?

lwIP comes with many options you can set in lwipopts.h to control debug output.

> To be an example, is there one tool, by which we can send a
> package or frame one time manually?

Not really. TCP has well-defined real-time constraints and timeouts. The
most you can do to split things up is to tweak your driver temporarily
(just while debugging) to not allow through only one packet at a time, e.g.
by masking the interrupt (which you can then unmask in your debugger when
you're ready to get another packet). But you can expect connections to time
out in your clients while doing this of course, and be faced with extra
traffic because of retransmissions, thus changing the traffic pattern.

Rather than trace a packet through the stack in your case, I think it would
be better to closely at the problem when you see the problem. So, what
problem are you actually seeing now?

You may need to pay attention to the stated assumption in the example
server that data arrives in a single netbuf. You may want to check if
that's why things are going wrong for you now.

Jifl

> 在2008-08-20，"Jonathan Larmour" <address@hidden> 写道：
>>yihect wrote:
>>>  
>>>   When I sent a http request using TELNET program in my pc, the 
>>> netconn_accept() returned, and I had noticed SYN/SYN+ACK/ACK packages in 
>>> Ethereal, I think that meas the TCP connection(accept_conn) have 
>>> established.
>>>   But when I stepped into netconn_recv() in http_server_serve() fun, I 
>>> found the conn->state is equal to zero, namely NETCONN_NONE.
>>
>>That is correct.
>>
>>> Finally, 
>>> netconn_recv() return a null pointer, and the port is crashed.
>>
>>Is that just after you closed your telnet? If so, then I don't believe 
>>there's any problem. The example program is not robust to that - it's only 
>>a trivial example for demonstration purposes. It doesn't check the return 
>>from netconn_recv.
>>
>>>   Here, Is something wrong? Since the connection had been established , 
>>> should state field of the connection be NETCONN_CONNECT , not be 
>>> NETCONN_NONE ? From Ethereal's output, the connection have closed, which 
>>> proved by debugging into following if-block in netconn_recv() fun:
>>
>>NETCONN_CONNECT is only used if something is waiting for a 
>>netconn_connect() to complete.
>>
>>Jifl
>>-- 
>>eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
>>Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
>>Registered in England and Wales: Reg No 4422071.
>>------["The best things in life aren't things."]------      Opinions==mine
>>
>>
>>_______________________________________________
>>lwip-users mailing list
>>address@hidden
>>http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> ------------------------------------------------------------------------
> 伊利：有梦想，就有下一次飞翔。期待刘翔王者归来。
> <http://popme.163.com/link/004758_0820_5283.html>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users


-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine