Send users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Re: Raspberry Pi as wlan2ethernet gateway with Linksys AE3000
(Andreas Hartmann)
----------------------------------------------------------------------
Message: 1
Date: Fri, 28 Mar 2014 10:44:53 +0100
From: Andreas Hartmann <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [rt2x00-users] Raspberry Pi as wlan2ethernet gateway with
Linksys AE3000
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15
I added some additional information resulting on new findings / new
versions.
Andreas Hartmann wrote:
> Hello!
>
>
> I built a wlan2ethernet GW with Raspi to resolve the following issues
> or meet these requirements:
>
> 1. security: all of the embedded supplicants I'm using don't support
> EAPTLS at all.
>
> 2. Stability / performance: it is often impossible to place the
> embedded supplicant to get best radio conditions.
>
> 3. I don't want to have another subnet behind the wlan2ethernet GW
> (ie.: no solution based on routing). The needed architecture looks
> like this:
>
> 192.168.5.0/24:
> server - switch - AP - Raspi - switch - some devices.
>
> 4. Download throughput should be continuously stable >= 50 MBit/s (real
> time application - TCP) over hours
>
> 5. Wired Ethernet isn't a solution for me here.
>
>
> How does Raspi perform as wlan2ethernet gw? Which performance can be
> expected?
>
> Using Raspi as wlan2ethernet GW involves two devices: the integrated
> Ethernet interface (connected via usb) and an external usb wlan device.
>
> The performance of the Ethernet interface (netperf - measured w/o any
> other load) achieves ~ 80 Mbit/s and a related high cpu load.
>
> The performance of the AE3000 [5] is 140 Mbit/s (download; radio through
> reinforced-concrete floor). The cpu load at this time is not that high
> as seen during measuring of the Ethernet interface.
>
>
> These measurements show:
>
> - The Ethernet interface will be the bottleneck. The best
> hypothetical throughput would be 80 MBit/s.
>
> - In real operation, both interfaces will need cpu resources at the
> same time, therefore the max throughput will be < 80 MBit/s!
>
>
>
>
> Technical thoughts of implementation
>
> The wlan2ethernet GW must work as bridge (requirement 3). To achieve
> this, you have to activate the 4 address mode of hostapd / nl80211. This
> requires a wlan driver, which supports 4 address mode on Raspi. It can
> be used w/ rt2800usb, but rt2800usb only achieves a poor, unstable max
> throughput of 30 Mbit/s (used as single device). Therefore: unusable.
>
> The above given 140 MBit/s are measured w/ rt5572sta - but this driver
> doesn't support 4 address mode. Therefore, there must be another
> solution: Tunneling.
>
> I used vxlan to implement a tunnel for the wlan line:
>
> server w/ vxlan - switch - Ap - Raspi w/ vxlan - switch
It's better to start the tunnel on the Ap instead of the host. See below!
> This solution provides a continuous, stable throughput of 50 MBit/s (74
> Mbit/s with Raspi's turbo), the absolute minimum I need.
Measured on raspi with bmon and linux 3.13.x I'm getting now a
throughput of about 90 MiByte/s (measured on eth0)! This is really cool!
A few thoughts about turbo on raspi:
You should use the frequency governor ondemand to better prevent damage
of filesystem on sd card during switch off (-> shutting down!) of raspi.
> Vxlan doesn't crypt the transported data, but this is ok, because the
> wlan line is already hardware crypted itself. In fact, it actually is
> desired, because it would be useless overhead.
>
>
>
> A few basic words how to practically implement it
>
> As basic Raspi image, I used 2013-07-26-wheezy-raspbian.zip from [3] -
> today there are newer ones. This image shipped w/ Linux 3.6.
>
> In order to use vxlan, Linux > 3.7 must be used. I'm using a cross
> compiled Linux 3.11 for Raspi.
>
> Description of cross compiling for Raspi: [1].
>
> Vendor driver for Linksys AE3000 (rt5572sta) can be found at [2].
>
> Setting up the vxlan tunnel:
>
> ip li add vxlan1 type vxlan id 1 group 239.1.1.1 dev br1
> brctl addif br1 vxlan1
>
> This adds the vxlan1 device as another stp to a virtual bridge (br1) on
> the server.
If the tunnel is started in Ap as mentioned above, it would look like this:
brctl show
bridge name bridge id STP enabled interfaces
br0 xxxx.xxxxxxxxxxxx no eth0
vxlan1
wlan1
ip li add vxlan1 type vxlan id 1 group 239.1.1.1 dev br0
brctl addif br0 vxlan1
Since newer kernels (>= 3.12.x), I'm partly facing _massive_ dead loops
on device vxlan1 or br0 on Ap which partly hung the complete VM (Ap is a
VM).
This looks like this in messages:
Dead loop on virtual device br0, fix it urgently!
or
Dead loop on virtual device vxlan1, fix it urgently!
To fight against these dead loops, you have to prevent retunneling of
already tunneled packages (that was the reason here for the dead loops):
ebtables -I OUTPUT -p 0x0800 -o vxlan1 --ip-protocol 17 --ip-source [IP
of br0] --ip-destination [group address of vxlan] -j DROP
e.g.:
ebtables -I OUTPUT -p 0x0800 -o vxlan1 --ip-protocol 17 --ip-source
192.168.11.25 --ip-destination 239.1.1.1 -j DROP
How to find dead loops:
Finding dead loops is not that easy. I used two means to find them:
1. Wireshark
Wireshark has the ability to translate the created udp vxlan packages.
The function is called "decode as" and can be find in the context menu
of the package. If the package decoded as vxlan shows more than one
vxlan entry, there is something wrong - this means, that a already
tunneld package got tunneled again and again ... .
2. iptables and ebtables
You can show each packet traversing the chains by enabling logging of
each packet:
iptables -I OUTPUT -j LOG --log-prefix "Output: "
iptables -I INPUT -j LOG --log-prefix "Input: "
iptables -I FORWARD -j LOG --log-prefix "Forward: "
iptables -t mangle -I FORWARD -j LOG --log-prefix "mForward: "
iptables -t mangle -I INPUT -j LOG --log-prefix "mInput: "
iptables -t mangle -I OUTPUT -j LOG --log-prefix "mOutput: "
iptables -t mangle -I PREROUTING -j LOG --log-prefix "mpreRoute: "
iptables -t mangle -I POSTROUTING -j LOG --log-prefix "mPostrouting: "
ebtables -A INPUT --log-level info --log-ip --log-prefix "EBINPUT "
ebtables -A FORWARD --log-level info --log-ip --log-prefix "EBFORWARD "
ebtables -A OUTPUT --log-level info --log-ip --log-prefix "EBOUTPUT "
It's best to put it in a small script to start it all at once. But be
very careful! You have to take care, that there is no other traffic but
the faulty one during tracing, because you won't see anything because of
the huge mass off log data!
That's the stop script:
iptables -D OUTPUT -j LOG --log-prefix "Output: "
iptables -D INPUT -j LOG --log-prefix "Input: "
iptables -D FORWARD -j LOG --log-prefix "Forward: "
iptables -t mangle -D FORWARD -j LOG --log-prefix "mForward: "
iptables -t mangle -D INPUT -j LOG --log-prefix "mInput: "
iptables -t mangle -D OUTPUT -j LOG --log-prefix "mOutput: "
iptables -t mangle -D PREROUTING -j LOG --log-prefix "mpreRoute: "
iptables -t mangle -D POSTROUTING -j LOG --log-prefix "mPostrouting: "
ebtables -D INPUT --log-level info --log-ip --log-prefix "EBINPUT "
ebtables -D FORWARD --log-level info --log-ip --log-prefix "EBFORWARD "
ebtables -D OUTPUT --log-level info --log-ip --log-prefix "EBOUTPUT "
This trace shows again the dead loop (the same package comes up again
and again - but the size is always +50 (-> the size of the additional
vxlan-header)).
On base of this trace, you are now able to decide how to fix the dead loop.
>
> On the Raspi, the vxlan is activated w/:
> ip li add vxlan1 type vxlan id 1 group 239.1.1.1 dev ra0
> brctl addbr br0
> brctl addif br0 vxlan1
> brctl addif br0 eth0
>
> The devices br0 and vxlan1 shouldn't have any IP address.
>
> Take care, that all devices are up to get it working (brctl showstp br0
> eg. should give forwarding for each device and br0 should be up itself).
A few words regarding MTU:
vxlan adds 50 bytes overhead. Now, you have the choice:
(1) reduce all the devices to 1450 (1500 is standard) but the devices
transferring the tunnelled data stay at 1500 or
(2) increase the mtu of the devices transferring the tunnelled data to
1550 and leave all the others at 1500.
I would have preferred (2), but it turned out, that the Ralink device
can't handle mtu > 1512 Byte: Sending is not the problem, but receiving.
Don't know, if it's a driver or a hardware / firmware restriction.
Therefore, I'm now using a variant of (1): I reduced all relevant
devices to 1462 Bytes and set the tunnel interfaces to 1512 bytes.
>
>
>
> Kind regards,
> Andreas
>
>
>
> [1] http://elinux.org/RPi_Kernel_Compilation
> [2] http://www.mediatek.com/_en/07_downloads/01_windows.php?sn=501
> [3] http://www.raspberrypi.org/downloads
> [4] http://wikidevi.com/wiki/TP-LINK_TL-WDN4800
> [5] http://wikidevi.com/wiki/Linksys_AE3000
>
------------------------------
Subject: Digest Footer
_______________________________________________
users mailing list
[email protected]
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
------------------------------
End of users Digest, Vol 61, Issue 3
************************************
