gluon-setup-mode: allow network-triggered activation

[blocktrron]

This commit adds the ability to Gluon's Setup-Mode to be activated using a magic packet while booting

Intention

Some Outdoor-Networking devices (Notably the ZyXEL NWA55AXE but also potential Extreme Networks / OCEDO APs) do not have a physical reset-button. Returning to setup-mode involves opening the devices case, attaching the serial console and proceeding from there.

This PR introduces a network-based activation process, where the device waits in preinit prior to setup-mode activation for a magic packet. When received, the setup-mode is activated for this power-cycle.

Implementation

The magic packet uses a custom ethertype and is sent with the LLDP Multicast ethernet-address. On proper networking equipment, this limits the packet scope to the domain of two devices and should not propagate over a switch. Combined with the activation window in preinit, this requires physical access to the device or the PoE Injector.

Usage

There are two c files located in the packet, one used in preinit by the target device and one for sending the magic packet.

Scope

This functionality is per-device specific. To be clear about this, a list of devices should be included in the documentation of Gluon's setup-mode where this activation method is supported.

This is intentional, as a generic invocation will (most likely) not work. Some devices use an internal switch which prevents the CPU from receiving this magic packet, thus breaking this feature.

ToDo

• [ ] Add python script to /contrib for setup-mode activation (C program is linux-specific)
• [ ] Switch board-platform detection to Gluons libplatform

[blocktrron]

Having dug deeper into this topic, it seems like you can not send raw ethernet frames on Windows using python but require to install WinPCAP.

Still, I'd like to keep the action radius of this feature limited to the physical point to point connection. Given that this is a "special" device-specific feature, I'd tend to suggest using a live-Linux distribution if necessary.

[herbetom]

I feel like people could confuse the gluon-enter-setup-mode command and the enter-config-mode binary.

[blocktrron]

enter-setup-mode is not accessible from the PATH on the device, so i don't see an issue with that.

[herbetom]

There were two ideas regarding this functionality at today's Gluon Meetup:

• for "scheduled" reboots, such as firmware upgrades, a flag could be set to disable the network triggered activation of the setup mode
• the node could activate setup mode as soon as it receives the packet, send a signal back to the user, and deactivate the setup mode flag after a timeout. This would require two power cycles as well as the packet to reach the node to activate the configuration mode

These are more "or" options, and it is probably not necessary to have both.

[blocktrron]

I dislike both concepts.

As outlined above, the packet is only transferred on the link and filtered at the switch.

So you need to a) have direct connection to the node and b) access to the power source.

I don't see a real attack vector for the already in-place requirements.

[herbetom]

The concern voiced on the Meetup was that Unmanaged Switches won't filter those LLDP Packages. (I've got no idea about that).

And then an attacker could take over a node once it reboots. On a Node with "Nightly" Firmware those reboots could take place quite often.

[blocktrron]

I see this scenario as extremely remote.

Even in case you flood LLDP packages over a switch, your threat-model implies an attacker already having compromised the Network the node is attached to. Looking at Gluons architecture, this is either the Uplink-LAN or another mesh-link.

The only thing i might be able to compromise on is the blocking on automatic upgrades. The reason for it being AVM introduced it to their newer models using TZ.

I however strongly oppose this proposal

the node could activate setup mode as soon as it receives the packet, send a signal back to the user, and deactivate the setup mode flag after a timeout. This would require two power cycles as well as the packet to reach the node to activate the configuration mode

This only introduces unnecessary complexity without really addressing a threat model apart from a crashing node.

[neocturne]

This only introduces unnecessary complexity without really addressing a threat model apart from a crashing node.

Could you explain what you mean? The idea behind the proposal was to prevent an attacker in the WAN network to use the reboot following an upgrade to take over a node by requiring two reboots in quick succession.

[T-X]

Another stupid/wild idea (but maybe it ain't stupid if it works?) came to my mind: There is another way to communicate with a node that is ensured to only work on a direct link: Changing the advertised link speed.

So one might be able to Morse(-like) a magic sequence via ethtool?

That contrary to LLDP would never propagate over a network, even with an unmanaged switch.

[kpanic23]

How about trying to detect a loopback plug?