EEVblog Electronics Community Forum
Products => Computers => Networking & Wireless => Topic started by: peter-h on August 07, 2021, 08:20:06 am
-
I am developing an embedded system which has ethernet (RJ45).
It is connected to a Draytek router, via a Linksys LGS116P 16-port switch. This is an unmanaged switch. No config.
Could not get DHCP to work. In fact the board was not seeing any incoming packets. But with a simple (Netgear) switch it worked fine.
I had the mac # set to something silly like 1 2 3 4 5 6. This is normal for development work.
Changing it to the mac # of a Lenovo laptop which worked fine on the same LAN (and then obviously disconnecting that laptop) made it work!
How is this possible?
Was the switch (it does QOS but there is no documentation on what it does) looking up the mac # on some equipment website, to work out what sort of device it was, and perhaps finding it wasn't issued to any equipment manufacturer?
Replacing the Linksys switch with a dumb Netgear one (actually just replacing the router-board portion of the LAN) made it work fine even with the fake mac #.
-
More likely it's just a bug in the Linksys firmware/hardware, you could probably find other combos of MAC address that fail.
-
What surprises me is that such a bug could exist. The switch isn't supposed to care about MAC addresses, other than to use them as an index into a routing table (or some such).
-
I think that LSB=1 in the 1st octet signifies a multicast packet, so that's probably screwing things up.
-
I was using
/* MAC ADDRESS: MAC_ADDR0:MAC_ADDR1:MAC_ADDR2:MAC_ADDR3:MAC_ADDR4:MAC_ADDR5 TODO DO THIS PROPERLY*/
#define MAC_ADDR0 1
#define MAC_ADDR1 2
#define MAC_ADDR2 3
#define MAC_ADDR3 4
#define MAC_ADDR4 5
#define MAC_ADDR5 6
so yes the first byte is 00000001.
Changing it to 2 fixes it!!!
THANK YOU! :)
-
I think that LSB=1 in the 1st octet signifies a multicast packet, so that's probably screwing things up.
Bloody hell, yes, so it does
-
The Q is why this breaks things with a switch which claims to do QOS, but works fine with any other switch tried.
-
The switch isn't supposed to care about MAC addresses, other than to use them as an index into a routing table (or some such).
That's incorrect - switching is all about MAC addresses, and which port they are connected to - and as far as routing tables go, switching is layer 2, routing is layer 3, so strictly speaking, from an OSI viewpoint switches don't route, and don't have routing tables, they have CAM tables, which are essentially a table that lists which MAC address is connected to which port.
-
Sure, but then how does QOS work (on an unmanaged switch)?
How can the switch decide which packets have priority?
One bizzare solution would be to do an online lookup on the MAC address of each device, to work out what type of device it is. Apparently this is possible, in the same way that you can check if a MAC address is a genuine paid-for one, rather than some random number; that is probably the only thing which stops a lot of chinese companies just generating MAC addresses since the risk of a collision on the same LAN segment is utterly negligible.