Re: [9fans] ip/rarpd problem

Re: [9fans] ip/rarpd problem

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

i suspect it's part of an IPv4 prefix.
ip/rarpd.c has
	if(myipaddr(myip, net) < 0)
but
	uchar	myip[4];
yet myipaddr now sets IPaddrlen (16) bytes
and static char *efmt is allocated close to myip
in data.

if that becomes
	uchar	myip[IPaddrlen];
and the subsequent
		memmove(rp->spa, myip, sizeof(rp->spa));
becomes
		v6tov4(rp->spa, myip);
it might work, but then again
that might just be the first of several changes required.

i haven't got appropriate devices here to test rarpd

[-- Attachment #2: Type: message/rfc822, Size: 5375 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 706 bytes --]

Given where it crashes, it isn't garbled, 0xffff0000 is what is being passed.
One possibility is that something on the stack above _fmtdispatch trashed the
stack.  I don't see anything obviously wrong.  We stopped running rarpd when
our last sun went nova.  You might try rebuilding the libraries and rarpd and
see if it still happens.  The line numbers from your acid stack dump are
a bit different than the current source, so you might have some incompatible
changes in there (or acid is guessing badly).

Otherwise, keep digging, bug snprint and see if fmt is 0xffff0000 coming in,
etc.  If it's consistently repeatable, it should be easy to track down just
by marching tests through the code.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 3024 bytes --]

From: kazumi iwane <kiwane@mx6.ttcn.ne.jp>
To: 9fans@cse.psu.edu
Subject: [9fans] ip/rarpd problem
Date: Wed, 04 Sep 2002 07:10:53 +0900
Message-ID: <20020903221016.ZHGO17976.mta5p@isabella>

ip/rarpd dies as soon as it receives a request.

 rarpd 208: suicide: sys: trap: fault read addr=0xffff0000 pc=0x00002c19

Below is what acid tells me. dofmt:fmt looks bad. This should be equal
to efmt$1, a static format string defined in eipfmt(). I can't figure
out why this looks garbled.

Can somebody please enlighten me?

acid: stk()
At pc:0x00002c19:dofmt+0x138 /sys/src/libc/fmt/dofmt.c:37
dofmt(*dofmt:fmt=0xffff0000,*dofmt:f=0x7fffe4a8)
	called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(*vsnprint:len=0x00000028,*vsnprint:buf=0x7fffe55c,
         *vsnprint:args=0x7fffe50c,*vsnprint:fmt=0xffff0000)
	called from snprint+0x2b /sys/src/libc/fmt/snprint.c:13
snprint(*snprint:fmt=0xffff0000,*snprint:buf=0x7fffe55c,
        *snprint:len=0x00000028)
	called from eipfmt+0x272 /sys/src/libip/eipfmt.c:38
eipfmt(*eipfmt:f=0x7fffe5f0)
	called from _fmtdispatch+0x94 /sys/src/libc/fmt/fmt.c:187
_fmtdispatch(*_fmtdispatch:isrunes=0x00000000,*_fmtdispatch:f=0x7fffe5f0,
             *_fmtdispatch:fmt=0x000114b8)
	called from dofmt+0x75 /sys/src/libc/fmt/dofmt.c:62
dofmt(*dofmt:fmt=0x000114b6,*dofmt:f=0x7fffe5f0)
	called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(*vsnprint:len=0x00010000,*vsnprint:buf=0x7fffe744,
         *vsnprint:args=0x7fffe650,*vsnprint:fmt=0x000114b6)
	called from sprint+0x2c /sys/src/libc/fmt/sprint.c:13
sprint(*sprint:fmt=0x000114b6,*sprint:buf=0x7fffe744)
	called from main+0x330 /sys/src/cmd/ip/rarpd.c:141
main(*main:argv=0x7fffefe4,*main:argc=0x00000000)
	called from _main+0x31 /sys/src/libc/386/main9.s:16

-- kazumi iwane

Re: [9fans] ip/rarpd problem

[presotto]

