The patch differenciate between 802.3 frames and Ethernet frames,
which are the usual ones.
802.3 frames have a length field where Ethernet frames have the protocol field.
The key to differenciate between them is protocols ids start in 0x0600 (1536)
but length is lower.

Spanning Tree Protocol Frames (BPDUs) use 802.3 frames.

That is the section in 802.3 about this issue, see b):
-------------------------------------------------
3.2.6 Length/Type field
This two-octet field takes one of two meanings, depending on its
numeric value. For numerical evaluation,
the first octet is the most significant octet of this field.
   a) If the value of this field is less than or equal to the value of
maxValidFrame (as specified in 4.2.7.1),
         then the Length/Type field indicates the number of MAC client
data octets contained in the subse-
         quent data field of the frame (Length interpretation).
   b) If the value of this field is greater than or equal to 1536
decimal (equal to 0600 hexadecimal), then
         the Length/Type field indicates the nature of the MAC client
protocol (Type interpretation).
         The Length and Type interpretations of this field are
mutually exclusive.
         When used as a Type field, it is the responsibility of the
MAC client to ensure that the MAC client
         operates properly when the MAC sublayer pads the supplied
data, as discussed in 3.2.7.
Regardless of the interpretation of the Length/Type field, if the
length of the data field is less than the mini-
mum required for proper operation of the protocol, a PAD field (a
sequence of octets) will be added at the
end of the data field but prior to the FCS field, specified below. The
procedure that determines the size of the
PAD field is specified in 4.2.8. The Length/Type field is transmitted
and received with the high order octet
first.
-------------------------------------------------

The function modified by the patch,
[EMAIL PROTECTED]/ieee80211_input.c, is a version of
kernel's
[EMAIL PROTECTED]/ethernet/eth.c:

[EMAIL PROTECTED]/ieee80211_input.c (madwifi)
-------------------------------------------------------
/*
 * The kernel version of this function alters the skb in a manner
 * inconsistent with dev->hard_header_len header reservation. This
 * is a rewrite of the portion of eth_type_trans() that we need.
 */
static __be16
ath_eth_type_trans(struct sk_buff *skb, struct net_device *dev)
{
...

but misses protocol handling:

[EMAIL PROTECTED]/ethernet/eth.c (kernel)
------------------------------------------
...
        if (ntohs(eth->h_proto) >= 1536)
                return eth->h_proto;

        rawp = skb->data;

        /*
         *      This is a magic hack to spot IPX packets. Older Novell breaks
         *      the protocol design and runs IPX over 802.3 without an 802.2 LLC
         *      layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. This
         *      won't work for fault tolerant netware but does for the rest.
         */
        if (*(unsigned short *)rawp == 0xFFFF)
                return htons(ETH_P_802_3);

        /*
         *      Real 802.2 LLC
         */
        return htons(ETH_P_802_2);
}

A new patch including the IPX packet detection taken from kernel should be:

Index: package/madwifi/patches/999-802_2_frame.patch
===================================================================
--- package/madwifi/patches/999-802_2_frame.patch       (revision 0)
+++ package/madwifi/patches/999-802_2_frame.patch       (revision 0)
@@ -0,0 +1,36 @@
+--- a/net80211/ieee80211_input.c
++++ b/net80211/ieee80211_input.c
+@@ -4407,6 +4407,7 @@
+ ath_eth_type_trans(struct sk_buff *skb, struct net_device *dev)
+ {
+       struct ethhdr *eth;
++      unsigned char *rawp;
+
+       skb_reset_mac_header(skb);
+       skb_pull(skb, ETH_HLEN);
+@@ -4421,7 +4422,24 @@
+               if (memcmp(eth->h_dest, dev->dev_addr, ETH_ALEN))
+                       skb->pkt_type = PACKET_OTHERHOST;
+
+-      return eth->h_proto;
++      if (ntohs(eth->h_proto) >= 1536)
++              return eth->h_proto;
++
++      rawp = skb->data;
++
++      /*
++       *      This is a magic hack to spot IPX packets. Older Novell breaks
++       *      the protocol design and runs IPX over 802.3 without an 802.2 LLC
++       *      layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. This
++       *      won't work for fault tolerant netware but does for the rest.
++       */
++      if (*(unsigned short *)rawp == 0xFFFF)
++              return htons(ETH_P_802_3);
++
++      /*
++       *      Real 802.2 LLC
++       */
++      return htons(ETH_P_802_2);
+ }
+ #endif
+

I have tested it too. It makes STP works, but I didn't test IPX detection.

