[comp.protocols.tcp-ip] wollongong win/3b bug

stanonik@NPRDC.NAVY.MIL (Ron Stanonik) (08/21/90)

We've run into what appears to be a bug in wollongong's
release 3.0 tcp/ip for at&t 3b2's (sysVr3.2.2).  The problem is that
connect complains "socket operation on non-socket".  The
conditions underwhich this occurs are that the socket was
obtained using rresvport() and the file descriptor was
previously used for reading a file (say, /etc/services).

Here's an outline of a program producing the error:

fd = open("/etc/services", 0)
read(...)	/* eg, lookup the service name */
close(fd)
fd = rresvport(...)	/* get's same descriptor as previous read() */
connect(fd, ...)

Apparently, wollongong's read() sets WIN_CANTSYNC (via win_sync), but
doesn't set s_used.  rresvport() doesn't modify the _win_sockinfo[] entry.
connect() (win_sync actually) finds WIN_CANTSYNC and gives up.

I'm not sure how best to fix this:
1) rresvport() appears to be in error because it doesn't fill in the
_win_sockinfo[] entry.
2) read() appears to be in error for calling _win_sync when the descriptor
is for a normal file.
3) _win_sync appears to be in error because it sets WIN_CANTSYNC, but
not s_used (if the descriptor is for a normal file).

Any reason to prefer one fix over the other?


Unrelated Questions

While digging around I noticed that the wollongong socket library
(built on top of tli) only pushes tirdwr onto the stream during
accept(), so if you're porting some bsd code which uses socket(),
bind(), connect(), then tirdwr tirdwr won't be pushed.  I thought
tirdwr was required before read/write/close would work properly?

I noticed that applications (eg, ftp, telnet, etc) included in
the wollongong distribution seem to always pop timod before
pushing tirdwr.  Why?  The sysV network programmer's guide doesn't
mention pop'ing timod being neccessary.

I noticed that telnetd seems to pop tirdwr then push timod (apparently
to undo the popd timod, push tirdw by tcplisten).  The sysV
network programmer's guide seems to say that pop'ing tirdwr closes
the connection.  Not so?

Thanks,

Ron Stanonik
stanonik@nprdc.navy.mil