Re: [9fans] HTTP forwarding with aux/trampoline

Re: [9fans] HTTP forwarding with aux/trampoline

[erik quanstrom]

> aux/listen1 tcp!*!80 rc -c 'sleep 1; cat /lib/words'
what's the sleep for?

> (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.
[...]
> 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).

why didn't you set the mtu to 1454?  you're setting the mtu on
the external interface, right?  if you set the mtu on the wrong
interface, the machine running trampoline will buffer and
refragment for the new mtu.

you could also use ip/ping -s $n to do a search for an acceptable
mtu.

- erik

Re: [9fans] HTTP forwarding with aux/trampoline

[Russ Cox]

> why didn't you set the mtu to 1454?

better, set it to 1000.
and remember that you have to set it on
the machine doing the transmitting,
i.e. the machine running aux/listen1.

russ

Re: [9fans] HTTP forwarding with aux/trampoline

[erik quanstrom]

On Sat Sep 26 14:14:16 EDT 2009, akumar@mail.nanosouffle.net wrote:
> 'httpserver' is a server on a remote connection from
> where the following is run:
>
> aux/listen1 tcp!*!80 aux/trampoline tcp!httpserver!442
>
> where httpserver is running httpd that listens on port 442.
> All is well, until it comes time for data transfer exceeding
> 1666 bytes (images and any other file, really). Through
> port 80 on the computer running trampoline, apparently
> only 1666 bytes of data can be transferred at once, from
> httpserver. The transfer just hangs after that. Getting
> the same data from httpserver directly, yields no such
> problem.

is t possible that the path mtu is < 1500 bytes?  if
so, trampoline isn't going to forward icmp messages.

- erik

Re: [9fans] HTTP forwarding with aux/trampoline

[Lyndon Nerenberg - VE6BBM/VE7TFX]

> is t possible that the path mtu is < 1500 bytes?  if
> so, trampoline isn't going to forward icmp messages.

Trampoline just copies the sequence of data bytes.  It doesn't know
anything about IP or ICMP datagrams.

[9fans] HTTP forwarding with aux/trampoline

[Akshat Kumar]

'httpserver' is a server on a remote connection from
where the following is run:

aux/listen1 tcp!*!80 aux/trampoline tcp!httpserver!442

where httpserver is running httpd that listens on port 442.
All is well, until it comes time for data transfer exceeding
1666 bytes (images and any other file, really). Through
port 80 on the computer running trampoline, apparently
only 1666 bytes of data can be transferred at once, from
httpserver. The transfer just hangs after that. Getting
the same data from httpserver directly, yields no such
problem.


ak

Re: [9fans] HTTP forwarding with aux/trampoline

[Russ Cox]

On Saturday, September 26, 2009, Akshat Kumar
<akumar@mail.nanosouffle.net> wrote:
> 'httpserver' is a server on a remote connection from
> where the following is run:
>
> aux/listen1 tcp!*!80 aux/trampoline tcp!httpserver!442

The thing to do is try to break the problem down
so that you can eliminate either the httpserver or listen1.

First, if you are not using hget to fetch the URL in question,
use hget.  That eliminates the browser.

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?

Third, if you run hget on the machine where you normally
run listen1, can you fetch the page normally?

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.

Russ

Re: [9fans] HTTP forwarding with aux/trampoline

[Akshat Kumar]

> 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