Pi as wireless bridge?

[mcgyver83]

Hi, I follwed this guide http://rbnrpi.wordpress.com/project-lis ... t-ready-tv
My TV connected to the rpi ethernet has a ip of the second net (192.168.2.10) but when I run the network setup from the tv menu it complains about DNS.
A red about bridging that seems simpler thant the guide I followed but each time wpa is used but I have an open wifi with mac address restriction.
Is bridging usable also for me?

Thanks

[Joe Schmoe]

I just want to point out that every time I've tried "bridging" under Linux, it has failed. It just seems like there's always some piece either missing or that doesn't work the way the tuts say it should.

Curiously, it has always worked under Windows. Funny that...

Anyway, the point is that, ultimately, there's no need (for bridging under Linux), since the other way, using "iptables" has always worked fine for me. Note that what I've called "the other way" is that which has been referred to as "routing" by others on this thread. Same thing.

So, I recommend you drop "bridging" and go with the iptables method.

[mcgyver83]

I followed the guide linked in my previous post that uses iptable but I had the issue described: my tv complains about DNS and Gateway value; ip is assigned to the Tv fine

[SirLagz]

What does the TV complain about ?
You may need to put the router of the first network (so not the one that your Pi is creating) into /etc/resolv.conf so that the TV can resolve things properly.

[mcgyver83]

My /etc/resolv.conf

Code: Select all

less  /etc/resolv.conf
domain localdomain
search localdomain
nameserver 192.168.1.1
nameserver 192.168.1.1

I followed this guide:
http://hackhappy.org/uncategorized/how- ... rk-bridge/
adapting a couple of settings and now my TV is happy
From what I understand I followed the bridge way.

The issue is that my tv is a samsung ue40d5000pw so not Smart TV; I want to connect it to my network to be able to use its DLNA stuff but the TV isn't detected by an app I have on android...

[SirLagz]

That way of doing things is still routing, which will cause issues like what you're experiencing with the TV.

The reason why you're experiencing issues is because the packets go from one network to another network. Unless you have port forwarded all the ports required for MiniDLNA from the PI to the TV, it won't work.

Add the following lines to iptables and see how you go.

Code: Select all

iptables -A PREROUTING -t nat -i wlan0 -p tcp --dport 8200 -j DNAT --to 192.168.2.10:8200
iptables -A INPUT -p tcp -m state --state NEW --dport 8200 -i wlan0 -j ACCEPT
iptables -A PREROUTING -t nat -i wlan0 -p udp --dport 1900 -j DNAT --to 192.168.2.10:1900
iptables -A INPUT -p udp -m state --state NEW --dport 1900 -i wlan0 -j ACCEPT

[Joe Schmoe]

Note that the thread title is now inaccurate and should be fixed - since we are no longer talking about bridging (we are talking about "routing").

[mcgyver83]

That way of doing things is still routing, which will cause issues like what you're experiencing with the TV.

The reason why you're experiencing issues is because the packets go from one network to another network. Unless you have port forwarded all the ports required for MiniDLNA from the PI to the TV, it won't work.

Add the following lines to iptables and see how you go.

Code: Select all

iptables -A PREROUTING -t nat -i wlan0 -p tcp --dport 8200 -j DNAT --to 192.168.2.10:8200
iptables -A INPUT -p tcp -m state --state NEW --dport 8200 -i wlan0 -j ACCEPT
iptables -A PREROUTING -t nat -i wlan0 -p udp --dport 1900 -j DNAT --to 192.168.2.10:1900
iptables -A INPUT -p udp -m state --state NEW --dport 1900 -i wlan0 -j ACCEPT

Ok, this is now my /etc/iptables.ipv4.nat

# Generated by iptables-save v1.4.20 on Sun Nov 10 18:50:55 2013
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o wlan0 -j ACCEPT
COMMIT
# Completed on Sun Nov 10 18:50:55 2013
# Generated by iptables-save v1.4.20 on Sun Nov 10 18:50:55 2013
*nat
REROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
OSTROUTING ACCEPT [0:0]
-A POSTROUTING -o wlan0 -j MASQUERADE
-A PREROUTING -t nat -i wlan0 -p tcp --dport 8200 -j DNAT --to 192.168.2.10:8200
-A INPUT -p tcp -m state --state NEW --dport 8200 -i wlan0 -j ACCEPT
-A PREROUTING -t nat -i wlan0 -p udp --dport 1900 -j DNAT --to 192.168.2.10:1900
-A INPUT -p udp -m state --state NEW --dport 1900 -i wlan0 -j ACCEPT
COMMIT
# Completed on Sun Nov 10 18:50:55 2013

