Wiz5100 : not accepting incoming packets after some time?

Hello everybody !

I am running into a weird behavior, which might be linked to my software, or hardware;

On my domino with an arduino WI5100 ethershield v5 board, I have been running several applications using WIZ5100 sockets. Either UDP or TCP. TCP : using either the httplistener class or regular sockets.

Either using static IPs or DHCP.

Powered via USB or external power.

After “some variable time”, the board stops accepting incoming calls. The “some time” can be between 12 and 48 hours. All the other process on the board keep working fine (writting data to the SD card every few minutes). It just behave as it was deaf to TCP and UDP incoming packets. However, ICMP/pings keep replying.

First I thought that in some cases (exeptions?), I was not properly closing the sockets, and I carrefuly monitored them (increasing counter when accepting, decreasing when closing) and it does not seem related.

If I perform a WIZnet_W5100.ReintializeNetworking() every few hours, the problem seem to be solved. However, due to the rare occurence of the problem, it takes a long time checking everything.

Has anyone already met this kind of problem ?
Or on the reverse, did anyone made an application, using the WIZ5100 board, work on the network fine for several days with no trouble ?

Just in case, I ordered another wiz5100 shield…

Thank you in advance for your help ;D !
Nicolas

Worst kind of problem to debug since each attempt takes several hours:/ Think it throuh and make some variables in which you will store your system status at runtime. Then run your program on that FEZ while connected to PC. Do not debug yet, wait till the problem occurs and than use ‘attatch to process’ option from VS debug menu. This way you can stop everything and investigate the state of your program. This is how i would try to do this, maybe it will help you

I’ve noticed this behavior, as well. Verbatim of what you describe (with your code ;)). All I’m doing is responding with the time/temperature when a request is made. I also refresh a serial LCD with the same data. As you noted, my LCD continues to update, but occasionally the http server stops responding and does not come back up unless I reset the hardware. I’m using a Panda II with a wiz811mj. I will try running some ‘bare bones’ code to see if I get the same issue.

Off topic - I’m hoping to have some time this weekend to test and ‘pretty up’ your beta4 NetConfig code.

@ Gralin, Thanks, working on it.
@ Eric, Thank you, that narrows the search between my code (most likely) or something with the firmware (should not be !). Must be a stupid mistake I’m doing all the time ::), because even whith other code not related to HTTP, I get the same problem. By chance, if you are using DHCP, would you know what is the lease time is on your network ?

Don’t bother with prettying up the beta4, it’s still a beta. Maybe wait for the RC ! However if you have time to give me a tip for the cleanest way to link the ressources, please let me know ! I’ll put an update about beta5 this week end. Trying to secure threading and working on improving the DHCP feature.

Nicolas,
I am not sure if this is related to the issue you are facing.

I got these from the release notes:

[quote]•Known Issues
◦ RSA Decrypt fails for certain input lengths.
◦Wiznet W5100 DHCP does not renew when it expires
[/quote]

But even if the lease expires I guess the DHCP server check if the lease is in use or not before releasing the lease,

To make use if it related to DHCP. try your example static network setting.
Also there is Dhcp.release() method, if you like to manually renew the lease.

FWIW, I’ve seen the same thing when using the shield on an Arduino. So it may be a problem with the w5100.

I’d suggest you also log some GC memory stats to see whether things are going weird there. I have (yes, it’s still something I haven’t looked at more) a memory / object leak that is causing the Fez to get to the point where “other things” including display output work ok but responding to network requests can’t be handled. I don’t think my case and yours are the same (its clearly my code issue!) but it might be another dimension that is worth looking at.