Bridging wired to STA interfaces.

Bridging wired to STA interfaces.

[Ben Greear]

We have some interest in being able to bridge wired systems to
(virtual) STA interfaces, primarily for using third-party
traffic generation tools over virtual stations.

I was thinking of writing a sta-bridge module that mapped
incoming packets on a wired interface to a STA with MAC
that matched the source MAC of the packet.  All packets
received on the STA would be forwarded un-modified out
the wired port.

I think this would allow someone to create a STA interface
with MAC matching a PC connected to the wired port and effectively
have it be a transparent bridge between STA and PC.

Has anyone attempted something like this before?

Any interest in having this feature in the upstream kernel?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Bridging wired to STA interfaces.

[Adrian Chadd]

How do you propose handling the case where people will hook up >1 device?
Print out a very loud warning? :-)

I did something like this a while ago for a company and their first
request was exactly that - "Customer X now wants two devices in a
vehicle hooked up to the wireless, it doesn't work, what do we do?"


Adrian


On 3 August 2011 13:33, Ben Greear <greearb@candelatech.com> wrote:
> We have some interest in being able to bridge wired systems to
> (virtual) STA interfaces, primarily for using third-party
> traffic generation tools over virtual stations.
>
> I was thinking of writing a sta-bridge module that mapped
> incoming packets on a wired interface to a STA with MAC
> that matched the source MAC of the packet.  All packets
> received on the STA would be forwarded un-modified out
> the wired port.
>
> I think this would allow someone to create a STA interface
> with MAC matching a PC connected to the wired port and effectively
> have it be a transparent bridge between STA and PC.
>
> Has anyone attempted something like this before?
>
> Any interest in having this feature in the upstream kernel?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Bridging wired to STA interfaces.

[Ben Greear]

On 08/03/2011 02:16 AM, Adrian Chadd wrote:
> How do you propose handling the case where people will hook up>1 device?
> Print out a very loud warning? :-)

I think you'd end up mapping the MAC of the PC to the STA, 1-to-1 mapping,
and possibly re-writing the src MAC when coming from the PC to the STA,
and dest MAC when coming from STA to PC.

Users wanting more than one PC could use a different virtual STA.

> I did something like this a while ago for a company and their first
> request was exactly that - "Customer X now wants two devices in a
> vehicle hooked up to the wireless, it doesn't work, what do we do?"

Did it at least work for 1-to-1 mapping OK?  Did you re-write MACs?

Thanks,
Ben

>
>
> Adrian
>
>
> On 3 August 2011 13:33, Ben Greear<greearb@candelatech.com>  wrote:
>> We have some interest in being able to bridge wired systems to
>> (virtual) STA interfaces, primarily for using third-party
>> traffic generation tools over virtual stations.
>>
>> I was thinking of writing a sta-bridge module that mapped
>> incoming packets on a wired interface to a STA with MAC
>> that matched the source MAC of the packet.  All packets
>> received on the STA would be forwarded un-modified out
>> the wired port.
>>
>> I think this would allow someone to create a STA interface
>> with MAC matching a PC connected to the wired port and effectively
>> have it be a transparent bridge between STA and PC.
>>
>> Has anyone attempted something like this before?
>>
>> Any interest in having this feature in the upstream kernel?
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear<greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Bridging wired to STA interfaces.

[Sam Leffler]

On Tue, Aug 2, 2011 at 10:33 PM, Ben Greear <greearb@candelatech.com> wrote:
> We have some interest in being able to bridge wired systems to
> (virtual) STA interfaces, primarily for using third-party
> traffic generation tools over virtual stations.
>
> I was thinking of writing a sta-bridge module that mapped
> incoming packets on a wired interface to a STA with MAC
> that matched the source MAC of the packet.  All packets
> received on the STA would be forwarded un-modified out
> the wired port.
>
> I think this would allow someone to create a STA interface
> with MAC matching a PC connected to the wired port and effectively
> have it be a transparent bridge between STA and PC.
>
> Has anyone attempted something like this before?
>
> Any interest in having this feature in the upstream kernel?

You've just described what's done in several products and it is indeed
useful.  The main issue is supporting it can incur overhead so you may
want to make it a compile-time option.

-Sam

Re: Bridging wired to STA interfaces.

[Ben Greear]