I wrote a wrong thing: my approach also uses iptable, routing not bridge.

Sorry

[heinzcooler]

Hello there,

I want to bridge wlan to ethernet and it worked, but after upgrading (also kernel) it crashes.

After reading here (in german): http://wiki.ubuntuusers.de/Netzwerkbr%C3%BCcke
I'm not sure if it's correct: bridges to wlan are now disabled by kernel? Since which kernel version?

[Lbfh]

nearly got it,
setup works corretly but, afterwards pc on eth0 cant ping anything in network connected to wlan0.

br0 hast ip 192.168.178.37 via DHCP

from Rpi i can ping my router 192.168.178.1 and google.de successfully but the connected pc on eth0 doesnt even receive dhcp ip and static ip doens't work either.

seems that the bridge is up but the connection doesn't work?

Hi,

I'm trying timb's solution and the setup works.
But dhcp doesn't work on eth0 and I don't know what to try now.

Should I try to add iptables or stmh ?

Thank you.

[eggy]

I got mine to work by following the post
by gabeblack » Fri Dec 28, 2012 10:13 pm

This worked on my home network, but not on the wireless network where i work.
The AP at my work must have safegaurds in place to prevent it working.

[Joe Schmoe]

The AP at my work must have safegaurds in place to prevent it working.

They probably read this board...

[littlebit]

I have been reading this thread up and down, followed every single link posted as a possible source of solving this problem.
Some suggested natting and firewaling the pi, which looks at first a very good and very secure solution. But it is also a very static, and gets complicated when setting up servers on the eth0 side of the pi.
Others succested to use a shell script that setsup a dhcp,firewall and another subnet which is a more user friendlier version of the first variant. The downside of this solution is that most users use the pi in their homes and really don't have a network of 20 to 30 hosts that would also need to get bind9 up and running etc. , which is an overkill.
In my humble opinion, a wlan to eth bridge is the most elegant and minimalistic solution and this is what I focused on in getting.
One thing is for sure, that wiki link of wiki.ubuntuusers.de in one of the posts of this thread says that a bridge doesn't know anything about wpa2 authentications and such things, therefore the wlan interface needs to be brought up first BEFORE the bridge is taken up.
I have a USB wlan thumbstick with a realtek chip, and this is my lsusb:

Code: Select all

0bda:8176 Realtek semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Now, when rebooting my raspberry pi, I get the following output at booting:

Code: Select all

ioctl[SIOCSWIAP]: Operation not permitted
ioctl[SIOCSIWEMCODEEXT]: Invalid argument
ioctl[SIOCSIWEMCODEEXT]: Invalid argument
Waiting for br0 to get ready (MAXWAIT is 5 seconds).
Internet Systems Consortium DHCP Client 4.2.2
All rights reserverd.
For info. please visit https://www.isc.org/software/dhcp/

Listening on LPF/br0/00:13:ef:50:0e:5d
Sending on  LPF/br0/00:13:ef:50:0e:5d
DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 10.0.0.254
DHCPACK from 10.0.0.254
Stopping NTP server: ntpd
Starting NTP server: ntpd
bound to 10.0.0.1 -- renewal in 431540 seconds
done.

As you can see I got several weird error messages but right after that I received an ip-address which looked great.
The output of my ifconfig is the following:

Pinging any host in the internet was a success and pinging hosts that are on the eth0 side also works.
THEN, after 15 minutes or so, all of the sudden my simultaneous pings freeze...
Taking a look at at my /var/log/systlog:

Code: Select all

Mar 19 19:30:33 matchbox kernel: [45763.039162] br0: port 1(wlan0) entered forwarding state
Mar 19 19:30:33 matchbox kernel: [45763.039238] br0: port 1(wlan0) entered forwarding state
Mar 19 19:30:33 matchbox kernel: [45763.040030] br0: port 1(wlan0) entered disabled state
Mar 19 19:30:33 matchbox ifplugd(wlan0)[1719]: Link beat detected.
Mar 19 19:30:37 matchbox ifplugd(wlan0)[1719]: Link beat lost.

