Closed sarcasticadmin closed 8 months ago
During mass flash mode , is it possible to configure the internface on the AP as a normal interface, i.e. without a VLAN.
Or do these things need to be able to flash in the field or something?
Configuring massflash without the added vlan stuff on top might be a more optimum solution.
I'll have to study massflash a little more and see exactly how it works....
masflash assumes that the routers are still configured from the last show, so their uplink port is a trunk with them looking for a DHCP address on one of two VLANs (the management VLAN for each building)
when it gets an IP address, the server then runs commands via ssh/scp to upload the new image to the AP and flash it. This requires that the AP have a known ssh key/password to allow this access.
Any requirement to reconfigure the interfaces defeats the purpose of the mass flash and would take us back to something similar to the prior version, which required booting each device with the reset held down to go into debricking mode (where they all would come up on the same IP, so could only be done one at a time)
David Lang
On Thu, 23 Mar 2023, Lee Hughes wrote:
During mass flash mode , is it possible to configure the internface on the AP as a normal interface, i.e. without a VLAN.
Or do these things need to be able to flash in the field or something?
Configuring massflash without the added vlan stuff on top might be a more optimum solution.
I'll have to study massflash a little more and see exactly how it works....
During mass flash mode , is it possible to configure the internface on the AP as a normal interface, i.e. without a VLAN.
Or do these things need to be able to flash in the field or something?
@nixinator its a good question and I initially thought about the backdoor interface we put on the device as a last resort: https://github.com/socallinuxexpo/scale-network/blob/master/facts/secrets/ar71xx-openwrt-show.yaml#L97-L101 However this too has a vlan :disappointed: additonally there all set to a static address so thats not really going to meet our needs.
As @davidelang points the other option would be to reconfigure them individually which is pretty time consuming.
I think massflah pretty close to what we need as-is. It just seems like a small order of operations that leaves the routing table in a broken state.
We should be able to add the route changes necessary to the ifup hooks for the interface in the live image.
One option to deal with both circumstances might be to set up a native VLAN on the mass flash switch in addition to the tagged VLANs and have mass flash interact with both networks.
It would add some small complexity to the DHCP server (might force us to abandon Rob's preference for DNSMASQ, which wouldn't be the worst thing IMHO), but it would allow mass flash to flash both tagged (already configured) APs and untagged (maybe not yet configured or somehow reverted to default configuration) APs in the same process. I'll discuss this in more detail with Rob.
It would add some small complexity to the DHCP server (might force us to abandon Rob's preference for DNSMASQ
massflash
doesnt run dnsmasq it runs on kea: https://github.com/socallinuxexpo/scale-network/blob/d695fc5f1121b4715a0b602508e4d0fe600a8d39/nix/machines/massflash.nix#L132-L165
autoflash
runs on dnsmasq :wink: : https://github.com/socallinuxexpo/scale-network/blob/d695fc5f1121b4715a0b602508e4d0fe600a8d39/openwrt/autoflash#L85
One option to deal with both circumstances might be to set up a native VLAN on the mass flash switch in addition to the tagged VLANs and have mass flash interact with both networks.
We would only really need 2 ports for this: one of the massflash
system and one for the router being flashed. Since the netgear WNDR3700v2 assumes a same IP in their low lever flash state. It would be a good idea though so we could have all the tools and capabilities in the massflash image
Native VLAN support for trunks really doesn't exist in our configuration management system. Adding it would be major surgery and involve adding at least one new directive to support that.
In general, I'm not at all a fan of native VLANs as I believe ports should either be tagged or untagged, but not both and no two vendors handle this mix in a compatible way (yes, we're homogeneous Juniper at the moment, but nothing says that never changes).
Also, if you do want to pursue a solution to this, let's open a new issue for it since this one is already closed and the dual VLAN thing is kind of orthogonal to the original issue.
Description
While using the massflash livecd and first associating it to another network, the user is unable to ping the flash network even after associating a nic via the addtobr
Currently you have to delete the existing default route
and add back one for only the massflash subnet(didnt have to add anything back the last time we ran massflash):Acceptance Criteria