george@ditmela.oz (George michaelson) (02/01/88)
We have discovered a problem with our local X25 switch being used with AUSTPAC/OTC/{other x25 network} which you may be interested in. this problem may be seen by anyone who is on a TRANSPAC-like X25 network being called from any other X25 network eg IPSS in the UK. it is caused by differences in the use & interpretation of X.121 addresses at each DTE, and propagated by X25 gateway and network provider behaviour. PROBLEM: Calls in to local host using subaddress routing are accepted but clear at once, possibly with error code 05 a7. Remote host may not see call connecting but local host does. -further problem: diagnostic a7 is referred to international provider and/or remote DTE ie no human readable form available locally to decode the problem! SEE WITH: smartnet 3000 series X25 switch and possibly any similar box doing sub-address routing from one X25 DCE to several hosts. Any host receiving calls off the address with no subaddress will function normally. any routing ignoring sub-address may function normally. WHAT HAPPENS: The call request packet when received by the local X25 provider has the LOCAL DTE stripped out, leaving the subaddress part only. This is perceived as a feature on certain nets. The switch then routes the CR packet to the correct host using its tables. The host accepts the call. The switch sends back a Connect Accept packet *WITH THE LOCAL SUBADDRESS IN IT BUT NOT THE FULL LOCAL DTE* as received from the local provider. The local provider does NOT re-insert the local DTE but passes this packet transparently to the gateway, which also passes direct to the remote X25 network. The remote network and/or DTE checks the CC packet, finds a DTE which (a) does not match the called address (b) does not conform to *its* idea of X.121 address format, and clears the call 05 (network congestion or other problem) a7 (DTE incorrect length) WHO IS TO BLAME? Well... clearly the switch could do better, but you can argue that if the network provider strips addresses on incoming calls they should be replaced in all packets going out during the connect phase. In our case we are using a box with little support and little configuration for this area. You should look carefully at any product & make sure you have full control over all fields of all packets if possible. FIX: (1) get a switch which you can tailor enough to specify ALL fields in ALL packets and write a valid address into your CC packet before sending. (2) discuss this feature with your network provider they *may* be able to switch it off, or insert full DTE into all connect-phase packets instead of leaving the CC alone. (3) use other routing mechanisms as a temporary bridge: PID or cudf can be used with DTE minus subaddress to select several hosts, if the hosts support this option: (the crucial one of ours claims to but the kernel crashes in this mode- the option is thus not available) I suspect this problem may be being seen by many people but ignored. At our site calls to some hosts worked ok, due to the default routing on no subaddress creating a CC with no arguments, which was accepted by everyone. Local tests fail to cause the problem, even loop-back through international gateway may fail to show problem, only a genuine call in from some remote net which also checks the DTE on all connect phase packets will cause rejection. Thanks to OTC and PSS engineers who helped track down this problem for us. (at time of writing we don't yet have fix working locally, there may not *be* a fix!) George Michaelson. -- ACSnet: G.Michaelson@ditmela.oz.au Postal: 55 Barry St, Carlton, Vic 3053 Phone: (03) 347 8644 Fax: (03) 347 8987
rob@COS.COM (Rob Clark) (02/05/88)
In article <284@ditmela.oz>, george@ditmela.oz (George michaelson) writes: > > We have discovered a problem with our local X25 switch > being used with AUSTPAC/OTC/{other x25 network} which you > may be interested in. > I had a chat with our X.25 guru who has had experience of transpac-type networks, and we came up with the following: I would agree that if the network provider (austpac) is going to strip the called address (except the subaddress if present) from incoming call packets, then it should do the converse, thereby injecting the network address in that same field (appending intact the subaddress which is returned by the switch which is interposed between the network provider and the one or more x25 hosts). I would think, though, that the interposed switch should be capable of creating a proper full x121 called address in the extended accept packet. It really should be its responsibility to act as the network interface to all of its attached DTEs. (Although it appears that not even the network provider is doing this detail correctly.) I know, however, that all equipment does not work this way. For example, Dynapac's model 8 (8 port) switch does just what is described in the message, ie, if it has been optioned to create extended call accept packets for an attached DTE that cannot do so, it will take the called address as it saw it and recreate it in the extended accept packet. So, no help there, I'm afraid. In such cases where the calling DTE's software (or the DCE node that it's connected to) compares the called address in the call request packet to the called address in the extended call accept packet, then extended call accept packets have to be disabled at the called end (since we know that the normal short form of the call accept packet is acceptable [normally] by all). This is, of course, unfortunate since one shouldn't have to disable a possibly desirable feature because there are certain networks or pieces of equipment that don't support them. C'est la vie! chris (Chris Rohrer @ Corporation for Open Systems) rob (Rob Clark @ Corporation for Open Systems) -- X@cos.com -- X%cos.com@uunet.uu.net -- {uunet, sundc, decuac, hqda-ai, hadron}!cos!X where X = "chris" or "rob"
george@ditmela.oz (George michaelson) (02/06/88)
Further to this saga, AUSTPAC were finally contacted and enabled a feature whereby they *DO* pass up the full called DTE in incoming CR packets, and also inserted them on outgoing CC and CR. However there remained a small snag. They pass in a DTE with a leading 0 thus generating 15 digit DTE's... and the sun being called can only declare itself to be a 14 digit address. This can be circumvented by using 1 digit subaddress routing but I regard that as a big kludge. AUSTPAC may be legally ok in adding the 0 but surely the DNIC identifies external routing directly, and thus guarantees an address can be resolved as net-internal or X.75 routed. Why do they do this? How many programs out there assume the first 4 digits are DNIC? To get round this we declared the sun as having a NULL DTE (which is a documented feature for TRANSPAC like networks), and rely on the switch to correctly route processes into the host. To separate out X25 applications (such as FTAM and our ISODE process) we can declare any DTE we like from homebrew or sourcecode available programs. Thus there is a limit of 9 identities (subaddress 0 being dubious) per host but the machine would die before we reached that anyhow. Don't ask why PID masks or CUDF don't work, the switch and the sun between them cannot agree on what to do there. The switch can't even *specify* the PID field of CUDF. The sun should be able to route calls on CUDF and should NOT pass X.29 to X.25 listeners. I think it's broken. Further the sun supplied pad program and other utilities make use of an ioctl (on the X.25 socket they open) to read the local DTE (from a config file) for assertion in outgoing calls. Thus the machine can have only a SINGLE declared DTE for all applications, and cannot be dual-ported into two different address spaces. The latter is a major headache for users of IPSS and JANET in the UK but could cause problems for sites using a local X25 switch with local address space as well as direct X25 connections to the outside world from some hosts. The switch is certainly broken. Enabling local DTE masking (where it fakes a given DTE on all outgoing calls taking only their subaddress where given) causes the incorrect DTE to be changed in call accept packets, it is unable to explicitly modify *as different objects* ALL addresses in ALL packets passed in either direction. it cannot route on PID. I received a local followup (from within australia that is) suggesting others have seen this problem. That one was involving DATAPAC (canada?) and was solved quite quickly. Do all networks ending in -PAC derive from common code? AUSTPAC is TRANSPAC derived. it would seem we still have a wee way to go with X25. -- ACSnet: G.Michaelson@ditmela.oz.au Postal: 55 Barry St, Carlton, Vic 3053 Phone: (03) 347 8644 Fax: (03) 347 8987