Date: Fri, 16 Apr 1999 20:03:17 +0100 From: Brian Somers <brian@Awfulhak.org> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, brian@Awfulhak.org, camel@avias.com, current@FreeBSD.ORG Subject: Re: some news about ftp hangs Message-ID: <199904161903.UAA00879@keep.lan.Awfulhak.org> In-Reply-To: Your message of "Sat, 17 Apr 1999 02:02:07 %2B0900." <37176D0F.904687D6@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Luoqi Chen wrote:
> >
> > Sorry, this is a legitimate ICMP packet: port unreacheable. It looks like
> > the ftp server (ftp.freebsd.org) was making an UDP query to DNS port on
> > the client (which happens to have a named server running, but that's just
> > for the internal network, external ip address is served by an outside server)
> > and the client responds with port unreacheable even though there is a named
> > running. I'm totally confused. I'll try to find out more. By the way, if
> > I turn off aliasing (set alias enable off), ftp works fine again.
>
> This might be a good time to point out that such changes were made
> not only to ftp but to a number of other clients. We now check the
> reverse address for the IP that was found, so we can decide whether
> log the name or the ip address (the later if the reverse does not
> match the original address).
Now I think I'm confused ;-} I haven't seen any changes to ftp....
I did the double lookup bit to all the stuff in libexec (including
ftpd), but that shouldn't effect what's going on here. If the
external NS record for Louqi's machine isn't supposed to be on that
machine, then we shouldn't have seen a DNS query (maybe named is only
binding to the internal IP - hence the ICMP unreachable bit).
But we digress !
What's supposed to happen w/ ftp (for anyone that doesn't already
know):
o The client does a ``get ....''.
o ftp creates a socket and bind()s it, getting a random port number
back.
o ftp sends a PORT command with arguments of the local IP number and
the port that bind() gave back.
o libalias catches this packet and tweaks it. It changes the IP to
the interface IP and may change the port so some arbitrary number
that fits in well with it's little world. It then makes an entry
in the internal alias tables so that it'll catch the subsequent
connection from the remote host, and undo the damage done from
mangling the PORT command. All this happens in
src/lib/libalias/alias_ftp.c
o ftp sends the RETR command down the original connection and gets
the data back on the new connection.
The deficiency in libalias is that it can't identify PORT commands
that span more than one packet fragment. In practice this has never
been a problem (well, to my knowledge).
On my laptop (-current from yesterday), things are just peachy.
So, I don't get it. I've tested without libalias involved to other
machines, and with libalias to my local machine (a ppp loopback). I
haven't tested via libalias to another machine (I've only got one
machine at the moment - I'm on the train!).
I'll have a further poke around when I get home, but I suspect no
changes ;-/
> --
> Daniel C. Sobral (8-DCS)
> dcs@newsguy.com
> dcs@freebsd.org
>
> "Well, Windows works, using a loose definition of 'works'..."
--
Brian <brian@Awfulhak.org> <brian@FreeBSD.org>
<http://www.Awfulhak.org>; <brian@OpenBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@uk.FreeBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904161903.UAA00879>