MAC address of some OM2P units incorrectly listed in cloudtrax

[jmatwyko]

I have 10 OM2P units connect to a buffalo router fed by cable modem. I wanted to reboot several units remotely so I ssh to buffalo unit and then when I listed DHCP clients to gather IPs/mac addresses of AP units and compare them to IPs/mac in cloudtrax (a tedious job as OM2P node name isn't listed as hostname in DCHP list, instead hostname is listed as AP's MAC). This is when I found that 2 of the units mac address don't jive with cloudtrax.

From buffalo router dhcp list.

root@westerly-main:~# more /tmp/dnsmasq.leases

43200 ac:86:74:02:18:59 172.16.0.152 * 01:ac:86:74:02:18:59

43200 ac:86:74:02:12:09 172.16.0.46 * 01:ac:86:74:02:12:09

43200 ac:86:74:02:12:00 172.16.0.182 * 01:ac:86:74:02:12:00

43200 ac:86:74:02:12:10 172.16.0.137 * 01:ac:86:74:02:12:10

43200 ac:86:74:02:18:f8 172.16.0.195 * 01:ac:86:74:02:18:f8

43200 ac:86:74:02:11:f8 172.16.0.104 * 01:ac:86:74:02:11:f8

43200 40:a6:d9:8b:04:0b 172.16.0.226 Robs-iPhone-2 01:40:a6:d9:8b:04:0b

43200 ac:86:74:02:18:60 172.16.0.243 * 01:ac:86:74:02:18:60

43200 ac:86:74:02:12:b0 172.16.0.193 * 01:ac:86:74:02:12:b0

43200 e8:3e:b6:86:eb:89 172.16.0.118 BLACKBERRY-9A1E 01:e8:3e:b6:86:eb:89

43200 60:fb:42:47:73:ff 172.16.0.225 Megans-Ipod 01:60:fb:42:47:73:ff

43200 cc:55:ad:e7:c1:a0 172.16.0.191 BLACKBERRY-B01B 01:cc:55:ad:e7:c1:a0

43200 34:51:c9:bf:94:d1 172.16.0.83 iPad 01:34:51:c9:bf:94:d1

43200 14:8f:c6:d7:fa:e5 172.16.0.55 Bethans-iPhone 01:14:8f:c6:d7:fa:e5

43200 00:1d:e0:37:25:a3 172.16.0.28 PRI-CNU7503BTX 01:00:1d:e0:37:25:a3

43200 14:5a:05:a3:a0:e0 172.16.0.6 iPhone 01:14:5a:05:a3:a0:e0

43200 78:ca:39:7e:f4:f9 172.16.0.73 Pascales-iPhone 01:78:ca:39:7e:f4:f9

43200 00:1b:9e:2d:3a:47 172.16.0.115 john-PC 01:00:1b:9e:2d:3a:47

43200 58:1f:aa:09:4c:03 172.16.0.96 Angelas-iPhone 01:58:1f:aa:09:4c:03

43200 00:1e:65:76:bf:3a 172.16.0.151 FS34040L0003136 01:00:1e:65:76:bf:3a

43200 70:de:e2:76:f2:90 172.16.0.172 * 01:70:de:e2:76:f2:90

43200 ac:86:74:02:12:78 172.16.0.224 * 01:ac:86:74:02:12:78

43200 ac:86:74:02:18:68 172.16.0.94 * 01:ac:86:74:02:18:68

Comparison from Cloudtrax.

43200 ac:86:74:02:12:09 172.16.0.46 * 01:ac:86:74:02:12:09 dchp -> is actually AP10 with mac address in cloudtrax more node details -> AC:86:74:02:12:08

43200 ac:86:74:02:18:59 172.16.0.152 * 01:ac:86:74:02:18:59 -> is actually AP11 with mac address in cloudtrax more node details -> AC:86:74:02:18:58

Could this be type of problem be the source of problems such as in ticket #174 and/or related to crazy mesh routing in ticket #172

If not, then still the mac addresses labeled on some units are for the wrong interface it seems???

[marek]

Each OM2P has 2 LAN interfaces and each interface comes with a different mac address. The label on the OM2P contains the first and primary mac address.

[jmatwyko]

