Correction to the "Ethernet problem"

[Ian Caddy]

Hi Leon,



Leon Pollak wrote:
> Sorry, the information about 7s was incorrect - now I received the case when 
> it was also insufficient. :(
> 
> But one thing is undoubted - when there is the first packet lost, there is 
> also doubled arp request. Below is the tcpdump printout (133=rtems, 57=pc):
> 
> Packet is lost:
> arp who-has 192.168.50.133 tell 192.168.50.133 <====WHY IS THIS?

This first ARP request is always done when you have a static IP address, 
at least in the RTEMS stack.

It comes about through a function in if_ether.c called arp_ifinit which 
is called from ether_ioctl (in if_ethersubr.c) when an IP address is 
setup.  I assume this is to let the rest of the network know who you are 
and also maybe to check if there is an address conflict.


> arp who-has 192.168.50.57 tell 192.168.50.133
> arp reply 192.168.50.57 is-at 00:19:db:ed:16:94
> arp who-has 192.168.50.57 tell 192.168.50.133 <====WHY IS THIS?
> arp reply 192.168.50.57 is-at 00:19:db:ed:16:94

OK, I think I might have sorted this one out as well!

How quickly do you send your UDP packets?  Do you wait for a response 
from the other end before sending your second packet?  If not, I think 
you are sending your second UDP packet before the first one has actually 
gone.

Let me explain.  All the work for ARP is performed in arpresolve (in 
cpukit/libnetworking/netinet/if_ether.c)

arpresolve will check the current arp table and if a valid entry is 
there, it will return the ether address and return code of 1.  This 
means that the higher level can send the packet.  If the ether address 
is not yet resolved, the packet (mbuf) will be held for transmission in 
an arptable holding buffer and the return code of 0 will be sent.  This 
tells the higher level not to worry about this packet, it will be send 
by ARP once it receives the correct ether address.

The problem is that if you send another packet, *before* the arp 
response is seen, that first packet is ditched, and replaced with the 
new packet, and another ARP request sent.  In arpresolve, look for 
la->la_hold which is the last packet (mbuf) that you had provided.  If 
it exists it will be freed.

The simple solution to your problem, is to wait slightly after your 
first UDP packet (for the other end to provide an ARP response) and you 
should be fine.

Remember, UDP is not a guaranteed packet mechanism.  The stack does not 
guarantee to send any UDP packet and it is upto you (application) to 
ensure that the packet arrives at the other end.  In this case, you 
would be looking for some sort of response from the other end before 
sending your 1 packet or some other mechanism of recovery.

I hope this helps.

regards,

Ian Caddy


-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9444 2634