[En-Nut-Discussion] ARP request kills realtime UDP packet stream?

Philipp Burch phip at hb9etc.ch
Mon Jan 6 08:09:43 CET 2014

Hi Nico,

I've seen the check of this flag, but at least gid tells me that it is
nowhere else used than for the check in the ARP cache. I suppose it was
either implemented for future extension or is meant to be modified
manually. I considered this first, but this would require manual
modification of the ARP cache based on some information about which IP
the host has. This would be possible of course, but I tried to avoid it.


On 01/06/2014 07:25 AM, Nicolas Heine wrote:
> Is the ATF_PERM flag still in use? I can't see where, when and if it gets 
> set.
> That might be usefull for what you are trying to do.
> Cheers
> Nico
> Hi everyone,
> I've now created an option to automatically reset the ARP cache timeout
> counter on reception of any IP packet. This seems to fix the problem for
> me, so probably it will be of use for others as well. It is integrated
> in the devnut_lm3s branch, revision r5497. If the option in the
> configurator stays disabled (the default), the behaviour is as before,
> so there should be no change for anyone unless they explicitly enable
> the fix/workaround/hack.
> Regards,
> Philipp
> On 12/17/2013 08:30 AM, Philipp Burch wrote:
>> Hi all,
>> I've got running a board with a Cortex-M3 running the (almost) latest
>> and greatest Ethernut version (right from SVN branch devnut_lm3s)
>> connected to a PC with LinuxCNC. The board controls the hardware of a
>> dispenser. The realtime-kernel on the PC regularly (at a rate of 500Hz)
>> sends UDP packets to the board to update motor position setpoints and
>> read back the current locations. So far so good, works like a charm.
>> Sometimes, however, it happens that the board fails to answer the PC's
>> requests for some time (100ms or so) but then becomes operational again.
>> It is not a crash, all threads run through this nicely, only the
>> software on the PC reports an error. The realtime capturing interface of
>> RTnet now allowed me to have Wireshark running for an extended period of
>> time (it took about 4h for the error to show up this time) with - uhm -
>> interesting results: Just before everything stops working, I can see the
>> usual ping-pong packets with response times <10us. But then, the board
>> suddenly does not respond to an incoming packet with a response, but
>> with an ARP request for the PC's IP. The PC eventually responds to that,
>> but in the meantime, no packets are sent from the board.
>> So I've got two questions:
>> 1. Do entries in the ARP cache age even if there are regular incoming IP
>> packets from the respective address?
>> 2. Are outgoing IP packets simply discarded/blocked if no ARP cache
>> entry is present, even if it was just removed because of the age?
>> Right now, I see two solutions/workarounds for the issue:
>> 1. Use static entries in the ARP table.
>> 2. Set the maximum ARP age to a very high value.
>> I'd probably prefer variant 2, as it is easier to do. It would only
>> help, however, if question 1 above can be confirmed.
>> Please comment, I'd like to fix this problem as soon as possible.
>> Thanks and best regards,
>> Philipp
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

More information about the En-Nut-Discussion mailing list