search

labrad / servers

LabRAD servers
24 stars 21 forks source link

direct ethernet server sets source MAC to bogus value #268

Closed DanielSank closed 8 years ago

DanielSank commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

Yeah, we were doing something silly.

ejeffrey commented 8 years ago

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 notifications@github.com 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 https://github.com/martinisgroup/servers/issues/268#issuecomment-157957567 .

DanielSank commented 8 years ago

@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 commented 8 years ago

@maffoo do we close this as wontfix?

maffoo commented 8 years ago

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 commented 8 years ago

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.