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: <CAExTYs3tTuLqYByki0JtWheVp=r+r9Xo8F=RryxVq8O+4zJVpw@mail.gmail.com>
Date:   Mon, 7 Mar 2022 09:45:52 -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 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