Correction to the "Ethernet problem"

Thu Jan 31 07:30:32 UTC 2008

Hello, Ian.

Thank you for your detailed explanation - it is very useful to know the way 
the stack works. Just it seems rather strange that packets are not queued, 
but have only one depth back log...

But, to my pity, this is not the problem in my case - I have 3s pause between 
sequential sends. 
I produced the printout with time information:

21:10:01.552784 arp who-has 192.168.50.133 tell 192.168.50.133
21:10:01.655041 arp who-has 192.168.50.57 tell 192.168.50.133
21:10:01.655067 arp reply 192.168.50.57 is-at 00:19:db:ed:16:94
21:10:04.656151 arp who-has 192.168.50.57 tell 192.168.50.133
21:10:04.656174 arp reply 192.168.50.57 is-at 00:19:db:ed:16:94
21:10:04.657101 IP (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
        Data:11111111111111111111 (must be 000000 !!! - packet lost)
21:10:07.656255 IP (tos 0x0, ttl 64, id 3, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
        Data:22222222222222222222

For some reason, together with missed arp also the first packet is missed!

If I make a pause of 7сек before opening the socket, then:

21:18:25.784785 arp who-has 192.168.50.133 tell 192.168.50.133
21:18:32.887687 arp who-has 192.168.50.57 tell 192.168.50.133
21:18:32.887716 arp reply 192.168.50.57 is-at 00:19:db:ed:16:94
21:18:32.888663 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
       Data: 0000000000000 !!!
21:18:35.888739 IP (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
       Data: 1111111111111111
21:18:38.889054 IP (tos 0x0, ttl 64, id 3, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
       Data: 2222222222222222222

But this works not always too!:
21:18:04.378562 arp who-has 192.168.50.133 tell 192.168.50.133
21:18:11.481686 arp who-has 192.168.50.57 tell 192.168.50.133
21:18:11.481716 arp reply 192.168.50.57 is-at 00:19:db:ed:16:94
21:18:14.482711 arp who-has 192.168.50.57 tell 192.168.50.133
21:18:14.482739 arp reply 192.168.50.57 is-at 00:19:db:ed:16:94
21:18:14.483658 IP (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
        Data: 1111111111111111
21:18:17.483039 IP (tos 0x0, ttl 64, id 3, offset 0, flags [none], proto UDP 
(17), length 74) 192.168.50.133.33100 > 192.168.50.57.33100: UDP, length 46
        Data: 2222222222222222222

On Thursday, 31 בJanuary 2008, Ian Caddy wrote:
> 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

-- 
            Dr.Leon M.Pollak
                Director
       PLR Information Systems Ltd.
Tel.:+972-98657670  |  POB 8130, H'Aomanut 9,
Fax.:+972-98657621  |  Poleg Industrial Zone,
Mob.:+972-544739246 |  Netanya, 42160, Israel.