Re: XOT

Re: XOT

[Ian Cass]

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.

--
Ian Cass

----- Original Message -----
From: "John Hughes" <John@Calva.COM>
To: "'Ian Cass'" <ian.cass@mblox.com>
Cc: <linux-x25@vger.kernel.org>
Sent: Tuesday, October 08, 2002 8:27 AM
Subject: RE : XOT


> Ian sez:
> > ... However, it [xot] does work, although not 100% reliably
> > for me at the moment.
>
> What's unreliable for you?
>
> 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.
>
> (rfc1613 says:
>
>
>    The TCP connection MUST be created before the virtual circuit
>    can be established.  The TCP connection MAY be maintained after
>    the virtual circuit has been cleared.
>
> Great, it MAY be maintained, but when should it be cleared?  Can
> it be cleared by either end, or only by the caller?)
>
>
>

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.
                    

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

[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