Author Topic: No responce from ARP  (Read 8031 times)

Offline akorud

  • Newbie
  • *
  • Posts: 31
    • View Profile
No responce from ARP
« on: November 25, 2008, 12:28:02 PM »
Hi,
during long time I've observing strange situation: randomly you have no response from ARP. What I mean - initiating UDP communication (either TFTP of raw) from the device - neither frame is sent, no ARP_RESOLVED or ARP_RESOLUTION_FAILED event is received. Just nothing happens.
The problem is that it happens randomly and I have no idea how, what and where check or debug.
Any ideas?

Best regards,
Andriy Korud

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: No responce from ARP
« Reply #1 on: November 25, 2008, 02:56:24 PM »
Hi Andriy

When a UDP frame is sent there are two possible cases:
- a) the destination address/MAC combination is known (is in the ARP table) and the UDP frame is sent immediately
- b) the destination is not in the ARP table and so ARP resolution is started.

In the first case there will be one UDP frame transmitted with no repetitions. If there is a collision on the LAN the frame may be lost if the Ethernet mode is not correct. Check that you are either using auto-negotiation (which should be right) or a fixed speed without duplex setting (unless you are connected directly to a PC). Assuming the Ethernet settings are correct this frame should always appear on the LAN.

In the second case ARP should send a resolution request. This is repeated a few times and the, either after an answer, or after several tries, the owner of the IP frame is informed of the result. If ARP is trying to resolve you should see the request (and possible repeats) on the LAN.

Can you please verify which of these 2 cases it is and check the LAN settings to be sure that no tx loss will occur when LAN collisions take place? If you can confirm the case which it is, I can give you some ideas about looking deeper.

Good luck

Regards

Mark

PS. I don't work a lot with UDP frames but I did notice that in some circumstances switches can get overloaded when fast UDP frames are sent. Some of them just disappear in the switch... this may have been a bad switch (it was rather old...) but it made debugging over a UDP connection quite difficult. With TCP frames there was not this problem (due to the automatic flow control in the protocol).