Bug 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
31 bug(s) found
Bug 1: UDP broadcast fails with Winsock 1.1
Bug 2: Weak pragma errors when compiling with gcc 2.95.x
Bug 3: UDP support hopelessly broken
Bug 4: IPX support
Bug 5: wsock interface: WsControl() code not working
Bug 6: wsock interface: vdhcp.vxd code not working
Bug 7: csock interface: No out-of-band data support
Bug 8: wsock interface: Incomplete support for OOB data
Bug 9: DXE support
Bug 10: Add support for routing tables
Bug 11: Add support for MS-DOS
Bug 12: libsocket 0.7.4 beta 3 (& earlier?) has broken assembly code
Bug 13: unix interface: Check mailslot names fit to 8+3 convention
Bug 14: Document debugging options in resolver
Bug 15: wsock interface: SO_LINGER support broken?
Bug 16: csock interface: close() always closes forcibly
Bug 17: Test multicast capability
Bug 18: Test suite needed
Bug 19: bindist and srcdist targets for automatically making distributions
Bug 20: csock interface: getsockopt() doesn't support SO_ERROR
Bug 21: Implement sendmsg(), recvmsg()
Bug 22: wsock interface: Can it use Winsock 2's wsock2.vxd?
Bug 23: Document loopback network - 127.0.0.0/8
Bug 24: Add to FAQ: How to use library without actually installing it
Bug 25: Generalise MSG_PEEK support
Bug 26: Generalised socket functions: getaddrinfo(), gai_strerror(), freeaddrinfo()
Bug 27: select() with socket fd + fileno(stdin) doesn't complete on keypress
Bug 28: csock interface: Blocks on recv(), recvfrom() after ~64K data received?
Bug 29: unix interface: Local mailslots can loose data?
Bug 30: libsocket fails to detect Windows version under Windows NT
Bug 31: libsocket programs crash on exit on Windows NT
Created: 1999-11-26 20:01:10
Priority: P2
Severity: major
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-26 20:01:10: Richard Dawe <richdawe@bigfoot.com>
Reported by Boris Pereira: the udp broadcast packet under win95 (winsock 1.1) don't work it return : a error but doing strerror it say no error ?! Rich Dawe's thoughts: - Maybe we need to set SO_BROADCAST on socket before trying? Since broadcast is conventionally allowed by default for UDP socket (IIRC). With the csock interface (sock.vxd), broadcast is allowed by default. Maybe this isn't the case for wsock interface (wsock.vxd). - The datagram socket handling is flaky anyhow - is this an artifact of this?
Created: 1999-11-27 02:20:01
Priority: P4
Severity: minor
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: sources
Platform: PC
Operating System: Windows 98
1999-11-27 02:20:01: Richard Dawe <richdawe@bigfoot.com>
Yoni Ribalsky reported this: I`m trying to install lsck0743 and after command "make -f makefile.src all" the build failles with error message l_herrno.c:12: warning: ignoring pragma: _h_errno l_herrno.c:19: warning: ignoring pragma: __normal_h_errno_location Richard Dawe comments: I asked Yoni which version of gcc, DJGPP he was using, but I received no response. I obtained these errors using gcc 2.95.2 + DJGPP 2.02. They occur with source files in src/inet/, which use #pragma weak to allow user programs to overload functions in the resolving code. gcc has an weak attribute now, so that should be used instead. This error actually occurs for ~10 files. The impact of this bug is likely to be minimal.
1999-12-18 02:08:59: Richard Dawe <richdawe@bigfoot.com>
This was fixed by changing '#pragma weak' to '__attribute__ ((weak, alias("")))'. gcc 2.95.x doesn't like pragmas very much. It does have a switch
to allow the weak pragmas, but since libsocket only compiles with gcc, it seems
better to use the attribute method.
2000-03-11 14:48:59: Richard Dawe <richdawe@bigfoot.com>
This problem later resurfaced when I tried cross-compiling with egcs-2.91.66 19990314 (egcs-1.1.2 release) on Linux. This generated errors rather than warnings. The solution was to remove all weak pragmas. This is unlikely to have any serious impact, because the weak pragmas were there to allow threading libraries to override the built-in functions. It is likely that libsocket will have to be majorly rewritten to work with any threading libraries, so this isn't really a problem. As part of the removal of weak pragmas, I implemented readv(), writev() calls.
Created: 1999-11-27 14:05:30
Priority: P1
Severity: blocker
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 98
1999-11-27 14:05:30: Richard Dawe <richdawe@bigfoot.com>
Reported by Gillius: After doing some testing on libsocket, I found some errors. I will note that I believe my code is not at fault because the code of the program will compile directly under Linux and run properly. Luckily I was able to use a linux to act both as server and client to test how far each side would go. Summary: accept() on server-side is broken, and does not properly initalize the port, and does not return an ERROR. Later calls to the socket return an invalid file descriptor error (ENOENT). select() on client side (using stdin and a UDP socket) fails by giving the error (ENOTCONN), transport endpoint is not connected. What happens and when: Server and client on Windows 98: Server loads and runs fine until client connects, then server returns ENOENT error which kicks the client out of the blocking recv() and terminates. Server (linux) and client (98): Server and client connect using TCP/IP correctly and terminate. Server proceeds normally on Linux as select() returns an error trying to listen to stdin and the UDP socket connected to the server. Server (98) and client (linux): Server returns ENOENT error which closes the connection (and therefore generates obvious error client-side during a recv(), terminating client). It seems there's an error on initalizing sockets or something in the library since ENOTCONN from the client on select() (this is the sockets first use since connect() which does not return an error), and the ENOENT from the server's recv() seem to be related. --- Richard Dawe asked for some clarification from Gillius and got some: > I've read your bug report and I'm slightly confused. IIRC you are using > both datagrams and streams. Okay this is what goes down. The server listens on two ports at once, a TCP/IP port and a UDP port. Remember this program was meant to simulate my game environment so this is why it's setup this way. The clients logon to the server using the TCP/IP port, where speed is of less concern than guaranteed data. After handshaking and communicating data back and forth, the client closes the TCP/IP connect and opens up the UDP connect to the server. When the server hears something on the UDP port it broadcasts it to all of the listeners. > > select() on client side (using stdin and a UDP socket) fails by giving > > the error (ENOTCONN), transport endpoint is not connected. > > I couldn't duplicate this - see the attached programs udpcli2.c and > udpserv.c. I've also attached the Makefile, although this will need some > editing (remove ref's to udpcli, change -I and -L paths to point at your > libsocket directories, if you haven't installed it) Do these programs work > for you? I can't remember if I tested against udpserv, but I believe this > isn't particularly relevant to the problem. Run udpcli2 and just leave it > going. It doesn't seem to return an error. Pressing a key doesn't seem to > break out of the loop for me. Weird. I tested it and ran both udpserv and udpcli at the same time. udpserv never asked for a port, and I gave udpcli the loopback address with just some port I made up. Udpcli happily created wonderfully timed periods for me whilst udpserv did nothing at all. Neither program quit with the press of a key or ctrl-break, so I had to force end task. --- Richard Dawe comments: I seem to recall that this is with the wsock interface. I am sure I asked for clarification about that, but I can't seem to find a mail with it in!
Created: 1999-11-27 14:11:55
Priority: P5
Severity: enhancement
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: MS-DOS
1999-11-27 14:11:55: Richard Dawe <richdawe@bigfoot.com>
Boris Pereira requested IPX support (PF_IPX/AF_IPX) a long time ago for Doom Legacy. Since there isn't much free documentation on the Internet about IPX, this may tricky. Linux's has support for IPX - look at its headers to see what sort of structures are necessary. I have some QuickBASIC, Turbo Pascal and C code that interfaces with the Netware IPX DOS interrupts. This is provided by Windows '95/'98's networking to DOS boxes, once you've checked an option in the networking configuration.
Created: 1999-11-27 14:16:48
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 14:16:48: Richard Dawe <richdawe@bigfoot.com>
Most of wsock.vxd is partially documented by the WSOCK.VXD Pseudo-Documentation. However, one of its most intriguingly named interfaces, WsControl(), is almost totally unknown. Alfons Hoogervorst produced a document for the undocumented WINSOCK.DLL interface WsControl(), listing data structures, etc. I attempted to implement the equivalent call via wsock.vxd, but it does not quite work. It also seems to corrupt the stack. If this interface could be deduced, then the IP addresses, etc. for each interface could be discovered more simply than walking the registry - they would simply be listed in a data structure.
2000-03-11 14:50:59: Richard Dawe <richdawe@bigfoot.com>
I actually have info and example code on how to use the WsControl() interface from Win32 programs. Perhaps this will provide clues as to how the VxD should be called?
Created: 1999-11-27 14:21:17
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 14:21:17: Richard Dawe <richdawe@bigfoot.com>
In Alfons Hoogervorst's document ipdata.txt (see the development home page), he describes an interface in vdhcp.vxd that allows the dial-up adapter's IP address to be discovered. Since this is the only type of address that libsocket can't find automatically, it would be good if the interface could be used. Currently libsocket has some code that attempts this in src/win9x/w9x_vdhc.c. Unfortunately, the code corrupts the stack, which causes libsocket to behave erratically and crash in most cases. I wonder if this is an artifact of the bugs in the assembler before the patch for gcc 2.95.x?
Created: 1999-11-27 14:26:55
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 14:26:55: Richard Dawe <richdawe@bigfoot.com>
The csock interface uses sock.vxd from the Coda Network File System project to provide TCP/IP and UDP/IP protocol support. sock.vxd has no concept of out-of-band data (*). (*) OOB data can be sent/received using the MSG_OOB data flag or using the SO_OOBINLINE socket option. OOB data for TCP is a packet sent with the urgent bit set. Since OOB data is generally frowned upon by the experts in the comp.os.ms-windows.programmer.winsock newsgroup, perhaps this isn't such a bad thing.
1999-12-18 02:34:59: Richard Dawe <richdawe@bigfoot.com>
According to TCP/IP Illustrated Volume 1, out of band data is different to urgent data. OOB data should be sent down a separate channel, e.g. another TCP connection. The BSD boys and gals decided to implement OOB transmission by (mis)using the urgent flag in TCP packets.
Created: 1999-11-27 14:42:17
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 14:42:17: Richard Dawe <richdawe@bigfoot.com>
The wsock interface uses wsock.vxd to provide TCP/IP and UDP/IP services. It supports the OOB options on calls like send(), setsockopt(), etc. Thus, you can send and receive OOB data. There are some problems in the implementation: 1. If you have set the socket option SO_OOBINLINE, there is currently no support for sockatmark() to determine if you are at an OOB mark. The sockatmark() call is in src/oob.c - this may change at a later date. 2. You can set a SIGURG handler, but it will never be called. There is no support for a callback from wsock.vxd. I think this would be needed to then signal SIGURG. Each interface has a non-blocking check function, that checks for completion of non-blocking calls. Maybe this could be adapted to check for OOB data too - i.e. by performing the appropriate ioctl, if SO_OOBINLINE is set? The extra VxD calls might not be great for performance though... Another question is whether OOB is actually supported - I've never tried it, and I don't remember anyone telling me they had tried it. Maybe Phillipe Hanrigou did once?
Created: 1999-11-27 14:45:52
Priority: P5
Severity: enhancement
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 14:45:52: Richard Dawe <richdawe@bigfoot.com>
DXEs are dynamically loadable libraries for DJGPP. I seem to recall that the mechanism generally only works for simple libraries, which libsocket clearly is not. It may be worth investigating one day though. A different DLL solution may be better, such as the one being developed as part of the X-Windows for DOS project.
Created: 1999-11-27 14:47:57
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 14:47:57: Richard Dawe <richdawe@bigfoot.com>
libsocket is going to need support for routing tables at some point, especially when DOS support is added. The BSD ioctls for querying routing tables should be supported too.
Created: 1999-11-27 14:51:03
Priority: P2
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: MS-DOS
1999-11-27 14:51:03: Richard Dawe <richdawe@bigfoot.com>
DOS support should be added to libsocket, so that people don't need to make the choice between networking libraries and don't need to recompile when they want to run on DOS or Windows. The current best solution would be to merge in some code from Watt-32. This is a big task, since it has its own BSD layer, socket file descriptor handling, etc. I envisage the best solution being a series of patches tracking the versions of Watt-32, so you can download libsocket, download Watt-32, unzip Watt-32 into a directory in the libsocket tree, apply patches, compile and run. It may not be that simple ;)
Created: 1999-11-27 14:55:24
Priority: P1
Severity: blocker
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: sources
Platform: PC
Operating System: All
1999-11-27 14:55:24: Richard Dawe <richdawe@bigfoot.com>
The gcc 2.95.x series of C compilers have stricter checking than earlier versions (2.8.x, 2.7.x). One of the things that was tightened up was checking of "spilled registers". Beta 3 has registers in the spill list that are assigned on entry and exit of the assembly block. Putting them in the spill list informs gcc that they should be saved. This is incorrect, since we are assigning them values! Hence, the assembly is broken. Previously gcc didn't complain, even though it should have done. See the gcc FAQ for more details.
1999-11-27 14:57:59: Richard Dawe <richdawe@bigfoot.com>
This is fixed by a patch available here: http://homepages.nildram.co.uk/~phekda/richdawe/lsck/lsck_new.htm#1999-11-24
Created: 1999-11-27 15:03:17
Priority: P3
Severity: major
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 15:03:17: Richard Dawe <richdawe@bigfoot.com>
The unix interface provides Unix domain socket support. It does this by using a pair of LAN Manager mailslots. On Windows '95 anyone can create a mailslot with any name they like. On Windows NT you need priveledges to create mailslots with long filenames, but not to create ones that fit the 8+3 filename convention. Presumably this is for backwards compatibility with DOS programs that are unaware on Windows NT's security.
2000-03-11 15:42:59: Richard Dawe <richdawe@bigfoot.com>
I guess this should also cope with "SET LFN=N" under Windows '95, DOS. A tricky problem is how to cope with communications between one DOS with LFN=N and another with LFN=Y, with a filename that doesn't fit the 8+3 convention. I guess the simple answer is not to and to have it as a limitation. I wonder what the behaviour is on Win2K?
2000-06-03 01:37:59: Richard Dawe <richdawe@bigfoot.com>
This should be addressed for 0.7.4 beta 5 / release.
Created: 1999-11-27 15:05:47
Priority: P3
Severity: minor
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: documentation
Platform: PC
Operating System: All
1999-11-27 15:05:47: Richard Dawe <richdawe@bigfoot.com>
I've found the resolver's debugging options to be particularly helpful when, er, debugging UDP support. They can also be useful if you're not sure if you've set your DNS settings properly.
2000-03-11 15:07:59: Richard Dawe <richdawe@bigfoot.com>
This is described in the user's guide (redist/u-guide.txt).
Created: 1999-11-27 15:13:45
Priority: P3
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 15:13:45: Richard Dawe <richdawe@bigfoot.com>
The socket option SO_LINGER option takes a "struct linger" as its argument. This contains two "int" arguments. Unfortunately, the size of an int is compiler dependent - for DJGPP's gcc port its a long integer, 32 bits or 4 bytes. It is less clear what it should be for the structure passed to wsock.vxd. wsock.vxd first appeared in the days of Windows 3.x, so it could be 16 bits, but the networking drivers are 32-bit so it's more likely to be 32 bits too. I did some test a while back and the structure appeared to contain two 2 byte ints. That is, the returned data from getsockopt() made more sense as a 2 * 2 byte structure than it did as a 2 * 4 byte structure. However, I've experienced GPFs when using SO_LINGER and the 4-byte _total_ size structure, so maybe I was wrong in my testing? I don't know what impact this has had on anyone, since no-one has reported any problems on this matter to me.
1999-12-24 11:19:59: Richard Dawe <richdawe@bigfoot.com>
I discovered that the 'struct linger' structure should use short unsigned ints. After removing the code from getsockopt(), setsockopt() to "interpret" this stucture from the input/output parameters, SO_LINGER support seemed to work. Whether it lingers or not is another question, but it seems that you can set lingering OK.
Created: 1999-11-27 15:22:10
Priority: P2
Severity: critical
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: WONTFIX
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 15:22:10: Richard Dawe <richdawe@bigfoot.com>
The csock interface's helper VxD, sock.vxd, has a bug in its close routine. It always forcibly closes a TCP connection. On a close(), a TCP packet with the RST bit set in the header is sent to the other end to close the connection. The normal method is to set the FIN bit, which leads to a negociated end of connection. Sending a RST means that the normal acknowledgement mechanism is not used, so any data waiting to be sent is just discarded. This is clearly not what you would want in most cases. The current close() code is OK for things like HTTP, but it completely kills FTP sessions. I ported a Linux program called sitecopy for uploading web pages, etc. to an FTP site. FTP uses a control connection and a data connection, i.e. 2 TCP connections. It connects to the control, opens a data connection, transfers data, etc. OK until the data connection is closed. The FTP session then fails, because the data connection was forcibly closed. The sock.vxd sources do have some comments in the sys_close() in socket.c (Coda sources, not libsocket!). It has some graceful disconnect code commented out, suggesting that it doesn't work. Maybe with a little work this could be fixed? Unfortunately I don't have the Win95 DDK, so I can't try modifying and compiling a fix. Maybe later I can obtain a copy.
2000-03-11 15:10:59: Richard Dawe <richdawe@bigfoot.com>
Unfortunately this is out of my control. I did manage to build sock.vxd from the sources using MS Visual C++ 6 and the Windows 98 DDK (some mods were necessary), but I could not fix the problem myself. Unless the Coda people sort this out, this bug will remain in libsocket's Winsock 2 support (unless an alternative method is found/ implemented).
Created: 1999-11-27 15:24:33
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 15:24:33: Richard Dawe <richdawe@bigfoot.com>
Winsock can support multicast - there are several MS Knowledge Base articles on it - but I have never tried it. csock currently has no support for multicast, i.e. the socket options are not presently supported.
Created: 1999-11-27 15:25:40
Priority: P2
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 15:25:40: Richard Dawe <richdawe@bigfoot.com>
libsocket needs a test suite, so I can do regression testing on the fixes. Currently it's difficult to tell if I've broken anything between fixes/patches.
2000-03-11 15:12:59: Richard Dawe <richdawe@bigfoot.com>
Work has begun, but many, many more tests and some kind of testing strategy are needed.
Created: 1999-11-27 15:28:05
Priority: P3
Severity: enhancement
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: sources
Platform: PC
Operating System: All
1999-11-27 15:28:05: Richard Dawe <richdawe@bigfoot.com>
Making distributions is hassle. Add some targets for doing this automagically. This should probably include a test build to check that everything needed is present in the distribution. Maybe I'm getting lazy in my old age ;)
2000-05-29 10:20:59: Richard Dawe <richdawe@bigfoot.com>
I am just being lazy. Use the install target to create the binaries for distribution! The source distribution isn't very much hassle compared with binaries anyway.
Created: 1999-11-27 15:41:32
Priority: P3
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 15:41:32: Richard Dawe <richdawe@bigfoot.com>
The socket option SO_ERROR is read-only and contains the current error status of the socket. Since sock.vxd does not provide a getsockopt() interface, this must be emulated by the internals of libsocket. It may, in fact, be better to put this in a generic getsockopt() handler, because SO_TYPE is already emulated by the csock interface. This could be similar in which the ioctlsocket() and fcntlsocket() functions have emulation routines.
1999-11-27 15:42:59: Richard Dawe <richdawe@bigfoot.com>
SO_ACCEPTCONN and SO_BROADCAST could also be emulated.
1999-12-24 11:22:59: Richard Dawe <richdawe@bigfoot.com>
After reading Stevens's book on Unix Network Programming, it seems I have misinterpreted the meaning of SO_ERROR. It's only the error value of pending I/O operations. So, normally you should not need to use it, because errno will contain the error code for the last socket option. Just a misinterpretation.
Created: 1999-11-27 15:46:57
Priority: P5
Severity: enhancement
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 15:46:57: Richard Dawe <richdawe@bigfoot.com>
Traditionally send(), recv() are implemented using sendto(), recvfrom(), which are in turn implemented using sendmsg(), recvmsg(). The latter functions are substantially more complicated than sendto(), recvfrom(). They can use scatter-gather I/O. For completeness, it would be nice to have these functions. Linux has some man pages on these functions + cmsg. This is something to do on a rainy day, when I have nothing better to do and I feel like breaking all the code I've (possibly) just got working ;)
Created: 1999-11-27 15:50:58
Priority: P3
Severity: enhancement
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 15:50:58: Richard Dawe <richdawe@bigfoot.com>
Recently on the dossock mailing list (http://www.bigfoot.com/~richdawe/dossock/) it was reported that wsock2.vxd could be used to create sockets, etc. in a similar method to that used with wsock.vxd. The main difference appears to be that everything is carried out asynchronously. Hopefully this will soon be resolved, so that code can be put into libsocket to use wsock2.vxd. I think the only thing remaining to discover is how to use the send/receive routines.
Created: 1999-11-27 15:52:02
Priority: P3
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: documentation
Platform: PC
Operating System: All
1999-11-27 15:52:02: Richard Dawe <richdawe@bigfoot.com>
This might be useful for TCP/IP newbies.
2000-06-03 01:33:59: Richard Dawe <richdawe@bigfoot.com>
This is documented in the info docs. It'll probably be moved around over time, though.
Created: 1999-11-27 15:52:44
Priority: P2
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: NEW
Resolution:
Component: documentation
Platform: PC
Operating System: All
Created: 1999-11-27 15:57:34
Priority: P2
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 15:57:34: Richard Dawe <richdawe@bigfoot.com>
The csock interface currently contains support for "faking" MSG_PEEK support. This should be generalised to _all_ interfaces. This might make it easier to add support for MSG_WAITALL too. The motivation for doing this is that the wsock interface could then support MSG_WAITALL, which is does not currently. Generalising the MSG_PEEK code would also tidy it up - it's currently a mess. It currently doesn't support multiple sources either. I think it should be switched to a linked-list, so the details of each peeked block can be stored along with the block. Additionally, Winsock's MSG_PEEK and FIONREAD support is broken (source: Winsock Programmer's FAQ, Winsock programmers' newsgroup. If we can emulate this using non-blocking reads and peek buffers, then that's a bonus.
2000-03-11 15:17:59: Richard Dawe <richdawe@bigfoot.com>
I have some ideas on this - it should be implemented as part of a generic layer, using the same interface as csock, wsock, unix. This would have functions prefixed __lsckg. This would support more than just MSG_PEEK, MSG_WAITALL - it could include the emulation of fcntl(), ioctl(), which are currently implemented in the fcntlsocket_emulated() and ioctlsocket_emulated() functions. This generic interface would only be used in cases where an interface such as csock did not have the required capabilities to support the operation. The capability bits have been added to libsocket 0.7.4 beta 4, but are currently unused. The use of capability bits will also allow us to get round bugs in the low-level drivers, because we can pretend that the low-level driver doesn't support a certain operation (e.g. MSG_PEEK) if it's broken (e.g. MSG_PEEK with Winsock).
Created: 1999-11-27 16:00:04
Priority: P5
Severity: enhancement
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: All
1999-11-27 16:00:04: Richard Dawe <richdawe@bigfoot.com>
These functions were suggested to add support for IPv6 and other protocols to the standard socket functions. The current IPv4 functions just won't cope with IPv6. libsocket is unlikely to support IPv6, but it would be a good idea to add these functions for future-proofing as people switch to IPv6 - OK, this is a long way off, which is why this is low priority.
1999-11-27 16:00:59: Richard Dawe <richdawe@bigfoot.com>
getnameinfo() should be implemented by the same illogic.
Created: 1999-11-27 16:03:39
Priority: P2
Severity: major
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: NEW
Resolution:
Component: sources
Platform: PC
Operating System: All
1999-11-27 16:03:39: Richard Dawe <richdawe@bigfoot.com>
When a program is testing the keyboard buffer and a socket for readiness, the select() call never completes on a keypress. It does work for sockets when data is received. Maybe the select call blocks for too long in the VxD, so the keypress data is lost? This seems implausible. This occurred with the wsock interface. I can't recall whether on not it did for csock - it needs more testing.
1999-12-18 02:14:59: Richard Dawe <richdawe@bigfoot.com>
I discovered my test program was defective (doh). Pressing a key does cause select() to signal input readiness. However, I do remember Jason Winnebeck saying that he had had problems with select() and stdin, so I'll leave this open for now.
Created: 1999-11-27 16:09:26
Priority: P1
Severity: critical
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 16:09:26: Richard Dawe <richdawe@bigfoot.com>
Using the test program httpget, I find that requesting a web page > 64K (*) causes httpget to block indefinitely. This occurs no matter how big the buffer is (I've tried from 1 byte (**) up to 128K in various sizes) or whether the socket is non-blocking or not. Using a 1K block size, you can see that it seizes at 64K. By coincidence, the receive buffer size in sock.vxd is 64K - except in one case where it's ~4K, but I'm not sure how often the case is. This seems to suggest that there are buffer handling bugs in sock.vxd (*) I use the DJGPP FAQ in HTML form. (**) If you're silly enough to try a 1-byte buffer, then your computer will crash and burn. I have reported this problem to the Coda Network File System guys, but they have not replied to my messages. Without any debugging tools or the Win95 DDK, it's hard to see what the problem is. The sock.vxd sources _looked_ OK, but there's clearly something wrong.
2000-03-11 15:20:59: Richard Dawe <richdawe@bigfoot.com>
I have deferred this, because it's a definite problem. Maybe there is some way around it? If I can't fix this in libsocket, then this bug will remain, in the same way as the forced closure of TCP/IP sockets by SOCK.VXD. This bug is completely reproducible from me on Winsock 1.1 - not sure what happens with Winsock 2.
Created: 1999-11-27 16:26:53
Priority: P2
Severity: critical
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: LATER
Component: sources
Platform: PC
Operating System: Windows 95
1999-11-27 16:26:53: Richard Dawe <richdawe@bigfoot.com>
The Unix domain socket interface, unix, currently assumes that there is no data loss when using local mailslots. This may or may not be the case (*). There is currently a limit on the amount of data that can be queued on a mailslot (almost 64K, the maximum mailslot buffer size). So, it is possible that data loss could occur, regardless of whether the mailslot is reliable. (*) There may be a limit on the number of queued messages. There appears to be one on Windows NT. I once tried a Denial Of Service (DOS) attack on one of my flatmates using a program that sent WinPopup-format messages to his NT box. After ~15 unread messages he did not receive any more. He then launched a reply DOS on my Win95 box, which almost completely killed it, because there didn't appear to be a similar limit on Win95. I couldn't kill WinPopup, because of Win95's lacklustre multitasking. The unix interface's messages should have sequence numbers, a la TCP, to recover from data loss. This should make it easier to implement some of the other features of sockets too.
2000-06-03 01:41:59: Richard Dawe <richdawe@bigfoot.com>
This could be sorted out post-0.7.4 release. For the moment I haven't seen data loss. Really more testing is needed.
Created: 1999-12-09 21:55:34
Priority: P4
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: RESOLVED
Resolution: FIXED
Component: sources
Platform: PC
Operating System: Windows NT
1999-12-09 21:55:34: Richard Dawe <richdawe@bigfoot.com>
libsocket's wsock & csock modules use INT 0x2F, AX=0x160A to detect the version of Windows that it's running under. This is used by the code to load the appropriate VxD and display appropriate debugging output. This call fails (well, returns no version information) for Windows NT. There is another function, AX=0x1600, that may yield the Windows version in more cases.
2000-03-11 15:21:59: Richard Dawe <richdawe@bigfoot.com>
I no longer have (practical) access to Windows NT, so I can't really test the fixes I put in.
2000-03-11 15:23:59: Richard Dawe <richdawe@bigfoot.com>
Oops, I haven't actually fixed it, just put Windows NT version detection in. I think the csock and wsock code will need to be updated to abort on detection of Windows NT, to avoid crashes.
2000-04-25 13:34:59: Richard Dawe <richdawe@bigfoot.com>
Windows NT is now detected
Created: 1999-12-09 21:57:27
Priority: P2
Severity: normal
Assigned To: Richard Dawe <richdawe@bigfoot.com>
Status: NEW
Resolution:
Component: sources
Platform: PC
Operating System: Windows NT
1999-12-09 21:57:27: Richard Dawe <richdawe@bigfoot.com>
libsocket programs crash with a segfault on exit on Windows NT. The message "General Protection Fault" is displayed. bfdsymify (a more advanced version of symify) did not seem to display any debugging info, so more investigation is needed to discover the cause of this bug.
2000-03-11 15:27:59: Richard Dawe <richdawe@bigfoot.com>
I no longer have (practical) access to Windows NT, so I can't really fix this.
2000-04-25 21:58:59: Richard Dawe <richdawe@bigfoot.com>
demo/diag.exe appears to crash in strerror().
Bug 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
31 bug(s) found
This page was generated on Sat Jul 27 07:51:22 2002 by bz_dumpbugs.pl.
bz_dumpbugs.pl, version 1.3, Copyright (C) 1999-2002 by Richard Dawe