From: Simon Barber <simon@superduper.net>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: bridge@lists.linux-foundation.org,
Umar Qureshey <umar.qureshey@lantronix.com>
Subject: Re: [Bridge] Hardware requirements for bridging wired+wireless together
Date: Wed, 19 May 2010 13:59:24 -0700 [thread overview]
Message-ID: <4BF4512C.4040903@superduper.net> (raw)
In-Reply-To: <20100519192011.GJ2412@tuxdriver.com>
I did write an ebtables module to work around this 802.11 3 address
problem - it performed L2 NAT on DHCP, ARP and IP packets, so allowing
an 802.11 client be added to a bridge. It was released under GPL about 5
years ago (from my previous company Instant802/Devicescape), but I can't
find the source anymore!!!
Simon
On 05/19/2010 12:20 PM, John W. Linville wrote:
> On Wed, May 19, 2010 at 10:15:35AM -0700, Umar Qureshey wrote:
>
>> What about bridging in Ad-Hoc mode? Would that technically work?
>
> No.
>
>> I guess what I am trying to figure out is why bridging would work in WDS mode? What is it about that mode that allows bridging to work?
>
> It has to do with the MAC-layer addressing on wireless LANs. Wireless
> frames can use 2, 3, or 4 MAC addresses to identify the transmitter,
> receiver, sender, and destination. For most frames and most modes,
> 3 MAC addresses are used. The FromDS and ToDS bits in the header
> are used to allow one of the MAC address fields to specify either
> the transmitter and sender or the destination and receiver. This is
> sufficient for non-bridged cases since the wireless station is either
> an endpoint of the communication or possibly a router (and therefore
> a Layer-2 endpoint).
>
> WDS (or 4 address) mode removes this limitation by using 4 MAC
> addresses to identify all 4 roles independently. So, the wireless
> station is able to forward frames received off the air to the
> appropriate destination with the correct sender information intact.
>
> mac80211-based devices can have interfaces created with support for
> 4 address mode using the iw command. For this to work, your AP has
> to be willing to accept and forward those frames appropriately --
> some do, others don't. This is only supported for "managed" mode
> interfaces AFAIK.
>
>> If one were to try to modify the kernel code to allow MAC-level NAT, which area of the kernel code would one look at?
>
> netfilter -- I thought there was already some ebtables code to
> do this...?
>
> John
next prev parent reply other threads:[~2010-05-19 20:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-17 20:17 [Bridge] Hardware requirements for bridging wired+wireless together Umar Qureshey
2010-05-18 19:32 ` Nicolas de Pesloüan
2010-05-18 23:38 ` Umar Qureshey
2010-05-18 23:51 ` Stephen Hemminger
2010-05-19 17:15 ` Umar Qureshey
2010-05-19 19:20 ` John W. Linville
2010-05-19 20:59 ` Simon Barber [this message]
2010-05-19 21:08 ` Umar Qureshey
2010-05-19 22:55 ` Simon Barber
2010-05-19 21:01 ` Umar Qureshey
2010-05-19 23:02 ` Simon Barber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BF4512C.4040903@superduper.net \
--to=simon@superduper.net \
--cc=bridge@lists.linux-foundation.org \
--cc=linville@tuxdriver.com \
--cc=umar.qureshey@lantronix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox