UDP fails to send after a web page is served

Ok i have a fairly large (HUGE) program that up to now works perfectly.

It hosts an internal web page (Mega with w5100 chip (freetronics ethermega))

It has to send a UDP packet once a minute as a heart beat to another arduino, and thats where things get weird.

It fails to send if i load the web page on any pc. I have wireshark running on my PC and for testing, i have the UDP send on a once per second call.
So wireshark works perfectly and i get 1 second UDP packets.

However as soon as i browse to the internal web page, the udp packets stop. However, the udp packet send returns no errors. Nothing at all changes, it’s just that the packets stop being sent.

I have showed socket status before and after the http client send, and showSockStatus shows that the packet was sent from my udp to the PC. Before and after browsing the hosted web page, you can definitely see the listening port 80 open, and on socket 2, you can see the data being sent to the web browser.
Socket 0 stays open on my sketch as a listening port (listening on 540)
Socket 1 is server.begin
Socket 2 and 3 are free, usually udp.begin uses socket 2, but if i happen to browse a site, it will switch to socket 3.

Whats even weirder - is on my internal hosted website is a button that calls the UDP.send manually - and THAT WORKS.
However the 1 second count down timer that calls exactly the same code doesnt work.

So literally:
every second - UDP send (works for as long as i dont touch the web site)
Browse the internal website - UDP send stops working.
Browse the internal website and click on the button that says “Send” and it calls the 1 second code anyway, that works - but the 1 second timer UDP code - which was working… never works again apart from very very sporadically, while continuing to browse the hosted http pages, the 1 second one works again.

But MANUALLY calling the code works every time.
I also have an ICMP ping instance but that was disabled for this test.

Things i have tried:
Ethernet libs. (1.0 up to 2.0)
Serial.printing all return status - all return codes point to the UDP packet sending.
No error messages at all.
Showsock status shows only the send port moving from 2 to 3 after accessing the internal web page, so i was thinking “code issue with socket 3?” but then when i do a manual send USING the web page that still works.

Using the NTP set time client (which also uses UDP) works fine.

Sometimes after a minute it starts working again on the one second timer, sometimes when closing the serial console, it sends a few more packets, but once i browse that internal website, the only guaranteed way to get the 1 second timer interval packets that are called once per second from a countdown timer is to … call the 1 second interval packet send manually.

Ok - another oddity i just discovered.
If i trigger the failure by browsing the website and the serial console is open… if i close the serial console… IT STARTS WORKING AGAIN for a minute or two… then breaks again.

Come to think of it i have had issues with locking up when sending lots of data over the serial port while communicating with the wiznet chip - is there any kind of crossover with sending serial data and communicating over the SPI bus to the w5100?

Without having seen your code I guess you have an out of memory problem.
There may be other problems, I would start checking if your timer code (whatever that means) runs correctly. Keep in mind that you must no call any code depending on interrupts (p.e. using the Serial object) during an interrupt handler.

Yea the code is a big project, about 25 individual tabs. I am thinking it is a memory issue, and i have a fairly large buffer allocated that i put some canary code into, but that came out fine as well.

I was using an individual session based UDP “sender” code, open the port, send, close the port, and i changed to opening it right at the beginning of the code and leaving it open for use. That actually fixed the issue, but it then binds up a single port on the W5100, and there is only 4.

2 being used for full time UDP comms, 1 for the web socket, leaving only one for the occasional NTP time keeping packet.

The reason im using 2 ports, one for send and one for recieve is that there is that UDP W5100 bug where it locks up if waiting for a recv it recvs something else. Unless thats been fixed?/fixable?

If thats been fixed, i will stick with using one single UDP port for all communications which would be ideal, as then i can put my ICMP code back in. The 4 ports on the W5100 are a bit of a pain, and my code is using it to the fullest extent with a web server, icmp, ntp and 2 way UDP comms.