Strange failure with W5500 shield

[Phono]

**** Please disregard this topic. I finally found a mistake in my code.

Hi,
I am using a Olimexino STM32 board (Maple-like, using a STM32F103RBT6) and an Ethernet shield using a W5500 chip.
I am using the library inherited from the Maple environment, that I have reworked to be multitasking-friendly. Basically I added mutexes around the SPI accesses to avoid mixups in the the various traffics between the processor and the W5x00 chip when it was accessed from different threads. I use FreeRTOS8.21.
i have already developped softwares implementing Ethernet communication, though using either W5100 or W5200 chips. Anyway, in one project I have two TCP clients; in another one a TCP server and a UDP client.
This time I have two TCP clients and one UDP server.
I experience a strange behaviour. The UDP communication task waits for incoming UDP datagrams on the chip's IP address and into the port I specified -- which is port 8000.
The problem is the following: one of the TCP clients sends a request to an outside server. The server responds with the expected data (a short string).
BUT at this time, the UDP socket behaves like it also received the incoming frame, and the library method Udp.parsePacket() returns a non-zero length, and updates the remote ip property of the Udp object. Specifically the claimed remote ip is 70.80.83.32 (all values decimal) and the received packet length is 31293.
Actually my network uses the addresses 192.168.1.xx, and no packet of this size has travelled on the network at these addresses, according to Wireshark. No UDP packet has been recorded by Wireshark, and it is exactly when the TCP packet that comes as a response of the TCP query arrives that the UDP socket erroneously pretends to have received a datagram.
Conversely, If from outside I send a UDP datagram to the port 8000 of the ip address of my board (192.168.1.80), Wireshark sees it go through, but it indicates "address unreachable", and my application does not react to the incoming datagram.
So for some reason, the UDP socket I have instantiated and initialized does not accept UDP datagrams as expected, but catches TCP frames meant for the other socket which works correctly otherwise.
Now, comparing the correct TCP message received and the wrong UDP datagram received, I notice that he value "source ip" : 70, 80, 83 32 actually belongs to the data field of the TCP message, and the packet length, 31293, is the decimal value of the two bytes 7A 3D that also belong the the received TCP message. These bytes occur to be decoded as a datagram header according to the UDP convention, whereas they belong to an incoming TCP frame, and the socket which receives it, and which is configured for UDP, receives it along with another socket which is configured for TCP and which correctly uses the received data.
Any idea?

[stevestrong]

Maybe OS related? Have you tried in non-OS environment?
Or the UDP datagram you send is not correct?
If you post a simple (non-OS) example showing the effect I could eventually try to reproduce the problem and support you.