W dniu 2013-05-13 08:52, Jeremy Chadwick pisze:
IPX has been neglected for what should be obvious reasons.  As someone
who got his CNE back in 1994 (circa Netware 3.11), you're the first
person I have encountered since roughly 1997 who is actively using IPX.
Netware does support TCP/IP, you know...

Yes, I am aware of it but in that case I would like to connect to Netware 3.12, which is configured in IPX-only environment. As you see some people still use it, it still works (and works good) and is a perfect back-end for applications and environments working on it.



Anyway, in your case, you're in luck:

#0  0x0000000800d285f7 in strlen () from /lib/libc.so.7
#1  0x0000000800d205b0 in gettimeofday () from /lib/libc.so.7
#2  0x0000000800d2163e in gettimeofday () from /lib/libc.so.7
#3  0x0000000800d21798 in vfprintf_l () from /lib/libc.so.7
#4  0x0000000800d0e701 in fprintf () from /lib/libc.so.7
#5  0x0000000800822a85 in ncp_error () from /usr/lib/libncp.so.4
#6  0x000000080081fa7c in ncp_li_readrc () from /usr/lib/libncp.so.4
ncp_li_readrc(), which is part of libncp, only has one call to
ncp_error() in it:

src/lib/libncp/ncpl_conn.c --

180 /*
181  * read rc file as follows:
182  * 1. read [server] section
183  * 2. override with [server:user] section
184  * Since abcence of rcfile is not a bug, silently ignore that fact.
185  * rcfile never closed to reduce number of open/close operations.
186  */
187 int
188 ncp_li_readrc(struct ncp_conn_loginfo *li) {
189         int i, val, error;
190         char uname[NCP_BINDERY_NAME_LEN*2+1];
191         char *sect = NULL, *p;
192
193         /*
194          * if info from cmd line incomplete, try to find existing
195          * connection and fill server/user from it.
196          */
197         if (li->server[0] == 0 || li->user == NULL) {
198                 int connHandle;
199                 struct ncp_conn_stat cs;
200
201                 if ((error = ncp_conn_scan(li, &connHandle)) != 0) {
202                         ncp_error("no default connection found", errno);
203                         return error;
204                 }

To me, this may indicate you have some kind of "ncp rc file" (I believe
this is ~/.nwfsrc according to the ncplist(1) man page) that may contain
something invalid, or maybe you lack such a file altogether (creating one
might work around the problem).

Seems you're right. What's more surprising, using

% sudo ncplogin

Results in no seg fault errors.

It creates a file in home directory:
arch-gate% sudo file ncplogin.core
ncplogin.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, from 'n'
arch-gate%

But, from shell account it results in segfault.



Back to the actual segfault itself: ncp_error() is pretty simple:

src/lib/libncp/ncpl_subr.c --

447 /*
448  * Print a (descriptive) error message
449  * error values:
450  *         0 - no specific error code available;
451  *  -999..-1 - NDS error
452  *  1..32767 - system error
453  *  the rest - requester error;
454  */
455 void
456 ncp_error(const char *fmt, int error, ...) {
457         va_list ap;
458
459         fprintf(stderr, "%s: ", _getprogname());
460         va_start(ap, error);
461         vfprintf(stderr, fmt, ap);
462         va_end(ap);
463         if (error == -1)
464                 error = errno;
465         if (error > -1000 && error < 0) {
466                 fprintf(stderr, ": dserr = %d\n", error);
467         } else if (error & 0x8000) {
468                 fprintf(stderr, ": nwerr = %04x\n", error);
469         } else if (error) {
470                 fprintf(stderr, ": syserr = %s\n", strerror(error));
471         } else
472                 fprintf(stderr, "\n");
473 }

What I don't understand from the calling stack is how gettimeofday() is
involved.  I have looked at the libc code, looked at the underlying
calling functions and so on (from fprintf() to vfprintf_l() and deeper),
and I don't see how or where gettimeofday() would be called.  The only
place I can think of might be the related locale stuff, but I'm doubting
that given what I've looked at but could still be wrong.

Have world/kernel on this system ever been rebuilt?  If they have,
were both kernel and world rebuilt together from the same source code
and not at different times?
I've installled the 9.1-RELEASE from ISO, then updated using:
# freebsd-update fetch install

And then recompiled the kernel from sources.
I haven't rebuilt the world.


If you're setting LANG, LC_CTYPE, LC_COLLATE, or other locale-oriented
settings in your environment (and my gut feeling is that you are), you
could try removing them and see if you get an actual useful error
message on stderr, but I'm not holding my breath.
No, I don't change any environment variables:
arch-gate% sudo env
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/marek/bin
TERM=xterm
SHELL=/usr/local/bin/zsh
MAIL=/var/mail/root
LOGNAME=root
USER=root
USERNAME=root
HOME=/root
SUDO_COMMAND=/usr/bin/env
SUDO_USER=marek
SUDO_UID=1001
SUDO_GID=1001
arch-gate%

root@arch-gate:/home/marek # env
_=/usr/bin/su
OLDPWD=/home/marek
PWD=/home/marek
SHLVL=2
USER=root
LOGNAME=root
HOME=/root
MAIL=/var/mail/marek
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
TERM=xterm
BLOCKSIZE=K
SHELL=/bin/csh
SSH_CLIENT=127.0.0.1 60737 22
SSH_CONNECTION=127.0.0.1 60737 127.0.0.1 22
SSH_TTY=/dev/pts/0
HOSTTYPE=FreeBSD
VENDOR=amd
OSTYPE=FreeBSD
MACHTYPE=x86_64
GROUP=wheel
HOST=arch-gate
REMOTEHOST=localhost
EDITOR=vi
PAGER=more
root@arch-gate:/home/marek #




I cannot help you with the remaining IPX-specific "stuff"; it's fairly
obvious though, as I said, that this code has been neglected.
Anyway, thanks for help.

3 years ago I've successfully integrated Linux Debian (kernel 2.6.20 as far as I remember) with Netware 3.12. Most likely I'd try to use it also that time instead of FreeBSD if it's not working.

--
Marek Salwerowicz

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to