direct ethernet server sets source MAC to bogus value

[DanielSank]

Using Wireshark on the new Windows7 version of redheatdos, we find that the packets sent from the direct ethernet server, when the FPGA server enumerates boards, have source MAC set to 00:00:00:00:00:00. This is obviously not the real MAC of NIC.

Aside: Interestingly, the FPGA server does manage to enumerate the FPGA boards (with the correct build numbers). However, when we next try to runt he PLL init command, the associated collect call on the direct ethernet server times out. The board bringup works too.

[maffoo]

You've crossed out the bit about the PLL failing; does that mean it works now? As for the source MAC address, I don't think that should matter. Unfortunately pcap does not reliably find MAC addresses for network interfaces. The server uses the MAC if it gets one, but if not it just nulls out the source MAC when sending. It will still capture response packets because it puts the NIC into promiscuous mode and only filters based on the source MAC of the response packet (the fpga MAC).

[DanielSank]

How does the switch know that 00:00:00:00:00:00 goes to the NIC if that's not the NIC's real MAC? I believe @ejeffrey already explained this to me last week but I've forgotten.

[DanielSank]

You've crossed out the bit about the PLL failing; does that mean it works now?

Yeah, we were doing something silly.

[ejeffrey]

Once the DE server sends a packet with MAC all zeros, the switch associates
that port with that address. I don't believe all zeros has any special
meaning (broadcast is all ones). It shouldn't matter, although if the
call to get the MAC address is failing, that concerns me that something
else is wrong.

On Wed, Nov 18, 2015 at 9:35 PM, Daniel Sank [email protected]
wrote:

How does the switch know that 00:00:00:00:00:00 goes to the NIC if that's
not the NIC's real MAC? I believe @ejeffrey https://github.com/ejeffrey
already explained this to me last week but I've forgotten.

—
Reply to this email directly or view it on GitHub
#268 (comment)
.

[DanielSank]

@ejeffrey according to my super sayan Google-fu skills, a MAC of all zeroes is not special.

if the call to get the MAC address is failing, that concerns me that something else is wrong.

We have a test rig mostly up and running now :D Props to @jrainbo for the PSU.

[DanielSank]

@maffoo do we close this as wontfix?

[maffoo]

Actually, I have a fix for this but I need to test it. It turns out the JDK itself has an interface for getting MAC addresses that bypasses pcap and takes core of the differences between platforms.

[maffoo]

So, I played around with this for a bit and it is possible to use the java.net.NetworkInterface class from the java standard library to get MAC addresses for interface cards on windows. However, the list of devices enumerated by that class does not match up with what pcap4j finds, and both the name and description fields of devices found by the two methods also differ, so there's no way to reliably tell which MAC goes with which pcap device. I've raised an issue about this with pcap4j (kaitoy/pcap4j#49) and pushed my code to the u/maffoo/de-cap branch in case anyone wants to play with this. But given that it doesn't actually affect communication with the boards I'm going to close for now.