[-- Attachment #1: Type: text/plain, Size: 25 bytes --]

thanks, I'll fix sources.

[-- Attachment #2: Type: message/rfc822, Size: 1934 bytes --]

From: kazumi iwane <kiwane@mx6.ttcn.ne.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ip/rarpd problem
Date: Mon, 09 Sep 2002 03:31:54 +0900
Message-ID: <20020908183107.NSED5386.mta1p@isabella>

kiwane@mx6.ttcn.ne.jp wrote:
>    if(write(edata, buf, 42) != 42)
>         error("write failed");
>
> gets Etoosmall.

I think it's because 42 < ETHERMINTU == 60, so I changed:

rarpd.c:159 c /n/sources/plan9/sys/src/cmd/ip/rarpd.c:159
< 		if(write(edata, buf, 60) != 60)
---
> 		if(write(edata, buf, 42) != 42)

and it is working now.

-- kazumi iwane

Re: [9fans] ip/rarpd problem

[kazumi iwane]

kiwane@mx6.ttcn.ne.jp wrote:
>    if(write(edata, buf, 42) != 42)
>         error("write failed");
>
> gets Etoosmall.

I think it's because 42 < ETHERMINTU == 60, so I changed:

rarpd.c:159 c /n/sources/plan9/sys/src/cmd/ip/rarpd.c:159
< 		if(write(edata, buf, 60) != 60)
---
> 		if(write(edata, buf, 42) != 42)

and it is working now.

-- kazumi iwane

Re: [9fans] ip/rarpd problem

[kazumi iwane]

presotto@plan9.bell-labs.com wrote:
> Forsyth is right.  Rarpd looks like it was never converted when I
> made all internal addresses V6.  There are other changes to bring it back
> to reality also.  All the %I's should turn into %V's and there should be
> a fmtinstall for 'V'.  I'll stick a new version on sources.

Thank you very very much.

I'd been off the net and I just got the new rarpd from sources
today. I think it's almot ok, but

   if(write(edata, buf, 42) != 42)
        error("write failed");

gets Etoosmall. write() only writes 40 bytes. I don't have time to
dig into it right now, but I will do so this weekend.

-- kazumi iwane

Re: [9fans] ip/rarpd problem

[presotto]

Forsyth is right.  Rarpd looks like it was never converted when I
made all internal addresses V6.  There are other changes to bring it back
to reality also.  All the %I's should turn into %V's and there should be
a fmtinstall for 'V'.  I'll stick a new version on sources.

Re: [9fans] ip/rarpd problem

[presotto]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Given where it crashes, it isn't garbled, 0xffff0000 is what is being passed.
One possibility is that something on the stack above _fmtdispatch trashed the
stack.  I don't see anything obviously wrong.  We stopped running rarpd when
our last sun went nova.  You might try rebuilding the libraries and rarpd and
see if it still happens.  The line numbers from your acid stack dump are
a bit different than the current source, so you might have some incompatible
changes in there (or acid is guessing badly).

Otherwise, keep digging, bug snprint and see if fmt is 0xffff0000 coming in,
etc.  If it's consistently repeatable, it should be easy to track down just
by marching tests through the code.

[-- Attachment #2: Type: message/rfc822, Size: 3024 bytes --]

From: kazumi iwane <kiwane@mx6.ttcn.ne.jp>
To: 9fans@cse.psu.edu
Subject: [9fans] ip/rarpd problem
Date: Wed, 04 Sep 2002 07:10:53 +0900
Message-ID: <20020903221016.ZHGO17976.mta5p@isabella>

ip/rarpd dies as soon as it receives a request.

 rarpd 208: suicide: sys: trap: fault read addr=0xffff0000 pc=0x00002c19

Below is what acid tells me. dofmt:fmt looks bad. This should be equal
to efmt$1, a static format string defined in eipfmt(). I can't figure
out why this looks garbled.

Can somebody please enlighten me?

acid: stk()
At pc:0x00002c19:dofmt+0x138 /sys/src/libc/fmt/dofmt.c:37
dofmt(*dofmt:fmt=0xffff0000,*dofmt:f=0x7fffe4a8)
	called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(*vsnprint:len=0x00000028,*vsnprint:buf=0x7fffe55c,
         *vsnprint:args=0x7fffe50c,*vsnprint:fmt=0xffff0000)
	called from snprint+0x2b /sys/src/libc/fmt/snprint.c:13
snprint(*snprint:fmt=0xffff0000,*snprint:buf=0x7fffe55c,
        *snprint:len=0x00000028)
	called from eipfmt+0x272 /sys/src/libip/eipfmt.c:38
eipfmt(*eipfmt:f=0x7fffe5f0)
	called from _fmtdispatch+0x94 /sys/src/libc/fmt/fmt.c:187
_fmtdispatch(*_fmtdispatch:isrunes=0x00000000,*_fmtdispatch:f=0x7fffe5f0,
             *_fmtdispatch:fmt=0x000114b8)
	called from dofmt+0x75 /sys/src/libc/fmt/dofmt.c:62
dofmt(*dofmt:fmt=0x000114b6,*dofmt:f=0x7fffe5f0)
	called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(*vsnprint:len=0x00010000,*vsnprint:buf=0x7fffe744,
         *vsnprint:args=0x7fffe650,*vsnprint:fmt=0x000114b6)
	called from sprint+0x2c /sys/src/libc/fmt/sprint.c:13
sprint(*sprint:fmt=0x000114b6,*sprint:buf=0x7fffe744)
	called from main+0x330 /sys/src/cmd/ip/rarpd.c:141
main(*main:argv=0x7fffefe4,*main:argc=0x00000000)
	called from _main+0x31 /sys/src/libc/386/main9.s:16

-- kazumi iwane

[9fans] ip/rarpd problem

[kazumi iwane]

ip/rarpd dies as soon as it receives a request.

 rarpd 208: suicide: sys: trap: fault read addr=0xffff0000 pc=0x00002c19

Below is what acid tells me. dofmt:fmt looks bad. This should be equal
to efmt$1, a static format string defined in eipfmt(). I can't figure
out why this looks garbled.

Can somebody please enlighten me?

acid: stk()
At pc:0x00002c19:dofmt+0x138 /sys/src/libc/fmt/dofmt.c:37
dofmt(*dofmt:fmt=0xffff0000,*dofmt:f=0x7fffe4a8)
	called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(*vsnprint:len=0x00000028,*vsnprint:buf=0x7fffe55c,
         *vsnprint:args=0x7fffe50c,*vsnprint:fmt=0xffff0000)
	called from snprint+0x2b /sys/src/libc/fmt/snprint.c:13
snprint(*snprint:fmt=0xffff0000,*snprint:buf=0x7fffe55c,
        *snprint:len=0x00000028)
	called from eipfmt+0x272 /sys/src/libip/eipfmt.c:38
eipfmt(*eipfmt:f=0x7fffe5f0)
	called from _fmtdispatch+0x94 /sys/src/libc/fmt/fmt.c:187
_fmtdispatch(*_fmtdispatch:isrunes=0x00000000,*_fmtdispatch:f=0x7fffe5f0,
             *_fmtdispatch:fmt=0x000114b8)
	called from dofmt+0x75 /sys/src/libc/fmt/dofmt.c:62
dofmt(*dofmt:fmt=0x000114b6,*dofmt:f=0x7fffe5f0)
	called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(*vsnprint:len=0x00010000,*vsnprint:buf=0x7fffe744,
         *vsnprint:args=0x7fffe650,*vsnprint:fmt=0x000114b6)
	called from sprint+0x2c /sys/src/libc/fmt/sprint.c:13
sprint(*sprint:fmt=0x000114b6,*sprint:buf=0x7fffe744)
	called from main+0x330 /sys/src/cmd/ip/rarpd.c:141
main(*main:argv=0x7fffefe4,*main:argc=0x00000000)
	called from _main+0x31 /sys/src/libc/386/main9.s:16

-- kazumi iwane