Re: IPv6 setup...
And if you want to check 6to4 prefix for some IPv4 addr
without doing 6to4 interface configuration, please try
following command.
echo 24.113.25.85 | sed -e s/"\."/" "/g | awk '{$5 = $1*256 + $2; $6 = $3*256 + $4;
printf "2002:%x:%x:\n", $5, $6}'
Then it will print out first 6byte for your 6to4 prefix.
just checking. from code inspection on cvsweb,
- rc.network6 is called before performing nfs mounts.
- awk and sed are in /usr
so the above sentence disallows NFS-mounted /usr. is it really okay
to do?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
I applied a variant of your patch to my NetBSD/i386 -currentish box that also uses the KAME stack and was able to ping6 your 6to4 address. For NetBSD-current, I'll bring in cleaner 6to4 code (since netbsd is not that close to the deadline). please wait for a while... itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp(1) breakage w/ passive mode?
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.
I personally believe the patch to getaddrinfo(3) by ume is
not very relevant - the patch may change part of its API,
and it can choke some of the callers. I personally prefer fixing
ftp(1) and other callers if necessary.
However, the change (IPv4 mapped address handling) leaves me very
fuzzy feeling... The specification is not well defined, and
the change itself breaks certain network setup (the configuration
is rather rare, though). here's a comment I left in KAME
netbsd/usr.bin/ftp/ftp.c. I try to persuade ipngwg folks...
itojun
--
for (res = res0; res; res = res-ai_next) {
/*
* make sure that ai_addr is NOT an IPv4 mapped address.
* IPv4 mapped address complicates too many things in FTP
* protocol handling, as FTP protocol is defined differently
* between IPv4 and IPv6.
*
* This may not be the best way to handle this situation,
* since the semantics of IPv4 mapped address is defined in
* the kernel. There are configurations where we should use
* IPv4 mapped address as native IPv6 address, not as
* "an IPv6 address that embeds IPv4 address" (namely, SIIT).
*
* More complete solution would be to have an additional
* getsockopt to grab "real" peername/sockname. "real"
* peername/sockname will be AF_INET if IPv4 mapped address
* is used to embed IPv4 address, and will be AF_INET6 if
* we use it as native. What a mess!
*/
ai_unmapped(res);
...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3338) Re: Panic on current (12 Sept)
"current machine" meaning FreeBSD-current? if so, are there any locking behavior changes due to the introduction of fine grain locks? what happens if you go back to coarse grain lock kernel? As far as I recall ... the first kernel was before any of the SMP commits ... but in case it was not ... how do I go about going back to a "coarse grain lock" kernel ... can I set something in the config file or do I have to checkout old sources ?? for this part (how to get a source before fine grain SMP) I'm totally unsure. sorry itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3337) RE: Panic on current (12 Sept)
Without starting the racoon daemon and doing a secure connect everything works fine without a problem. If I start racoon, do a tunnel connection and then run daily, the machine panics .. I bet you can panic the kernel with setkey(8) in that case. am I correct? if so, something is not friendly with fine grain SMP, under sys/netkey. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I18N Progress, Plans, and Proposals
3. Itojun mentioned that the CITRUS Japanese people will be able to import the wchar* and libxpg4 changes soon. the code is there, but as i talked, we need more manpower for babysitting. cvs -d :pserver:[EMAIL PROTECTED]:/anoncvs/citrus co -P xpg4dl itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [solicite review and confirmation of tcp for IPv6 patches]
--- http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/tcp-apps.2114 http://www.FreeBSD.org/~shin/tcp-apps.2114 They includes, -inetd -libutil -rlogin -rlogind -rshd -telnetd As far as I checked, those apps seems to be working over both IPv4 and IPv6. Sorry for delayed response, and sorry for doing this here (I should have talked about this in KAME team earlier, I think I have noted about rcmd API issues already to shin, before freebsd IPv6 commits start) I suggest to defer committing rsh/rlogin related items, as there are reference to libc functions which we do not have consensus even among *BSD (not to mention linux camp, or any of vendor UN*X which may have those interfaces) IMHO committing them causes more confusion. We do not really use rlogin/rsh these days, we can just use ssh. For realhostname2() I have no opinion as is freebsd only API (as I heard from shin). rcmd and bindresvport items are already committed, I think they shouldn't have been committed (for openssh port you can include bindresvport_af in "patches" directory) I would propose to back these out, like iruserok_af and bindresvport_af from the library. Items that would be deferred are rsh and rlogin related items, and those only (I believe). most of other IPv6 services can be put and enabled. What I'm trying to say is that we need to get consensus on these API functions amoung at least *BSDs, and we should not be putting those before that. I'm soliciting comments on IETF ipngwg mailing list so that I can get more comments. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getaddrinfo with IPv6 and unqualified hostname
Is it just some misconfiguration of mine which causes getaddrinfo() with an unqualified hostname, IPv6 and hints-ai_family == AF_UNSPEC to block (trying a DNS lookup I guess), even when the hostname has a perfectly good IPv4 address, or is this normal behaviour? This seems rather annoying, and means something as simple as "ftp otherhost" will block unless I use the FQDN. Is there any way to avoid this behaviour? It may happen with older versioin of getaddrinfo() at least. getaddrinfo() in getaddrinfo.c before 1.5 did reverse lookup when AI_CANONNAME flag is specified, so if reverse lookup information was not obtained, it would block. Ben, if you run tcpdump, do you see forward lookups for ? If so, I believe this problem is same as this one, not AI_CANONNAME issue in old getaddrinfo code: http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=9413 I intend to correct this one, however, the way to fix it is very dependent to resolver internal functions. so fix to netbsd-current won't apply to freebsd-current. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wide char support
Is there anything in current that provides wide character support? I'm messing around with document formatting, and I have to be involved with wide character things. One example: wcscat(). It's not the only one, I just need to know if it's in *any* library, and declared in any include file. There are several Japanese people working on stateful multibyte char support. Existing codebase like glibc only supports stateless multibyte char. People using iso-2022 variants (Japan, Korea, China, you name it) need stateful multibyte char support. We have some code fragment used in various software packages like multilingual vi or multilingual schedule management tool, and we would like to clean up those to fit into src/lib/whatever. I'll be talking about this issue a bit in my presentation at Usenix/ Freenix99 (titled multilingual vi) so come to presentation room or catch me somewhere in the conference site. (again, there's language barrier problem... I think we should sort it out. I believe the best way is to ban Japanese-language mailing list for the project, but other volunteers may have some trouble) ito...@involved into too many projects To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
