RE: [lwip-users] Communication delays, if using lwIP in different network areas

[Benjamin Schelte]

I am back on this topic once more, just in case that you are interested what
I found out in the meantime.
After digging in the lwIP tcp/ip stack I could not find any reason, why lwIP
should drop a package.
I enabled some of the debug outputs of the stack, but there was no
processing of the packages that were not properly answered by the device
(just as I have seen in the wireshark logs).

Then I put some debug output in the function right behind the ISR of my
Ethernet adapter. The result was that none of the packages sent by my PC
(that were not "acked" by the device) arrived in the device.
In the end I came to the conclusion that our network setup is not set up
100% correct. Therefore I am waiting for one of our Admins to proof that I
am wrong before spending any more time on this issue.

Thanks for your investigation and the time you spent Kieran.

Best regards,
Benjamin



> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Kieran Mansley
> Sent: Monday, November 15, 2010 11:00 AM
> To: Mailing list for lwIP users
> Subject: RE: [lwip-users] Communication delays, if using lwIP in
> different network areas
> 
> On Mon, 2010-11-15 at 09:14 +0100, Benjamin Schelte wrote:
> > Hi Kieran,
> >
> > Here is some more information about my configuration settings and
> stuff.
> >
> > > 1) a packet capture.
> > Please see the attachments.
> > 10.34.3.179_POR is a short communication between the PC and the
> device
> > inside the 10.x.x.x network
> > 192.168.2.107_POR is the same call to the device from 10.x.x.x
> network to
> > 192.x.x.x network through the router
> 
> Let's take a look at that one:
> 
> 1: PC opens connection with SYN
> 2: lwIP replies with SYN-ACK
> 3: PC acks our SYN-ACK
> 4: PC sends 272 bytes of data
> 5: PC sends 219 bytes of data
> 6: lwIP sends ACK, but not for data in 4 and 5
> 7: PC retransmits data from 4 and 5 (491 bytes) after 3 second delay
> 8: lwIP acks data from 7 and sends 315 bytes of its own
> 9: PC sends FIN to say it has done sending, and acks data from 8
> 10: lwIP sends FIN of its own but does not ack FIN in 9
> 11: PC acks lwIP's FIN from 10
> 12: lwIP retransmits the data from segment 8
> 13: PC acks everything again
> 14: lwIP retransmits the FIN from segment 10
> 15: PC acks everything again
> 16: PC retransmits its SYN as lwIP has still not acked it.
> 17: lwIP finally ACKs PC's FIN.
> 
> This is bad.  It looks like lwIP is just not receiving most of the
> packets sent by the PC.  Was this captured at the PC?  If so there are
> two possibilities:
>  - packets are getting dropped in the network
>  - lwIP is dropping or rejecting packets for some reason.
> 
> > > 2) an example of how you're configuring your netif (e.g. the call
> to
> > > netif_add)
> > tcpip_init(vPrvEthCtrl_ConfigureInterface, NULL );
> > ...
> > vPrvEthCtrl_SetDefaultNetConfig(MacAddress, &xIpAddr, &xNetMask,
> &xGateway);
> > ...
> > /* add data to netif */
> > netif_add(&gsEthCtrl.sNetif, &xIpAddr, &xNetMask, &xGateway, NULL,
> > ethernetif_init, tcpip_input);
> >
> > /* make it the default interface */
> > netif_set_default(&gsEthCtrl.sNetif);
> >
> > /* register status callback */
> > netif_set_status_callback(&gsEthCtrl.sNetif,
> vPrvEthCtrl_NetifStatus);
> >
> > if (bUseDHCP == TRUE) {
> >     // Start DHCP service
> >     dhcp_start(&gsEthCtrl.sNetif);
> > }
> > else {
> >     // Start the network interface with a static IP address
> >     netif_set_up(&gsEthCtrl.sNetif);
> > }
> 
> Looks OK.
> 
> > > 3) your lwipopts.h
> > Please see the attachment.
> 
> Looks OK too. You have the pbuf buffer size set to 2k, but the max
> packet size will be smaller than that.  You could probably get away
> with
> setting them to (3 * 512) instead of (4 * 512) bytes each.  I'd be
> tempted to set MEMP_NUM_PBUF higher but the LWIP_STATS (see below)
> should tell you if that's a problem.
> 
> > Last Friday I did some more debugging and found out that the call to
> > netconn_recv() in my communication task does not always return, if
> data is
> > received.
> > This results in the described response delay, which you can see in
> the logs
> > I attached.
> >
> > I also did some tracing and debugging about the ARP-cache, but that
> one
> > seems to be ok.
> > The entry was 192.168.2.2 (Gateway-IP address) and the according MAC-
> address
> > of the interface.
> 
> OK, it looks to me like the most likely cause is lwIP dropping or
> rejecting packets.  You should be able to debug this either by turning
> on some of the debug print statements and/or using the LWIP_STATS code.
> 
> Kieran
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users