Re: [lwip-users] lwIP trouble

[Slava Zilberfayn]

Hello all,

I've  done some more testing with tcpecho example. When I set
chunk  size  to  be  less  than the size of the tcpecho
packets,  I  get  exactly  the same failure during the second
call  to netconn_write. When the packet size small than chunk
size  it  crashes fairly quickly. For example I set chunk size
to  400  in the tcpecho example and send 400 bytes packets to
it. Works fine.

If   I  start  sending  401 bytes, it crashes fairly quickly.
There   must   me   something  wrong  with  my  settings. Any
help would be appreciated.

Thanks, Slava





Monday, February 25, 2019, 9:30:28 PM, you wrote:

SZ> Hello Lwip-users,

SZ> I  have a networked device that was running lwIP 1.4.1 in the
SZ> past,  but  now I'm upgrading it to 2.1.0. The reason for the
SZ> upgrade  is  that  we  have  a  bit  of  instability.  I have
SZ> previously identified two bugs in 1.4.1 that we were hitting,
SZ> and applied fixes. But since we still have occasional faults,
SZ> I  decided to upgrade. The application is an http_server that
SZ> uses netconn API.

SZ> Now, I have also upgraded the FreeRTOS, which went relatively
SZ> trouble free.

SZ> With    lwIP    I    first    hit    the    new   #ifdef   in
SZ> netconn_write_vectors_partly:

SZ> #if LWIP_SO_SNDTIMEO
SZ>   if (conn->send_timeout != 0) {
SZ>       dontblock = 1;
SZ>   }
SZ> #endif /* LWIP_SO_SNDTIMEO */
SZ>   if (dontblock && !bytes_written) {
SZ>     /* This implies netconn_write() cannot be used for non-blocking send, 
since
SZ>        it has no way to return the number of bytes written. */
SZ>     return ERR_VAL;
SZ>   }

SZ> I   was  using  netconn_write()  macro, and so it was exiting
SZ> here with ERR_VAL.

SZ> I switched to netconn_write_partly() and it made things work,
SZ> sort  of.  I'm  testing the access of a single file. It works
SZ> about  90%  of  the  time, but the other 10% it explodes in a
SZ> strange way.

SZ> Here is the log file.

SZ> Netcnn a009879c
SZ> http_server_netconn_thread: Sending Message             
SZ> Netcnn 2 a009879c                                       
SZ> http_file_server: Processing Message                    
SZ> netconn_recv...                                         
SZ> resource requested = '/s.xml'                           
SZ> tcp_write(), LR = 28a77                                 
SZ> tcp_write(pcb=a0098eac, data=10003160, len=68,
SZ> apiflags=1)                      
SZ> tcp_write: queueing 1b1c:1b60                           
SZ> tcp_output_segment: 1b1c:1b60                           
SZ> XML Generated 2000 bytes                                
SZ> calling netconn_write_partly 36                         
SZ> tcp_write(), LR = 28a77                                 
SZ> tcp_write(pcb=a0098eac, data=1000c2c0, len=1460,
SZ> apiflags=1)                    
SZ> tcp_write: queueing 1b60:2114                           
SZ> tcp_output_segment: 1b60:2114                           
SZ> calling netconn_write_partly 37                         
SZ> tcp_write(), LR = 28a7************tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=1000c874, len=540,
SZ> apiflags=1)                     
SZ> tcp_write: queueing 2114:2330                           
SZ> tcp_output_segment: 2114:2330                           
SZ> ************7
SZ> tcp_write(pcb=a0098eac, data=1000c874, len=540,
SZ> apiflags=1)                     
SZ> tcp_write: queueing 2330:254c                           

SZ> HARD FAULT                                              
SZ> _CFSR 8200                                              
SZ> _BFAR 18                                                
SZ> LR 2022d                                                
SZ>                                                         
SZ> I    have   added   the  *********  manually  to  demark  the
SZ> intervening call. What I see is that in
SZ> the  middle  of  the  tcp_write  execution  another  call  of
SZ> tcp_write   comes   in   with   exactly  the same parameters.
SZ> Presumably   to   send  the  same  piece  of data. I've added
SZ> printing LR register at the entry into tcp_write to see there
SZ> it  is  called  from.  Both calls come from the same location
SZ> (api_msg.c:1712).  Now  I'm  kind  out of ideas. Any pointers
SZ> where to look at would be appreciated.

SZ> attached are my config files.

SZ> Thank you, Slava



-- 
Slava Zilberfayn mailto:address@hidden
Phone: 416 7289367

Home Electronics, www.home-electro.com
100 Drumlin Circle,
Suite 205
Concord, ON, L4K 3E6
CANADA