Re: res_init.c 1.20 broke non-INET6 kernel!
On Wed, 14 Jun 2000 12:21:48 -0700 "Andrey A. Chernov" [EMAIL PROTECTED] said: ache All nameservers are initialized to AF_INET6 which cause socket() to return -1 ache in non-INET6 kernel. ache All names lookups fails as result. Oops, sorry. I'll backout previous commit right now. ache I think IPV6 support is optional, isn't? Yes, of couece. It's just my mistake. Sorry again. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM OpenSSH 2.1 X11 - signal 11
On Sun, 4 Jun 2000 12:30:42 -0500 (EST) "Andrew J. Korty" [EMAIL PROTECTED] said: On Fri, 2 Jun 2000, Hajimu UMEMOTO wrote: BTW, I believe this version of pam_ssh.so doesn't support DSA key yet. Does someone working on it? ajk Oops ... it looks like ssh-agent doesn't support DSA keys yet. Am ajk I missing something? I suppose I could just add DSA support for the ajk PAM authentication phase ... Oh, I see. You are right. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM OpenSSH 2.1 X11 - signal 11
On Tue, 30 May 2000 12:30:41 -0700 (PDT) Kris Kennaway [EMAIL PROTECTED] said: kris On Tue, 30 May 2000, Alexander Leidinger wrote: I've just committed the version from ports to the source tree - could you verify it works? I have to wait until internat catches up, but I'm using pam_ssh.c from ports for a while and it didn't kill xdm. kris Oops, this is now committed to internat also. Thank you. It's working fine with wdm here. BTW, I believe this version of pam_ssh.so doesn't support DSA key yet. Does someone working on it? -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp(1) breakage w/ passive mode?
On Wed, 31 May 2000 10:14:33 +0900
[EMAIL PROTECTED] said:
itojun isn't there some issue in getipnodebyname(), instead of getaddrinfo()?
itojun (NOTE: I'm not really up-to-date with the current status of freebsd4
itojun lib/libc/net)
itojun if you can tell me repeatable example of getaddrinfo() failure,
itojun that would be helpful...
Yes, it's a FreeBSD specific issue. Current getaddrinfo() is using
getipnodebyname_multi(). This was introduced by fixing search order.
There is a limitation that struct hostent cannot hold two address
families at once. So, the host has both A RR and RR, A RR is
converted into mapped address and getaddrinfo() returns only AF_INET6.
This problem was known at introducing getipnodebyname_multi(). But,
priority of fixing search order was higher than this problem in that
time. So, this problem is remained.
I think previous my patch is best workaround to solve this problem as
far as getaddrinfo() use getipnodeby_multi(). But, it is still
workaround.
There is one more problem. getipnodebyname() cannot handle scope-id.
To solve above problems, we should consider that getaddrinfo() don't
use getipnodebyname(). Actually, KAME, NetBSD-current, and
OpenBSD-current don't use getipnodebyname() any more and use res_*N()
calls. I ported it from NetBSD-current version of getaddrinfo.c and
it is running on my boxes. And, it was committed to KAME/FreeBSD4
version of getaddrinfo.c. But, I don't use NIS and NIS code is not
tested yet. I attach the patch to don't use getipnodebyname_multi().
BTW, there is search order problem in current getipnodebyname(), too.
If getipnodebyname() is called with `AI_ALL|AI_V4MAPPED', this is
occur. I attach the patch to solve this problem, too. It also use
res_*N() calls.
Index: lib/libc/net/getaddrinfo.c
diff -u lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c
--- lib/libc/net/getaddrinfo.c.orig Thu Apr 20 12:31:08 2000
+++ lib/libc/net/getaddrinfo.c Fri May 5 22:02:17 2000
@@ -37,6 +37,9 @@
* - Return values. There are nonstandard return values defined and used
* in the source code. This is because RFC2553 is silent about which error
* code must be returned for which situation.
+ * - freeaddrinfo(NULL). RFC2553 is silent about it. XNET 5.2 says it is
+ * invalid.
+ * current code - SEGV on freeaddrinfo(NULL)
* Note:
* - We use getipnodebyname() just for thread-safeness. There's no intent
* to let it do PF_UNSPEC (actually we never pass PF_UNSPEC to
@@ -45,6 +48,41 @@
* when globbing NULL hostname (to loopback, or wildcard). Is it the right
* thing to do? What is the relationship with post-RFC2553 AI_ADDRCONFIG
* in ai_flags?
+ * - (post-2553) semantics of AI_ADDRCONFIG itself is too vague.
+ * (1) what should we do against numeric hostname (2) what should we do
+ * against NULL hostname (3) what is AI_ADDRCONFIG itself. AF not ready?
+ * non-loopback address configured? global address configured?
+ * - To avoid search order issue, we have a big amount of code duplicate
+ * from gethnamaddr.c and some other places. The issues that there's no
+ * lower layer function to lookup "IPv4 or IPv6" record. Calling
+ * gethostbyname2 from getaddrinfo will end up in wrong search order, as
+ * follows:
+ * - The code makes use of following calls when asked to resolver with
+ * ai_family = PF_UNSPEC:
+ * getipnodebyname(host, AF_INET6);
+ * getipnodebyname(host, AF_INET);
+ * This will result in the following queries if the node is configure to
+ * prefer /etc/hosts than DNS:
+ * lookup /etc/hosts for IPv6 address
+ * lookup DNS for IPv6 address
+ * lookup /etc/hosts for IPv4 address
+ * lookup DNS for IPv4 address
+ * which may not meet people's requirement.
+ * The right thing to happen is to have underlying layer which does
+ * PF_UNSPEC lookup (lookup both) and return chain of addrinfos.
+ * This would result in a bit of code duplicate with _dns_ghbyname() and
+ * friends.
+ */
+/*
+ * diffs with other KAME platforms:
+ * - other KAME platforms already nuked FAITH ($GAI), but as FreeBSD
+ * 4.0-RELEASE supplies it, we still have the code here.
+ * - EAI_RESNULL support
+ * - AI_ADDRCONFIG support is supplied
+ * - EDNS0 support is not available due to resolver differences
+ * - some of FreeBSD style (#define tabify and others)
+ * - AI_ADDRCONFIG is turned on by default.
+ * - classful IPv4 numeric (127.1) is allowed.
*/
#include sys/types.h
@@ -62,6 +100,7 @@
#include ctype.h
#include unistd.h
#include stdio.h
+#include errno.h
#if defined(__KAME__) defined(INET6)
# define FAITH
@@ -108,6 +147,7 @@
};
struct explore {
+ int e_af;
int e_socktype;
int e_protocol;
const char *e_protostr;
@@ -118,10 +158,21 @@
};
static const struct explore explore[] = {
- { SOCK_DGRAM, IPPROTO_UDP, "udp",
Re: ftp(1) breakage w/ passive mode?
On Tue, 30 May 2000 17:05:15 +0900 Jun-ichiro itojun Hagino [EMAIL PROTECTED] said: ume and I discussed it a little bit, directly. Tested the patch on a 4.0S system against KRB5 tunnelled through VPN (pipsecd for now) then NATed (using IP Filter at the remote side) to my employer's network. Kerberos rlogin and KRB5 telnet now work however KRB5 ftp still has problems. itojun I personally believe the patch to getaddrinfo(3) by ume is itojun not very relevant - the patch may change part of its API, itojun and it can choke some of the callers. I personally prefer fixing itojun ftp(1) and other callers if necessary. Yes. the patch convert all IPv4 mapped IPv6 address returned into IPv4 address. If someone announce mapped address using RR, it also converted. So, caller have no chance to know whether returned address is mapped address or native IPv4 address. However, I think this is rare case in at least now. After correcting getaddrinfo()'s search order, in some case, A RR is accidentaly converted into mapped address without expectation of caller. This may confuse IPv4 people and force inconvenience. I worry about this. Fixing ftp(1) and other caller is also important. But, it is another issue. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp(1) breakage w/ passive mode?
On Sun, 28 May 2000 21:04:23 -0400
Will Andrews [EMAIL PROTECTED] said:
What would make ftp(1) think it has an IPv6 connection?
andrews I have no idea..
It seems ftp(1) think using IPv6.
There is a bug in existing getaddrinfo(). getaddrinfo() returns IPv4
address as IPv4 mapped IPv6 address in some case. It occures when:
- INET6 is enabled in kernel
- host has A RR and RR
IPv4 connection via mapped address is still IPv6 connection. In this
case, if ftp(1) doesn't have awareness of using mapped address, your
problem will occur. And, ftp(1) seems not aware about it.
But, it seems ftp.FreeBSD.org does't have RR. So, I believe it
is not applicable to your case. And, actually I dont' see this
problem here. However, I have no idea without this case. So, I
attach the patch to solve getaddrinfo() problem. Please try it and I
would like to hear the result.
Index: lib/libc/net/getaddrinfo.c
diff -u lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c
--- lib/libc/net/getaddrinfo.c.orig Thu Apr 20 12:31:40 2000
+++ lib/libc/net/getaddrinfo.c Mon Apr 24 21:41:24 2000
@@ -148,6 +148,7 @@
static int get_portmatch __P((const struct addrinfo *, const char *));
static int get_port __P((struct addrinfo *, const char *, int));
static const struct afd *find_afd __P((int));
+static void unmappedaddr __P((struct addrinfo *));
static char *ai_errlist[] = {
"Success",
@@ -512,6 +513,7 @@
*/
GET_CANONNAME(cur-ai_next, hp-h_name);
}
+ unmappedaddr(cur-ai_next);
while (cur cur-ai_next)
cur = cur-ai_next;
@@ -903,4 +905,25 @@
return afd;
}
return NULL;
+}
+
+static void
+unmappedaddr(struct addrinfo *res)
+{
+ struct sockaddr_in6 *sin6;
+ struct sockaddr_in *sin;
+ u_int32_t addr;
+ int port;
+
+ sin6 = (struct sockaddr_in6 *)res-ai_addr;
+ if (IN6_IS_ADDR_V4MAPPED(sin6-sin6_addr)) {
+ sin = (struct sockaddr_in *)res-ai_addr;
+ addr = *(u_int32_t *)sin6-sin6_addr.s6_addr[12];
+ port = sin6-sin6_port;
+ memset(res-ai_addr, 0, res-ai_addrlen);
+ sin-sin_addr.s_addr = addr;
+ sin-sin_port = port;
+ sin-sin_family = res-ai_family = AF_INET;
+ sin-sin_len = res-ai_addrlen = sizeof(struct sockaddr_in);
+ }
}
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.imasy.org/~ume/
Re: PAM OpenSSH 2.1 X11 - signal 11
On Thu, 18 May 2000 16:19:25 +0200 (CEST)
Alexander Leidinger [EMAIL PROTECTED] said:
Alexander after a new build{world,kernel} after the import of OpenSSH 2.1 to
Alexander internat (cvsupped 2517, around 14:00 CEST), xdm gets a signal
Alexander 11 if I use pam_ssh.so (after entering the password).
Alexander After removing the lines with pam_ssh.so for xdm I'm able to login.
Alexander Is someone else able to reproduce this?
I also met this with wdm here.
To avoid this problem, I replaced pam_ssh.c with
ports/security/opessh/pam_ssh.c with changing PATH_SSH_AGENT to
/usr/bin/ssh-agent. It seems working.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning
Hi, On Wed, 19 Apr 2000 12:33:44 +0100 Brian Somers [EMAIL PROTECTED] said: brian I did the find, removed the bdevs in /compat/linux/dev and rebooted - brian no luck, the message is still there. brian thinks brian I wonder if whatever's done on 2000-06-01 will leave the emulators brian intact. I *seem* to be able to survive without these devices... brian /thinks Same messages is out on my PC, too. And, there is no bdev in /dev. But, I'm using devfs and ls -l /devs | grep ^b returns: b- 1 root wheel 0, 0 Apr 17 05:40 cd0 b- 1 root wheel 0, 0 Apr 17 05:40 da0 b- 1 root wheel 0, 0 Apr 17 05:40 da1 b- 1 root wheel 0, 0 Apr 17 05:40 da2 brw-r- 1 root operator0, 0 Apr 17 05:40 fd0 b- 1 root wheel 0, 0 Apr 17 05:40 md0 I suspect it. But I cannot reboot now. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 75 second delay using telnet/ssh (ipv6 related)
On Mon, 20 Mar 2000 12:02:21 -0800 Chris Piazza [EMAIL PROTECTED] said: According to Mr. Stevens (Unix Network Programing Vol 1 chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set will cause the behavior you are describing... It's a behavior of gethostbyname(). Ssh uses getaddrinfo() instead of gethostbyname(). See RFC2553. cpiazza No, neither of those. FreeBSD searches inet6 first at the moment. cpiazza I don't know if I made this clear in my email, but this just started cpiazza happening... Hmm... it's fixed again: Don't you see packet loss or name server problem? Your previous log seems 128.189.4.1 didn't answer to RR query. cpiazza 12:01:15.622122 24.113.19.137.1253 24.2.10.36.53: 61892+ ? beast.freebsd.org. (35) cpiazza 12:01:15.706319 24.2.10.36.53 24.113.19.137.1253: 61892 1/1/0 (132) cpiazza 12:01:15.707070 24.113.19.137.1254 24.2.10.36.53: 61893+ A? beast.freebsd.org. (35) cpiazza 12:01:15.750017 24.2.10.36.53 24.113.19.137.1254: 61893 2/4/4 (238) Is it a log with `ssh -4'? Why does ssh qurey RR with -4? Using ssh -4 or telnet -4 makes it work right away (of course), but I don't want to have to type that all the time. [program] ipv4address also works. How about `alias ssh "ssh -4"'? -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netstat output for inet6
Hi, On Sat, 11 Mar 2000 12:44:57 + Ben Smithurst [EMAIL PROTECTED] said: ben Is there any way to see the full IPv6 address with netstat? I just see: Try do with -l option. ume@peace:263# netstat -anl -f inet6 Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp6 0 20 2001:200:301:0:200:f8ff:fe05:3eae.22 2001:200:301:0:200:f4ff:fe5e:7147.1022ESTABLISHED -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh-askpass OpenSSH
On Sun, 27 Feb 2000 11:01:39 -0800 "Jordan K. Hubbard" [EMAIL PROTECTED] said: jkh I'm not really sure what this ssh-askpass thing is or where it was jkh supposed to come from, but I found a great lack of information on jkh it when I switched myself to openssh (from the ports collection) a jkh long time ago, and in the interim I just put this in my .xsession jkh file: There was OpenSSH version of ssh-askpass written in Tcl/TK. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/Attic/ssh-askpass.wish?rev=1.2 I wrote it in Ruby/GTK and used it. http://www.imasy.or.jp/~ume/ssh-askpass/ But now, I prefer to use pam_ssh.so with wdm. Wdm doesn't support PAM session. So, I merged the code from XFree86-3.3.6 of xdm. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wdm PAM support
On Sun, 27 Feb 2000 11:49:52 -0800 "Jordan K. Hubbard" [EMAIL PROTECTED] said: jkh Hmmm. I see that /usr/ports/x11/wdm has merged in support for jkh FreeBSD's login classes, but not PAM. Are you planning to merge these jkh changes of yours into the port so that the rest of us can play too? :-) Yes, of course. I put it on http://www.imasy.or.jp/~ume/FreeBSD/wdm-pam-port.tar.gz Please review it. To play with pam_ssh.so, you need to add following lines into /etc/pam.conf. wdm authrequiredpam_ssh.so wdm account requiredpam_unix.so try_first_pass wdm session requiredpam_ssh.so wdm password required pam_deny.so -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INET6 changes for tcp_wrappers broke libwrap?
Hi, On Fri, 11 Feb 2000 19:59:03 +0100 (CET) Blaz Zupan [EMAIL PROTECTED] said: After doing a buildworld yesterday I noticed that my sshd (1.2.27, with libwrap support) immediately closes the connection when a connection is made, without logging anything via syslog. sshd itself was not changed but I did remember seeing INET6 changes being committed for tcp_wrappers. When I backed out those changes and remade libwrap, sshd starting working as usual. blaz Funny you mention that, I noticed it just yesterday as well. Recompiling blaz sshd fixed the problem for me, but this means we have somehow broken blaz binary compatibility. I brought sshd1 compiled on pure 3.4-RELEASE into 4.0-CURRENT. Then, I see this problem. This is why new libwrap uses getipnodeby*() added by recent IPv6 supported libc. Though, libc's major version was incremented, libwrap's major version should be incremented, too. ume@peace:229# /usr/local/sbin/sshd -d debug: sshd version 1.2.27 [i386--freebsd3.4] debug: Initializing random number generator; seed file /etc/ssh_random_seed log: Server listening on port 22. log: Generating 768 bit RSA key. Generating p: ++ (distance 72) Generating q: .++ (distance 0) Computing the keys... Testing the keys... Key generation complete. log: RSA key generation complete. debug: Server will not fork when running in debugging mode. /usr/libexec/ld-elf.so.1: /usr/lib/libwrap.so.2: Undefined symbol "getipnodebyaddr" ume@peace:230# ldd /usr/local/sbin/sshd1 /usr/local/sbin/sshd1: libgmp.so.3 = /usr/lib/libgmp.so.3 (0x28085000) libz.so.2 = /usr/lib/libz.so.2 (0x2809a000) libwrap.so.2 = /usr/lib/libwrap.so.2 (0x280a7000) libcrypt.so.2 = /usr/lib/libcrypt.so.2 (0x280ae000) libutil.so.2 = /usr/lib/libutil.so.2 (0x280c3000) libc.so.3 = /usr/lib/libc.so.3 (0x280cd000) ume@peace:231# ls -l /usr/lib/libc.* -r--r--r-- 1 root wheel 1127474 Feb 12 17:22 /usr/lib/libc.a lrwxr-xr-x 1 root wheel9 Feb 12 17:22 /usr/lib/libc.so - libc.so.4 -r--r--r-- 1 root wheel 561464 Dec 28 05:02 /usr/lib/libc.so.3 -r--r--r-- 1 root wheel 533908 Feb 12 17:22 /usr/lib/libc.so.4 -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp passive modem is on by defaut?
Hi, Sun, 06 Feb 2000 17:42:14 +0900 $B$N9o$K!V(Bshin$B!W!"$9$J$o$A(B Yoshinobu Inoue [EMAIL PROTECTED] $B;a[)$/(B shin Wmmm, I actually enabled it, but it is causing problems, so shin should EPSV only allowed for IPv6 at least for several shin starting 4.x releases? I'm sorry. My previous message confused you. shin (About EPRT, initiating client retry PORT command next if EPRT shin failes, so trying EPRT first will be OK.) No. In this senario, if server knows EPRT, EPRT request will be accepted, and will not fail. But, existing NAT box doesn't handle EPRT request. So, NAT box cannot treat data connetion as if it treat for PORT. Then, data connection request from server will not reach to client. shin As RFC2428(FTP Extensions for IPv6 and NATs), EPSV can be used shin for IPv4 and IPv6 and it has performance benefit for firewall shin and NAT, because it doesn't include an IP address in its shin command, so firewall and NAT doesn't need to translate them. No problem will occur with EPSV on even if IPv4. If server doesn't know EPRT, client will try PASV next. shin And there is also a chicken and egg issue, because if usual shin ftp clients don't try EPSV first, then usuall firewall and NAT shin don't notice the necessity of supporting EPSV. I agree. I think EPSV is OK in any case. We should be careful to only EPRT on IPv4. Using EPRT on IPv4 is a chicken and egg issue. shin But now passive is used by default, and not many firewall and shin NAT support it yet, so many user will be upset that they can't shin connect to some of ftp servers. It's firewall and NAT frendry. :-) shin So if no other better suggestion, I think I'll get permission shin to fix 4.0 ftp client to try EPSV only for IPv6. EPSV is NAT frendly. I think disabling EPRT on IPv4 is better for a while. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp passive modem is on by defaut?
Hi, Mon, 07 Feb 2000 00:24:09 +0900 $B$N9o$K!V(Bshin$B!W!"$9$J$o$A(B Yoshinobu Inoue [EMAIL PROTECTED] $B;a[)$/(B shin In non passive case, . . . shin The 1st trial seems to be rejected at, shin 500 Illegal PORT range rejected. shin and 2nd trial seems to be accepted at, shin 200 pcmd command successful. This problem was reported at [FreeBSD-users-jp 46521]. It is Japanese FreeBSD mailing list. In my experience, EPRT didn't fail in such case. I didn't understand what you say. At last, I understand it. It's my misunderstanding of my test environment. I used NetBSD-current for FTP server. FreeBSD version of ftpd checks the validity of PORT request for security reson by default. EPRT request via NAT box is rejected by this check. But, NetBSD's ftpd need `checkportcmd' options to behave as FreeBSD does, and I didn't specified it. I think `ftpd -R' causes same situation. shin And then I tried passive mode. ftp passive shin Passive mode on. ftp dir shin 229 Entering Extended Passive Mode (|||1044|) shin ^C shin receive aborted shin waiting for remote to finish abort. shin The connection hanged at shin 229 Entering Extended Passive Mode (|||1044|) shin for a while, so I aborted it. This is something strange. I still cannot understand why it occures. It seems libalias does no additional thing for PASV. So, I think, if EPSV isn't NAT friendly, PASV would also fail. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp passive modem is on by defaut?
Hi, On Sat, 5 Feb 2000 22:09:18 +0300 (MSK) Dmitry Valdov [EMAIL PROTECTED] said: dv 229 Entering Extended Passive Mode (|||1049|) Since KAME version of ftp/ftpd was merged, ftp speaks EPSV/EPRT as default not only IPv6 but also IPv4. Currently, existing natd is not recognize EPRT. So, NAT user may be confuse. Please examine bin/14305. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
