> First, if you are not using hget to fetch the URL in question,
> use hget. That eliminates the browser.
I've tried with wget in the httpserver network. That's how I
got the 1666 bytes value.
> Second, if you run
>
> aux/listen1 tcp!*!80 rc -c 'sleep 1; cat /lib/words'
>
> can you use con -l tcp!yourserver!80 to get all of /lib/words?
No. I ran further test cases, and the outcome was that I get
all the data from:
aux/listen1 tcp!*!80 rc -c 'sleep 1; sed 170q /lib/words'
(and any amount of lines less than 170, from /lib/words)
but I get *no* output (using con(1) from outside the network)
with:
aux/listen1 tcp!*!80 rc -c 'sleep 1; sed 171q /lib/words'
(that is, the con(1) connection just waits and waits). With that
threshold, I found:
--rw-rw-r-- M 9714 akumar akumar 1447 Sep 27 12:52 tmp/170words
--rw-rw-r-- M 9714 akumar akumar 1454 Sep 27 12:53 tmp/171words
> Third, if you run hget on the machine where you normally
> run listen1, can you fetch the page normally?
I can get all of the data normally, *from* the httpserver, using
hget on the computer running listen1.
> I think Erik is right that you have MTU problems. I think that
> either the connection from 442 to listen1 or the connection
> from listen1 to your client machine has its device MTU set
> larger than some intermediate piece of network hardware
> allows, so that once the packets get too big they just start
> dropping on the floor, and for some reason the ICMP packets
> you'd need to do path MTU discovery on that connection are
> not getting through either. But you need to isolate the
> problem with a simpler test case first.
With the above test case of the first 171 lines of /lib/words,
I tried `{echo mtu 1492 > /n/ipifc/0/ctl}, as well as other MTU
settings (the default being 1514), but with none of them could
I send all (well, I didn't get *any* output from con(1), so I don't
think partial data was being sent either?) of the data out of the
network (it worked fine on the machine running listen1, itself,
of course).
Thanks,
ak
