0

Setup I'm trying to create would consist of lets say 5 devices, all connected to each other over wireless. At any point, you would be able to connect to any of those APs and ping any device in that network. Each AP would have their own DHCP server aswell.

To make it more interesting, have it all dynamic, ie any of those devices might drop off or a new one might be added.

A, E - clients.

B, C, D - APs and clients

WLAN1 - AP interface

WLAN0 - client interface

Example setup:

A(WLAN0) --- B(WLAN0,WLAN1) --- C(WLAN0,WLAN1) --- D(WLAN0,WLAN1) --- E(WLAN0)

Any recommondations what would be proper way to have them connected.

so far..

  • Wifi driver is rtl8723ds, bridging interfaces doesn't seem to be working.

  • Having a different subnet for each AP (device starts as client, scans network, chooses a subnet not in use before bring its AP up) - this seemed promising but, routing is turning into a nightmare..

Update: To add more details and clarify a few things.

  • Only have wireless interfaces available. WLAN1, WLAN0

  • An external device should be able to connect to an AP (or somehow over wifi), to see all devices in that network and send UDP packets to any of those devices.

  • Did play around with babeld ad-hoc/mesh protocol, but... Ran into quite a few issues though, had WLAN0 for babeld and WLAN1 for AP, so that an external device(eg smartphone) can talk to mesh. I was using hostapd for AP configuration.
    Issues came when AP was brought up - couldn't see any devices any more, ie the mesh was gone. Even needed to restart babeld on some random devices.
    Never managed to get DHCP to work for mesh nodes. Maybe because devices will be brought up in random order and the whole network will be brought up/down quite often. No static nodes..
    Did run some random tests, strange instabilites.. eg: left mesh running for the night and in the morning devices couldn't see each other anymore.

Update2: More details what is the end goal here.

Been stressing with this for some time now and think I've left out a few too many key details trying to explain the purpose of all this. Maybe there is a better approach.

Collection of small embedded devices, relatively close range, all connected to each other.
Only connection option is WiFi.
Some other WiFi enabled device(eg smartphone) must be able to connect to one device to send custom UDP data/identifying packets to all devices. Most logical solution seemed something like a button is pressed on one of those devices, which brings up an AP.
Nothing will be static, number of devices will change.

Babeld kinda put me off the mesh idea, but maybe batman is more promising. There isn't many more alternatives, is there..?
Connecting APs, clients, APs... and all that routing. More I look into it, worse it gets.

Update3:

batman with rtl8723ds driver - haven't been able to get module working. Keep getting Segmentation Fault, when trying to load the module.

Running into dead end once again..

1

The "proper" way to do it depends on the circumstances of your setup.

If you have a number of fixed devices installed that are connceted to each other via LAN, and that are also connected to the internet, than you want to use the totality of those devices as a distribution system with the same BSSID, and run an access point on each device. Which means you bridge the wlan AP interface and the ethernet interface (say, wlan0 and eth0) on each of those devices, and run a single DHCP server elsewhere (or on a single one of those devices). Adding more APs in the same way "just works", just as using any number of clients.

If, on the other hand, you have a number of devices you want to connect to each other via WLAN, then you need a mesh network. Which means you use a single WLAN interface on each of those devices either in "mesh" or in "ad-hoc" (IBSS) mode, and not as access points and client. You also have to specify your routing goals, i.e. if all of those devices always can see each other, or if you want to route between devices that don't see each other, etc. There are a number of mesh routing protocols for that you can play with.

Trying to create a mesh network out of a number of APs and clients is probably going to be ... interesting, and not something I'd recommend.

More details when you've updated your question.

Edit

I am still not completely sure about the scenario you want to implement.

If you want the following scenario:

  • A number of nodes ("routers") that mesh among themselves over WLAN, and where each node provides an AP. Optionally, some nodes can be connected to the internet.

  • A number of clients that choose exactly one of those node APs to connect to, and which possibly need to be isolated from the "node network" (need, not must)

then I would recommend an infrastructure similar to those used by the Freifunk initiative. They use batman for layer 2 routing, they have ready-made firmware for the "nodes" based on OpenWRT and Gluon (usually cheap routers with a single WLAN interface, if you have hardware with two WLAN interfaces, even better), and they connect local meshes via gateways (which you may not need). This is working successfully with local communities of hundreds of nodes and sometimes thousands of clients.

Babel with layer 3 routing is supposed to scale better for larger networks, and I know some people from Freifunk are working on that as an alternative to batman, but so far it's still buggy (which seems to match your experience).

If your scenerio is different and you want something else, please specify.

Edit

Yes, please add more information about the end goal, the picture is still not clear. Questions:

  • Why must the smartphone send identifying packets to all devices? Wouldn't one device be enough? What kind of answer/interaction to you expect from the devices?

  • Why is there suddenly user interaction ("a button must be pressed")? Is that needed for authentication? What would go wrong if a smartphone could just send identifying packets at any time? Possibly with a pre-shared key the smartphone app user has to enter?

  • Do you have any kind of security considerations? Do the nodes have to authenticate each other? Does the smartphone need to authenticate itself to the nodes? To one node? To all nodes? Secutiry considerations are important, please make them explicit, and complete.

  • What are the requirements for the client (smartphone)? If it's a smartphone, are you restricted to running an app (so the smartphone must connect as STA via an AP)? Or can you fiddle with the network settings? Any other kind of clients hat are expected besides smartphones?

Anyway, from what I've understood so far, what about the following:

  • All nodes implement a batman mesh via IBSS on wlan0, and an open AP on wlan1 (no encryption). The AP (wlan1) is bridged to the batman mesh (bat0). There's a single DHCP server for the complete mesh which assigns IPv4 addresses. Or, if IPv6 can be used, link-local IPv6 addresses are enough.

    This means we have an open, unsecured transport layer for all devices, which is basically a single LAN segment. All security protocols must be implement atop this layer.

  • All nodes run some demon for interaction. Nodes authenticate against each other via UDP broadcasts.

  • A client (smartphone) connects to any of the APs using the normal procedure. On the smartphone there is an app with authenticates itself to all nodes via UDP broadcasts. From then on, it can interact with one, several or all node demonds via UDP unicasts (or TCP, or whatever).

And yes, distributed networking applications are difficult... you don't "just quickly write" those.

And batman is completely independent from the WLAN driver that is used. Make sure you pick a batman version that's recent enough for your kernel version, the compile the kernel module and insert it. You should get a bat0 interface, and then you use batctl to add mesh interfaces.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.