Pi as network bridge works... but then it doesn't

[Peter Ryan]

Hi all,

TL;DR - I'm using a Raspberry Pi as an ethernet to WiFi bridge. It works, but occasionally stops forwarding packets even though both the ethernet and WiFi interfaces appear to be working.

The long version: I've been using a Raspberry Pi running headless as a network bridge for a few months now; it works very well. The WiFi does drop from time to time, and I need to sudo ifdown wlan0 and sudo ifup wlan0 to bring it back up again, but not enough for me to bother trying to automate that.

Brief outline of my network: My router is on 192.168.1.254 and provides internet access via WiFi for the house. Upstairs I've got a bunch of computers many without WiFi so they're hooked up to an ethernet switch and the Pi is connected to that and bridges to the WiFi. The upstairs ethernet subnet is 192.168.2.0/24. Oh, and the Pi provides DHCP and DNS services to the upstairs subnet.

ASCII diagram here:

Code: Select all

[ROUTER]
    |    192.168.1.254 (WiFi)
    |    192.168.1.5   (WiFi)
 [RASPI]
    |    192.168.2.2   (Ethernet)
[SWITCH]  <- a bunch of stuff hooked up to this
    |    192.168.2.80  (Ethernet)
[DESKTOP]

Both the ethernet and WiFi interfaces needed a static IP address, so my /etc/network/interfaces file reads:

Code: Select all

auto lo

iface lo inet loopback
iface eth0 inet static
	address 192.168.2.2
	netmask 255.255.255.0

allow-hotplug wlan0
iface wlan0 inet static
	address 192.168.1.5
	netmask 255.255.255.0
	gateway 192.168.1.254
	wpa-ssid MYSSID
	wpa-psk MYPASSPHRASEHEX

iface default inet dhcp

I've enabled kernel packet forwarding using:

Code: Select all

$ sudo sysctl -w net.ipv4.conf.all.forwarding=1

and I've persisted this setting in /etc/sysctl.d/local.conf

And I've added a static route on the router to 192.168.2.0/24 via 192.168.1.5 (the WiFi dongle on the Pi). So that's all good.

Don't think it's relevant to my problem, but I'm using isc-dhcp-server for my DHCP and dnsmasq for DNS. I also have the Transmission bit-torrent client running, but this wasn't neither sharing or downloading anything when I experienced this problem.

This all works fine, except for the odd WiFi drop, but at least twice now, I've had a problem where my computer, DESKTOP, suddenly can't connect beyond the Pi:

Code: Select all

[DESKTOP]$ ping router          # No response!
[DESKTOP]$ ping raspi           # This gets a response
[DESKTOP]$ ssh raspi
[RASPI]$ ping router            # This gets a response

The interfaces (eth0 and wlan0) are both working, but for some reason the Pi seems to just stop forwarding. I tried ifdown wlan0 followed by ifup wlan0 to see if that would help, but it made no difference. So I disconnected the DESKTOP to RASPI SSH session and SSH'ed into the Pi via the WiFi on my phone to try and ifdown / ifup the eth0 interface. As soon as I'd issued:

Code: Select all

$ sudo ifdown eth0

I lost all access and the Pi would no longer respond on either interface.

Since it's running headless, I don't know if it had crashed or if it was just some kind of networking problem. On this last occasion, the Pi had been up for about 35 days.

So (finally) my question is: what can I do the next time this happens to figure out what's going on?

Thanks in advance!

Peter.

[Dutch_Master]

If you find it's acting up again, try logging in from both the wired and wireless network. If either one fails to connect, troubleshooting is already limited to that interface. If you succeed from both, it's the bridge that's faulty. In either case, your first port of call is the log files and dmesg (the kernel messages). It could be that either interface is down, which can be examined with the iwconfig tool (use the -a flag to list all interfaces) on the RPi.

Another avenue to investigate is the TTL, time-to-life period, of key data in the bridge. The TTL is basically telling the recipient application if the data it gets still is valid or it should request a new set of data. It's a basic part of network connectivity.

[Peter Ryan]

Hi Dutch_Master,

The wired and wireless network interfaces were working, so the problem is certainly something to do with the bridge - failing to forward packets.

I might check iptables next time this happens; perhaps something is inserting an entry that breaks the forwarding. But I'm certain that packets were arriving at the Raspi successfully, otherwise I wouldn't have been able to SSH to it!

As for TTL, unless the Raspi was suddenly changing this, it shouldn't be an issue... I wouldn't have thought anyway.

But really, I'm just after any commands I can use to see where/why packets aren't being forwarded. I did have a dig through dmesg/syslog/messages and couldn't see anything obviously wrong.... except maybe this:

Code: Select all

Aug  8 18:02:42 rpi2 kernel: [3215774.089348] nr_pdflush_threads exported in /proc is scheduled for removal
Aug  8 18:02:42 rpi2 kernel: [3215774.091415] sysctl: The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case.  If you have one, please send an email to linux-mm@kvack.org.

I'm only singling that one out because I think it was just prior to the problem occuring - it might be completely unrelated however.

[jojopi]

Firstly, this is not actually a bridge configuration, but a router. A bridge joins two networks into a single interface, say br0. Machines identify each other by MAC address, so only one IP range is needed, and even broadcast traffic passes across the bridge. A router only passes traffic that is addressed to the MAC address of the router with an IP address in a different network.

I am not suggesting that you should switch to a bridge configuration, just that you should not use the wrong terminology. Presumably you are happy with the routeing when it is working properly.

[DESKTOP]$ ping router # No response!

iptables and the kernel forwarding control are obvious things to re-check at this point. You should also check that the netmask on DESKTOP is correct, and that its default route is 192.168.2.2. You would be able to connect to the Pi even if these were wrong, but not through the Pi.

In an SSH session on the Pi, you can view the (non-SSH) traffic on the two interfaces with "sudo tcpdump -n -i eth0 not port 22" and "sudo tcpdump -n -i wifi0 not port 22". This should help to determine whether the packets to be routed are arriving, whether they are leaving again, and whether they are correctly addressed. It is helpful to test connections from the WiFi side to the Ethernet as well. Obviously, dropping packets in either direction will make most protocols unusable.

[Peter Ryan]

Hi jojopi,

Firstly, this is not actually a bridge configuration, but a router.

Oops! The worst part is that I checked Wikipedia before posting here just to check I'd got it right.
But thanks for correcting me all the same!

Originally I set it up with iptables doing NAT until I figured out I could I just get the kernel to forward packets and add a static route on the router (the other one, not the Raspi )

iptables and the kernel forwarding control are obvious things to re-check at this point. You should also check that the netmask on DESKTOP is correct, and that its default route is 192.168.2.2. You would be able to connect to the Pi even if these were wrong, but not through the Pi.

In an SSH session on the Pi, you can view the (non-SSH) traffic on the two interfaces with "sudo tcpdump -n -i eth0 not port 22" and "sudo tcpdump -n -i wifi0 not port 22". This should help to determine whether the packets to be routed are arriving, whether they are leaving again, and whether they are correctly addressed. It is helpful to test connections from the WiFi side to the Ethernet as well. Obviously, dropping packets in either direction will make most protocols unusable.

That's great - I'll check both of these when/if it fails again.

[philc]

I was having similar issues and was able to get it to work finally.