And here is my dmesg output:

Code: Select all

[   28.705411] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[   28.798028] device eth0 entered promiscuous mode
[   28.861362] device wlan0 entered promiscuous mode
[   28.927519] br0: port 2(wlan0) entered forwarding state
[   28.927727] br0: port 2(wlan0) entered forwarding state
[   28.927784] br0: port 1(eth0) entered forwarding state
[   28.927839] br0: port 1(eth0) entered forwarding state

And this is my interface config:

Code: Select all

auto lo0
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
pre-up wpa_supplicant -B w -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

auto br0
iface br0 inet dhcp
    bridge ports eth0 wlan0
    bridge_stp off
    bridge_maxwait 5

Now I have found a daemon called ifplugd who has his config file in /etc/default/ but there is nothing that appears to me unusual. Then I get those weird "ioctl" messages at boot time, I don't know from where they come from. So this is a partial success of getting a wireless to wired bridge up and running to all of you who are struggling with this problem.
If someone knows what these ioctl messages mean, from where they come from and how to fix them would be great.
Also if someone has the last piece of the puzzle of getting a stable bridge up and running, please let us know.

[littlebit]

Now I have been turning things upside down and with a lot of googling I have a suspect.
This question goes to the kernel experts, is it possible that the usb hub suspends after a while? And if so how can someone change that??

I would be happy to receive your suggestions and thoughts..

[briguy84]

I haven't tried it yet but this post looks promising.....http://raspberrypi.stackexchange.com/qu ... d-ethernet

[baantonia]

Success yesterday! After a week of trial and error, scouring the Internet for clues, I managed to build a transparent bridge using a Raspberry Pi and an Edimax wifi USB dongle. A device (laptop) was connected to the ethernet port using a crossover UTP cable and its wifi disabled.

This is using the most up to date Raspbian distro, install of bridge-utils and ebtables followed by a full update.

The Raspberry Pi is connecting to one of our SSIDs via Cisco APs and controller.

One thing I found though, if I gave the Raspberry Pi an IP address, communication between the device connected to the ethernet port had intermittent connectivity to the rest of the network. The device also required a static address in the range of the wireless range , DHCP did not work.

Two sites which helped me to some extent were:
http://blog.slor.net/2013/09/turning-yo ... eless.html
https://wiki.debian.org/BridgeNetworkConnections
However both solutions if configured as described, for me did not work.

The solution is completely transparent and works at layer 2, no NATting, proxies or port fowarding which are all layer 3. I am able to ping other equipment around the network and nmap the device from the network to discover open ports.

I'll post the configuration as soon as I get chance, but at present, cooking supper is calling......

[baantonia]

Here are the configurations I'm using:

/etc/network/interfaces

Code: Select all

# /etc/network/interfaces

auto lo

iface lo inet loopback

allow-hotplug eth0
iface eth0 inet manual

auto ath0
iface ath0 inet manual
    bridge_ports eth0
    bridge_hw <mac-address-of-wireless-dongle>
    bridge_stp off
    bridge_maxwait 5

allow-hotplug wlan0
auto wlan0
iface wlan0 inet manual
    pre-up wpa_supplicant -Dwext -i wlan -b ath0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B

#iface default inet dhcp

/etc/wpa_supplicant/wpa_supplicant.conf

Code: Select all

# /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant Group=netdev
update_config=1
ap_scan=2
eapol_version=1
network={
    ssid="Your-SSID"
    scan_ssid=1
    mode=0
    proto=WPA
    pairwise=TKIP
    group=TKIP
    key_mgmt=WPA-PSK
    psk="Your-Pre-Shared-Key"
}

/etc/rc.local

Code: Select all

