Re: [9fans] ftpd

Re: [9fans] ftpd

[presotto]

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

correcto mundo

I left pointers in order because idiot systems that reverse lookup
to allow operations often only look at the first returned record
so I kept the most likely first.

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

From: geoff@collyer.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ftpd
Date: Wed, 16 Jan 2002 15:22:55 -0800
Message-ID: <20020116232532.66B2E19A57@mail.cse.psu.edu>

Actually, Plan 9 dns returns resource records of types A, MX and NS
only in random order.  This is the relevant fragment from ndb/dn.c:

	/* just randomize addresses and mx's */
	for(x = rp; x; x = x->next)
		if(x->type != Ta && x->type != Tmx && x->type != Tns)
			return rp;

In particular, PTR records are returned in the order in which the dom=
clauses that they are generated from were read, if I remember it
right.  This doesn't help much if you have DNS secondaries running
BIND, since they will randomise all RRs, but can sometimes be of help
locally.

Re: [9fans] ftpd

[geoff]

Actually, Plan 9 dns returns resource records of types A, MX and NS
only in random order.  This is the relevant fragment from ndb/dn.c:

	/* just randomize addresses and mx's */
	for(x = rp; x; x = x->next)
		if(x->type != Ta && x->type != Tmx && x->type != Tns)
			return rp;

In particular, PTR records are returned in the order in which the dom=
clauses that they are generated from were read, if I remember it
right.  This doesn't help much if you have DNS secondaries running
BIND, since they will randomise all RRs, but can sometimes be of help
locally.

Re: [9fans] ftpd

[Boyd Roberts]

presotto@closedmind.org wrote:
>
> I'm standing against a brick wall now with a blindfold
> and a cheap cigarette hanging from my lips.

Well, you were between a rock and a hard place, so you're excused :)

Re: [9fans] ftpd

[presotto]

...of course why I'ld hang a blindfold from my lips
is another story.

Re: [9fans] ftpd

[presotto]

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

I'm standing against a brick wall now with a blindfold
and a cheap cigarette hanging from my lips.

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

From: Boyd Roberts <boyd@strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ftpd
Date: Wed, 16 Jan 2002 16:08:58 +0100
Message-ID: <3C45978A.9E02D856@strakt.com>

presotto@closedmind.org wrote:
>
> That would break plan 9 in general since we don't use
> port 53 as our source address when resolving dns requests.

I'm pretty sure when I debugged that one apple.com was one
such offender.  That was 18 months (or so) ago.

People who NAT UDP should be shot.

Re: [9fans] ftpd

[Boyd Roberts]

presotto@closedmind.org wrote:
>
> That would break plan 9 in general since we don't use
> port 53 as our source address when resolving dns requests.

I'm pretty sure when I debugged that one apple.com was one
such offender.  That was 18 months (or so) ago.

People who NAT UDP should be shot.

Re: [9fans] ftpd

[presotto]

That would break plan 9 in general since we don't use
port 53 as our source address when resolving dns requests.

Re: [9fans] ftpd

[Boyd Roberts]

presotto@closedmind.org wrote:
> I live behind a NAT now, much to my utter shame and horror,
> because my ISP stopped giving out multiple addresses.

Beware that if they NAT UDP some DNS servers will not respond
to DNS UDP requests that don't originate from port 53.

Re: [9fans] ftpd

[presotto]

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

We also return random ordering to DNS requests in an attempt to
spread load.

However, DNS has nothing to do with arisawa's fix.  He is correct.
When an ftp client uses Active mode transfers, it requires the
server to call it back.  If the client is behind a box doing
NAT for it, the data call back may have to be from the same
address that the control call was to.  I say may because the
ftp rfc doesn't require this, so some NAT box may get it right
if it just uses a two tuple (local port/local addr) rather
than a 4 tuple (local port/local addr/remote port/remote addr)
to index its mappings.

I live behind a NAT now, much to my utter shame and horror,
because my ISP stopped giving out multiple addresses.  However,
I don't notice the problem; perhaps because all servers these
days seem to accept Passive ftp connections, i.e., the client
makes both the control and data connections avoiding the call
back scenario arisiwa is fixing.  I take it he still talks to
some old ftp servers.  The code would work in more situations
with his fix, regardless of what the rfc says.  I remember the
original RFC was written to allow the data call back to come
from an entirely different machine to allow load distribution
but since noone does that, I wouldn't expect any NAT to support
it, except by accident.

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

From: Boyd Roberts <boyd@strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ftpd
Date: Wed, 16 Jan 2002 13:01:19 +0100
Message-ID: <3C456B8F.E715F1D6@strakt.com>

arisawa@ar.aichi-u.ac.jp wrote:
> The line:
>         fd = dial(data,"20",0,0);
> in ftpd.c may make a trouble when the server has two IPs.

I may be a bit out of context here but it must be remembered
that the IP addresses returned by the remote DNS are returned
in a random order, if we are talking unix BIND/named.

This was a design/implementation decision.

Does plan 9 allow you to specify the 'sort order' [a heuristic
in the client resolver library to get around these types
of problems]?

Re: [9fans] ftpd

[Boyd Roberts]

arisawa@ar.aichi-u.ac.jp wrote:
> The line:
>         fd = dial(data,"20",0,0);
> in ftpd.c may make a trouble when the server has two IPs.

I may be a bit out of context here but it must be remembered
that the IP addresses returned by the remote DNS are returned
in a random order, if we are talking unix BIND/named.

This was a design/implementation decision.

Does plan 9 allow you to specify the 'sort order' [a heuristic
in the client resolver library to get around these types
of problems]?

[9fans] ftpd

[arisawa]

Hello 9fans,

The line:
	fd = dial(data,"20",0,0);
in ftpd.c may make a trouble when the server has two IPs.
For example, plan9.aichi-u.ac.jp and ar.aichi-u.ac.jp is the
same machine with different IPs.
I could not get data from plan9.aichi-u.ac.jp from my home,
because my machines are inside of a boardband router with IP
masquerade.

The following may fix the problem.

term% diff /sys/src/cmd/ip/ftpd.c ftpd.c
151a152
> static	char*	myip;
208c209
< 	if(argc)
---
> 	if(argc){
209a211,212
> 		myip = ends->lsys;
> 	}
1558a1562,1568
> 		if(myip){
> 			char buf[80];
> 			snprint(buf, sizeof buf,"%s!20", myip);
> 			fd = dial(data, buf, 0, 0);
> 		}
> 		else
> 			fd = dial(data, "20", 0, 0);



Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp