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]
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

Powered by blists - more mailing lists