#!/bin/sh -e
#
# /etc/rc.local
brctl addif ath0 wlan0
ebtables -t nat -A POSTROUTING -o wlan0 -j snat --to-src <mac-address-of-wireless-dongle> --snat-arp --snat-target ACCEPT
ebtables -t nat -A PREROUTING -p IPv4 -i wlan0 --ip-dst <IP-address-of-device> -j dnat --to-dst <mac-address-of-device> --dnat-target ACCEPT
ebtables -t nat -A PREROUTING -p ARP -i wlan0 --arp-ip-dst <IP-address-of-device> -j dnat --to-dst <mac-address-of-device> --dnat-target ACCEPT

Also in /etc/sysctl.conf the following line is enabled, not sure if it is required, have not tested with it commented out.
net.ipv4.ip_forward=1

Replace the parts in <>, including the symbols <> with those for your own configuration. My wpa_supplicant config uses a cleartext pre shared key, change yours to suit your own setup. I've used ath0 as my bridge interface, probably br0 could be used instead. Haven't tested multiple devices connected to the eth0 port of the Raspberry Pi, but if required, repeat the last two ebtables statements with the appropriate changes for the next device. Note none of the interfaces have a static IP address or get one from DHCP, in my setup, adding an IP address caused intermittent issues. Each ebtables line is on one line, in my browser it gets wrapped, the --snat-target ACCEPT and the --dnat-target ACCEPT should be on the same line as the ebtables.

Well this is how I did it.

[littlebit]

I went through your configuration and aside that you have a thing for atheros wireless cards, it seems to work as you described. But unfortunately doesn't cover that needs to be covered.

[razza30]

Success yesterday! ......

Excellent, thanks! I will have a play next week when I am back home

[baantonia]

On some site I read that using br0 had an ill effect in using wpa_supplicant, which was probably incorrect, I didn't test it, but that said, at that point I hadn't managed to get a working connection. Maybe I should replace all the ath0 for br0 and check, it would be an interesting experiment to see if using br0 has a detrimental effect.

Anyway, in theory you could use any label for the bridging interface, I chose ath0 as an alternative, you could use goldfish0 in place of ath0 and it should work, just make sure to replace them all to be the same, the label ath0 has no real meaning. The bridging interface doesn't physically exist, it only exists in software.

The physical interface for the wireless I'm using is a Edimax USB dongle, I expect many owners of Raspberry Pi's have these.

Note, I've configured bridging interfaces on Cisco 3640 routers before but haven't done so using Linux, let alone a Debian variety, normally I use OpenSuSE for my desktop. So the label ath0 is an enigma to me, I just saw it and used it in my configuration. The relative merits, or otherwise, of atheros wireless cards I don't know as I don't have one to test.

The original question was:

This may be a crazy question, but is there any way to easily allow a Pi with a working wi-fi connection to 'share' its internet connection with anything plugged into the ethernet conenctor, in much the same way as Windows computers can be set to do that?

Although SiriusHardware only required a temporary connection.

This is what I needed to achieve as well but more permanent and this configuration seems to fit the bill, all that needs to be changed is the wifi authentication, the MAC addresses and a chosen IP address which would also be statically set on the device (with the associated other settings such as mask, gateway and DNS), to connect to the Raspberry Pi's ethernet port. Note the use of a crossover UTP cable and the Raspberry Pi itself has no layer 3 network connectivity, it cannot be used to communicate to the Internet itself in this state as it has no IP address. I found in my test scenario with Cisco AP's, adding an IP address to the Raspberry Pi produced an intermittent wifi connection, probably something to do with security. I did play with the security settings on the controller but didn't manage to make it work continuously. Also I couldn't get DHCP to work for the connected device, hence the static settings, and in any case, the MAC address received by the DHCP server would be that of the wireless dongle, not that of the connected device.

[littlebit]

Ok, after spontaneous reviewing my bridge configurations I thought that it could be the ifplugd that could be someone that meddles with my interfaces, as a result I went to /etc/default/ifplugd.conf and commented out all the lines. I still get those dropouts from my router (avm fritzbox 7270) and ifplugd still appears, so I took my pi and set it up at work and took it for a testdrive, and the link was stable .

So this is my configuration that I would like to share with the community to try out and give me their feedback, also please mention what kind of router do you have when using the pi as a bridge.
@/etc/network/interfaces:

Code: Select all

auto lo
iface lo inet loopback

iface eth0 inet manual

auto wlan0
iface wlan0 inet manual
pre-up wpa_supplicant -B w -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

