Bizzare issue with a Linksys LGS116P "QOS" switch - fake MAC # related? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2021, 08:20:06 am
content: 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 #.

author: CJay
author_rank: Super Contributor
timestamp: August 07, 2021, 08:48:22 am
content: More likely it's just a bug in the Linksys firmware/hardware, you could probably find other combos of MAC address that fail.

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2021, 08:53:35 am
content: 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).

author: nali
author_rank: Frequent Contributor
timestamp: August 07, 2021, 09:47:39 am
content: I think that LSB=1 in the 1st octet signifies a multicast packet, so that's probably screwing things up.

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2021, 11:29:45 am
content: 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 6so yes the first byte is 00000001.Changing it to 2 fixes it!!!THANK YOU!

author: CJay
author_rank: Super Contributor
timestamp: August 07, 2021, 02:33:50 pm
content: Quote from: nali on August 07, 2021, 09:47:39 amBloody hell, yes, so it does

author: peter-h
author_rank: Super Contributor
timestamp: August 09, 2021, 06:03:12 am
content: The Q is why this breaks things with a switch which claims to do QOS, but works fine with any other switch tried.

author: fordem
author_rank: Regular Contributor
timestamp: September 07, 2021, 01:15:04 pm
content: Quote from: peter-h on August 07, 2021, 08:53:35 amThat'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.

author: peter-h
author_rank: Super Contributor
timestamp: September 13, 2021, 04:26:38 am
content: 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 thisispossible, 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.