6

I have multiple raspberry pi 3 model B boards with an external wifi adapter attached to them. My purpose is:

  1. Create a mesh network of RSP devices.
  2. Each RSP board should have their own AP and clients (mobile/laptops) can be connected to it.
  3. Clients of these AP can be moving around different RSP device range and still should be able to talk to each other no matter which AP they are connected to (like they are connected to a single network)

To fix #1: I used batman-adv on the internal wifi interface (wlan0) of RSP3 and now all the devices can ping each other through their virtual bat0 interfaces.

For #2: I used the external wifi adapter(wlan1) and with the help of hostapd and dnsmasq, I can run the AP (same ssid and channel on all AP) on each of the RSP board. I have also connected few mobile devices in different APs now.

My main blocking issue is objective #3:

To solve this, I tried to create a bridge between wlan0 and wlan1 interfaces with bridge-utils tool. But in RSP, both the interfaces do not support WDS module. So till now I am unable to make a single network for all the clients. I also tried to use IP forwarding between wlan0 and wlan1 but I cannot ping the connected clients from other RSP devices.

Is there any other approach (other than WDS) to create a single network for all the connected clients?

4

There are a couple of things that need tweaking to get this to work.

  • First, you shouldn't have every RPI's wlan1 AP be on the same channel because it will cause significant interference between them.

  • You also shouldn't need to use WDS. See this explanation for more information about this. Just be sure that each AP has the same SSID, WiFi security type, and the same password.

  • You have the right idea in that you need to create a bridge between wlan0 and wlan1 on every RPI. I'm not familiar with bridge-utils, but it would probably be better to just follow the instructions on making a bridge in the batman-adv documentation here.

Another thing to note is that you probably don't need to be running dnsmasq for DHCP services. Your clients could just use their automatically assigned link local IPv6 addresses to communicate with each other over this wireless LAN.

EDIT: My mistake. It sounds like making a true bridge using wlan on RPI3 isn't supported. It looks like there's a potential workaround using NAT here. It also may be possible if you connect two external WiFi adapters that support bridge connections.

3
  • thanks @davekats for the quick response. i will implement your 1st 2 points and update you the result. for the 3rd suggestion, I have already tried to create bridge between bat0 and wlan1 while in the quick guide example they have mentioned bat0 and eth0 (ethernet) port to connect a single device and not wireless interface which could be an AP connecting other clients. However, creating bridge between wlan1 and bat0 fails in RSP with error: Not Supported(-95). Aug 11 '17 at 9:47
  • @MaheshJena my mistake! I'll edit my answer. Sounds like there's no true bridge solution for wlan using the RPI 3's built in wireless interface.
    – davekats
    Aug 11 '17 at 19:25
  • @MaheshJena Can you please update.. were you able to implement wifi roaming / handovers on rpi? Jan 21 '19 at 7:14
3

You havn't said anything about IP configuration, and IP configuration is precisely what you need to address problem #3.

Choose your IP plan carefully

Your whole network will have a "general IP scheme". For instance, a lot of networks use 192.168.*.*.

You can use any IP private space, both in IPv4 and IPv6. Make sure it would not collide with any other networks your users or RPis might be connected to.

For instance, let's say we will use the global network 172.17.*.*. Note that the "all-zero" (172.17.*.0) and "all-ones" (172.17.*.255) addresses are reserved (i.e. not usable) in a network and all its subdivisions.

We will have to subdivide this big network into smaller networks that every RPi will use independently. One of the subnetworks will be used for communication between the RPis, for that we will keep 172.17.0.* for ourselves. We could use another number, but using 0 makes it easy to configure the Pis with a script.

The "public" part of the network will use the IPs 172.17.xxx.* where xxx is unique to each RPi. Again, to make it easy for a script, we start at 1, and increment.

The RPis need an IP in both networks. For the public network, it's best practice to use .254, so it will be 172.17.xxx.254. But what about the central network? The RPi will be used as a gateway to network 172.17.xxx.* by the opther RPis. It would only be logical to match IP address to relayed network: we'll use 172.17.0.xxx.

Set up the Pis

  1. Configure your RPis' wlan1 (the public interface) to use the fixed IP 172.17.xxx.254 where xxx is unique among all your RPis and not 0 (see above). Netmask is 255.255.255.0.

  2. Configure your RPis' wlan0 (the private interface) to use the fixed IP 172.17.0.xxx where xxx is the same as above. Netmask is 255.255.255.0.

  3. On every RPi, run the following script, after replacing $END by the number of RPis you're using:

    echo 1 > /proc/sys/net/ipv4/ip_forward
    for i in $(seq 1 $END); do route add -net 172.17.$i.0 netmask 255.255.255.0 gw 172.17.0.$i; done
    iptables -A FORWARD -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
    

TL;DR, we do the following: we choose a big network, here 172.17.0.0/16. We subdivide it in 255 smaller networks: 172.17.xxx.0/24. We keep 0 for ourselves, and give all other numbers to the users. Then, we tell the RPis to transfer packets headed to other computers to the appropriate "gateway" RPi.

Tell the users' devices to look in the right place

I assume you are using dnsmasq as the DHCP server for the public networks. In order to have the user devices configured correctly, you will need to tweak its settings.

  1. Set up DHCP so it serves addresses in a range adapted to the network, I.E. 172.17.xxx.1 to 172.17.xxx.253.

  2. Add a static route the the DHCP part of dnsmasq config (again replacing xxx appropriately):

    dhcp-option=121,16.172.17.0.0,172.17.xxx.254
    

Using a static route avoid overwriting the default gateway of your clients. This way, if they are still connected to another network (i.e. a laptop with Ethernet plugged in), they should not have any problem.

Make sure you test this with 1 or 2 Pis and 1 or 2 clients before doing committing to set up all your RPis.

2
  • sorry for late reply. unfortunately your solution didnt work for this issue. however i used your direction to solve the problem. Aug 23 '17 at 4:04
  • Well, at least I helped a bit ^^ In order to help other people who try to do something similar, can you post what you actually did as an answer, and mark it accepted? Thank you. Aug 23 '17 at 7:09

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.