Currently, I connect my laptop directly to the mesh. Since I run Linux, I have a network-manager script set up to configure my IP and start olsrd on connect. However, I also have a tablet and a phone that do not run OLSR, and would love to be able to connect them directly as well. So, here's my idea.
If each AP ran a DHCP server on their wireless interface, we could support devices without OLSR support. The DHCP server would need to support the last-three-octets-of-mac-to-last-three-octets-of-ip conversion, as well as advertise a single route for all 10.*.*.* traffic, through the AP. This would create a limitation where roaming would not be supported until the client renewed its DHCP lease, although the lease times could be kept small to facilitate hopping to the next node.
What do you think? Is this feasible?
If each AP ran a DHCP server on their wireless interface, we could support devices without OLSR support. The DHCP server would need to support the last-three-octets-of-mac-to-last-three-octets-of-ip conversion, as well as advertise a single route for all 10.*.*.* traffic, through the AP. This would create a limitation where roaming would not be supported until the client renewed its DHCP lease, although the lease times could be kept small to facilitate hopping to the next node.
What do you think? Is this feasible?
The thought crossed my mind in early development and quickly fell off because of many items making it non viable.
It is much better to put an AP locally on a non ham RF channel that can speak to the local users. This can be mounted indoors/outdoors as needed and can perform actions needed to allow content. In addition users connected to this device can share content internally at full RF rate without limitations on content exchanged between them.
The Ubiquiti AirGateways have been picking up a lot of attention, they are small, portable, and fit onto the power injectors.
Intermingling of Part 15 and 97 operations is such a complicated question, that I would recommend invoking the first rule of regulatory interaction taught to me by that old sage, Paul Rinaldo, W4RI in the pre-AX.25 days of packet radio wherein he intoned, "Never ask a regulatory question for which you don't have an answer with which you can live."
Let me take your suggestion one step further and suggest that Part 15 APs be put on high channels to get their noise as up and away from the AREDN-based Part 97 mesh channels.
73,
Gordon Beattie, W2TTT
201.314.6964
>The thought crossed my mind in early development and quickly fell off because of many items making it non viable.
I think there's only one item below that could make it non-viable; the others appear doable.
Technically yes you cold move everything over part 97 however there isn't as easy as you might thing. To start off with there is actually a lot of laptop traffic the nodes by the way they are designed filter out, lots of broadcasts between computers known as self discovery and "network broadcasts" this is traffic that may not qualify under the Part 97 one way traffic exception. This is traffic for file shares for local windows PC, media center finding, printer discovery. All very useful features on a LAN, very unuseful for HAM bands.
2) This isn't just an OLSRD problem is a driver problem and in the case of some operating systems it's even a legal problem. Standing up an AP you can accept everything from laptops to phones to tablets.
3) let's assume 4 devices device A is your local mesh node, B is a remote mesh node, C is even further and can see B but not A and L1 is your laptop and L2 is another laptop. When L1 wants to talk to L2 it has to go through A , when A transmits L1's packets to L2 A takes up (Jam's) B's Receicer because it's on the same Frequency. B can now no longer hear C whIle A transmits and C's information ends up getting lost (lowering LQ) this already happens as mesh nodes transmit to each other but at least in that case it's only information that had no other choice but to go through the mesh , in this case L1 and L2 if on different frequency through a real AP they wouldn't interfer as much with their local traffic. BTW the broadcast packets I mentioned in 1 come back again, mesh nodes already filter these out, an AP wouldn't.
4) interesting suggestion, not sure if it qualifies or not as identification but interesting argument would require thought.
-- this brings up a sub question: requirement of OLSR and self addressing are two things that make the mesh a willful item to join one would have to take action (load up ham only software or take time to discovery the protocols and activity force themselves into the mesh. How would you keep PART 15 users from joining your node? You can't use normal WIFI WPA2 protection because of Part 97 regulation it's now a device that is open to every neighbor to join the mesh
5) same as sub comment above really how to keep all those devices part 97 in a controlled fashion as they talk to each other and make sure they all have callsigns set and keep the guy across the street from joining on just by opening their laptop. Some devices join the first unencrypted network they can find.
But I do agree, get a WAP and hook that up instead.
Local LAN discovery is for items that are intended to be used by computers on the same home network. Most devices don't intend to have to try and work across multiple router hops. It's more like shouting CQ while the mesh node would be radio transmitting a CQ.
Mesh nodes act as routers, routers naturally filter out all broadcast packets and prevent it from passing through. If routers didn't do this the Internet wouldn't work
1) Good point. DHCP traffic(the core idea of this extension) itself might even fall under that.
2A) No more of a legal problem than not transmitting out of band on any other band, right?
2B) Standing up another AP still seems like overkill when trying to connect a single laptop or even a wifi-enabled microcontroller as you might have in a weatherstation.
3) - For broadcast packets, I'd expect the mesh node wouldn't route them, just as they are now. I don't mean to utilize a mesh node like an AP to connect two clients that are near each other(although it could). For the L1->A->L2(and accidentally jamming B) use-case I agree you'd be better off using a separate AP, or just forming a direct Ad-Hoc network connection. But, this use-case could also be L1->A->B->C->L2, where A->B->C could be any number of mesh routing nodes, and it would still be handy to skip having an additional AP for each L<->Mesh link.
4A) "How would you keep PART 15 users from joining your node?" How do we currently? For DHCP though, we could require a specifically formatted callsign as the hostname in the DHCP options. This seems better than analog repeaters that just share a tone.
4B) "You can't use normal WIFI WPA2 protection because of Part 97 regulation it's now a device that is open to every neighbor to join the mesh" If I had 802.11 to do over again, I'd add a signed, cleartext mode, somewhere between WPA2 and open networks, for exactly this purpose.
5A) "how to keep all those devices part 97 in a controlled fashion as they talk to each other..." That would, as always, be up to the individual operators.
5B) "...and keep the guy across the street from joining on just by opening their laptop." I think lots of folks avoid ad-hoc networks since they're usually printers, or some other internet-less device. I'm not familiar with internet interaction with the mesh, but if it ended up providing free internet to anyone in RF range, that would be bad news. So I agree this is a valid concern worth solving.
5C) "Some devices join the first unencrypted network they can find." What devices do that?
2b) you may be thinking one device but when I look at code I tend to need to look for worst case scenarios to be able to prepare for that. On top do that I had users tell me they would only want one maybe two devices on their AP, the next thing I know I'm getting a call "how can I increase how many users can connect to the AP? Half of city hall tried to join it during our last drill". I have to look at this from worst case angles to help ensure AREDN stays sound and strong as it goes forward.
3) problem is for this to work you really need it to be an AP. Once two devices are attached one could be on the left side of the node the other the right side, the node is the only device to link them and this is handled under AP connections. In addition as noted when evaluating features need to look to worst case scenarios while your example L1-A-B-C-L2 wouldn't be as subject to the issue in ways it's actually just as bad when A transmits to L1 it Jams B with information B had just sent it that easily could be moved to a different frequency.
4a/b) at the moment as noted it's controlled by the fact it takes an active configuration to join, unlike this proposed method that an "off the shelf" device be able to join. Requiring the DHCP server to authenticate the call would add a small level of this yes. Subnote though: served agency user doesn't have the ability to change the computer name this woildnt work. I also know a ham locally who user a work laptop and same thing. An AP doesn't have these issues making it more flexible.
5c) I've had laptops with vendor software do this, believe I've had android devices do this. Looking at my iPhone it doesnt look like it will do this off hand but it will ask you to join the first unencrypted network and you just have to say "yes" and it connects.
Because for this to work seamlessly for local users and be of any real use it needs to be an AP connection not an adhoc connection to be assured of best device support (there have been reports in the past of some Android devices that don't have an ADHOC stack in the kernel or those that do where it is broken-- refer to OLSR group about this). In addition to get around device security it would need to be an AP connection on its own virtual interface (similar to a vlan) for routing and firewalls to work well.
"Assuming we were to augment each laptop with its own ethernet-connected mesh radio, call them Z for L1 and D for L2, and add parens to denote a local LAN, if the topology were (L1-ethernet-Z)-A-B-C-(D-ethernet-L2) radio-jamming-wise, wouldn't this be the same problem where A->B traffic jams Z, and C->D traffic still jams B? At least for this admittedly simple topology, it's still 5 radios, regardless of frequency. I do agree that if one end had multiple laptops, then it might make sense to have them all behind only a single mesh."
Except
1) a mesh node would filter broadcasts which removes some traffic which helps. -- Even if we somehow added this as an extra filter into the device this would decrease the usefulness of this feature compared to running a real AP with dedicated AP firmware.
2) This sort of setup is ALWAYS advised against, people use to do this in the BBHN days put a mesh node outside and a meshnode indoors, this is VERY POOR AMATEUR RADIO practice and is to be frowned upon when other alternatives exist, like using a real AP and moving to a NON MESH rf channel way up in the Part 15 band.
Believe me I gave this discussion SERIOUS consideration before I walked on it because I know just how poor this is and how much more efficient, better supported, etc it is to run an external AP.
Why should a mesh node do something poorly when for 20$ it could be done perfectly?
And remember all these example shave equally bad sub examples where node B is jamming A and C (which then jam's its neighbors, etc). all this going on at once.
IF 20$ is too much to keep the setup uncomplicated I'm sure you can also pick up Linksys nodes on the used market from hams who are getting rid of them to replace with Ubiquiti (I have even seen some hams give away their Linksys devices to make room for the Ubiquiti's with airgateways)
Subnote: Keep in mind we also have already deprecated the AP mode because we want mesh nodes focusing on being mesh nodes
In the end its just not viable from every standpoint I can see, the feature as described increases load, decreases RF efficiency, increases vulnerability potential, and takes focus away from mesh nodes being mesh nodes. A real AP is far more flexible off a node then this feature ever could be and our tradition at AREDN is to build strong reliable solutions which this could never fit into.
Each client IP could isolated in its own /32 subnet, so there shouldn't be any broadcast traffic.
Edit: I'm not sure that's really feasible.
I'm missing something here... Why would you not simply connect a simple WIFI Access Point to the mesh node LAN? This is supported and used extensively as a deployment technique to connect laptops.tablets, cell phones, etc. What value you are gaining in having these device use OLSR routing?
I always perceived delivering 'standard', if not Internet connected, 802.11 wifi as one of AREDN's most desirable attributes.
Admittedly, the discussion of if/how/where and under what circumstances any of that traffic would be transmitted beyond other Nodes, similarly served w/standard wifi, into the Internet is a more interesting discussion but for initial, new 'island' planning purposes clarity about the simpler question seems essential.
You could route them over the mesh, so potentially you could hook two wireless VOIP phones directly to the mesh, on different sides of town, and the could call each other.
You can do that in one of the phone's standard protocols, 802.11 WIFI. No fussing with the phone's software... People can bring and use their own. Oh, and did I mention... people can bring their own laptop computers as well, because they support the same protocol!
Again I'll ask... why would you force them to all be upgraded to route OLSR unnecessarily? For under $20 a site you add all of that compatibly. In the chaos of a disaster support scenario, I'll trade $20 for the reduced support burden.
Andre
Yes! That's exactly what I want! I just think every mesh node could do it. If they should is a question discussed in another branch of comments above.
>Again I'll ask... why would you force them to all be upgraded to route OLSR unnecessarily? For under $20 a site you add all of that compatibly. In the chaos of a disaster support scenario, I'll trade $20 for the reduced support burden.
Oh, I'm sorry - I must not have explained that clearly enough. As part of the DHCP server changes, the mesh nodes would advertise a single route to itself, for the rest of the 10/8 network, to any DHCP clients. The only requirements for an end device would be support of 802.11 Ad-Hoc WiFi, a DHCP client, other normal routing support, and whatever we want to do to prevent access to non-hams.
You wouldn't need to spend an extra $20 on every node, because not every node would have local users who could use a local access point. And access points are already so common that you may already have one that you can use. This was true for my house when I put up a mesh node.
I'm with Conrad on this one. Client-mode WiFi operation is much more widely used than ad-hoc mode, and is therefore better supported on your average user device. Also, efficient radio networking is all about careful frequency management. More channels are always better than fewer channels.
It's especially important to isolate short- and long-range traffic on separate channels, as shown by the longstanding practice in mountainous areas like California to have separate "low level" and "high level" repeater frequency pairs.
WiFi managed mode (aka base station or access point mode) is also better than ad-hoc mode at managing interference because the clients transmit only when polled by the access point while ad-hoc mode is pretty much a free-for-all, though there is a collision avoidance scheme that provides some limited benefit (hold off when you overhear somebody solicit a transmission you might not hear directly). In fact, I question the use of ad-hoc mode even within the AREDN network itself; I think the choice is not at all clear and is worthy of some serious experimentation.
That said, there's no reason why you can't still run OLSR on your end-user device, eg., to provide mobility with a fixed IP address as you move around the network, even if its radio operates as a WiFi client through a conventional access point. You'd have to deal with some minor details involving VLANs when interoperating with an AREDN node over Ethernet, but that's no big deal.