Routing or bridging to connect eth0 and wlan0

Question

I have the following setup:

Device A (sensor, static ip=192.168.6.83) | | Enet connection | Device B (raspberry) | | Wifi | Device C (laptop)

I have managed to setup the raspberrys wifi as an acces point so I can connect with device C to device B. When connected to the access point I can ssh to the raspberry (device B). When I am connected through ssh I can access device A through ssh from the raspberry (B). What I want is to ssh directly from device C (laptop) to device A (sensor).

The sensor is connected through the ethernet port of the raspi and is set the a fixed ip (eth0 = 192.168.6.2) The laptop is connected through the wifi of the raspi and is also set to an fixed ip (wlan0- 192.168.6.1)

I have been reading about bridging and routing and if I understood it right you use bridging to connect different subnets, while in my case everything is located on the same subnet. I simply want the eth0 and wlan0 to share the same network.

So my question is:

How do I connect these two interface to each other (eth0 and wlan0) so that I can access device A and B from device C?

• Is the assigning of a static ip to eth0 and wlan0 ok?
• Or should I solve this by assigning different subnets to the interfaces and bridge?

---

Things that should be noted:

1. No device is connected to the internet.
2. I still want to be able to access device B (raspberry) from the laptop (device C)
3. I am using buildroot to create an OS.

---

Update 2: almost there... The contents of some important files/commands:

hostapd.conf:

    interface=wlan0
    ssid=wifi_test
    hw_mode=g
    channel=10
    wmm_enabled=1
    macaddr_acl=0
    auth_algs=1
    ignore_broadcast_ssid=0
    wpa=2
    wpa_passphrase=wifi_password
    wpa_key_mgmt=WPA-PSK
    wpa_pairwise=CCMP 
    rsn_pairwise=CCMP
    ieee80211n=1

/etc/network/interface:

iface br0 inet static
  bridge_ports eth0 wlan0
  address 192.168.6.3
  netmask 255.255.255.0
  pre-up brctl addbr br0
  pre-up brctl addif br0 eth0 wlan0
  post-down brctl delif br0 br0 eth0 wlan0
  post-down brctl delbr br0

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet static
  address 192.168.6.1
  netmask 255.255.255.0

dnsmasq.conf

interface=wlan0     
dhcp-range=192.168.6.150,192.168.6.180,255.255.255.0,24h

---

Ok, so I almost have it working (thank @eftshift0). I use the above config files and I am able to do what I wanted. There is only one BUT...:

The setup works if:

1. first connect to the wifi
2. Then activate the bridge

The has as effect that I can access both the Pi and the sensor. However I do not want to activate the bridge manually. It seems that the handing out of the IP addresses does not work when the bridge is active. This is further confirmed by the fact that if I use an static IP I can make the connection. So now the question comes down to this: Why is the dhcp server not working of the bridge is active?

Answer 1

Given that you appear to have a single network segment set up (192.168.6.0/24) for both interfaces on the rpi (let me stress out: appear), then there's only one day to get this done: bridging.

If you want to use routing, then these are the things that you should consider:

They should have separate network segments or you will come into all kind of craziness. Say, keep network for wired/sensor on 192.168.6.0/24 and have 192.168.7.0/24 for wireless.

Then if you are using static IPs on the wifis of rpi/desktop, the simplest thing to do is to add a routing rule on your desktop so that it knows that in order to reach network 192.168.6.0/24, it has to go through the rpi. How to set it up is OS-specific but I'll provide how to do it on linux:

ip route add 192.168.6.0/24 dev wlan0 via 192.168.7.1 # adjust wlan0 to whatever device the wireless is on the laptop and I'm assuming 192.168.7.1 is the IP of the rpi wireless interface

There's nothing to do in terms of routing on the rpi because the rpi knows what both network segments are and how to reach them so no need to set up any special routing information on it.

Then, there are other details: - Is the rpi allowing to forward traffic? sysctl -w net.ipv4.ip_forward=1 - Is the rpi firewall allowing traffic to be forwarded? This has to be checked with iptables. iptables -L FORWARD -nv and the policy and the rules have to be checked. This should allow traffic that is going from the desktop to the sensor to reach the sensor network interface. You can check this by running a sniffer on the rpi (use tshark, for example.... how to use it is outside of the scope of the question).

Then there are more details. Does the sensor know that in order to go back to 192.168.7.0/24 it will have to send the traffic through rpi? If the sensor is set up to have its default gateway to be the rpi, then no problem, when it wants to send traffic to 192.168.7.0/24 it will send it to the rpi and the rpi will be able to send it back to the desktop, but if it's not possible to do this then you have to "fool" the sensor into believing that the traffic was generated by the rpi... this is not that difficult to achieve. This netfilter rule on the rpi would take care of that:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE -m comment --comment "masquerade all traffic that is sent out to the sensor"

All kinds of tricky stuff, right?