Return to Answer

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 yourself? Are you sure it's not a multicast MAC? Try 00:00:00:AA:BB:CC instead.

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.

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.

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 yourself? Are you sure it's not a multicast MAC? Try 00:00:00:AA:BB:CC instead.

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.

And finally, stupid question: are you sure your wifi device is not doing NAT or some kind IP routing? Because then it wouldn't forward ARP.

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.