[PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[Dimitrios P. Bouras]

Practical use cases exist where being able to receive Ethernet packets
encapsulated in LLC SNAP is useful, while at the same time encapsulating
replies (transmitting back) in LLC SNAP is not required. Accordingly, this
is not an attempt to add full-blown support for IP over LLC SNAP, only a
"hack" that "just works" -- see Alan's comment on the the Linux-kernel
list on this subject ("Linux supports LLC/SNAP and various things over it
(IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
bodies driven bogosities which nobody ever actually deployed" --
http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html). It is worth
noting, however, that the networking stack in all recent versions of MS
Windows behaves in the exact same way (receives LLC/SNAP-encapsulated IP
just fine but replies in plain IP), even though this doesn't appear to be
documented anywhere.

Signed-off-by: Dimitrios Bouras <dimitrios.bouras@gmail.com>
---
I hope I've addressed this properly - please be gentle in guiding me if otherwise (it's my first).

Many thanks,
Dimitri

 net/ethernet/eth.c | 59 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 17 deletions(-)

diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index ebcc812735a4..1df5446af922 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -15,23 +15,24 @@
  *		Alan Cox, <gw4pts@gw4pts.ampr.org>
  *
  * Fixes:
- *		Mr Linux	: Arp problems
- *		Alan Cox	: Generic queue tidyup (very tiny here)
- *		Alan Cox	: eth_header ntohs should be htons
- *		Alan Cox	: eth_rebuild_header missing an htons and
- *				  minor other things.
- *		Tegge		: Arp bug fixes.
- *		Florian		: Removed many unnecessary functions, code cleanup
- *				  and changes for new arp and skbuff.
- *		Alan Cox	: Redid header building to reflect new format.
- *		Alan Cox	: ARP only when compiled with CONFIG_INET
- *		Greg Page	: 802.2 and SNAP stuff.
- *		Alan Cox	: MAC layer pointers/new format.
- *		Paul Gortmaker	: eth_copy_and_sum shouldn't csum padding.
- *		Alan Cox	: Protect against forwarding explosions with
- *				  older network drivers and IFF_ALLMULTI.
- *	Christer Weinigel	: Better rebuild header message.
- *             Andrew Morton    : 26Feb01: kill ether_setup() - use netdev_boot_setup().
+ *		Mr Linux		: Arp problems
+ *		Alan Cox		: Generic queue tidyup (very tiny here)
+ *		Alan Cox		: eth_header ntohs should be htons
+ *		Alan Cox		: eth_rebuild_header missing an htons and
+ *					  minor other things.
+ *		Tegge			: Arp bug fixes.
+ *		Florian			: Removed many unnecessary functions, code cleanup
+ *					  and changes for new arp and skbuff.
+ *		Alan Cox		: Redid header building to reflect new format.
+ *		Alan Cox		: ARP only when compiled with CONFIG_INET
+ *		Greg Page		: 802.2 and SNAP stuff.
+ *		Alan Cox		: MAC layer pointers/new format.
+ *		Paul Gortmaker		: eth_copy_and_sum shouldn't csum padding.
+ *		Alan Cox		: Protect against forwarding explosions with
+ *					  older network drivers and IFF_ALLMULTI.
+ *		Christer Weinigel	: Better rebuild header message.
+ *		Andrew Morton		: 26Feb01: kill ether_setup() - use netdev_boot_setup().
+ *		Dimitrios Bouras	: May 2021: transparently receive Ethernet over LLC/SNAP.
  */
 #include <linux/module.h>
 #include <linux/types.h>
@@ -157,6 +158,7 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
 	unsigned short _service_access_point;
 	const unsigned short *sap;
 	const struct ethhdr *eth;
+	const unsigned char *esn;
 
 	skb->dev = dev;
 	skb_reset_mac_header(skb);
@@ -185,9 +187,32 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
 	if (unlikely(netdev_uses_dsa(dev)))
 		return htons(ETH_P_XDSA);
 
+	/* The protocol field is > 0x0600 so this is an Ethernet frame */
 	if (likely(eth_proto_is_802_3(eth->h_proto)))
 		return eth->h_proto;
 
+	/* Check for Ethernet protocol packets encapsulated in LCC SNAP.
+	 * If found, de-encapsulate transparently and feed them upwards
+	 * as if they were received inside normal Ethernet frames.
+	 *
+	 *    6      6     2      1      1     1      5    0-1492 0-38    4
+	 * +------+-----+-----+------+------+-----+-------+------+-----+-----+
+	 * | Dest | Src | Len | DSAP | SSAP | CTL | Proto | Data | Pad | FCS |
+	 * |      |     |     |  xAA |  xAA | x03 |       |      |     |     |
+	 * +------+-----+-----+------+------+-----+-------+------+-----+-----+
+	 */
+	esn = skb->data;
+	if (esn[0] == 0xAA && esn[1] == 0xAA && esn[2] == 0x03 &&
+	    esn[3] == 0x00 && esn[4] == 0x00 && esn[5] == 0x00) {
+		/* pull LLC header (3 bytes) and protocol ID (5 bytes) */
+		/* then recalculate the FCS checksum. After the call, */
+		/* skb->data will be pointing to the IP protocol payload */
+		skb_pull_rcsum(skb, 8);
+		/* pretend that this is an Ethernet frame by returning */
+		/* the encapsulated prototol code (2 LSBytes of Proto) */
+		return *(__be16 *)(esn + 6);
+	}
+
 	/*
 	 *      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
-- 
2.34.1

RE: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[David Laight]

From: Dimitrios P. Bouras
> Sent: 05 March 2022 00:33
> 
> Practical use cases exist where being able to receive Ethernet packets
> encapsulated in LLC SNAP is useful, while at the same time encapsulating
> replies (transmitting back) in LLC SNAP is not required.

I think you need to be more explicit.
If received frames have the SNAP header I'd expect transmitted ones
to need it as well.

> Accordingly, this
> is not an attempt to add full-blown support for IP over LLC SNAP, only a
> "hack" that "just works" -- see Alan's comment on the the Linux-kernel
> list on this subject ("Linux supports LLC/SNAP and various things over it
> (IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
> bodies driven bogosities which nobody ever actually deployed" --
> http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html).

IP over SNAP is needed for Token ring networks (esp. 16M ones) where the
mtu is much larger than 1500 bytes.

It is all too long ago though, I can't remember whether token ring
tends to bit-reverse the MAC address (like FDDI does) which means you
can't just bridge ARP packets.
So you need a better bridge - and that can add/remove some SNAP headers.

...

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[Dimitrios Bouras]

On 2022-03-04 11:02 p.m., David Laight wrote:
> From: Dimitrios P. Bouras
>> Sent: 05 March 2022 00:33
>>
>> Practical use cases exist where being able to receive Ethernet packets
>> encapsulated in LLC SNAP is useful, while at the same time encapsulating
>> replies (transmitting back) in LLC SNAP is not required.
> I think you need to be more explicit.
> If received frames have the SNAP header I'd expect transmitted ones
> to need it as well.

Hi David,

Yes, in the general case, I agree. In the existing implementation of the
stack,however, (as far as I have researched) there is nothing available to
process IP over LLC/SNAP for Ethernet interfaces.

In the thread I've quoted in my explanation Alan Cox says so explicitly:
https://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html

Maybe I should change the text to read:

   Practical use cases exist where being able to receive IP packets
   encapsulated in LLC/SNAP over an Ethernet interface is useful, while
   at the same time encapsulating replies (transmitting back) in LLC/SNAP
   is not required.

Would that be better? Maybe I should also change the following sentence:

   Accordingly, this is not an attempt to add full-blown support for IP over
   LLC/SNAP for Ethernet devices, only a "hack" that "just works".

>> Accordingly, this
>> is not an attempt to add full-blown support for IP over LLC SNAP, only a
>> "hack" that "just works" -- see Alan's comment on the the Linux-kernel
>> list on this subject ("Linux supports LLC/SNAP and various things over it
>> (IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
>> bodies driven bogosities which nobody ever actually deployed" --
>> http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html).
> IP over SNAP is needed for Token ring networks (esp. 16M ones) where the
> mtu is much larger than 1500 bytes.
>
> It is all too long ago though, I can't remember whether token ring
> tends to bit-reverse the MAC address (like FDDI does) which means you
> can't just bridge ARP packets.
> So you need a better bridge - and that can add/remove some SNAP headers.
I've read that some routers are able to do this but it is out of scope for my
simple patch. The goal is just to be able to receive LLC/SNAP-encapsulated
IP packets over an Ethernet interface.

>
> ...
>
> 	David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

Additional feedback you may have is greatly appreciated.

Many thanks,
Dimitri

Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[Stephen Hemminger]

On Sun, 6 Mar 2022 13:09:03 -0800
Dimitrios Bouras <dimitrios.bouras@gmail.com> wrote:

> On 2022-03-04 11:02 p.m., David Laight wrote:
> > From: Dimitrios P. Bouras  
> >> Sent: 05 March 2022 00:33
> >>
> >> Practical use cases exist where being able to receive Ethernet packets
> >> encapsulated in LLC SNAP is useful, while at the same time encapsulating
> >> replies (transmitting back) in LLC SNAP is not required.  
> > I think you need to be more explicit.
> > If received frames have the SNAP header I'd expect transmitted ones
> > to need it as well.  
> 
> Hi David,
> 
> Yes, in the general case, I agree. In the existing implementation of the
> stack,however, (as far as I have researched) there is nothing available to
> process IP over LLC/SNAP for Ethernet interfaces.
> 
> In the thread I've quoted in my explanation Alan Cox says so explicitly:
> https://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html
> 
> Maybe I should change the text to read:
> 
>    Practical use cases exist where being able to receive IP packets
>    encapsulated in LLC/SNAP over an Ethernet interface is useful, while
>    at the same time encapsulating replies (transmitting back) in LLC/SNAP
>    is not required.
> 
> Would that be better? Maybe I should also change the following sentence:
> 
>    Accordingly, this is not an attempt to add full-blown support for IP over
>    LLC/SNAP for Ethernet devices, only a "hack" that "just works".
> 
> >> Accordingly, this
> >> is not an attempt to add full-blown support for IP over LLC SNAP, only a
> >> "hack" that "just works" -- see Alan's comment on the the Linux-kernel
> >> list on this subject ("Linux supports LLC/SNAP and various things over it
> >> (IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
> >> bodies driven bogosities which nobody ever actually deployed" --
> >> http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html).  
> > IP over SNAP is needed for Token ring networks (esp. 16M ones) where the
> > mtu is much larger than 1500 bytes.
> >
> > It is all too long ago though, I can't remember whether token ring
> > tends to bit-reverse the MAC address (like FDDI does) which means you
> > can't just bridge ARP packets.
> > So you need a better bridge - and that can add/remove some SNAP headers.  
> I've read that some routers are able to do this but it is out of scope for my
> simple patch. The goal is just to be able to receive LLC/SNAP-encapsulated
> IP packets over an Ethernet interface.
> 
> >
> > ...
> >
> > 	David
> >
> > -
> > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > Registration No: 1397386 (Wales)  
> 
> Additional feedback you may have is greatly appreciated.
> 
> Many thanks,
> Dimitri
> 

The Linux device model is to create a layered net device. See vlan, vxlan, etc.
It should be possible to do this with the existing 802 code in Linux, there
is some in psnap.c but don't think there is a way to use this for IP.

Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[Dimitrios Bouras]

On Mon, Mar 7, 2022 at 8:08 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Sun, 6 Mar 2022 13:09:03 -0800
> Dimitrios Bouras <dimitrios.bouras@gmail.com> wrote:
>
> > On 2022-03-04 11:02 p.m., David Laight wrote:
> > > From: Dimitrios P. Bouras
> > >> Sent: 05 March 2022 00:33
> > >>
> > >> Practical use cases exist where being able to receive Ethernet packets
> > >> encapsulated in LLC SNAP is useful, while at the same time encapsulating
> > >> replies (transmitting back) in LLC SNAP is not required.
> > > I think you need to be more explicit.
> > > If received frames have the SNAP header I'd expect transmitted ones
> > > to need it as well.
> >
> > Hi David,
> >
> > Yes, in the general case, I agree. In the existing implementation of the
> > stack,however, (as far as I have researched) there is nothing available to
> > process IP over LLC/SNAP for Ethernet interfaces.
> >
> > In the thread I've quoted in my explanation Alan Cox says so explicitly:
> > https://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html
> >
> > Maybe I should change the text to read:
> >
> >    Practical use cases exist where being able to receive IP packets
> >    encapsulated in LLC/SNAP over an Ethernet interface is useful, while
> >    at the same time encapsulating replies (transmitting back) in LLC/SNAP
> >    is not required.
> >
> > Would that be better? Maybe I should also change the following sentence:
> >
> >    Accordingly, this is not an attempt to add full-blown support for IP over
> >    LLC/SNAP for Ethernet devices, only a "hack" that "just works".
> >
> > >> Accordingly, this
> > >> is not an attempt to add full-blown support for IP over LLC SNAP, only a
> > >> "hack" that "just works" -- see Alan's comment on the the Linux-kernel
> > >> list on this subject ("Linux supports LLC/SNAP and various things over it
> > >> (IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
> > >> bodies driven bogosities which nobody ever actually deployed" --
> > >> http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html).
> > > IP over SNAP is needed for Token ring networks (esp. 16M ones) where the
> > > mtu is much larger than 1500 bytes.
> > >
> > > It is all too long ago though, I can't remember whether token ring
> > > tends to bit-reverse the MAC address (like FDDI does) which means you
> > > can't just bridge ARP packets.
> > > So you need a better bridge - and that can add/remove some SNAP headers.
> > I've read that some routers are able to do this but it is out of scope for my
> > simple patch. The goal is just to be able to receive LLC/SNAP-encapsulated
> > IP packets over an Ethernet interface.
> >
> > >
> > > ...
> > >
> > >     David
> > >
> > > -
> > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > Registration No: 1397386 (Wales)
> >
> > Additional feedback you may have is greatly appreciated.
> >
> > Many thanks,
> > Dimitri
> >
>
> The Linux device model is to create a layered net device. See vlan, vxlan, etc.
> It should be possible to do this with the existing 802 code in Linux, there
> is some in psnap.c but don't think there is a way to use this for IP.

Hi Stephen,

Thank you for taking the time to send feedback. Yes, that is the route
I took initially, looking at how to implement this through existing SNAP
protocol support. In the end, it was an awful lot of work for a very
simple requirement -- in  my mind, small is better.

Are there drawbacks to my approach for this very special case that you
think are detrimental to the device model? As I understand, encapsulated
IP shouldn't be coming through the Ethernet interface. When I was coding
and testing this patch I felt it may be justified in the same way as the
"magic hack" for raw IPX a bit further down in eth_type_trans().

Looking forward to your additional thoughts or guidance,
Dimitri

Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[Stephen Hemminger]

On Mon, 7 Mar 2022 09:45:52 -0800
Dimitrios Bouras <dimitrios.bouras@gmail.com> wrote:

> On Mon, Mar 7, 2022 at 8:08 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Sun, 6 Mar 2022 13:09:03 -0800
> > Dimitrios Bouras <dimitrios.bouras@gmail.com> wrote:
> >  
> > > On 2022-03-04 11:02 p.m., David Laight wrote:  
> > > > From: Dimitrios P. Bouras  
> > > >> Sent: 05 March 2022 00:33
> > > >>
> > > >> Practical use cases exist where being able to receive Ethernet packets
> > > >> encapsulated in LLC SNAP is useful, while at the same time encapsulating
> > > >> replies (transmitting back) in LLC SNAP is not required.  
> > > > I think you need to be more explicit.
> > > > If received frames have the SNAP header I'd expect transmitted ones
> > > > to need it as well.  
> > >
> > > Hi David,
> > >
> > > Yes, in the general case, I agree. In the existing implementation of the
> > > stack,however, (as far as I have researched) there is nothing available to
> > > process IP over LLC/SNAP for Ethernet interfaces.
> > >
> > > In the thread I've quoted in my explanation Alan Cox says so explicitly:
> > > https://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html
> > >
> > > Maybe I should change the text to read:
> > >
> > >    Practical use cases exist where being able to receive IP packets
> > >    encapsulated in LLC/SNAP over an Ethernet interface is useful, while
> > >    at the same time encapsulating replies (transmitting back) in LLC/SNAP
> > >    is not required.
> > >
> > > Would that be better? Maybe I should also change the following sentence:
> > >
> > >    Accordingly, this is not an attempt to add full-blown support for IP over
> > >    LLC/SNAP for Ethernet devices, only a "hack" that "just works".
> > >  
> > > >> Accordingly, this
> > > >> is not an attempt to add full-blown support for IP over LLC SNAP, only a
> > > >> "hack" that "just works" -- see Alan's comment on the the Linux-kernel
> > > >> list on this subject ("Linux supports LLC/SNAP and various things over it
> > > >> (IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
> > > >> bodies driven bogosities which nobody ever actually deployed" --
> > > >> http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html).  
> > > > IP over SNAP is needed for Token ring networks (esp. 16M ones) where the
> > > > mtu is much larger than 1500 bytes.
> > > >
> > > > It is all too long ago though, I can't remember whether token ring
> > > > tends to bit-reverse the MAC address (like FDDI does) which means you
> > > > can't just bridge ARP packets.
> > > > So you need a better bridge - and that can add/remove some SNAP headers.  
> > > I've read that some routers are able to do this but it is out of scope for my
> > > simple patch. The goal is just to be able to receive LLC/SNAP-encapsulated
> > > IP packets over an Ethernet interface.
> > >  
> > > >
> > > > ...
> > > >
> > > >     David
> > > >
> > > > -
> > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > > Registration No: 1397386 (Wales)  
> > >
> > > Additional feedback you may have is greatly appreciated.
> > >
> > > Many thanks,
> > > Dimitri
> > >  
> >
> > The Linux device model is to create a layered net device. See vlan, vxlan, etc.
> > It should be possible to do this with the existing 802 code in Linux, there
> > is some in psnap.c but don't think there is a way to use this for IP.  
> 
> Hi Stephen,
> 
> Thank you for taking the time to send feedback. Yes, that is the route
> I took initially, looking at how to implement this through existing SNAP
> protocol support. In the end, it was an awful lot of work for a very
> simple requirement -- in  my mind, small is better.
> 
> Are there drawbacks to my approach for this very special case that you
> think are detrimental to the device model? As I understand, encapsulated
> IP shouldn't be coming through the Ethernet interface. When I was coding
> and testing this patch I felt it may be justified in the same way as the
> "magic hack" for raw IPX a bit further down in eth_type_trans().
> 
> Looking forward to your additional thoughts or guidance,
> Dimitri

The transparent model assumes everyone wants to let these type of packets in.
And that everyone wants 802 and Ethernet to appear as one network.
Most users don't

Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

[Dimitrios Bouras]

On Mon, Mar 7, 2022 at 10:10 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 7 Mar 2022 09:45:52 -0800
> Dimitrios Bouras <dimitrios.bouras@gmail.com> wrote:
>
> > On Mon, Mar 7, 2022 at 8:08 AM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Sun, 6 Mar 2022 13:09:03 -0800
> > > Dimitrios Bouras <dimitrios.bouras@gmail.com> wrote:
> > >
> > > > On 2022-03-04 11:02 p.m., David Laight wrote:
> > > > > From: Dimitrios P. Bouras
> > > > >> Sent: 05 March 2022 00:33
> > > > >>
> > > > >> Practical use cases exist where being able to receive Ethernet packets
> > > > >> encapsulated in LLC SNAP is useful, while at the same time encapsulating
> > > > >> replies (transmitting back) in LLC SNAP is not required.
> > > > > I think you need to be more explicit.
> > > > > If received frames have the SNAP header I'd expect transmitted ones
> > > > > to need it as well.
> > > >
> > > > Hi David,
> > > >
> > > > Yes, in the general case, I agree. In the existing implementation of the
> > > > stack,however, (as far as I have researched) there is nothing available to
> > > > process IP over LLC/SNAP for Ethernet interfaces.
> > > >
> > > > In the thread I've quoted in my explanation Alan Cox says so explicitly:
> > > > https://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html
> > > >
> > > > Maybe I should change the text to read:
> > > >
> > > >    Practical use cases exist where being able to receive IP packets
> > > >    encapsulated in LLC/SNAP over an Ethernet interface is useful, while
> > > >    at the same time encapsulating replies (transmitting back) in LLC/SNAP
> > > >    is not required.
> > > >
> > > > Would that be better? Maybe I should also change the following sentence:
> > > >
> > > >    Accordingly, this is not an attempt to add full-blown support for IP over
> > > >    LLC/SNAP for Ethernet devices, only a "hack" that "just works".
> > > >
> > > > >> Accordingly, this
> > > > >> is not an attempt to add full-blown support for IP over LLC SNAP, only a
> > > > >> "hack" that "just works" -- see Alan's comment on the the Linux-kernel
> > > > >> list on this subject ("Linux supports LLC/SNAP and various things over it
> > > > >> (IPX/Appletalk DDP etc) but not IP over it, as it's one of those standards
> > > > >> bodies driven bogosities which nobody ever actually deployed" --
> > > > >> http://lkml.iu.edu/hypermail/linux/kernel/1107.3/01249.html).
> > > > > IP over SNAP is needed for Token ring networks (esp. 16M ones) where the
> > > > > mtu is much larger than 1500 bytes.
> > > > >
> > > > > It is all too long ago though, I can't remember whether token ring
> > > > > tends to bit-reverse the MAC address (like FDDI does) which means you
> > > > > can't just bridge ARP packets.
> > > > > So you need a better bridge - and that can add/remove some SNAP headers.
> > > > I've read that some routers are able to do this but it is out of scope for my
> > > > simple patch. The goal is just to be able to receive LLC/SNAP-encapsulated
> > > > IP packets over an Ethernet interface.
> > > >
> > > > >
> > > > > ...
> > > > >
> > > > >     David
> > > > >
> > > > > -
> > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > > > Registration No: 1397386 (Wales)
> > > >
> > > > Additional feedback you may have is greatly appreciated.
> > > >
> > > > Many thanks,
> > > > Dimitri
> > > >
> > >
> > > The Linux device model is to create a layered net device. See vlan, vxlan, etc.
> > > It should be possible to do this with the existing 802 code in Linux, there
> > > is some in psnap.c but don't think there is a way to use this for IP.
> >
> > Hi Stephen,
> >
> > Thank you for taking the time to send feedback. Yes, that is the route
> > I took initially, looking at how to implement this through existing SNAP
> > protocol support. In the end, it was an awful lot of work for a very
> > simple requirement -- in  my mind, small is better.
> >
> > Are there drawbacks to my approach for this very special case that you
> > think are detrimental to the device model? As I understand, encapsulated
> > IP shouldn't be coming through the Ethernet interface. When I was coding
> > and testing this patch I felt it may be justified in the same way as the
> > "magic hack" for raw IPX a bit further down in eth_type_trans().
> >
> > Looking forward to your additional thoughts or guidance,
> > Dimitri
>
> The transparent model assumes everyone wants to let these type of packets in.
> And that everyone wants 802 and Ethernet to appear as one network.
> Most users don't

I fully agree but does this include encapsulated IP over 802.2
LLC/SNAP coming in through the Ethernet interface?

Unless I'm mistaken, this patch does nothing to impede LLC/SNAP
traffic from token-ring or FDDI interfaces.