On 08/03/2011 03:37 PM, Sam Leffler wrote:
> On Tue, Aug 2, 2011 at 10:33 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> We have some interest in being able to bridge wired systems to
>> (virtual) STA interfaces, primarily for using third-party
>> traffic generation tools over virtual stations.
>>
>> I was thinking of writing a sta-bridge module that mapped
>> incoming packets on a wired interface to a STA with MAC
>> that matched the source MAC of the packet.  All packets
>> received on the STA would be forwarded un-modified out
>> the wired port.
>>
>> I think this would allow someone to create a STA interface
>> with MAC matching a PC connected to the wired port and effectively
>> have it be a transparent bridge between STA and PC.
>>
>> Has anyone attempted something like this before?
>>
>> Any interest in having this feature in the upstream kernel?
>
> You've just described what's done in several products and it is indeed
> useful.  The main issue is supporting it can incur overhead so you may
> want to make it a compile-time option.

I got some basic functionality working today with some
user-space bridging code I've already written for other purposes...

Can you think of any reason (beyond a bit of performance) that
this should be in the kernel?

My target hardware is fast enough that copying through user-space
at moderate (ie, fast as STA can go) speeds isn't too big of a deal, but
if someone wanted to run this on weak hardware, that might be reason
enough...  It might also make it easier to filter our management frames
(EAPOL, etc), but we should be able to do that easily enough in user-space
with a small bit of work.

Thanks,
Ben

>
> -Sam
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Bridging wired to STA interfaces.

[Sam Leffler]

On Wed, Aug 3, 2011 at 5:44 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 08/03/2011 03:37 PM, Sam Leffler wrote:
>>
>> On Tue, Aug 2, 2011 at 10:33 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> We have some interest in being able to bridge wired systems to
>>> (virtual) STA interfaces, primarily for using third-party
>>> traffic generation tools over virtual stations.
>>>
>>> I was thinking of writing a sta-bridge module that mapped
>>> incoming packets on a wired interface to a STA with MAC
>>> that matched the source MAC of the packet.  All packets
>>> received on the STA would be forwarded un-modified out
>>> the wired port.
>>>
>>> I think this would allow someone to create a STA interface
>>> with MAC matching a PC connected to the wired port and effectively
>>> have it be a transparent bridge between STA and PC.
>>>
>>> Has anyone attempted something like this before?
>>>
>>> Any interest in having this feature in the upstream kernel?
>>
>> You've just described what's done in several products and it is indeed
>> useful.  The main issue is supporting it can incur overhead so you may
>> want to make it a compile-time option.
>
> I got some basic functionality working today with some
> user-space bridging code I've already written for other purposes...
>
> Can you think of any reason (beyond a bit of performance) that
> this should be in the kernel?

Doing it in user space seems fine to start.  All the examples I can
think of are on minimal embedded platforms where taking the user-space
hit is infeasible.  All the wireless devices that are interesting can
do this in h/w w/ only minimal kernel support (except for the vif
setup).

FWIW the overhead I was referring to is in the kernel.  A many-to-1
mapping of STA<->AP can be more expensive to support than 1-1.  But
since you already support multi-sta you're already paying the price.

>
> My target hardware is fast enough that copying through user-space
> at moderate (ie, fast as STA can go) speeds isn't too big of a deal, but
> if someone wanted to run this on weak hardware, that might be reason
> enough...  It might also make it easier to filter our management frames
> (EAPOL, etc), but we should be able to do that easily enough in user-space
> with a small bit of work.

Setting up and tearing down the sta's in response to wired traffic was
always the fun part.  Everything else was straightforward from what I
can recall.

-Sam

Re: Bridging wired to STA interfaces.

[Ben Greear]

On 08/09/2011 11:11 AM, Sam Leffler wrote:
> On Wed, Aug 3, 2011 at 5:44 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 08/03/2011 03:37 PM, Sam Leffler wrote:
>>>
>>> On Tue, Aug 2, 2011 at 10:33 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>
>>>> We have some interest in being able to bridge wired systems to
>>>> (virtual) STA interfaces, primarily for using third-party
>>>> traffic generation tools over virtual stations.
>>>>
>>>> I was thinking of writing a sta-bridge module that mapped
>>>> incoming packets on a wired interface to a STA with MAC
>>>> that matched the source MAC of the packet.  All packets
>>>> received on the STA would be forwarded un-modified out
>>>> the wired port.
>>>>
>>>> I think this would allow someone to create a STA interface
>>>> with MAC matching a PC connected to the wired port and effectively
>>>> have it be a transparent bridge between STA and PC.
>>>>
>>>> Has anyone attempted something like this before?
>>>>
>>>> Any interest in having this feature in the upstream kernel?
>>>
>>> You've just described what's done in several products and it is indeed
>>> useful.  The main issue is supporting it can incur overhead so you may
>>> want to make it a compile-time option.
>>
>> I got some basic functionality working today with some
>> user-space bridging code I've already written for other purposes...
>>
>> Can you think of any reason (beyond a bit of performance) that
>> this should be in the kernel?
>
> Doing it in user space seems fine to start.  All the examples I can
> think of are on minimal embedded platforms where taking the user-space
> hit is infeasible.  All the wireless devices that are interesting can
> do this in h/w w/ only minimal kernel support (except for the vif
> setup).
>
> FWIW the overhead I was referring to is in the kernel.  A many-to-1
> mapping of STA<->AP can be more expensive to support than 1-1.  But
> since you already support multi-sta you're already paying the price.
>
>>
>> My target hardware is fast enough that copying through user-space
>> at moderate (ie, fast as STA can go) speeds isn't too big of a deal, but
>> if someone wanted to run this on weak hardware, that might be reason
>> enough...  It might also make it easier to filter our management frames
>> (EAPOL, etc), but we should be able to do that easily enough in user-space
>> with a small bit of work.
>
> Setting up and tearing down the sta's in response to wired traffic was
> always the fun part.  Everything else was straightforward from what I
> can recall.

