OSI TP4 stack on netbsd

[Marcos Pindado Sebastian]

Hello, I would like to know if osi stack is still supported on NetBSD, particularly TP4 transport services.
In the archive list along the years it seems several people tried to make this work but don't seem to get it.

This is what we are doing:

- Compile kernel with OSI stacks
- Configure osi protocol for the interface:

XXXX# ifconfig tlp0 iso 2222

XXXX$ ifconfig -a
tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:30:05:56:34:d2
media: Ethernet autoselect (10baseT)
status: active
inet 192.168.17.55 netmask 0xffffff00 broadcast 192.168.17.255
inet6 fe80::230:5ff:fe56:34d2%tlp0 prefixlen 64 scopeid 0x1
iso 22.22 netmask

- Write a simple client and server socket example. Server justs binds to any address and listens for connections. Client just tries to connect. It will happen in the same machine.
server:
tp4sock = socket(AF_ISO, SOCK_SEQPACKET, 0)
               memset(&isoaddr, 0, sizeof(isoaddr)); => Empty addr, listen on any nsap
               isoaddr.siso_family = AF_ISO;
               isoaddr.siso_tlen = 2;
               cp = (char*)TSEL(&isoaddr); => 2 bytes for selector.
               *cp++ = (PORT >> 8); => The same on client. Find this code on bsd nfs server.
               *cp = (PORT & 0xff);
               Bind => ok, listen => ok
               accept => Blocks (ok)
Client:
               siso.siso_addr = *iso_addr("2222"); => NSAP addr
               int res = connect (sock,(const struct sockaddr*)&siso,sizeof(siso)); => Blocks forever.

This is what we get:

