Build GENERIC with IPX support

Marek Salwerowicz marek_sal at wp.pl
Mon May 13 21:11:02 UTC 2013


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 at 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 at 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



More information about the freebsd-stable mailing list