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 processor is the in the bridge the skb->protocol is set to 802_2_LLC, 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 headers, RFC1042 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. > Would it make sense to add the code to eth_trans_type or create a > ieee80211_trans_type? > > Advantages: > 1) Better code reuse > 2) Frame data is no longer moved or touched unless bridging. > > Disadvantage: > 1) things like dhcpd need to understand SNAP header format (unless > frames going to a raw socket have the header re-written) > 2) bridge code needs to rewrite frames according to the output port's > needed header type > > Comments? Suggestions? > > Simon We already have a snap processor, so why not just do a netif_receive_skb on the frame. You need to select LLC in the kernel config with that driver. -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