- Server seems to listen. If we specify a wrong nsap or a nsap other than 1111 bind doesn't work. It blocks on accept as it should.
- netstat does not show any information about osi protocol (no listen)
- client blocks forever on connect and does nothing. Symptoms are the same as (http://mail-index.netbsd.org/tech-net/1996/08/01/0001.html)
- client blocks always. Even if no server is listening, if a wrong or inexistent nsap is specified etc
- "route show" cmd shows routes for osi:

ISO:
Destination        Gateway            Flags
(7) 0000 0000 0000 link#1             U
(7) 0000 0002 2222 link#1             UHL


Any help would be much appreciated. We already know it is rare to find people with OSI issues, but maybe someone has a simple test program or configuration to make this work.
The fact is that we need TP4 and netbsd would be our best solution.

Best regards
____________
Verificada la ausencia de virus por G Data AntiVirus
Versión: AVA 22.4810 del 30.04.2012
Noticias de virus: www.antiviruslab.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Marcos Pindado Sebastian
Hello, I would like to know if osi stack is still supported on NetBSD,
particularly TP4 transport services.
In the archive list along the years it seems several people tried to
make this work but don't seem to get it.
- Compile kernel with OSI stacks
XXXX# ifconfig tlp0 iso 2222
XXXX$ ifconfig -a
tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:30:05:56:34:d2
media: Ethernet autoselect (10baseT)
status: active
inet 192.168.17.55 netmask 0xffffff00 broadcast 192.168.17.255
inet6 fe80::230:5ff:fe56:34d2%tlp0 prefixlen 64 scopeid 0x1
iso 22.22 netmask
- Write a simple client and server socket example. Server justs binds to
any address and listens for connections. Client just tries to connect.
It will happen in the same machine.
tp4sock = socket(AF_ISO, SOCK_SEQPACKET, 0)
               memset(&isoaddr, 0, sizeof(isoaddr)); => Empty addr,
listen on any nsap
               isoaddr.siso_family = AF_ISO;
               isoaddr.siso_tlen = 2;
               cp = (char*)TSEL(&isoaddr); => 2 bytes for selector.
               *cp++ = (PORT >> 8); => The same on client. Find this
code on bsd nfs server.
               *cp = (PORT & 0xff);
               Bind => ok, listen => ok
               accept => Blocks (ok)
               siso.siso_addr = *iso_addr("2222"); => NSAP addr
               int res = connect (sock,(const struct
sockaddr*)&siso,sizeof(siso)); => Blocks forever.
- Server seems to listen. If we specify a wrong nsap or a nsap other
than 1111 bind doesn't work. It blocks on accept as it should.
- netstat does not show any information about osi protocol (no listen)
- client blocks forever on connect and does nothing. Symptoms are the
same as (http://mail-index.netbsd.org/tech-net/1996/08/01/0001.html)
- client blocks always. Even if no server is listening, if a wrong or
inexistent nsap is specified etc
Destination        Gateway            Flags
(7) 0000 0000 0000 link#1             U
(7) 0000 0002 2222 link#1             UHL
Any help would be much appreciated. We already know it is rare to find
people with OSI issues, but maybe someone has a simple test program or
configuration to make this work.
The fact is that we need TP4 and netbsd would be our best solution.

This has not been tested for many years so it is likely to be broken.
I you can test/fix it yourself, please do so and submit patches. If
you cannot, please open a PR, and submit test programs that demonstrate
the broken behavior. I can't promise that someone will look at it because
the interest is limited, but at least the behavior is going to become
reproducible and documented.

Thanks,

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by Christos Zoulas

Post by Marcos Pindado Sebastian
Hello, I would like to know if osi stack is still supported on NetBSD,
particularly TP4 transport services.
In the archive list along the years it seems several people tried to
make this work but don't seem to get it.

This has not been tested for many years so it is likely to be broken.
I you can test/fix it yourself, please do so and submit patches. (...)

My old SOCK_DGRAM test is at

ftp://ftp.netbsd.org/pub/NetBSD/misc/is/isotest/

I didn't try it for a while, though, but it might be useful to see if
it's the network or the transport layer you have problems with...

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Marcos Pindado Sebastian]

Hi, thanks everyone for your answers.

I saw that test but the problem is I need a TP4 transport socket, implemented with SOCK_SEQPACKET and not network CLNP datagram.

Finally I could communicate my client-server program with transport tp4 sockets in a one machine environment. I was simply missing to add the iso protocol to the loopback interface (lo0) besides the real network interface (tlp0).

However, after 2 days testing and changing parameters, I see throughput in a single machine is very poor. I tcpdumped packets and saw there were frequent retransmissions at the TP level and sometimes everything seemed to stuck for seconds without sending any packets. Ktruss shows the select/poll/recvfrom facilities do not work well with these sockets and it seems related to netiso kernel issues...

The same program between to twin machines does not work, clnp discards the first ACK data message after connection is done, although it is the same as in the one-machine case.

So the conclusion is this was already old when it was implemented in bsd 4.4.

Thanks again, I will try other options for tp4/clnp.


-----Mensaje original-----
De: tech-net-***@NetBSD.org [mailto:tech-net-***@NetBSD.org] En nombre de Ignatios Souvatzis
Enviado el: miércoles, 02 de mayo de 2012 11:14
Para: tech-***@netbsd.org
Asunto: Re: OSI TP4 stack on netbsd

Post by Christos Zoulas

Post by Marcos Pindado Sebastian
Hello, I would like to know if osi stack is still supported on
NetBSD, particularly TP4 transport services.
In the archive list along the years it seems several people tried to
make this work but don't seem to get it.

This has not been tested for many years so it is likely to be broken.
I you can test/fix it yourself, please do so and submit patches. (...)

My old SOCK_DGRAM test is at

ftp://ftp.netbsd.org/pub/NetBSD/misc/is/isotest/

I didn't try it for a while, though, but it might be useful to see if it's the network or the transport layer you have problems with...

Regards,
-is
____________
Verificada la ausencia de virus por G Data AntiVirus
Versión: AVA 22.4837 del 02.05.2012
Noticias de virus: www.antiviruslab.com

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de