RE: SNAP headers, RFC1042
The problem is that when bridging the bridge code gets run before the protocol handlers, hence psnap never sees the frame before it is output again. In addition any ingress qdisc has already been run before the protocol handlers, so the protocol is wrong there - hence my suggestion of using the _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 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
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
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: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
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