2008/11/18 David Manso <[EMAIL PROTECTED]>:
> The patch differenciate between 802.3 frames and Ethernet frames,
> which are the usual ones.
> 802.3 frames have a length field where Ethernet frames have the protocol 
> field.
> The key to differenciate between them is protocols ids start in 0x0600 (1536)
> but length is lower.
>
> Spanning Tree Protocol Frames (BPDUs) use 802.3 frames.
>
> That is the section in 802.3 about this issue, see b):
> -------------------------------------------------
> 3.2.6 Length/Type field
> This two-octet field takes one of two meanings, depending on its
> numeric value. For numerical evaluation,
> the first octet is the most significant octet of this field.
>   a) If the value of this field is less than or equal to the value of
> maxValidFrame (as specified in 4.2.7.1),
>         then the Length/Type field indicates the number of MAC client
> data octets contained in the subse-
>         quent data field of the frame (Length interpretation).
>   b) If the value of this field is greater than or equal to 1536
> decimal (equal to 0600 hexadecimal), then
>         the Length/Type field indicates the nature of the MAC client
> protocol (Type interpretation).
>         The Length and Type interpretations of this field are
> mutually exclusive.
>         When used as a Type field, it is the responsibility of the
> MAC client to ensure that the MAC client
>         operates properly when the MAC sublayer pads the supplied
> data, as discussed in 3.2.7.
> Regardless of the interpretation of the Length/Type field, if the
> length of the data field is less than the mini-
> mum required for proper operation of the protocol, a PAD field (a
> sequence of octets) will be added at the
> end of the data field but prior to the FCS field, specified below. The
> procedure that determines the size of the
> PAD field is specified in 4.2.8. The Length/Type field is transmitted
> and received with the high order octet
> first.
> -------------------------------------------------
>
> The function modified by the patch,
> [EMAIL PROTECTED]/ieee80211_input.c, is a version of
> kernel's
> [EMAIL PROTECTED]/ethernet/eth.c:
>
> [EMAIL PROTECTED]/ieee80211_input.c (madwifi)
> -------------------------------------------------------
> /*
>  * The kernel version of this function alters the skb in a manner
>  * inconsistent with dev->hard_header_len header reservation. This
>  * is a rewrite of the portion of eth_type_trans() that we need.
>  */
> static __be16
> ath_eth_type_trans(struct sk_buff *skb, struct net_device *dev)
> {
> ...
>
> but misses protocol handling:
>
> [EMAIL PROTECTED]/ethernet/eth.c (kernel)
> ------------------------------------------
> ...
>        if (ntohs(eth->h_proto) >= 1536)
>                return eth->h_proto;
>
>        rawp = skb->data;
>
>        /*
>         *      This is a magic hack to spot IPX packets. Older Novell breaks
>         *      the protocol design and runs IPX over 802.3 without an 802.2 
> LLC
>         *      layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. 
> This
>         *      won't work for fault tolerant netware but does for the rest.
>         */
>        if (*(unsigned short *)rawp == 0xFFFF)
>                return htons(ETH_P_802_3);
>
>        /*
>         *      Real 802.2 LLC
>         */
>        return htons(ETH_P_802_2);
> }
>
> A new patch including the IPX packet detection taken from kernel should be:
>
> Index: package/madwifi/patches/999-802_2_frame.patch
> ===================================================================
> --- package/madwifi/patches/999-802_2_frame.patch       (revision 0)
> +++ package/madwifi/patches/999-802_2_frame.patch       (revision 0)
> @@ -0,0 +1,36 @@
> +--- a/net80211/ieee80211_input.c
> ++++ b/net80211/ieee80211_input.c
> +@@ -4407,6 +4407,7 @@
> + ath_eth_type_trans(struct sk_buff *skb, struct net_device *dev)
> + {
> +       struct ethhdr *eth;
> ++      unsigned char *rawp;
> +
> +       skb_reset_mac_header(skb);
> +       skb_pull(skb, ETH_HLEN);
> +@@ -4421,7 +4422,24 @@
> +               if (memcmp(eth->h_dest, dev->dev_addr, ETH_ALEN))
> +                       skb->pkt_type = PACKET_OTHERHOST;
> +
> +-      return eth->h_proto;
> ++      if (ntohs(eth->h_proto) >= 1536)
> ++              return eth->h_proto;
> ++
> ++      rawp = skb->data;
> ++
> ++      /*
> ++       *      This is a magic hack to spot IPX packets. Older Novell breaks
> ++       *      the protocol design and runs IPX over 802.3 without an 802.2 
> LLC
> ++       *      layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. 
> This
> ++       *      won't work for fault tolerant netware but does for the rest.
> ++       */
> ++      if (*(unsigned short *)rawp == 0xFFFF)
> ++              return htons(ETH_P_802_3);
> ++
> ++      /*
> ++       *      Real 802.2 LLC
> ++       */
> ++      return htons(ETH_P_802_2);
> + }
> + #endif
> +
>
> I have tested it too. It makes STP works, but I didn't test IPX detection.
>
> 2008/11/18 Stanislav Sinyagin <[EMAIL PROTECTED]>:
>>
>>
>>
>>
>> ----- Original Message ----
>>> From: Felix Fietkau <[EMAIL PROTECTED]>
>>> > ++    if (ntohs(eth->h_proto) >= 1536)
>>> > ++        return eth->h_proto;
>>> > ++    return htons(ETH_P_802_2);
>>> The 'ntohs(eth->h_proto) >= 1536' part looks weird. What is 1536
>>> supposed to be? Could you explain that part to me or did you just
>>> copy the patch from the madwifi trac?
>>> I'd like to understand this fix before applying it.
>>
>> I suppose the answer is here
>> http://www.erg.abdn.ac.uk/ipdvb/archive/0405/msg00001.html
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to