All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.