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: <20220307101035.7015201e@hermes.local>
Date:   Mon, 7 Mar 2022 10:10:35 -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 Mon, 7 Mar 2022 09:45:52 -0800
Dimitrios Bouras <dimitrios.bouras@...il.com> wrote:

> On Mon, Mar 7, 2022 at 8:08 AM Stephen Hemminger
> <stephen@...workplumber.org> wrote:
> >
> > 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.  
> 
> 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