Hardware won't respond to each others ARP requests

Question

I have two pieces of hardware (embedded devices) that I have setup to communicate via TCP over Ethernet in a client/server fashion.

The topology of the network is as follows:

-----
| S ||=|== Debug PC (w/ Wireshark) 192.168.10.41
| W ||=|== Hardware 1 TCP Client 192.168.10.42
| I ||=|== Hardware 2 TCP Server 192.168.10.40
| T |
| C |
| H |
-----

When Hardware 1 try's to send packets to the server, Hardware 2, it sends out an ARP packet to get Hardware 2's MAC address first:

No.     Time        Source             Destination  Protocol Length Info
157 11772.776136 Microchi_13:c3:6a     Broadcast    ARP      60     Who has 192.168.10.40?  Tell 192.168.10.42

However, it receives no reply from the server, and then the server ARPs for the clients MAC a few moments later:

No.     Time        Source             Destination  Protocol Length Info
158 12183.800839 00:3f:2d:02:1a:35     Broadcast    ARP      60     Who has 192.168.10.42?  Tell 192.168.10.40

Which also receives no reply from the client. I am very confused.

I know that the Server is replying correctly, since I wrote a simple TCP Client in C# that could connect and send packets to the server from the Debug PC.

I'm not sure why my Hardware Client cannot communicate.

Thanks for your help in advance.

Details of ARP packets if needed:

From Client:

Ethernet II, Src: Microchi_13:c3:6a (00:04:a3:13:c3:6a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Microchi_13:c3:6a (00:04:a3:13:c3:6a)
    Type: ARP (0x0806)
    Trailer: 000000000000000000000000000000000000
Address Resolution Protocol (request)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    [Is gratuitous: False]
    Sender MAC address: Microchi_13:c3:6a (00:04:a3:13:c3:6a)
    Sender IP address: 192.168.10.42 (192.168.10.42)
    Target MAC address: Broadcast (ff:ff:ff:ff:ff:ff)
    Target IP address: 192.168.10.40 (192.168.10.40)

From Server:

Frame 158: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: 00:3f:2d:02:1a:35 (00:3f:2d:02:1a:35), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: 00:3f:2d:02:1a:35 (00:3f:2d:02:1a:35)
    Type: ARP (0x0806)
    Trailer: 000000000000000000000000000000000000
Address Resolution Protocol (request)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    [Is gratuitous: False]
    Sender MAC address: 00:3f:2d:02:1a:35 (00:3f:2d:02:1a:35)
    Sender IP address: 192.168.10.40 (192.168.10.40)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 192.168.10.42 (192.168.10.42)

What is the netmask in your case? Do you have any static routes defined in your device's configuration aside from the default route? BTW: you would not see any ARP replies as these are going unicast to the destination hosts - your switch does filter unicast packets to foreign destinations for your "debug PC". You could use a hub instead or enable the "monitor" or "mirror port" feature on your switch (if available) to get all traffic flooded to "debug PC's" port. — the-wabbit, Jul 08 '11 at 23:08
@syneticon-dj The netmask in this case is just: 255.255.255.0. I'm not 100% sure what you mean by static routes, but I have not added anything extra and just used default TCP settings. — Ryan R, Jul 11 '11 at 16:19
Thanks for your valuable comment. I didnt know ARP replies were unicast. That is why I wasn't seeing any response. But in fact is was connecting fine. You can add an answer and I will accept it if you like. — Ryan R, Jul 11 '11 at 17:20
I've expanded the text somewhat for better readability and inserted some reference links. — the-wabbit, Jul 11 '11 at 19:29

score 1 · Accepted Answer · answered Jul 11 '11 at 19:28

You would not see any ARP replies on your "debug PC" switch port as these are going unicast to the destination hosts. Your switch is filtering unicast packets to foreign destinations for your "debug PC". If you need to monitor unicast traffic as well, you could either use a hub instead of a switch or enable the "monitor" or "mirror port" feature on your switch (most managed switches do have something like this) to get all traffic including foreign unicasts flooded to "debug PC's" port.

Hardware won't respond to each others ARP requests

1 Answers1