[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4baebbcb95d84823a7f4ecbe18cbbc3c@AcuMS.aculab.com>
Date: Sat, 5 Mar 2022 07:02:26 +0000
From: David Laight <David.Laight@...LAB.COM>
To: "'Dimitrios P. Bouras'" <dimitrios.bouras@...il.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
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.
> 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.
...
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists