Solstice X.25 sockets calling a PAD host

Solstice X.25 sockets calling a PAD host

Post by Rene Oude Vrielin » Thu, 16 Sep 1999 04:00:00



Hi,

I've got the following problem with my application that uses the
Solstice X.25 9.1 socket interface to talk to a PAD host.

The initial connect() call works fine to the PAD host. The PAD host
then sends a specific PAD command back to my Solstice X.25 software
which is passed on through the sockets to my application.
This is wrong, the X.25 software should recognise it as PAD data and
treat it accordingly. In this case it should return an acknowledgement
to the PAD host and not sent the PAD data to my application...

Has anybody got experience with this kind of X.25
software/configuration??
What should I do to make my application which uses the socket
interface talk to a PAD host?

G'day and thanks,

Rene Oude Vrielink

 
 
 

Solstice X.25 sockets calling a PAD host

Post by Andrew Gabri » Thu, 16 Sep 1999 04:00:00



        Rene Oude Vrielink writes:

Quote:

>Hi,

>I've got the following problem with my application that uses the
>Solstice X.25 9.1 socket interface to talk to a PAD host.

>The initial connect() call works fine to the PAD host. The PAD host
>then sends a specific PAD command back to my Solstice X.25 software
>which is passed on through the sockets to my application.
>This is wrong, the X.25 software should recognise it as PAD data and
>treat it accordingly. In this case it should return an acknowledgement
>to the PAD host and not sent the PAD data to my application...

You are talking to an X.25 driver at the socket level.
The PAD protocol, X.29, runs over X.25, so you are going
to see X.29 protocol presented to you in the X.25 data
(or in most cases, X.25 qualified data).
I think you are going to have to implement X.29 and X.3
in your code. The protocol is not complicated (although
if you've never dealt with ITU/CCITT recommendations, it
will initially look like a much harder task than reading
an RFC). There might be a library to do this somewhere,
but I haven't seen one (I haven't looked either).

An analogy is that you wish to write a program which does
a telnet to a login port. You make a TCP connection to
the remote IP+port. Your TCP connection will now return
telnet protocol commands, and you will need to handle
these and issue responses in your own code.

--
Andrew Gabriel
Consultant Software Engineer

 
 
 

Solstice X.25 sockets calling a PAD host

Post by dhagb.. » Fri, 17 Sep 1999 04:00:00





>    Rene Oude Vrielink writes:
> >This is wrong, the X.25 software should recognise it as PAD data and
> >treat it accordingly. In this case it should return an
acknowledgement
> >to the PAD host and not sent the PAD data to my application...

> You are talking to an X.25 driver at the socket level.
> The PAD protocol, X.29, runs over X.25, so you are going
> to see X.29 protocol presented to you in the X.25 data
> (or in most cases, X.25 qualified data).

Mr. Gabriel is correct.  The easiest alternative is to configure the
remote PAD to act as a clear pass-thru device, disabling X.29 and X.3
negotiations.  We do this for 185 remote sensors, with our apps
communicating via X.25 sockets.  Our apps never see an X.29 control
code, only raw bytes from the sensors.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

1. Any X.25 pad software and X.25 card run on Linux?

I'm looking for an isa X.25 card with pad software that will run
on linux. So far I've come across 2 such cards with pad software that
run under SCO, but nothing that will run on linux. Anybody use or
know of any such card plus software that runs on linux?

Paul Popper.

2. KDE is buggy?

3. Block tcp/25 Services (telnet host 25)

4. bad PBR sig .. error

5. x.25 socket and tcp/ip socket

6. Booting..

7. PPP over PAD(X.25)

8. YOUR CV WANTED IF YOUR GOOD!

9. x.25 socket and tcp/ip socket

10. Need Help! X.25 PAD Error in Script

11. X.25 PADS for RS/6000

12. Running x.25 pad on console from startup

13. x.25 socket and tcp/ip socket