🚀 go-pugleaf

A previously stable NW 3.11 server upgraded to NW 4.1. Worked fine
until I wanted to get my Mercury mail transport going.

It seems that any NLM which uses TCP/IP sockets abends the server as
soon as it closes a socket.

  - When Mercury is loaded, it displays a few lines on its console
    (corresponding to an SMTP transaction it is starting) and then
    abends the server (running process: Mercury). The abend ocurs
    more or less at the point where I guess mercury would close the
    socket
  - When loading FTPD (the freeware FTP daemon from HellSoft), the
    server stays up. When a client opens an FTP session to the
    server, the connection is estabelished but the server abends
    after the client asked the server for a directory listing.
    The abend occurs at the point where I guess the socket of the
    directory listing's data stream is closed.)
    Notably, HellSoft's RESOLV.NLM and BOOTP.NLM do *not* abend the
    server. Maybe UDP socket's are not part of the problem? But see
    the following:
  - NetWare's PING.NLM works fine, I can ping hosts, but when I press
    ESC to exit it, the server abends (running process: Server 
    Process 02)
  - Once, the server abended when unloading INETCFG.NLM after having
    made TCP/IP config changes (but not yet activating them). I can
    only speculate as to whether sockets are involved.

Each of the above was loaded without any of the other's being
presente, so I can rule out the posibility of a buggy 3rd-party NLM
trashing the servers TCP/IP transport for all the rest.

I guess that the problem is somewhere in CLIB, but it may also be in
STREAM and/or TLI (If CLIB's BSD socket interface is implemented on
top of those).

I have tried the following, to no avail:

  - Rolling back the server to pre-patched state (I applied the latest
    patches directly after upgrading the server).
  - Working through all the available pacthes and ensuring that they
    are correctly installed in (in the boot partition, too).
  - Replacing the nework cards with 3COM 3C509 Combo's and loading
    the corresponding driver. (In case the NE2000.LAN drivers in the
    distribution and LANRV4.EXE patch file where at fault.)

Has anybody experienced something similar? I am on the verge of
opening a Technical Support incident with Novell.


        ,_
        /_)              /| /
       /   i e t e r    / |/ a g e l
       The Platinum Puma