You are here

DHCP Server Idea

25 posts / 0 new
Last post
KD0LIX
DHCP Server Idea

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?

 

KG6JEI
The thought crossed my mind

The thought crossed my mind in early development and quickly fell off because of many items making it non viable.

  1. The nodes often are running at power levels that exceed part 15 limits meaning that it would be in non compliance when it speaks to a Part 15 laptop. 
  2. Many nodes are now running in Part 97 only RF space to get away from part 15 interference on channel bandwidths and frequencies not supported by standard laptop builds.
  3. RF Jamming will occur as the node retransmits traffic coming in for the local laptop which causes the node to jam the RF.
  4. The node is identifying with its Part 97 Callsign meaning all traffic it works with generally needs to be Part 97 it can no longer speak to PART 15 devices over the air (the FCC has never had a case to my knowledge where it has allowed a single transmitter in operation at the same moment to be operated under two license classes) 
  5. Nodes will often be installed outside signal loss will be significant and in some cases absolute going through walls, in this case the recommended solution also is able to overcome this because of its use of a wire at one point in the equation.

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.

W2TTT
W2TTT's picture
Part 15 operation on 2.4 GHz

Conrad,
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

KD0LIX
>The thought crossed my mind

>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.

  1. The nodes often are running at power levels that exceed part 15 limits meaning that it would be in non compliance when it speaks to a Part 15 laptop. 
    1. All nodes(dedicated routers, laptops, smartphones) would have to operate in Part 97.
  2. Many nodes are now running in Part 97 only RF space to get away from part 15 interference on channel bandwidths and frequencies not supported by standard laptop builds.
    1. This could be the dealbreaker. Once you get to this level of configuration, you could probably stand up another mesh node or hardwire into one, or make the equivalent changes to add olsrd to a laptop.
  3. RF Jamming will occur as the node retransmits traffic coming in for the local laptop which causes the node to jam the RF.
    1. Is this worse than the jamming any node routing packets would cause(A->B->C)? Or do you mean in the case where the direct A->C path would normally be taken by mesh routers, but ignored by a laptop?
  4. The node is identifying with its Part 97 Callsign meaning all traffic it works with generally needs to be Part 97 it can no longer speak to PART 15 devices over the air (the FCC has never had a case to my knowledge where it has allowed a single transmitter in operation at the same moment to be operated under two license classes) 
    1. Clients would have to be Part 97 as well. I think we could support this with a single client-side-configuration(set your callsign as part of your hostname), DHCP Option 12(common on most clients), and a short DHCP renewal interval. We'd also have to verify that DHCP renewals still carry the Option 12 hostname information.
  5. Nodes will often be installed outside signal loss will be significant and in some cases absolute going through walls, in this case the recommended solution also is able to overcome this because of its use of a wire at one point in the equation.
    1. In that particular use-case, a wire would be best. But I think there's use-cases outside of that where connecting off-the-shelf laptops or smartphones is handy(Field day, debugging, connecting clients without a middleman, ...).
KG6JEI
Item 1) 

Item 1) 
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.

K7DXS
Item 1: a. Isn't that

Item 1: a. Isn't that analogous to CQCQCQ on HF? It's trying to find other hosts which will respond. b. I'm curious as to what exactly gets filtered out, and how it gets filtered out without interfering with things that could be useful.

But I do agree, get a WAP and hook that up instead.

KG6JEI
Yes and no.

Yes and no.

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

KD0LIX
I should've prefaced my post

I should've prefaced my post with a note that I don't intent to turn the mesh into a gigantic glorified AP, just a way to add a single, simple node

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?

KG6JEI
2a) more referring to legal

2a) more referring to legal on there are a lot of devices ou CAN'T modify and put the ability to go out of band without non RF related legal issues. iPhone for example you can't do this without jail breaking and the DMCA is iffy on Jailbreaking since it has in the past IIRC involved bypassing the cryptography, Ignoring the jailbreaking distributing the modified driver of its based on existing code could have issues of its own related to copyright law.

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. 

KD0LIX
>problem is for this to work

>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.

I'm not sure I get what you mean when you say AP connections. If we had a network topology of L1-A-L2(normally we would just use an AP for this, lets assume A has links to of other useful mesh nodes but unrelated to this paragraph), and we want to support a TCP connection from L1 to L2, L1's packets would be routed to A, which would route them to L2, and the same would be true for the reverse. L1 and L2 would've both gotten their routes from  It's quite similar to how an AP would work, but it would still be an Ad-Hoc network(you could even build this particular Ad-Hoc network without DHCP or even OLSR, but again, if that was your goal you would only use an AP and be done with it).

>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.

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.

KG6JEI
"I'm not sure I get what you

"I'm not sure I get what you mean when you say AP connections."
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.

KD0LIX
Each client IP could isolated

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.

KD0LIX
Turns out that while you can

Turns out that while you can locate each client in their own /32, traffic to 255.255.255.255 still hits the wire or Ad-Hoc network as a broadcast packet. And as excessive broadcast traffic isn't great for 802.11 performance(that whole slowest supported rate), I'll not be looking into this any further.

K6AH
K6AH's picture
I'm missing something here...

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?
 

WL7COO
WL7COO's picture
I too am missing something.

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.

KD0LIX
It would ease connecting off

It would ease connecting off-the-shelf hardware directly to any node the mesh, without extra hardware, with following the existing MAC->IP mappings. Your normal, non-meshable device would be mesh-routable by virtue of the closest, single mesh node it connects to.

K7DXS
The point is to connect wifi

The point is to connect wifi devices without extra hardware. But I agree just get a WAP.

K5DLQ
K5DLQ's picture
yes.  a $20 Ubiquiti

yes.  a $20 Ubiquiti AirGateway (and all the features it provides) and you're done.  No need to complicate the node.

KD0LIX
>What value you are gaining

>What value you are gaining in having these device use OLSR routing?

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.

K6AH
K6AH's picture
I'll ask again...

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

KD0LIX
> You can do that in one of

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!

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.

KD0LIX
Well, then you'd need $20 of

Well, then you'd need $20 of extra AP for every node. In effect, you'd be complicating the node by adding a second radio.

K7DXS
It's worth it because

It's worth it because otherwise the entire network would slow to a crawl. 

KD0LIX
Are you worried about the

Are you worried about the increased number of IPs that olsrd would have for routing(my biggest worry), the local jamming that traffic crossing a single node might cause mentioned above, or something else?

KA9Q
You wouldn't need to spend an

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.
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer