[En-Nut-Discussion] En-Nut-Discussion Digest, Vol 92, Issue 4

[Mingshu Wang]

We don't use DHCP. The port number is 0xbac0. The storm consists of
broadcast messages sending to this port with a few hundred microseconds
between each other. It should have nothing to do with the port number. I
feel the problem is caused by frequent allocating and de-allocating
memory.

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of
en-nut-discussion-request at egnite.de
Sent: Saturday, June 04, 2011 5:00 AM
To: en-nut-discussion at egnite.de
Subject: En-Nut-Discussion Digest, Vol 92, Issue 4

Send En-Nut-Discussion mailing list submissions to
	en-nut-discussion at egnite.de

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.egnite.de/mailman/listinfo/en-nut-discussion
or, via email, send a message with subject or body 'help' to
	en-nut-discussion-request at egnite.de

You can reach the person managing the list at
	en-nut-discussion-owner at egnite.de

When replying, please edit your Subject line so it is more specific than
"Re: Contents of En-Nut-Discussion digest..."


Today's Topics:

   1. Re: NutUdpSetSockOpt problem? (Ulrich Prinz)
   2. Re: NutUdpSetSockOpt problem? (Bernd Walter)


----------------------------------------------------------------------

Message: 1
Date: Fri, 03 Jun 2011 23:08:13 +0200
From: Ulrich Prinz <uprinz2 at netscape.net>
Subject: Re: [En-Nut-Discussion] NutUdpSetSockOpt problem?
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Message-ID: <4DE94D3D.8080303 at netscape.net>
Content-Type: text/plain; charset=ISO-8859-1

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.

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.

> 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?

Ulrich


------------------------------

Message: 2
Date: Sat, 4 Jun 2011 00:50:49 +0200
From: Bernd Walter <enut at cicely.de>
Subject: Re: [En-Nut-Discussion] NutUdpSetSockOpt problem?
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Message-ID: <20110603225049.GH71716 at cicely7.cicely.de>
Content-Type: text/plain; charset=us-ascii

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.


------------------------------

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion


End of En-Nut-Discussion Digest, Vol 92, Issue 4
************************************************