Re: [9fans] /lib/rfc

Re: [9fans] /lib/rfc

[john]

/lib/rfc/grabrfc?  I'm running it now and it seems to be populating
just fine.

John

Re: [9fans] /lib/rfc

[erik quanstrom]

On Tue Apr 22 13:50:10 EDT 2008, john@csplan9.rit.edu wrote:
> /lib/rfc/grabrfc?  I'm running it now and it seems to be populating
> just fine.
>
> John

i had the usual fight with the natted dsl that doesn't pass icmp mustfrags.
i also elected to skip the big honking xml index

	if(! ~ $target *.xml *.xsd && \
	  test ! -e $LIB/$target && test -f $i){

- erik

Re: [9fans] /lib/rfc

[Francisco J Ballesteros]

We had the same problem time ago and had to lower the mtu by hand.
Perhaps detecting too many retransmissions of the same packet could be
considered a hint
of this problem and try by reducing at least once the mtu. In any
case, it´s been
a long time since we had this problem. I even forgot about it.

On Tue, Apr 22, 2008 at 8:58 PM, erik quanstrom <quanstro@coraid.com> wrote:
>
>
>  i had the usual fight with the natted dsl that doesn't pass icmp mustfrags.
>  i also elected to skip the big honking xml index
>
>         if(! ~ $target *.xml *.xsd && \
>           test ! -e $LIB/$target && test -f $i){
>
>  - erik
>
>

Re: [9fans] /lib/rfc

[Gorka Guardiola]

On Tue, Apr 22, 2008 at 9:12 PM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> We had the same problem time ago and had to lower the mtu by hand.
>  Perhaps detecting too many retransmissions of the same packet could be
>  considered a hint
>  of this problem and try by reducing at least once the mtu. In any
>  case, it´s been
>  a long time since we had this problem. I even forgot about it.
>

I think we just got bye with setting the mtu to be some arbitrary 1480
or something
instead of 1500. It was a bug in some adsl router coupled with another
but which was it dropped the packet and did not reported it or the
icmp got lost or something. I cannot remember it too well though
either.

-- 
- curiosity sKilled the cat

Re: [9fans] /lib/rfc

[Francisco J Ballesteros]

Yes, but IIRC, I did undo the change some time after we had the problem,
leaving it back to 1500, and I´ve never seen it happen again. Perhaps we
were lucky and did not connect to a broken router again.

On Tue, Apr 22, 2008 at 10:05 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Tue, Apr 22, 2008 at 9:12 PM, Francisco J Ballesteros <nemo@lsub.org> wrote:
>  > We had the same problem time ago and had to lower the mtu by hand.
>  >  Perhaps detecting too many retransmissions of the same packet could be
>  >  considered a hint
>  >  of this problem and try by reducing at least once the mtu. In any
>  >  case, it´s been
>  >  a long time since we had this problem. I even forgot about it.
>  >
>
>  I think we just got bye with setting the mtu to be some arbitrary 1480
>  or something
>  instead of 1500. It was a bug in some adsl router coupled with another
>  but which was it dropped the packet and did not reported it or the
>  icmp got lost or something. I cannot remember it too well though
>  either.
>
>  --
>  - curiosity sKilled the cat
>
>

Re: [9fans] /lib/rfc

[Charles Forsyth]

> Perhaps we
> were lucky and did not connect to a broken router again.

>The fault on why QEMU crashes every time
> I boot Plan 9 -- venti. With a fossil only system, everything worked
> without a hitch -- until that corrupt

>On Leopard I've found that QEMU runs very slowly but crashes
>exceedingly reliably.  So much so, that it wasn't worth my effort to

>Keep the console running and use drawterm
>instead and it works like a charm.

any sufficiently advanced technology eventually becomes completely indistinguishable from witchcraft

[9fans] /lib/rfc

[erik quanstrom]

is there an existant script for populating this?

- erik

Re: [9fans] /lib/rfc

[geoff]

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

Yes, /lib/rfc/grabfc.  Uncomment this line:

/cron/sys/cron:#30 9 * * *	local	/lib/rfc/grabrfc

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

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: [9fans] /lib/rfc
Date: Tue, 22 Apr 2008 13:11:14 -0400
Message-ID: <189906e1fb5454d42d22ce9a773709ed@quanstro.net>

is there an existant script for populating this?

- erik

Re: [9fans] /lib/rfc

[erik quanstrom]

> Yes, /lib/rfc/grabfc.  Uncomment this line:
>
> /cron/sys/cron:#30 9 * * *	local	/lib/rfc/grabrfc

thank you.  unfortunately, it turns out that this script causes
something that looks like deadlock between ramfs and ftpfs.
i didn't get a bead on ramfs before ftpfs exited but it was in
state Pread as was ramfs.

here's where ftpfs was

tyty# cd /proc/389580
tyty# cat fd
/lib/rfc
  0 r  c    0 (000000000000000a 0 00)     0        0 /dev/null
  1 w  c    0 (000000000000000a 0 00)     0        0 /dev/null
  2 w  M 256525 (0000000000000001 0 00)  8192   337626 /mnt/term/dev/cons
  3 rw |    0 (000000000023e801 0 00) 65536 17056533 #|/data
  4 rw M 258155 (0000000000000141 0 00)  8192     7835 /tmp/ftpo0000389580
  5 r  c    0 (0000000000000001 0 00)     0    75912 /dev/bintime
  6 rw M 258155 (0000000000000142 0 00)  8192    83648 /tmp/ftp00000389580
  7 rw I    1 (00000000000201ad 0 00)     0    86141 /net.alt/tcp/13/data
  8 rw M 258155 (0000000000000143 0 00)  8192   156468 /tmp/ftpa0000389580
  9 rw M 258155 (0000000000000144 0 00)  8192    24637 /tmp/ftpb0000389580
 10 rw M 258155 (0000000000000145 0 00)  8192    14741 /tmp/ftpc0000389580
 11 rw M 258155 (0000000000000146 0 00)  8192    18268 /tmp/ftpd0000389580
 12 rw M 258155 (0000000000000147 0 00)  8192    13356 /tmp/ftpe0000389580
 13 rw M 258155 (0000000000000148 0 00)  8192    15548 /tmp/ftpf0000389580
 14 rw M 258155 (0000000000000149 0 00)  8192    29417 /tmp/ftpg0000389580
 15 rw M 258155 (000000000000014a 0 00)  8192    34950 /tmp/ftph0000389580
 16 rw M 258155 (000000000000014b 0 00)  8192    13591 /tmp/ftpi0000389580
 17 rw M 258155 (000000000000014c 0 00)  8192     4892 /tmp/ftpj0000389580
 18 rw M 258155 (000000000000014d 0 00)  8192    16607 /tmp/ftpk0000389580
 19 rw M 258155 (000000000000014e 0 00)  8192     6641 /tmp/ftpl0000389580
 20 rw M 258155 (000000000000014f 0 00)  8192   221184 /tmp/ftpm0000389580
 22 rw I    1 (00000000000201cd 0 00)     0   221184 /net.alt/tcp/14/data
tyty# acid 389580
acid: lstk()
pread()+0x7 /sys/src/libc/9syscall/pread.s:5
read(fd=0x16,buf=0xdfffde00,n=0x1000)+0x2f /sys/src/libc/9sys/read.c:7
readfile1(node=0x100330)+0xdf /sys/src/cmd/ip/ftpfs/proto.c:941
	tries=0x0
	bp=0x67328
	off=0x36000
	buf=0x62206f74
	n=0x498
readfile(node=0x100330)+0x36 /sys/src/cmd/ip/ftpfs/proto.c:986
	inimage=0x1
	rv=0x8
ropen(f=0x9a8d8)+0x129 /sys/src/cmd/ip/ftpfs/ftpfs.c:463
io()+0x207 /sys/src/cmd/ip/ftpfs/ftpfs.c:279
	n=0xc
	buf=0x88
main(argv=0xdfffef7c,argc=0x1)+0x207 /sys/src/cmd/ip/ftpfs/ftpfs.c:184
	mountroot=0x2eaec
	mountpoint=0x2eae5
	cpassword=0xdfffef93
	_argc=0x61
	_args=0xdfffef91
	cp=0x0
	o=0x0
	p=0x3
_main+0x31 /sys/src/libc/386/main9.s:16

- erik

Re: [9fans] /lib/rfc

[erik quanstrom]

> > Yes, /lib/rfc/grabfc.  Uncomment this line:
> >
> > /cron/sys/cron:#30 9 * * *	local	/lib/rfc/grabrfc
>
> thank you.  unfortunately, it turns out that this script causes
> something that looks like deadlock between ramfs and ftpfs.
> i didn't get a bead on ramfs before ftpfs exited but it was in
> state Pread as was ramfs.
>
> here's where ftpfs was
>
> tyty# cd /proc/389580
> tyty# cat fd
> /lib/rfc
>   0 r  c    0 (000000000000000a 0 00)     0        0 /dev/null
>   1 w  c    0 (000000000000000a 0 00)     0        0 /dev/null
>   2 w  M 256525 (0000000000000001 0 00)  8192   337626 /mnt/term/dev/cons
>   3 rw |    0 (000000000023e801 0 00) 65536 17056533 #|/data
>   4 rw M 258155 (0000000000000141 0 00)  8192     7835 /tmp/ftpo0000389580
>   5 r  c    0 (0000000000000001 0 00)     0    75912 /dev/bintime
>   6 rw M 258155 (0000000000000142 0 00)  8192    83648 /tmp/ftp00000389580
>   7 rw I    1 (00000000000201ad 0 00)     0    86141 /net.alt/tcp/13/data
>   8 rw M 258155 (0000000000000143 0 00)  8192   156468 /tmp/ftpa0000389580
>   9 rw M 258155 (0000000000000144 0 00)  8192    24637 /tmp/ftpb0000389580
[...]

actually, i tracked this a bit further.  the passive connection
gets crossed up.  if killed in this state, ftpfs will exit with
part of the downloading file in its exit status.  this only happens
with larger files.

- erik

Re: [9fans] /lib/rfc

[Lyndon Nerenberg]

On 2008-Apr-22, at 10:11 , erik quanstrom wrote:
> is there an existant script for populating this?

/n/sources/contrib/lyndon/rfcmirror is one.

Re: [9fans] /lib/rfc

[Lyndon Nerenberg]

On 2008-Apr-22, at 10:11 , erik quanstrom wrote:
> is there an existant script for populating this?

Actually, is uses /lib/ietf/rfc, and the corresponding idmirror script
uses /lib/ietf/id.