RE: [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs

[David Laight]

From: Xie He
> Sent: 10 December 2020 10:17
> 
> On Thu, Dec 10, 2020 at 1:14 AM David Laight <David.Laight@xxxxxxxxxx> wrote:
> >
> > > To me, LLC1 and LLC2 are to Ethernet what UDP and TCP are to IP
> > > networks. I think we can use LLC1 and LLC2 wherever UDP and TCP can be
> > > used, as long as we are in the same LAN and are willing to use MAC
> > > addresses as the addresses.
> >
> > Except that you don't have any where near enough 'ports' so you need
> > something to demultiplex messages to different applications.
> 
> Yes, LLC only has 256 "ports" compared to more than 60000 for UDP/TCP.

And ISO transport separates out the address from the connection-id.
The TSAP (used to select the listening application) is 32 bytes.
If you run the ISO Network layer (which isn't X.25 level 3) on a LAN
you have an additional 24 byte NSAP.

For X.25 level 3 we routed calls to applications using any of (IIRC):
- called number sub-address.
- CUG (closed user group number)
- Some other L3 parameters I can't remember :-)
- TSAP if transport layer also in use.
The only way to pass that down was in a TLV format.
Fortunately we weren't even trying to use BSD style sockets.

> > We (ICL) always ran class 4 transport (which does error recovery)
> > directly over LLC1 using MAC address (a NUL byte for the network layer).
> > This requires a bridged network and globally unique MAC addresses.
> > Sending out an LLC reflect packet to the broadcast MAC address used to
> > generate a couple of thousand responses (many would get discarded
> > because the bridges got overloaded).
> 
> Wow, You have a really big LAN!

I think it 'only' stretched from London to Manchester.
But it might have gone up to Edinburgh.
It wasn't a single collision domain, there were bridges doing
MAC filtering - but they had to be open to broadcast traffic.

It was actually a bad IP broadcast packet that took out all the
unix servers in several cities!
(Zero length in a IP options field caused the code trying to skip
the options to generate the ICMP error to spin.
By the time the corporate network guys came storming into our lab
we'd already got a dump from one system and had found the bad packet.
We never did find out why it got sent - the originating system
wasn't doing anything 'odd'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)