Network Loss causes network to go down

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Network Loss causes network to go down

Bomsta, Dan

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Network Loss causes network to go down

Trampas Stern
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Network Loss causes network to go down

Bomsta, Dan

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=[hidden email]> On Behalf Of Trampas Stern
Sent: Tuesday, March 31, 2020 5:11 PM
To: Mailing list for lwIP users <[hidden email]>
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Network Loss causes network to go down

Trampas Stern
I had thought about trying to time out on not getting a packet.  That is assume there will always be some packets received, ARP messages etc.  Then if no packet received in say 1 minute reset lwip.  However GPIO pin was better long run.    

Another idea was that our PHY chip also has SPI mode which might have more information about cable status, but since we are spinning hardware anyway we did the cable detect pin. 

Trampas

On Tue, Mar 31, 2020 at 6:45 PM Bomsta, Dan <[hidden email]> 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=[hidden email]> On Behalf Of Trampas Stern
Sent: Tuesday, March 31, 2020 5:11 PM
To: Mailing list for lwIP users <[hidden email]>
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Network Loss causes network to go down

Jan Menzel
In reply to this post by Bomsta, Dan
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=[hidden email]> *On Behalf Of
> *Trampas Stern
> *Sent:* Tuesday, March 31, 2020 5:11 PM
> *To:* Mailing list for lwIP users <[hidden email]>
> *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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     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=tkg6qBpVKaymQv9tTEpyCv5e23C4oKrSdZwjE7Q68Ts&r=-BFNB_Gh7uVsB52WcbiFwUj7o24P6Ed-I3ShWtNr6WI&m=tTdQEdg2QwqZRBlEpezVVPzGuYEtrth1C8oixb1w_pc&s=YKP0gARz9hVNrJIaM7SyZUrn3gq4MsOiny9JGHeSUeA&e=>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Network Loss causes network to go down

yacobh@dds-security.com
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=[hidden email]> On Behalf Of Jan Menzel
Sent: Thursday, April 2, 2020 1:17 AM
To: [hidden email]
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=[hidden email]> *On Behalf Of
> *Trampas Stern
> *Sent:* Tuesday, March 31, 2020 5:11 PM
> *To:* Mailing list for lwIP users <[hidden email]>
> *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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>



_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users