Ignore tunnel interface on client

[Sebastian Roth]

@Jbob Lately we have seen those kind of weird MAC addresses in client logs (00:00:00:00:00:00:00:E0). Those seam to be toredo tunnel interfaces/MACs which don’t play any role for FOG imaging clients I suppose. Should we ignore those when enumerating interfaces/MACs on the client to maybe cause less confusion for users? What do you think?

[Tom Elliott]

While I agree it may be confusing, the MAC is filtered at the Server side. So while the logs may show these toredo tunnel adapters being passed, the FOG Server cannot use them anyway.

I don’t know how hard or easy it is to remove it from the C# side of the house though, so maybe @jbob can help us with understanding there (or lead us to the right path.)

[Wayne Workman]

The users should know it’s not even a valid MAC address, it’s too long. And if it doesn’t show up on the web server side, that should be clear right?

[Sebastian Roth]

But why should the client send invalid MAC addresses (even duplicate ones…)?? I think it’s wrong.

@Jbob How much effort would it be to filter out those too long non-MACs? I am willing to jump in the code and help out if time is short for you right now.

[Joe Schmitt]

@Sebastian-Roth Tom is correct, all mac filtering is done server side. While I could certainly add basic mac format checks ultimately there is no need. Not all mac addresses are six octets long such as the one you posted. From an implementation standpoint its better to have all mac processing happen at one location; if we need to patch that filtering, we only need to update 1 line of code instead of accompanying it with an additional client release.

I have done work with analyzing interfaces and detecting which ones are backed by physical hardware and it can be done with some know-how about win32 api, network interface registry entries are structured, and windows driver conventions (I have made a proof-of-concept before that was able to filter out all virtual adapters, including TAP drivers, virtualbox, vmware, and such). This is something I may provide in 0.10.0 due to its success rate.

However, I will not provide mac format filtering as that should be left to the server. The only filtering I may add is checking if its backed by detectable physical hardware. Even then, I may provide an option to disable my analysis in case of false-positives.

[Sebastian Roth]

@Jbob Thanks for your detailed answer. I agree that string filtering the MACs on the client is not wise! Shouldn’t do that. Detecting physical devices only sounds like a way better approach. See what you can do if you find the time and let me know if I can give you a hand.