ARP message to enc28j60

Question

I have made the driver for enc28j60 for LPC1788 and I'm trying to send UDP message to LPC via wifi enabled device (iOS, windows over wifi). But transmission fails. Wifi device sends the ARP request. LPC sends the response, but it doesn't arrive. I have checked the ARP cache on windows machine and it stayed empty. When I do the same with cable connected machine, it arrives correctly, ARP cache is populated. That concludes that ARP response is sent and it is correctly built.

I have tried ping as well and same thing, every device that comes via router failed to get ARP response, but devices that are connected by cable receives the ARP response.

But, same enc28 board is working fine with Arduino. Arduino implementation of driver and ethernet was not done by me.

That means that it is somehow related to the driver. I have either forgot to switch some option of enc28 chip or ...

I have looked at Arduino driver but I could not find any obvious error in my implementation.

Any idea what could be wrong?

UPDATE:

I now have Wifi router with tcpdump installed on it. I have run it and sniff the packets from Wifi to Arduino (everything is fine there. ARP request, ARP response and Ping echo/reply can be seen in trace). When i start Wifi to LPC i only see ARP requests. Although it says that few packets are received by the filter, but i cant see those packets in dump file. Is there any option on tcpdump to see raw data ?

What I can see when use tcpdump with "-i any" option, is my lost arp response. But it looks fine to me.

ARDUINO

ARP Request
0004 0001 0006 d89e 3f87 3ad5 0000 0806
0001 0800 0604 0001 d89e 3f87 3ad5 c0a8
0564 7069 692d 3031 c0a8 0508

ARP Response
0003 0001 0006 7069 692d 3031 0000 0806
0001 0800 0604 0002 7069 692d 3031 c0a8
0508 d89e 3f87 3ad5 c0a8 0564 0000 0000
0000 0000 0000 0000 0000 0000 0000

LPC

ARP Request
0001 0001 0006 d89e 3f87 3ad5 0000 0806
0001 0800 0604 0001 d89e 3f87 3ad5 c0a8
0564 0000 0000 0000 c0a8 0507

ARP Response
0003 0001 0006 891d dc9f da6e 0000 0806
0001 0800 0604 0002 891d dc9f da6e c0a8
0507 d89e 3f87 3ad5 c0a8 0564 0000 0000
0000 0000 0000 0000 0000 0000 0000

I dont see any differences in the response from LPC (which doesnt work) and one from Arduino (which works).

Could it be some kind of timing issue ?

LPC

11:39:05.194814 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.194889 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.195001 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.194814 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.195537 arp reply 192.168.5.7 is-at 89:1d:dc:9f:da:6e (oui Unknown)
11:39:06.194815 arp who-has 192.168.5.7 tell 192.168.5.113
...

Arduino

11:42:27.712993 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.713068 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.713180 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.712993 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.714049 arp reply 192.168.5.8 is-at 70:69:69:2d:30:31 (oui Unknown)
11:42:27.714141 arp reply 192.168.5.8 is-at 70:69:69:2d:30:31 (oui Unknown)  
11:42:27.767303 IP 192.168.5.113 > 192.168.5.8: ICMP echo request, id 56841, seq 0, length 64 
... 

Answer 1

In general, to have any kind of meaningful insight into what happens, you'll need a way to examine the packets on the networks. Both between the Ethernet gadgets and the Wifi AP, and between the Wifi AP and the PC(s) connected to the Wifi network. On the PC(s), you can run a network traffic analyzer to watch the traffic seen by that PC, but your Ethernet gadgets probably don't have enough resources to provide a meaningful traffic dump. In that case, you'll need some kind of Ethernet sniffer between the Ethernet gadgets and the Wifi AP. The easiest solution is usually an Ethernet device capable of tapping the traffic (a plain old Ethernet hub, or a manageable Ethernet switch configured appropriately), and a PC connected it to receive the tapped traffic, and analyzing it with a network traffic analyzer (a software like Wireshark, for example).

Then you should examine the differences between the ARP requests coming from a PC directly over the Ethernet LAN, and those coming from a PC over Wifi, bridged to the Ethernet LAN. These requests will differ (for example: the Wifi AP will put its own MAC address into the Ethernet header). Also, you could examine the 'good' replies from your Arduino and the 'bad' replies from your box to see the differences.

Answer 2

It's a bit hard to remote-debug this. You absolutely need to look at the frames in wireshark. Use 'tcpdump -s 9999 -w dump.cap' to record a pcap file.

Classical bugs of home-grown MAC drivers:

• Forgetting to pad frames to 60 bytes. Result: frame may be dropped by the receiving MAC because of undersize.
• In the IRQ handler, reading only one frame from the MAC queue, instead of reading the whole queue. Result: frames may be delayed (by several seconds) until another frame arrives.
• When copying data to/from the MAC word by word, pay attention to handling of an odd number of bytes. Otherwise the last byte may get mangled.
• Endian confusion. Usually, everything is big endian (network order). It's easier to avoid mistakes if you assemble your frame byte by byte, rather than casting from integers or structs.

PS: have you chosen the MAC address yourself? Are you sure it's not a multicast? Try 00:00:00:AA:BB:CC instead.