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: <7e75125d-c222-46cf-50b3-c80978cbfff2@gmail.com>
Date:   Sun, 6 Mar 2022 13:09:03 -0800
From:   Dimitrios Bouras <dimitrios.bouras@...il.com>
To:     David Laight <David.Laight@...LAB.COM>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/1] eth: Transparently receive IP over LLC/SNAP


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