XOT

XOT

[Ian Cass]

Hi,

I'm using  xotd 0.04 by Stephane Fillod with a degree of success, but it
seems a horrible hack. I wonder if this is the best (only?) xotd available.

--
Ian Cass

Re: XOT

[John Hughes]

> I'm using  xotd 0.04 by Stephane Fillod with a degree of success, but
> it seems a horrible hack. I wonder if this is the best (only?) xotd
> available.

I've not had time to look at the code; what's so hacky about it?

Re: XOT

[Ian Cass]

> I've not had time to look at the code; what's so hacky about it?

It's a userland driver using a ethertap like device. That sort of thing
should really be integrated into the kernel. However, it does work, although
not 100% reliably for me at the moment.

--
Ian Cass

Re: XOT

[Arnaldo Carvalho de Melo]

Em Sat, Oct 05, 2002 at 06:41:04PM +0100, Ian Cass escreveu:
> > I've not had time to look at the code; what's so hacky about it?
> 
> It's a userland driver using a ethertap like device. That sort of thing
> should really be integrated into the kernel. However, it does work, although
> not 100% reliably for me at the moment.

I've been thinking about working on this for a long time, as I have written
a driver for a serial sync card that has a X.25 stack in firmware and by
means of the wanrouter subsystem allows tcp to be carried over X.25, having
infra-structure to make one protocol work on top of other on a easy way is
something interesting to have, but I haven't looked at xotd, if I had perhaps
I'd be of the opinion that the current infrastructure could be easily used
to have a X.25 over TCP in the kernel.

- Arnaldo

RE : XOT

[John Hughes]

Ian Cass writes:

> John Hughes wrote: 
>>'ve not had time to look at the code; what's so hacky about it?

>It's a userland driver using a ethertap like device. That sort of
>thing should really be integrated into the kernel. However, it
>does work, although not 100% reliably for me at the moment.

Ah, you mean it's very existence is a hack :-)

Any idea how you write a Linux driver that uses another Linux
driver for it's I/O?

Re: RE : XOT

[Arnaldo Carvalho de Melo]

Em Mon, Oct 07, 2002 at 09:21:43AM +0200, John Hughes escreveu:
> Ian Cass writes:
> 
> > John Hughes wrote: 
> >>'ve not had time to look at the code; what's so hacky about it?
> 
> >It's a userland driver using a ethertap like device. That sort of
> >thing should really be integrated into the kernel. However, it
> >does work, although not 100% reliably for me at the moment.
> 
> Ah, you mean it's very existence is a hack :-)
> 
> Any idea how you write a Linux driver that uses another Linux
> driver for it's I/O?

Look at ncpfs, smbfs, TUX, khttpd, IPX and Appletalk working on top of SNAP
that works on top of LLC, etc.

- Arnaldo

RE : XOT

[John Hughes]

> It'll just stop accepting inbound X25 connections & stop
> allowing outgoing connections to be initiated. A restart
> of xotd & all x25 daemons cures this. It'll show this
> behaviour every 10-12hrs.

Oh blurgh.  With no error messages?

Have you ever run it with debugging on?

RE : XOT

[John Hughes]

I said:

> I'm having a little problem making Linux xotd work with my
> home grown implementation, but I think I've tracked it down
> to a difference of opinion about when the TCP call should be
> cleared.

The way xotd works is that it clears the TCP call if it
recieves an X.25 CLEAR CONFIRMATION:

	void *tap_writer(void *arg)
	{
	...
	    while (1) {

	        nread = readn(sockfd,(unsigned char*)&header,
	                      sizeof(struct xot_header));
	        if (nread != sizeof(struct xot_header)) {
	...
	             break;  /* abort */
	        }
	...

	    }

	    if (isVerbose)
	        printd("TCP connection closed (tap writer), 
	               lci=%d.",curr_lci);

	    hash_remove(&hash_table, sockfd, lci);

	    close(sockfd);      /* TODO: add to a spare list, 
	                           for use by tap_reader */

This seems reasonable.  *BUT* if xotd SENDS a CLEAR CONFIRMATION,
in the other direction it does not clear the call, it keeps it
open and will re-use it for new connections.  (It used to clear
the call, but as of version 0.04 this is commented out).

Now imagine what happens when two of these xotd's are talking
together - 

xotd#1                            xotd#2         
send clear conf >----\
                      \----------> Get clear conf
                                           |
                        /--------< Clear TCP call
Send new call >----\   /
                    \ /
                     X
                    / 
Eurgh          <---/

Whoops! the new call has been sent on a socket that has been
closed by the other side.