Build GENERIC with IPX support

Tue May 14 02:10:21 UTC 2013

Hi,

Are you able to help someone figure out what's going on?

The main problem with IPX / netware testing is that we just don't have
netware servers lying around. :)

Adrian

On 13 May 2013 14:10, Marek Salwerowicz <marek_sal at wp.pl> wrote:
> 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
>