Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Getting started
|
Hi,
I just came across the TELEBAHN network and don't have much idea of how to start exploring, I've never used X.25 before :) Can any Cisco router do XOT / X.25 routing? Does it require additional hardware? How do I get started / start reading up stuff? :) Apologies if I sound as clueless as I actually am, I just couldn't find as much info online as, say, HECnet or similar networks. Cheers, Alice |
|
Hi Alice, and welcome to the framestream!
toggle quoted message
Show quoted text
No worries about "sounding clueless", it's a very esoteric subject and really took me a couple of years to wrap my head around. Nobody has written about it since the 90ies because, once you actually get down to nitty-gritty, there's not actually much there? The way I like to think of X.25 is this: Imagine it's 1982, you operate a voice telephone network, and many of your customers use analog modems to communicate across it. You've recently spent a lot of time and money transitioning your network to Digital so this seems a bit silly, and maybe it would even be simpler for you (the phone company) to provide customers with a serial port as their telco interface instead of a voice pair. Then, you can bill them for a full channel and you only have to carry 2400 baud or whatever, which (a) probably they won't be saturating even that anyway and (b) you can multiplex it and a bunch of other data into a 64k timeslot. It's free money! So that's what X.25 et alia are: a series of protocols and interface specifications, such that (assuming access to a conforming network) you can "dial" from any one serial port to another by typing in the number of the remote port. Plus all the multi-carrier network interop and billing stuff that you would expect from a telco. None of these standards specify what the "internal" architecture of a commercial network should look like... that's because X.25 started as a formalization/generalization of the interface already provided by TYMNET, who were the first but definitely not the only provider in the space, and American telcos in that era preferred to specify the customer interface while keeping the switching and transmission as secret-sauce. You'll see a lot of references to PADs, this is a fairly simple device that has a standard async serial port (rs232) on one side and connects to an X.25 network on the other side. The async port speaks a protocol called X.3. It's nominally human-accessible but actually fairly unpleasant to use; I find it even less fun than Hayes AT commands. Cisco routers that speak X.25 have an X.3 PAD built in. You can try to read X.3, X.25, X.28, X.29, etc, at this url n.b.: the way they write is weird, and can be pretty tough to understand until you cultivate the necessary brain-worms. whether you do so or not is up to you ... TELEBAHN per se doesn't really provide anything other than a number-to-IP mapping system and a few common specifications to ease interoperation. As such anything that speaks XOT can connect to it, and (almost*) anything that speaks X.25 can be downstream from that in your network. Good luck finding gear! * I assume there's some combination of window size and acknowledgement settings that would make coexistence difficult, but there aren't too many knobs to twiddle in the core protocol so maybe not? Every Cisco router since the 1990s should be able to speak XOT and X.25 enough to do TELEBAHN; they don't remove stuff. But also they don't fix it unless someone pays - like, IOS XOT doesn't do IPv6 and probably never will. Further hardware is not required but if you find some, that's super cool and I encourage you to figure out how to plug it in :) The cables are weird but not too expensive. All mine is packed away in storage at the moment. I have an 8-port PAD that works almost acceptably .. it requires manual reconfiguration on every powerup to layer2 link-up with anything, for unclear reasons. I think all X.25 gear is probably buggy. I also have a 16-port "switch" (?) that has not meaningfully responded to any stimulus that I've given it on the config async port, but it does seem to exchange layer2 packets on the "uplink" port. But only NAKs. Doesn't like me. This is the sum total of my ebay watched searches for a few years. X.25 stuff is pretty thin on the ground, most electronics recyclers know that there's no money in it. -- ?strid smith (she/her) =<[ c y b e r ]>= antique telephone collectors association member #4870 On 2023-05-24 at 7:28 pm JST, Alice Wyan wrote:
Hi, |
|
Hi Alice, technically, X.25 is pretty similar to IP in that it provides a packet layer that is then used by higher-level protocols to exchange data.? X.25 is connection oriented, however, so you need to establish a connection before you can exchange data.? The reverse charging of X.25 shows that it is coming from a classic Telecommunications background:? In the X.25 world, users would typically be billed by packet or by segment (64 bytes).? By default, the caller would have to pay for the connection, but if the reverse charging request is present in the connection establishment packet, the callee would get to pay (and the callee would get to accept or reject the reverse charged connection by its response to the call establishment packet).? Reverse charging was useful with public dialin PADs that provided telephone access to X.25.? Users would be able to dial in to the PAD using a normal modem and then connect to a host that accepts reverse charging without having to log in to the PAD.? Logging in to the PAD was also possible in many public networks, which would then make the charge go to the PAD user ID (Network User ID, NUI). As I was programming X.25 before I got to learn IP, I was quite amazed that the BSD socket interface does not make the connection establishment packet available to user programs.? With X.25, white listing would happen in the user mode application, i.e. the connection establishment packet would be inspected by the program and only if the program wanted to accept the connection, the network would proceed with the setup (like with a telephone, where you see the number and you can decide whether you pick up or you don't).? If the user mode application does not want to accept the connection, it can tell the network stack to reject it and optionally provide a reason (e.g. "Reverse charging not accepted").? The socket interface does not provide such a mechanism:? If your program wants to deal with incoming connections, the kernel accepts all of them and then gives them to the user program.? Any form of access control by the user program needs to be done when the connection has already been established.? It still feels quite wrong to me today. Here's a story that I like to tell about my experience with this:? Back in the day here in Germany, DATEX-P NUIs were often shared among interested adolescents and many of us were surfing the net using the same NUI.? Network security was not existent in those days, and the telco did not restrict how many users could use the same NUI, they did not monitor NUI usage in real time and NUI passwords could not be changed by users.? This meant that we often enjoyed weeks of online fun using the same NUI until it was closed down.? You would think that if the NUI no longer worked, we'd disconnect from the PAD, but in West Berlin, phone connections were billed per call, not by duration, so hanging up would cost us money.? To save us that, we had what we called Park-NUAs back then:? Systems that were connected to DATEX-P that accepted reverse charging and that did not have a timeout in their login procedure (BTW: NUA == Network User Address, the equivalence of an IP address).? The most dependable of those Park-NUAs was a Prime that announced itself as "Prime Stadt D", but I don't remember whether that was Düsseldorf or Dortmund.? In any case, many Berlin hackers parked there for hours and days in NUI-less periods, with the bill silently being paid by some municipal entity or organization that had no clue (and apparently did not care). Hardware wise, my TELEBAHN setup consists of a cisco 2811 with a WIC-2T card and two CAB-SS-232FC cables.? The two synchronous serial ports are connected to a SPARCstation IPX running SunOS 4.1.4 using the on-board?serial port and a VAX 4000-105A running VMS V5.5-2H4 using a DSW42-AA dual port synchronous serial card.? I needed to build adapters to get from the cisco cable to the Mini-DIN8?and DB50 ports of the Sun and the VAX.? Things just about started to work last weekend, but I plan to finalize the setup in the coming weeks and connect a timer to run the systems on a regular weekly schedule. The cisco acts as my X.25 router and as the gateway to TELEBAHN using XOT. One word of caution:? For the clock generation in the cisco to work properly, CAB-232FC or CAB-SS-232FC cables are needed.? It is not possible to use DTE cables as the cisco decides based on the cable whether it generates the serial clock itself or receives the clock from the DCE (Modem). Sorry for the rambling. Cheers, Hans Am Mi., 24. Mai 2023 um 15:02?Uhr schrieb ?strid smith <astrid@...>: Hi Alice, and welcome to the framestream! |
|
I see, thanks for your explanations :D
I don't see myself finding much X.25 hardware (I'm in Spain, "vintage" hardware is usually rare and expensive), but can totally set up a XOT link?once I get my hands on the 1921! Then I can route another ancient protocol over TCP/IP?(already on HECnet and hope to get on HNET eventually as well, so the more networks the merrier), and will apply to join TELEBAHN. Regards Alice |
|
If you want to play around with XOT, you could also give? a spin. Am Mi., 24. Mai 2023 um 18:22?Uhr schrieb Alice Wyan <finitud@...>: I see, thanks for your explanations :D |
|
Hi Hans,
That's pretty cool that you could access X25 networks in your youth! I never managed to figure out anything of interest in the phone network back then -- we were charged by connection plus duration, so anything beyond local BBSs was totally out of the question, but none of the amazing tales about red boxing and blue boxing worked here, sadly. I've been looking at the WIC-1T and WIC-2T cards these last few days while totally confused. With the right cable, should I be able to connect to any device that supports serial connection then? That'd be pretty interesting, as I could then connect some interesting devices. I've also seen a cable that fits the strange WIC-2T serial port and has multiple RJ-45 connections on the other end, would that sort of cable work in this set up to connect multiple serial devices per port? (I'm assuming the original purpose is to connect many device console ports to one) Regards Alice |
|
Am Mi., 24. Mai 2023 um 18:31?Uhr schrieb Alice Wyan <finitud@...>: I've been looking at the WIC-1T and WIC-2T cards these last few days while totally confused. With the right cable, should I be able to connect to any device that supports serial connection then? That'd be pretty interesting, as I could then connect some interesting devices. I've also seen a cable that fits the strange WIC-2T serial port and has multiple RJ-45 connections on the other end, would that sort of cable work in this set up to connect multiple serial devices per port? (I'm assuming the original purpose is to connect many device console ports to one) The WIC-1T and WIC-2T are synchronous serial cards with one and two ports, respectively.? Synchronous means that there are separate clock signals on the interface, which allows higher speeds than the usual asynchronous serial connections (even though asynchronous serial can be pretty fast nowadays).? On the cisco side, there are proprietary connectors with 60 (legacy) or 26 (smart serial) pins, but the large number of pins is owed to the fact that these ports have a number of ID pins which signal the type of cable to the cisco router, and many signals that are only used with certain physical connection types (i.e. differential signaling of X.21 and V.35).? Multiport asynchronous modules exist (e.g. HWIC-8A and HWIC-16A), but they use different connector types and cables. X.25 does not work over asynchronous serial lines, and most standard serial ports do not support synchronous operation as they lack the required controller chips and clock signals.? SPARCstations are an exception, which is why I found myself a SPARCstation IPX. |
|
On Wed, May 24, 2023 at 3:06?PM Alice Wyan <finitud@...> wrote: Hi, It might, if you want to have a "subnet" with more than one device. If I understand things correctly, Cisco IOS will not route from XOT to XOT – if you make a call locally (or if it arrives via serial link) then you can talk to any other host via XOT, but if a call *comes in* via XOT it can only be routed to a physical interface (e.g. Serial0/1 on a WIC-2A/S or WIC-2T<2>). Fortunately my Cisco1760s all had serial cards but I had to find some cables to connect them<1>. (No, async ports like Aux0 won't work.) As far as software goes, though, the lowest-end "y" (Basic IP) IOS image (the only thing that fits in them) was enough for X.25 and XOT. <1> (Chonky CAB-SS-V35MT<->
CAB-SS-V35FC at first, but later I found out that eBay has unofficial "back-to-back smart-serial" serial cables nowadays.) <2> (WIC-1T seems to lack the "clock generation" pieces – as the manual mentions it lacking a CSU/DSU – so I assume it wouldn't work for a back-to-back connection; you need one side capable of providing clocking.) |
|
I see, this might be a problem for the time being... also it seems that the WIC-2T is no longer supported on the 1900 series, and the HWIC-2T are quite a lot more expensive, so I might need to postpone XOT on the router. I vaguely remember there being X25 support in the Linux kernel a while ago, is doing XOT on a Linux box an option? Or perhaps on some other older OS?
|
|
john jones
开云体育You could use something like a Cisco 2501 which has the correct serial ports (2).? You would need to also get an AUI adapter as the 2501 predates 10Base-T.? Truly retro.? Maybe. ? John ? From: [email protected] <[email protected]> On Behalf Of Alice Wyan
Sent: Wednesday, May 24, 2023 2:49 PM To: [email protected] Subject: Re: [X.25] Getting started ? I see, this might be a problem for the time being... also it seems that the WIC-2T is no longer supported on the 1900 series, and the HWIC-2T are quite a lot more expensive, so I might need to postpone XOT on the router. I vaguely remember there being X25 support in the Linux kernel a while ago, is doing XOT on a Linux box an option? Or perhaps on some other older OS? |
|
XOT works without any cards, this is for connecting multiple local devices only. On Wed, May 24, 2023, 21:48 Alice Wyan <finitud@...> wrote: I see, this might be a problem for the time being... also it seems that the WIC-2T is no longer supported on the 1900 series, and the HWIC-2T are quite a lot more expensive, so I might need to postpone XOT on the router. I vaguely remember there being X25 support in the Linux kernel a while ago, is doing XOT on a Linux box an option? Or perhaps on some other older OS? |
|
You sorta can, using the cisco as a PAD.
toggle quoted message
Show quoted text
You can connect async devices to the AUX port, such as the console port on a computer, allowing others to connect via x.25 and get the console. You can also configure IOS to convert incoming x.25 connections to telnet. On Thu, May 25, 2023 at 2:43?PM Alice Wyan <finitud@...> wrote:
|
|
Just reread your post, I think I misunderstood it the first time around.
The AUX port on the Cisco is just an async serial port, right? So what you are suggesting, if I read correctly, would be: a) plug a serial device (computer or whatever) on to the AUX port of the Cisco router b) configure x25 routing on the Cisco so that incoming X.25 connections via XOT go to the AUX port Would this be correct? If so, that would allow me to join TELEBAHN quite easily :) I guess the computer to connect could be an ESP32 running a CP/M emulator, there must be software from that era available. |
|
john jones
开云体育Whose post? ? John ? From: [email protected] <[email protected]> On Behalf Of Alice Wyan
Sent: Thursday, July 13, 2023 4:50 PM To: [email protected] Subject: Re: [X.25] Getting started ? Just reread your post, I think I misunderstood it the first time around. |
|
On 13/07/2023 23.50, Alice Wyan wrote:
Just reread your post, I think I misunderstood it the first time around.It is, yes. So what you are suggesting, if I read correctly, would be:If you mean running actual X.25 communications software on the CP/M – I don't think that'll quite work, as IOS will not let you route X.25 over async lines; I believe it only works over synchronous serial ports. (The cpm-x25 docs mention synchronous mode being required on its end, too.) Though if all you have is an async AUX, you can still connect devices over it, but you'll need the Cisco router *itself* to accept the X.25 call into one of its vty lines (service pad from-xot), and have that line configured with an `autocommand` to telnet somewhere further. (E.g. if the device provides a plain login prompt via serial, then an autocommand to telnet to the router's own "reverse telnet" ports for the AUX line. If the device does PPP, *that* can run over AUX and you can have an autocommand to telnet to the device via PPP, or DECnet `lat` connection, or something such.) (From what I understand, that's how actual "PADs" used to work – they'd accept the X.25 call on behalf of whatever async lines they had.) Though the full "enterprise" IOS images might have more capabilities there; I still haven't installed the RAM upgrades to try it out. |
|
On 14/07/2023 00.44, Mantas Mikul?nas via groups.io wrote:
On 13/07/2023 23.50, Alice Wyan wrote:About what you said earlier about not giving users access: In IOS, lines *won't* have console (Exec) access if an `autocommand` is set on them. So it should be safe to assign a few vty lines to `transport input pad`, give them an X.25 sub-address using `rotary XX`, and point them wherever is needed. It's not exactly a pure conversion but it does the job...Just reread your post, I think I misunderstood it the first time around.It is, yes. |
|
On 14/07/2023 00.49, Mantas Mikul?nas via groups.io wrote:
On 14/07/2023 00.44, Mantas Mikul?nas via groups.io wrote:Ahhhh. Hold on. I completely forgot about an easier possibility, even though I was making my own notes on this *literally two days ago.*On 13/07/2023 23.50, Alice Wyan wrote:About what you said earlier about not giving users access: In IOS, lines *won't* have console (Exec) access if an `autocommand` is set on them. So it should be safe to assign a few vty lines to `transport input pad`, give them an X.25 sub-address using `rotary XX`, and point them wherever is needed. It's not exactly a pure conversion but it does the job...Just reread your post, I think I misunderstood it the first time around.It is, yes. You don't need an autocommand or "reverse telnet" for X.25-to-AUX. You can just directly assign `rotary` to the aux line, and the router will accept PAD calls and directly connect them to the AUX output. Sorry for forgetting that option. |
|
On Fri, Jul 14, 2023 at 02:07 PM, Mantas Mikul?nas wrote:
You don't need an autocommand or "reverse telnet" for X.25-to-AUX. You can just directly assign `rotary` to the aux line, and the router will accept PAD calls and directly connect them to the AUX output.So it would be just a matter of setting up XOT and then set up 'rotary' and all set? |
to navigate to use esc to dismiss