Wifi Mac aliases

[freifunk-bamberg]

Hi,
the Wifi Aliases list not work by us.
here an example:
Node primary Mac: e8:94:f6:90:bf:8c
Wifi Mac : 6e:87:70:c5:b4:20
Hopglass Alias entry: ea:96:f7:90:bf:8c|xxxx (e8:94:f6:90:bf:8c)

the wifi mac ist builded with:
nodeinfo.network.mesh.bat0.interfaces.wireless
-1 at last segment is 2,4ghz
-2 at last segment ist 5 ghz

i have try to change in hopglass server but it stop working

we use gluon 2016.2.1 with tunneldigger

here the raw json:
"network": { "addresses": [ "2a03:2260:300c:200:ea94:f6ff:fe90:bf8c", "fe80::ea94:f6ff:fe90:bf8c" ], "mesh": { "bat0": { "interfaces": { "wireless": [ "6e:87:70:c5:b4:21" ], "other": [ "4a:7d:0c:55:f9:a9", "6e:87:70:c5:b4:23" ] } } }, "mac": "e8:94:f6:90:bf:8c"

[ghost]

The way gluon calculates macs is different depending on the version the router was originally flashed. Sometimes the first bits are counted, sometimes the last. I don't see a solution right now. I will talk to Matthias on 33C3 about this.

[freifunk-bamberg]

OK, thanks for your god work

[anoymouserver]

Now the 33C3 is over .. Is there something new on this issue?

[ghost]

No news, I didn't have the time.

[jannic]

Different algorithms to calculate the macs wouldn't be too bad: We could just include all those values in the aliases file. Would increase the size of the file, but would work.
But: Some router models seem to just use the vendor assigned mac addresses on the wifi interfaces, instead of the gluon-generated ones. I see only one solution to that: Add model-specific code to the algorithm generating the alias file. Would be ugly and a lot of work :-( but I don't see an alternative, at the moment.
(Well, at least if it should be solved inside hopglass. One could, of course, add the assigned addresses to the nodeinfo reported by gluon.)

[ghost]

Not completely true: MACs with one algorithm overlap with the MACs of other routers generated with the 2nd algorithm.
I don't think gluon will send the data. But we do have the wifi mesh MAC addresses and the main MAC address, which could help determining the algorithm.

Also different "algorithms" just change different octets of the MAC.

[jannic]

Overlaps, really? Ouch... didn't observe those, by now.

But it doesn't seem to be true that only different octets are changed: I see both MAC addresses which differ from the primary mac by some bits (probably those are vendor-assigned addresses), and MACs based on md5(primary MAC).

[ghost]

Ok, we should probably collect a few examples here to get a better overview.

[jannic]

I'm currently just using the algorithm described here:
http://gluon.readthedocs.io/en/v2016.2.5/dev/mac_addresses.html
This resolves about 50% of the nodes I tried.

Examples where it didn't work:

On an Archer C5, primary MAC is c4:e9:84:ad:6f:c2, 2.4GHz MAC is c4:e9:84:ad:6f:c1 and 5GHz MAC is c4:e9:84:ad:6f:c0. So it's not md5 based.

On an TL-WDR4900, primary MAC is f8:1a:67:5a:b8:87, 2.4GHz MAC is f8:1a:67:5a:b8:86 and 5GHz MAC is 42:78:50:ba:f0:a0. md5(f8:1a:67:5a:b8:87) == "427850baf0a1..." so the 5GHz MAC is clearly based on the md5sum of the primary MAC, but the 2.4GHz MAC is not...

[ghost]

are these all running latest gluon?

[jannic]

They are running 2016.2.4. As 2016.2.5 only fixes a batman bug which doesn't affect our community, this should be close enough.