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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220307080834.35660682@hermes.local>
Date:   Mon, 7 Mar 2022 08:08:34 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Dimitrios Bouras <dimitrios.bouras@...il.com>
Cc:     David Laight <David.Laight@...LAB.COM>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP

On Sun, 6 Mar 2022 13:09:03 -0800
Dimitrios Bouras <dimitrios.bouras@...il.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.