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] [day] [month] [year] [list]
Date:   Mon, 7 Mar 2022 10:19:14 -0800
From:   Dimitrios Bouras <dimitrios.bouras@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
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, Mar 7, 2022 at 10:10 AM Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
> 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

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.