any plan for a coordinated SSID switch from BroadbandHamnet to AREDN?
I've updated my nodes to AREDN, but changed the SSID to BroadbandHamnet to maintain functionality.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
We'll talk about this at our upcoming SDWG Meeting. Please join us.
Andre
Wish I could be there, I'll be out of town. Will the meeting notes be posted? Perhaps an audio recording can be made and posted?
I sure would like to see a good reason to even change the SSID in the first place...
Access control for groups that want an isolated network is one reason.
Personally (and this is a personal opinion) I belice that if you keep the default SSID you must consider your node an "open" system that lets anyone use it, while if you change the SSID you can be a closed system (or an open system)
Ideally all your local users work together, but I've seen some groups locally who insist some infrastructure is all Theres, must be a member etc, those groups would want to change the SSID in my opinion.
Another good reason is to increase the local training by being on a non default SSID this gives you a chance to reach and train users locally on local best practices rather than just all of a sudden seeing a node pop up. One common to this is I know several hams who do not believe you should ever have a mesh gateway on the network (I can agree in many cases though they can be useful sometimes) in this case they would likely want a different SSID so that any random user in the area doesn't just turn it on for the whole local mesh.
I can also see edge cases in highly populates metro areas that don't want to be one super large mesh but want to be multiple smaller meshes it could help. This may become more important if/when we put better network division tools in place you might have north and south nets, etc.
I have to disagree. I can certainly see why some groups might want to optionally change the SSID, e.g., for a small test network to keep others from joining it accidentally. Merely changing the SSID won't keep anybody out who wants to get onto your network, and they can inject any routes they want because there's no authentication on olsr. So if it's access control you want, there are much better mechanisms.
But this still doesn't explain the change in default SSID from BroadbandHamnet-20-v3 to AREDN-20-v3. Quite frankly, it seems gratuitous. It's been over a month since the nodes on Qualcomm WT switched to AREDN, and I still haven't seen anybody else (other than me) switch over so they can reconnect. I.e., the core of the network here has been broken for over a month and nobody seems to care.
I understand that some manual configuration of a new node is probably unavoidable, e.g., to set a callsign, but I strongly reject the idea of forcing people to reconfigure their devices just for the sake of proving they know how to reconfigure their devices. If this is supposed to be an emergency network, manual configuration must be kept to an absolute minimum. You won't necessarily have a knowledgeable ham in the right place at the right time to tweak something when the Big One hits. And whoever is there will want to use whatever he has on hand that stll works, which will almost certainly be some mix of amateur and commercial facilities. And the last thing he'll want to deal with are private address conflicts, NATs and firewalls, and any other obstacles to smoothly passing traffic between the ham mesh network in the disaster area and the regular Internet outside it.
That's one reason I like the idea of running olsrd on host nodes when possible so they can advertise their own addresses and services wherever you happen to plug them in, without having to reconfigure whatever you plug them into. I understand the concern about routing packet sizes but I believe this can be handled with features already in OLSR (e.g., the 'fisheye' feature). Right now I see a way to shrink these updates and the mesh routing table. Instead of giving each node two distinct IPv4 addresses, one for its wlan0 interface and the other for eth0.2, and a third if it's also supporting a HNA, just give it a single address in the 10.0.0.0/8 block that it uses for everything. If it has a HNA, have it use one of the addresses in that subnet as its only local address. Only if it's also connecting to a non-mesh subnet with its own address block will it need additional addresses.