I think I'll just force user to create an STA with matching MAC (for the
MAC of the PC/whatever to be bridged).  Ath9k and ath5k can support at
least 128 stations, so that will be plenty for our uses...

We saw some problems changing MAC on STA after they were created, but
it seems to be ok if we just create it with correct STA the first time,
and we'll try to figure out why changing MAC was acting weird as well.

Thanks,
Ben

>
> -Sam


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Bridging wired to STA interfaces.

[Adrian Chadd]

On 11 August 2011 15:14, Ben Greear <greearb@candelatech.com> wrote:

> I think I'll just force user to create an STA with matching MAC (for the
> MAC of the PC/whatever to be bridged).  Ath9k and ath5k can support at
> least 128 stations, so that will be plenty for our uses...
>
> We saw some problems changing MAC on STA after they were created, but
> it seems to be ok if we just create it with correct STA the first time,
> and we'll try to figure out why changing MAC was acting weird as well.

Oh wow, that's a cool use of multi-STA support. Now I want to get it
working in FreeBSD.

I think I may need to corner you sometime and sort out exactly how
this works. Nice thinking Ben!


Adrian

Re: Bridging wired to STA interfaces.

[Ben Greear]

On 08/11/2011 01:48 AM, Adrian Chadd wrote:
> On 11 August 2011 15:14, Ben Greear<greearb@candelatech.com>  wrote:
>
>> I think I'll just force user to create an STA with matching MAC (for the
>> MAC of the PC/whatever to be bridged).  Ath9k and ath5k can support at
>> least 128 stations, so that will be plenty for our uses...
>>
>> We saw some problems changing MAC on STA after they were created, but
>> it seems to be ok if we just create it with correct STA the first time,
>> and we'll try to figure out why changing MAC was acting weird as well.
>
> Oh wow, that's a cool use of multi-STA support. Now I want to get it
> working in FreeBSD.
>
> I think I may need to corner you sometime and sort out exactly how
> this works. Nice thinking Ben!

Just to follow up on this, I believe I now have this working
with a user-space bridge.  It's part of my proprietary app, but
here's the basic algorithm in case someone else wants to try
this:

Network setup:

server -- AP {{{}}} station-bridge  -- clients

For each client, create a virtual station on the station-bridge machine
with the same MAC as the client.

Packets coming in a station interface are sent out the wired interface
unless they are 802.1X frames (0x888e ethernet type).  These
are just dropped.  If destination MAC is broadcast, it is changed
to be that of the STA's MAC.  This is probably not required, but seems
a good optimization and I cannot think of any reason not to...I may be
wrong however.

Packets coming in the ethernet interface are mapped onto the STA that
matches the source MAC of the ethernet frame.  Packets that do not match
are silently discarded.

You have to explicitly disable IPv4/6 routing on the bridge interfaces
or the OS might try to route them.  You should also disable ARP and such.
You must remove all IP addresses from the bridge interfaces.  You should
probably disable LRO and such as well.  In general, the idea is to make
the packet socket the only active consumer of the packets so that the OS
doesn't muck with things and toss un-expected packets onto the network.

Use packet sockets to read/write the packets.


This could all be done in the kernel, but aside from saving some packet
copies to/from user-space, it seems like a user-space app is sufficient.

I tested this with ath9k in the AP and virtual station machines.  The
pertinent bits should be available in standard upstream kernels,
but we're using our hacked kernels.

If anyone writes a stand-alone app to do this, I'm interested to know.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com