Feature request: 802.11 ad-hoc mode

RouterOS General
1

I have a small full-mesh network, using OSPF for routing, where it would be useful to have all the nodes associate with each other arbitrarily, without any bridging or WDS. 802.11 ad-hoc fits that description nicely.

Right now, I can create a similar effect, by setting them all to AP mode with dynamic WDS, and then blocking all forwarding in the bridge firewall. This works, but ad-hoc would be simpler and lighter weight. Since everything gets routed at each node, the extra MACs carried by WDS are un-necessary, as is the overhead of having all the WDS links in a bridge that blocks everything.

Thanks for considering it,
–Eric

2

You know I was investigating something like this - I noticed you mentioned blocking forwarding in the firewall - why not just disable bridging completely and just use the dynamically created WDS interface directly with an IP address?

3

Due to the way MT enumerates WDS (and other dynamic interfaces), it does not usually retain referances to that interface. The IP, and other interface-dependent settings end up assinged to “(unknown)”, when the link is restablished.

Using static WDS would resolve the issue (settings are not gorked), but I want a more dynamic system. The less administrative overhead, the better.

–Eric

4

How about using scripting to auto-assign a new WDS link to an (unknown) interface IP address… Something like, initially creating say 8 subnets with no interface, and then as each WDS connects, it gets assigned a subnet, and then the IP address is enabled. At disconnection, it disables the IP address and of course it’s unknown again. I guess a bad link would cause major OSPF redistribution issues though.

But to ask about your setup now, how are your nodes communicating with each other - maybe I don’t understand OSPF, but wouldn’t each node need to have a IP pair to talk to each other (like this):

Node 1:
wlan1 10.1.1.1/24
wlan1 10.1.2.1/29

Node 2:
wlan1 10.1.5.1/24
wlan1 10.1.2.2/29

In other words, the 10.1.2.x/29 is a point to point IP route between nodes 10.1.5.1 and 10.1.1.1…? Or does OSPF basically remove the need to do that?

5

How about using scripting to auto-assign a new WDS link to an (unknown) interface IP address…

Could likely do it that way, but it seems overly complicated, and would generate unnecessary flash writes. It would also be more difficult for techs to understand.

I have another working, but unnecessarily complex, setup now (dynamic bridge-blocked WDS). But, my goal here is to reduce overhead and complexity.

I guess a bad link would cause major OSPF redistribution issues though.

Not too bad on a small, isolated, OSPF domain. Redistribution into the core would be bad, probably very bad.

OLSR would be a much better protocol for this sort of thing, but OSPF is the closest MT supports.

But to ask about your setup now, how are your nodes communicating with each other - maybe I don’t understand OSPF, but wouldn’t each node need to have a IP pair to talk to each other (like this):

Node 1:
wlan1 10.1.1.1/24
wlan1 10.1.2.1/29

Node 2:
wlan1 10.1.5.1/24
wlan1 10.1.2.2/29

In other words, the 10.1.2.x/29 is a point to point IP route between nodes 10.1.5.1 and 10.1.1.1…? Or does OSPF basically remove the need to do that?

Actually, you can use /32 PtP addressing under OSPF in NBMA or PtMP (not broadcast) modes, eliminating the need for multiple addresses per node.

I.e.:

Node 1:

Customer interface - 10.0.0.1/24 net:10.0.0.0
Mesh blocked-bridge interface - 10.0.0.1/32 net:10.0.1.1
Mesh blocked-bridge interface - 10.0.0.1/32 net:10.0.2.1

Node 2:

C - 10.0.1.1/24 net:10.0.1.0
M - 10.0.1.1/32 net:10.0.0.1
M - 10.0.1.1/32 net:10.0.2.1

Node 3:

C - 10.0.2.1/24 net:10.0.2.0
M - 10.0.2.1/32 net:10.0.0.1
M - 10.0.2.1/32 net:10.0.1.1

I actually use a different mechinism, where even when full-meshing fails, all the nodes have IPs within a /24, and run broadcast OSPF between them. This does lead to inconsistant OSPF views of the /24 itself, which renders that subnet fundamentally broken. In a large OSPF domain, this would probably wreck severe havoc; but in a small domain, “external” OSPF routes will remain functional. It makes for some strange (wrong) traceroutes, but it does work on a small scale.

No OSPF setup in a network like this will be fully stable, nor is the 802.11 coordination function (even in ad-hoc mode) a good protocol for this sort of thing. OLSR+TDMA would be much better, but I’m not holding my breath for either.

–Eric