Re: [lwip-users] Network Loss causes network to go down

[Yacob Hassidim]

Hello all,

My project environment is:
- Controller:  STM32F439BGT6
- Ethernet  PHY chip: LAN8742A (from Microchip)
- OS: FreeRTOS
- TCP/IP stack: LwIP Version 2.0.3

My project also requires to identify Link (network) disconnection.

I used HAL_ETH_ReadPHYRegister (&heth, PHY_BSR, &regvalue) to identify the 
status of the link.

The definition PHY_LINKED_STATUS masks the bit of link status.

I read the PHY register twice to ensure the link is down.

I changed the function ethernetif_set_link() in the file: ethernetif.c for 
reading twice the PHY register.

The link disconnection is identified successfully. 

Sincerely,

Yacob Hassidim,
Real Time Embedded Software Engineer

-----Original Message-----
From: lwip-users <lwip-users-bounces+yacobh=address@hidden> On Behalf Of Jan 
Menzel
Sent: Thursday, April 2, 2020 1:17 AM
To: address@hidden
Subject: Re: [lwip-users] Network Loss causes network to go down

Hi Dan!
        Its a fundamental thing with TCP and UDP that there is not way to know, 
that the link is valid but the other side just did not had anything to say 
unless you added it to your protocol. Using cable detection in the phy might 
help, but only a little bit as most devices talk to other devices that are 
multiple hops away and any problem between the first hop and the remote side 
are not covered then.
        I once had a project where a LWIP driven device had to send small 
amount of data ever few minutes to a remote server that was located on the 
other side of the world. This devices had nobody to maintain it like watching 
for status leds or pressing a reset knob.
        We finally solved the issue using multiple points:
- enabled timeouts for receive and transmit to never block. Thats what we 
observed first: the transmit loop was blocked due to to many unacked data.
- use some watchdog/ping command in the protocol to detect if the connection to 
the remote side is still valid/active. Thats the only way to be sure, the 
remote side is still reachable.
        The F427 has lots of RAM. You might provide more storage to allow more 
then one connection.

        Jan

On 01.04.2020 00:45, Bomsta, Dan wrote:
> Thanks Trampas!  You went down the same road I started on with the 
> ability to detect the disconnection.  I was told we cannot change the 
> hardware, so I am trying to find the correct location in Lwip to 
> “clean up” when there is no route.  Just haven’t found it yet.
> 
>  
> 
> The correct solution in using the carrier sense pin.
> 
>  
> 
> Thanks again,
> 
> Dan
> 
>  
> 
> *From:*lwip-users
> <lwip-users-bounces+dan.bomsta=address@hidden> *On Behalf Of 
> *Trampas Stern
> *Sent:* Tuesday, March 31, 2020 5:11 PM
> *To:* Mailing list for lwIP users <address@hidden>
> *Subject:* Re: [lwip-users] Network Loss causes network to go down
> 
>  
> 
> Dan,
> 
>  
> 
> I had been using a RMII phy and noticed similar issues.  Specifically 
> I could not detect cable connected or disconnected using the RMII, the 
> link activity bit does not work for cable connected/disconnected.  I 
> was shocked to find that RMII did not provide this functionality.  
> Sure the LED blink but no bits in the RMII register map changes when 
> cable is inserted or not.
> 
>  
> 
> We had problems where it timeouts in setting up the netif/lwip  were 
> causing watch dog time outs if cable was unplugged on boot. Then when 
> cable was removed and reinserted (not a normal case for our device) we 
> were having similar issues as you.  We could not find a way to know if 
> the cable was connected or not, except by redesigning hardware.  So we 
> are redesigning hardware to use hardware cable connection detection 
> using PHY carrier sense pin.   The plan was try and shutdown lwip and 
> restart netif and lwip when cable was plugged back in.
> 
>  
> 
> Trampas
> 
>  
> 
>  
> 
> On Tue, Mar 31, 2020 at 5:51 PM Bomsta, Dan <address@hidden 
> <mailto:address@hidden>> wrote:
> 
>     I have am working  on an issue with our device.  First here are the
>     particulars
> 
>     Micro:  STM32F427
> 
>     LwIP: 2.0.3
> 
>     WolfSSL: 3.15.3
> 
>     Microchip managed switch KSZ8863RLLI.
> 
>      
> 
>     If one removes the Ethernet cable from our device (typically during
>     heavy traffic) the network is not usable for many minutes upon
>     reconnecting the Ethernet cable.  I have been printing WolfSSL debug
>     messages and Lwip debug messages without solving the issue yet.
> 
>      
> 
>     No, we do not have the ability to “hardware” determine when the
>     cable is unplugged.  Our system has these devices “daisy chained” so
>     one would need to ping to determine if the network is available. 
>     The last good trace I got is this (then my laptop crashed)
> 
>      
> 
>     ip4_route: No route to 172.20.0.14
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: polling application
> 
>     b
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     ip4_route: No route to 172.20.0.14
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     [512942] Link up? 0
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: polling application
> 
>     b
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     ip4_route: No route to 172.20.0.14
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: polling application
> 
>     b
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     ip4_route: No route to 172.20.0.14
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     [514966] Link up? 0
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: polling application
> 
>     b
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     ip4_route: No route to 172.20.0.14
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     [517070] Link up? 0
> 
>     tcp_slowtmr: processing active pcb
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     tcp_slowtmr: polling application
> 
>     b
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     ip4_route: No route to 172.20.0.14
> 
>     data=0x0
> 
>     =0x0)
> 
>     sum)
> 
>     4ac (0x14ac, 0x14ac, 0x64080000)
> 
>     )
> 
>     x64080000)
> 
>     ac, 0x14ac, 0x64080000)
> 
>     JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
> 
>     T
> 
>      
> 
>     Any ideas would be greatly appreciated.
> 
>      
> 
>     Dan
> 
>     _______________________________________________
>     lwip-users mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.nongnu.org/mailman/listinfo/lwip-users
>     
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org
> _mailman_listinfo_lwip-2Dusers&d=DwMFaQ&c=tkg6qBpVKaymQv9tTEpyCv5e23C4
> oKrSdZwjE7Q68Ts&r=-BFNB_Gh7uVsB52WcbiFwUj7o24P6Ed-I3ShWtNr6WI&m=tTdQEd
> g2QwqZRBlEpezVVPzGuYEtrth1C8oixb1w_pc&s=YKP0gARz9hVNrJIaM7SyZUrn3gq4Ms
> Oiny9JGHeSUeA&e=>
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>