[En-Nut-Discussion] NutUdpSetSockOpt problem?

[Bernd Walter]

On Fri, Jun 03, 2011 at 11:08:13PM +0200, Ulrich Prinz wrote:
> Hi Mingshu,
> 
> Am 02.06.2011 22:07, schrieb Mingshu Wang:
> > Hi all,
> > 
> > I am running Nut/OS on AT91SAM7X256. In my application, I create a
> > socket to receive UDP messages and set a UDP buffer size of 256 by
> > calling NutUdpSetSockOpt(). When I test the application, I found the
> > application can't receive any messages on that UDP port after a
> > broadcast storm. 

Can you tell something about the used network addresses/ports and those
of the broadcast storm?

> Right, I get the same issue if there is a second media receiver using
> multicast in my network. My switch doesn't know anything of IGMP so he
> forwards multicast TV streams to any port. If that happens the Nut/OS
> can't even get an IP address via DHCP but hangs up after opening the
> network stack.
> Can you check if we're talkin about the same problem and try to boot up
> your application with enabled DHCP? It should fail and might even hang
> up completely.

In the meantime I've experienced something strange with a customer
project.
The application requires sending and receiving regular UDP traffic
from and to a single server.
It is not extremly high volume, just one after sleeping for ~100ms,
so no traffic peak.
The original implementation was that the ethernut has send a UDP
packet and the server responded.
Everything was fine with that.
Then the server has send his UDP packets timed on it's own, so
it was sending the packets without the requirement of receiving some.
When the ethernut board was restarted it never got an IP because it
was receiving the UDP packets.
Just to repeat: the load wasn't high and was handled fine when the
system was up, but it was a problem for the board to come up.
The packets were intended for the board and the ARP entry of the
sending side was still established so they were send to the right
MAC-address, although the system didn't had the IP configured yet.
My assumption is that something is fishy when receiving packets
for foreign IPs in some situations.
But I don't see any corelation with the receive buffer size.
Maybe that's a different point, which happens when the receive buffer
overruns - just wild guessing of course.

> > If I comment out NutUdpSetSockOpt(), the application
> > survives the storm. But without the buffer, the application works much
> > slower. I check the heap with function NutHeapAvailable(). I have 5k
> > available during the storm. Other threads like webpage are still
> > working. It seems only that UDP socket is broken. Can anyone help me
> > with this problem?
> 
> Bernd and some others are investigating this during the work of
> implementation of IPv6. I myself started investigation but had to shift
> cause lots of work and not much time left.
>
> Bernd, Ole, Harald? Any update on that?

Just the above new trigger case - so far I'd assumed that it required
some kind of flooding to overflow something.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.