_type_trans as a place to do it.
Simon
-Original Message-
From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
Sent: Friday, February 03, 2006 1:25 PM
To: Simon Barber
Cc: netdev@vger.kernel.org; Jouni Malinen
Subject: Re: SNAP headers, RFC1042
On Fri, 3 Feb 2006 13:22:48 -0800
"Simon B
On Fri, 3 Feb 2006 13:22:48 -0800
"Simon Barber" <[EMAIL PROTECTED]> wrote:
> The main reason is bridging - the header format needs to be different
> for different ports. Ideally I'd like to see a single snap processor
> used in both cases (local receive & bridging). One problem with the
> current
, not to the real protocol type. This prevents ebtables rules
and tc from working correctly.
Simon
-Original Message-
From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
Sent: Friday, February 03, 2006 1:19 PM
To: Simon Barber
Cc: netdev@vger.kernel.org; Jouni Malinen
Subject: Re: SNAP head
On Fri, 3 Feb 2006 13:08:17 -0800
"Simon Barber" <[EMAIL PROTECTED]> wrote:
> Currently many wireless drivers handle SNAP->Ethernet header processing
> - this is an obvious candidate for factoring out - and might possibly be
> something that should be moved out of the wireless code completely.
> W
Currently many wireless drivers handle SNAP->Ethernet header processing
- this is an obvious candidate for factoring out - and might possibly be
something that should be moved out of the wireless code completely.
Would it make sense to add the code to eth_trans_type or create a
ieee80211_trans_type
