Products > Networking & Wireless

Bizzare issue with a Linksys LGS116P "QOS" switch - fake MAC # related?

(1/2) > >>

peter-h:
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 #.

CJay:
More likely it's just a bug in the Linksys firmware/hardware, you could probably find other combos of MAC address that fail.

peter-h:
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).

nali:
I think that LSB=1 in the 1st octet signifies a multicast packet, so that's probably screwing things up.

peter-h:
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! :)

Navigation

[0] Message Index

[#] Next page