SNAP headers, RFC1042
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 - 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
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
RE: SNAP headers, RFC1042
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
Re: SNAP headers, RFC1042
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 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 Then psnap should reset skb-protocol. - 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
