Let's see if this fixes it. When a Netware server first comes up, both
IPX and NCP are active, but do return some error codes if the SYS volume
has not been mounted yet if someone attempts to connect to the LOGIN
directory (which is where clients get pointed by default when they first
connect). It sounds like someone is getting a field with '0' in it in
the request which is causing the NULL deference. NetWare 5.1 is a
little different, but only because the IPX and NCP modules are not
compiled proper in the NetWare kernel as they are in 4.11, and get
loaded AFTER the volume mounts. I am wondering if this problem is
confined to 4.X and below. I would think that 5.1 would not have this
problem since the SYS:LOGIN directory will get mounted before the IPX
and NCP engines load. Let's see if what you suggest fixes this.
Jeff
Petr Vandrovec wrote:
>
> On 29 Sep 00 at 1:51, Jeff V. Merkey wrote:
> > Describein more detail, perhaps I can help.
>
> Hi Jeff,
> this is what I send just half a hour ago to Linux-net as response
> to someone else's request... I can't think any reason why info@primakow.ru
> got that oops except if one part of kernel was compiled with different
> options that another, and so ipx specific info was overwritten by generic
> socket layer... If recompiling whole kernel+modules does not fix it,
> then also bit error in lowest order bit can cause it (remember,
> sk->protinfo.af_ipx.intrfc was (void*)1).
> Best regards,
> Petr Vandrovec
> vandrove@vc.cvut.cz
>
> From: Self <VCNET/VANDROVE>
> To: Yuri Syrota <yuri@renome.rovno.ua>
> Subject: Re: spx socket
> Cc: linux-net@vger.kernel.org
> Date: Fri, 29 Sep 2000 11:15:56 MET-1
>
> On 29 Sep 00 at 9:53, Yuri Syrota wrote:
> >
> > will be fixed spx sockets in kernel 2.4?
>
> I do not think. But maybe I'm wrong. Jeff Merkey from Timpanogas was
> talking about this and SPXII implementation some time ago, but I believe
> that after he saw sources, he forgot about fixing, and is now
> investigating possibility of complete reimplementation (as for SPXII
> client port number can change after connection is opened, only SPX
> connection ID is thing which matters, not (port,connID) pair... dunno
> why spec says this).
>
> And if someone has interest in fixing SPX... Please, look into IPX first.
> My understanding is that
>
> ipx_rcv -> ipxitf_auto_create -> ipxitf_insert
>
> contains no locking against concurrent ipxitf_create -> ipxitf_insert,
> ipxitf_delete -> ipxitf_down, and, worse,
>
> ipx_rcv -> ipxitf_find_using_phys
>
> accesses ipx_interfaces linked list without any lock, so it can
> run in parallel with ioctl->ipxitf_delete->ipxitf_down...
>
> Or does ipx_rcv run under big kernel lock? I do not think ;-)
> Same races occurs in routing code wrt ipx routing table... Also
> linked list, also no locks. Even worse, ipxrtr_add_route first
> insert kmalloced route entry into list, and fills it with valid
> data after that! So you can retrieve invalid rt->ir_intrfc, causing
> oops...
>
> If you do not use 'ipx_configure --auto_interface=on --auto_primary=on'
> and you disconnect network cable when doing manipulations with
> routing table (running 'ipx_route' and/or 'nwsfind' and/or 'ipxd'),
> you are on safe side... Having one CPU makes race windows smaller,
> but does not close them (f.e. received packet while in the middle
> of ipxrtr_add_route...)
> Best regards,
> Petr Vandrovec
> vandrove@vc.cvut.cz
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:25 EST