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

2020-03-31 Thread 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  On 
Behalf Of Trampas Stern
Sent: Tuesday, March 31, 2020 5:11 PM
To: Mailing list for lwIP users 
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 
mailto:dan.bom...@sageglass.com>> 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, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
[512942] Link up? 0
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
[514966] Link up? 0
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
[517070] Link up? 0
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac

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

2020-03-31 Thread 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 
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, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: polling application
>
> b
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> ip4_route: No route to 172.20.0.14
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> [512942] Link up? 0
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: polling application
>
> b
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> ip4_route: No route to 172.20.0.14
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: polling application
>
> b
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> ip4_route: No route to 172.20.0.14
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> [514966] Link up? 0
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: polling application
>
> b
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> ip4_route: No route to 172.20.0.14
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )
>
> x6408)
>
> ac, 0x14ac, 0x6408)
>
> JSH˛ÓdĘÚ@¨0Ď$ü‡ouóćq
>
> tcp_slowtmr: processing active pcb
>
> data=0x0
>
> =0x0)
>
> sum)
>
> 4ac (0x14ac, 0x14ac, 0x6408)
>
> )

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

2020-03-31 Thread 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, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
[512942] Link up? 0
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
[514966] Link up? 0
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
[517070] Link up? 0
tcp_slowtmr: processing active pcb
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
tcp_slowtmr: polling application
b
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
ip4_route: No route to 172.20.0.14
data=0x0
=0x0)
sum)
4ac (0x14ac, 0x14ac, 0x6408)
)
x6408)
ac, 0x14ac, 0x6408)
JSH²ÓdÊÚ@¨0Ï$ü‡ouóæq
T

Any ideas would be greatly appreciated.

Dan
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Network mapped drive

2020-03-31 Thread Trampas Stern 
Has anyone used LWIP to create a mass storage device that can mapped as a
drive on a PC?  That is a samba or other type of server?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

2020-03-31 Thread Massimiliano Cialdi 
On Tue, Mar 31, 2020 at 10:11 PM Simon Goldschmidt  wrote:
> You're mixing link state with admin state here. That might work, but
> might not work in some situations.
It's not so clear to me.
Which pattern should I adopt to keep the link status under control?
What do you mean by 'admin state'?
How should the admin state be affected by the link state?


> > Then when the link goes down while
> > err = netconn_recv(conn, );
> > is waiting, it doesn't exit with an error. Is that correct?
> Correct or not depends on how you define it. There's currently no code
When you say "depends on how you define it.", what are you talking about?

> in lwIP to unblock on link loss. That could only work if you're bound to
> a netif. I'm not sure if what you think of works in other stacks.
What other stacks? Stacks other than lwip?

best regards
Max



-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

2020-03-31 Thread Simon Goldschmidt 



On 31.03.2020 21:34, Massimiliano Cialdi wrote:

I have a process that polls the PHY to find out if the link is up or
down. It calls netif_set_link_up()/netif_set_link_down(). I also have
the link callback calling netif_set_up()/netif_set_down().


You're mixing link state with admin state here. That might work, but
might not work in some situations.



I wonder what happens if the functions:
   conn = netconn_new(NETCONN_UDP);
   netconn_bind(conn, IP_ADDR_ANY, 7);
are called when netif is still down. This happens because, for
example, the udpecho_thread() process starts before the netif is up.

Then when the link goes down while
err = netconn_recv(conn, );
is waiting, it doesn't exit with an error. Is that correct?


Correct or not depends on how you define it. There's currently no code
in lwIP to unblock on link loss. That could only work if you're bound to
a netif. I'm not sure if what you think of works in other stacks.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] bind with link down

2020-03-31 Thread Massimiliano Cialdi 
I have a process that polls the PHY to find out if the link is up or
down. It calls netif_set_link_up()/netif_set_link_down(). I also have
the link callback calling netif_set_up()/netif_set_down().

I wonder what happens if the functions:
  conn = netconn_new(NETCONN_UDP);
  netconn_bind(conn, IP_ADDR_ANY, 7);
are called when netif is still down. This happens because, for
example, the udpecho_thread() process starts before the netif is up.

Then when the link goes down while
   err = netconn_recv(conn, );
is waiting, it doesn't exit with an error. Is that correct?

best regards
Max
-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users