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

[Philipp Burch]

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.

Regards,
Philipp

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
>