Yes I understand. 2 LAN intefaces and wireless interface all having unique MAC. I guess what I'm saying is the primary MAC listed on label on the unit is for POE lan port, correct? Yet, 2 of the 10 don't reflect this in reality> All units that are hardwired are connected to lan on POE port only. So either the decal on the unit is wrong or the primary and secondary ethernet ports have magically swapped MACs.

It would be easy enough to test this, connect lan to other port and power cycle the unit and see what the DHCP list contains.

I just wanted to be sure that this doesn't or isn't causing problems and it is really mostly just a display issue in cloudtrax.

[marek]

As far as I can tell cloudtrax shows the mac address you enter. Therefore I can't quite follow your thought of cloudtrax not displaying what it should display.

What you are saying is: The PoE LAN port does not use the primary mac address corresponding the label on the bottom ? If that is the case how can these nodes check into the dashboard ? The dashboard uses the mac address you enter to identify the node. If the mac address is not correct the node can't check in.

[jmatwyko]

"What you are saying is: The PoE LAN port does not use the primary mac address corresponding the label on the bottom ?"

Correct, only these two units MAC address labels don't match the MAC from that ethernet port i.e., DHCP from buffalo shows that MAC is not same.

"If that is the case how can these nodes check into the dashboard ?"

Good question. Maybe cloudtrax is ok with node checking in with either of the LAN port MAC addresses??

"The dashboard uses the mac address you enter to identify the node. If the mac address is not correct the node can't check in."

AP10 main building ground floor is checking in fine.

eth0 ac:86:74:02:12:08 -> MAC address on label -> entered in Cloudtrax when adding unit to network (assumed to be primary attached to PoE port) but its not.

eth1 ac:86:74:02:12:09 -> (actual physical PoE port) that is DHCP'ing address for unit (it is not the MAC address on label)

eth0 Link encap:Ethernet HWaddr AC:86:74:02:12:08

UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:4

eth1 Link encap:Ethernet HWaddr AC:86:74:02:12:09

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5998 errors:0 dropped:0 overruns:0 frame:0 TX packets:5473 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1875337 (1.7 MiB) TX bytes:805617 (786.7 KiB) Interrupt:5

See what I mean eth1 is doing all the work, it is the PoE port, it isn't the primary MAC listed on unit. eth0 is.

[marek]

Replying to jmatwyko:

"What you are saying is: The PoE LAN port does not use the primary mac address corresponding the label on the bottom ?" Correct, only these two units MAC address labels don't match the MAC from that ethernet port i.e., DHCP from buffalo shows that MAC is not same.

Ok.

"If that is the case how can these nodes check into the dashboard ?" Good question. Maybe cloudtrax is ok with node checking in with either of the LAN port MAC addresses??

No, it always checks in with the eth0 mac address. That is how the dashboard identifies each node. eth0 is considered the primary interface.

eth0 ac:86:74:02:12:08 -> MAC address on label -> entered in Cloudtrax when adding unit to network (assumed to be primary attached to PoE port) but its not. eth1 ac:86:74:02:12:09 -> (actual physical PoE port) that is DHCP'ing address for unit (it is not the MAC address on label)

I tunneled into your node to check. From the software's perspective it seems you are using eth1 (the non-PoE port). If you are absolutely sure that the cable is plugged into the PoE labeled port (the port next to the power port) then we have an issue. I can only imagine that either the label is in the wrong place or the hardware is incorrectly wired.

[jmatwyko]

I haven't looked at those units since I installed them. Both of the two units are located inside 11-12' high false ceiling, not easy to get to. It is possible that maintenance staff at hotel could have "rebooted" units, possibly disconnecting lan and power cable then reconnecting lan on wrong port.

I'll inspect them today and update ticket.

[jmatwyko]

Well its confirmed, maintenance people had indeed repowered and replugged units. Both were both into the non-PoE port!

So cloudtrax is ok with units checking in with MACs that are not the one on the label. It seems that the associated LAN partner MAC must also be included in the device list (somewhere some how). When you find out from Cloudtrax crew let me know.

Sorry for the wild goose chase. At least we learned something from this exercise.

thanks, Jeff

[marek]

Thanks for the update.

To clarify: Each node checks in with a couple of parameters to inform the dashboard about this and that. One of these parameters is the mac address of eth0 which is the mac address you entered to begin with. The dashboard updates its database entries according to the mac address but it does not know / see which of the ports has a cable plugged into.

When I read your bug report initially I got the feeling eth0 had the wrong mac address. If that were the case the node would not have been able to check in.