archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Xie He' <>
Cc: "David S. Miller" <>,
	Jakub Kicinski <>,
	"" <>,
	"" <>,
	"" <>,
	"Martin Schiller" <>
Subject: RE: [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs
Date: Thu, 10 Dec 2020 22:34:02 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: Xie He
> Sent: 10 December 2020 10:17
> On Thu, Dec 10, 2020 at 1:14 AM David Laight <> 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'.


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

  reply	other threads:[~2020-12-10 23:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  3:33 [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs Xie He
2020-12-09 21:21 ` David Laight
2020-12-09 22:53   ` Xie He
2020-12-10  9:14     ` David Laight
2020-12-10 10:17       ` Xie He
2020-12-10 22:34         ` David Laight [this message]
2020-12-13  1:20 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).