auto br0
iface br0 inet dhcp
	bridge_ports wlan0 eth0
	bridge_stp off
	bridge_maxwait 5
	bridge_fd 0

@/etc/default/ifplugd.conf:

Code: Select all

# This file may be changed either manually or by running dpkg-reconfigure.
#
# N.B.: dpkg-reconfigure deletes everything from this file except for
# the assignments to variables INTERFACES, HOTPLUG_INTERFACES, ARGS and
# SUSPEND_ACTION.  When run it uses the current values of those variables
# as their default values, thus preserving the administrator's changes.
#
# This file is sourced by both the init script /etc/init.d/ifplugd and
# the udev script /lib/udev/ifplugd.agent to give default values.
# The init script starts ifplugd for all interfaces listed in
# INTERFACES, and the udev script starts ifplugd for all interfaces
# listed in HOTPLUG_INTERFACES. The special value all starts one
# ifplugd for all interfaces being present.
#INTERFACES=""
#HOTPLUG_INTERFACES=""
#ARGS="-q -f -u0 -d10 -w -I"
#SUSPEND_ACTION="stop"

@/etc/wpa_supplicant/wpa_supplicant.conf:

Code: Select all

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
	ssid="your ssid here"
	psk="your preshared key here"
	proto=RSN
	key_mgmt=WPA-PSK
	pairwise=CCMP
	auth_alg=OPEN
}

What I need to know if there is anyone who is using this config is having similar problems or not.
Let me read your feedback, and my question to the hardware and kernel developers:
What does

ifplugd(eth0) Link beat detected

mean?

[pathead]

This thread was useful but pretty old so I just wanted to explain how I got it working using the current Rasbian distro(4.1).

Starting from a clean install, as mentioned by timb, use the wifi connection GUI so that it fills out the wpa_supplicant file automatically. For reference, my auto-generated wpa_supplicant.conf looked like this:

Code: Select all

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="mynetwork"
        psk="secret"
        key_mgmt=WPA-PSK
}

Then install the bridge-utils and create the bridge.

(side note, I forgot to apt-get update before doing this but it turned out fine)

Code: Select all

sudo apt-get install bridge-utils
sudo brctl addbr br0
sudo brctl addif br0 wlan0 eth0

That should be all you have to do to get this setup manually. The only problem is that it gets reset during a reboot.

I tried pretty much every configuration I could think of to put into /etc/network/interfaces and could not get it to work no matter what I did. The obvious alternative though is to just add them to /etc/rc.local instead and have the commands run at boot.

So, from a clean install, you should not have to edit /etc/network/interfaces at all. For reference, I'll copy/paste what that should look like with the current kernel:

Code: Select all

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

The only real change we need to do is add the 2 commands from above to /etc/rc.local. The default file has some comments and a print statement, just add the commands after the statement but before 'exit 0':

Code: Select all

_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

brctl addbr br0
brctl addif br0 wlan0 eth0

exit 0

In order for this to work at startup wlan0 and eth0 need to be initialized before the bridge is added. There are several ways to do this and since I am fairly new to linux I decided to just turn on the 'wait for network at boot' option in raspi-config and that worked fine for me. A script call that first sleeps for 30 seconds or something would probably work as well.

This seems like a long explanation but ultimately, from a clean install, you just need to setup the wifi connection and then edit rc.local to start the bridge on boot. Like I said I am new so maybe I am doing something wrong or maybe there is just a lot of ways to do this but I could not get this to work using any of the methods described in previous posts.

Good luck...

[RDK]

Which distro are you using Wheezy or Jessie? Did you install the bridge-utils ? Thanks....RDK

[pathead]

Raspbian Jessie 4.1. And yes bridge-utils is the only thing you need to install.

[RDK]

Hi. Just got around to trying this as I have an application for a wireless bridge. No happiness here. I tried the "wait for network..." option in the Raspi-Config and the sleep 10 option in the rc.local (along with the other two commands). In both cases I get "can't add wlan 0 to bridge br0: operation not supported".

When I do either of the above, I do get the print message with my IP address in the boot-up console messages. That does not show when I use the default rc.local, so I know the network configuration process is finished.

It also says something about an rc.local compatibility issue??...RDK