OSI TP4 stack on netbsd

[Marcos Pindado Sebastian <mapindado%aubay.es@localhost>]

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