OK, so here I am with a requirement to add Ethernet support to AGROS in the next few months, in support of Project Egbert.
No problem, right? I'd designed Ethernet into the Egbert hardware in anticipation of this; the LPC2387 has the MAC handily built in, so it's just a matter of adding a PHY with a suitably small footprint, plus a magjack. Then, of course, I need to write a driver, and integrate some FOTS (Freeware Off-The-Shelf) TCP/IP stack if there isn't time to write my own.
Well... I wrote enough of the driver to start testing it for basic functionality, i.e., confirming that it receives packets.
And indeed it does, after a few tweaks.
Trouble is... it receives all the packets. I played with the filtering options, if not eight ways from Sunday then at least half a dozen from Friday afternoon, and it persists in being in promiscuous mode, even when I resort to settings that should reject everything.
Thinking it might be a problem with the down-rev LPC2378 I was initially playing with, I switched to a board with a current-model LPC2387. Same result.
Now, here's the thing: normally, you'd set up the filtering options to pass perfect address matches and broadcast packets.
But... those are exactly the packets you'd see if you were plugged into a switch, rather than a hub. Most Ethernet installations these days are switched... but my lab has an old-fashioned hub, so anything plugged into it will see all the packets going to or from the lab PC and the little NAS that lives in the lab.
And so I come to wonder whether the filters on the LPC23xx Ethernet actually work at all, or if the subsystem has only been tested on switched networks.
If I were confident the end product would only be plugged into switched networks, I wouldn't worry about the interface being stuck in promiscuous mode, but it'll be getting installed in far-off places with unpredictable network characteristics.
Oh, well. Maybe I'll bother NXP tech support this coming week and try to get an answer. Or, I could try to corner somebody at the ARM Developer's Conference (or whatever it's called this year) next month. If all else fails, I can do an address compare on all unicast packets in the device driver.