Re: gif devices in -current
When I compiled/installed -current, and started setting things up again, I noticed that gif devices now expect IPv6 prefix lengths of 128. Most providers use 127, and some even use 64 as prefix lengths for tunnels. I was just curious why the change was made to only support prefix lengths of 128. Is there an RFC that covers this perhaps? either of the following works. the other configurations are now considered ambiguous. (the point is, if you specify prefixlen 128 you don't need to say the peer's address) # ifconfig inet6 A prefixlen X (X can be 128) # ifconfig inet6 A B prefixlen 128 itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: (KAME-snap 3972) TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
I don't think this is within the KAME-project scope. On NetBSD, the NetBSD crowd has done this almost a year ago (I believe) and NFS over IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot from the NetBSD work, reducing the major-ness of the task? The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6) is TI-RPC based, and it was done by NetBSD guys not KAME guys. It is not impossible to support IPv6 NFS without switching to TI-RPC, INRIA IPv6 has the code (IIRC). However, if you try this, there will be a lot of of non-intuitive typecast against library arguments. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3976) Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6) is TI-RPC based, and it was done by NetBSD guys not KAME guys. Sorry, I was not clear. The question about moving towards TI-RPC was directed to freebsd-current. Just out of interest. No critisism intended. no, i did not took it as criticism. i (and feico) just tried to clarify. 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: (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: (KAME-snap 3327) Re: Panic on current (12 Sept)
I'm running a current machine of 12 Sept although this problem also occured on a current of a few days earlier ... "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? itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp and /etc/services...
This is on a recently-built -current box. When I try to move ftp from
port 21 to port 2121 in /etc/services, I get a "Connection
refused" message when I try to login to anonymous ftp sites. Should ftp
be this dependent on /etc/services? What if you _have_ no services
running, e.g. inetd portmap? Returning ftp to port 21 in services fixes
this problem. I posted earlier about my problems with ftp recently.
/usr/bin/ftp depends on "ftp" line in /etc/services. you cannot just
change it.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current, racoon, ipsec
Grr... ok, that might be solved when putting IPSEC in the kernel config, but the second part still stands, I guess. (Why include libipsec code when it is in the base tree... they should be compatible) they are NOT compatible. security/racoon really needs to compile libipsec by itself. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT in libusb libutil
It's a macro that NetBSD uses just to be different from the rest of the known world which uses the assert() macro from /usr/include/assert.h. _DIAGASSERT() has its history and reasons (there was some proposal on it and _DIAGASSERT() implements that). it is not just to be different. I admit it is now equivalent to assert(). netbsd may need to clean them up... itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/net getaddrinfo.c
Hmmm. Something definitely looks strange, 'cause since this morning if I do: telnet localhost (or telnet to ANY host, either in my host file or in DNS) I get: localhost: no address associated with name whereas a 'ping localhost' works perfectly fine (and so does a telnet 127.0.0.1) usr.bin/telnet/commands.c:tn() does something very strange. i'll take a look at it. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/net getaddrinfo.c
Hmmm. Something definitely looks strange, 'cause since this morning if I do: telnet localhost (or telnet to ANY host, either in my host file or in DNS) I get: localhost: no address associated with name whereas a 'ping localhost' works perfectly fine (and so does a telnet 127.0.0.1) usr.bin/telnet/commands.c:tn() does something very strange. i'll take a look at it. usr.bin/telnet/commands.c revision 1.22 should correct it. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
These changes should only impact ipv6 and ipsec, with the exception of the DNS resolver code which I'm still unsure about merging (even though it's been well tested by KAME users, there remains the possibility of breakage for ipv4 resolution if there are undiscovered bugs) actually, I've touched sys/sys/mbuf.h. there should be no behavior change if you do not use any of the following items: - ipsec - ipv6, inclding stf interface - gif interface gif can be used for v4 over v4. due to the change mentioned above, and recent checksum offloading stuff, some of network driver code may need fixes like below. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/lnc/if_lnc.c.diff?r1=1.78r2=1.79 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vx/if_vx.c.diff?r1=1.27r2=1.28 (if a driver sets M_PKTHDR flag manually, it needs checking) itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? thanks for your understanding, will try to list those and put the list into sys/netinet6/README. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
This is great news -- one of the big hangups in our interop testing at NAI Labs was the like of IKE on FreeBSD. I notice that right now racoon is a port -- assuming this interpretation is correct, are their any plans to integrate racoon as a base system component? As you point out, without IKE, FreeBSD's IPsec implementation is effectively useless for cross-platform communication due to the number of frobs in SA configuration. I also look forward to the rapid MFC'ing, assuming that the code works :-). this is because we expect to have so many many changes/improvements in racoon - once we put racoon into base tree, we need to be much more careful about backward-compatibility in config file, for example. also, we need to improve kernel policy management for socket-based policy, and process-to-process policy inheritance. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: more recent KAME code will hit the tree (as of early July 2000)
hello, more recent KAME code will hit the main trunc shortly. the code in the freebsd-current tree is dated November 1999, and there are many good changes made in KAME side. there will be tons of changes in: sys/netinet sys/netinet6 and also to sync with modified headers: lib/libipsec usr.sbin/setkey usr.bin/netstat other portions may be updated shortly. please torture-test it, so that the changes can go into 4.1. there are some API changes with the commit. specifically: - some ioctls are added for IPv6. - change in ipsec policy specification language change. you may need to change setkey(8) configuration files. - change in PF_KEY socket behavior to conform to standard better. - additional member in mbuf header structure to carry around ipsec policy better. you really need to swap setkey(8) if you update to the new kernel. sorry that it took this long period to upgrade, there are couple of reasons behind this: (1) shin, who took the primary role for freebsd-kame synchronization, is now real busy doing his company's job and cannot put time for us. (2) during previous merge, there were too many cosmetic changes made. this adds many unnecessary diffs between kame tree and freebsd tree (we can't just back import them into kame tree, as we share sys/netinet6 ACROSS 4 BSD PLATFORMS). this time, i decided to put kame tree as is, decreasing # of diffs as much as possible. this should ease future upgrades. PLEASE REFRAIN FROM DOING TABIFY/UNTABIFY/YOU-THINK-IT-SMALL-KNF in kame-origin tree like sys/netinet6, they will become real PITA for future upgrades. (you don't usually untabify/tabify third-party source code, do you?) as for point (2), i'll add sys/netinet6/README which has some notices on kame tree. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: more recent KAME code will hit the tree (as of early July 2000)
itojun - change in ipsec policy specification language change. you itojun may need to change setkey(8) configuration files. Do you plan to integrate racoon while updating IPsec? It would be really great! (or whatever gives the same functionality) it will go into ports tree. 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: ftp(1) breakage w/ passive mode?
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. isn't there some issue in getipnodebyname(), instead of getaddrinfo()? (NOTE: I'm not really up-to-date with the current status of freebsd4 lib/libc/net) if you can tell me repeatable example of getaddrinfo() failure, that would be helpful... 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?
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
I guess the condition includes RES_USE_INET6 ("options inet6"
in resolv.conf).
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?
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. Yes. NetBSD did that commit just right now. I guess they obtained it from you, or it's just a BIG coincidence. ume and I discussed it a little bit, directly. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual-booting: FreeBSD, NetBSD and OpenBSD
I need to setup a machine that will boot FreeBSD, NetBSD and OpenBSD. Assume I have an insane amount of disk space. What's the best way to accomplish this? Last time I tried it, the partition ID numbers were all the same, making this difficult if not impossible. just a starter: NetBSD 1.4 and recent use different FDISK partition ID, so it is easy to share FreeBSD and NetBSD on a same disk using separate FDISK partition. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: authentication for nis-user fails, only local user can login
I installed FreeBSD 3.4 release and the most recent Kame v6 SNAP kernel and then configured nis. Now I have this mysterious problem. NIS and amd are working fine and I can su to the user accounts from root. Kame's inet46d invokes a telnetd with v6 support but my nis server does not support V6, could this be the problem? KAME libinet6 does not support NIS at all. therefore, KAME inet46d nor KAME telnetd do not. workaround: use FreeBSD telnetd (IPv4 only - does not allow IPv6 connections). itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: down gif0
Hi, Whats the right way od downing or reiniciating gif interface? "ifconfig gif# down" doesnt seems to work if its in mans just tell me where to look what do you mean by "reniciating"? if you would like to overwrite configuration, you just need to "gifconfig gif0 newsrc newdst". Or, if you no longer want to accept/transmit packets via gif0 , "ifconfig gif0 down" should work. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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: IPv6: can a link-site (or global) address be configured in rc.conf?
For NetBSD-current, I'll bring in cleaner 6to4 code (since netbsd is not that close to the deadline). please wait for a while... This is what I expected. I was just messing around some and was pleased that it didn't panic my machine. Thanks. BTW, please be sure to read this before you configure 6to4 interface. I recommend you to run configured tunnels. (I missed the i-d cutoff date...) http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt 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?
Very unfortunately, 6to4 is not yet supported in FreeBSD/KAME. So now available options will be, -Use freenet6 (for one hosts). -Get IPv6 address block and connect to 6bone using gif tunnel. We hope to add 6to4 support for KAME/FreeBSD very soon (next week is a good guess). We may need some more testing before real use, but it should work. it is in KAME/NetBSD already, I just don't have time to make it work on othre *BSDs yet... itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPSec in 4.0-current questions..
I've been messing about with IPSEC in 4.0-current, and have observed some unexpected behavior. Is there someone I can swap some email with off the list to determine if what I'm seeing is a bug, or I'm just confused? It has to do with security policy specifications and what SAID is being selected when a TCP connection is being opened. could you try sending details to [EMAIL PROTECTED] (KAME users mailing list, you may want to subscribe it - see www.kam.enet). 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
(I've tried to send it personally but it seems I couldn't) Ben, if you run tcpdump, do you see forward lookups for ? yes: 10:32:43.545488 platinum.scientia.demon.co.uk.1787 magnesium.scientia.demon.co.uk.domain: 42376+ ? localhost.scientia.demon.co.uk. (48) 10:32:43.545951 magnesium.scientia.demon.co.uk.domain platinum.scientia.demon.co.uk.1787: 42376* 0/1/0 (118) 10:32:43.546321 platinum.scientia.demon.co.uk.1788 magnesium.scientia.demon.co.uk.domain: 42377+ ? localhost. (27) 10:32:43.546584 magnesium.scientia.demon.co.uk.3719 scientia.demon.co.uk.domain: 54839+ ? localhost. (27) 10:32:48.552729 platinum.scientia.demon.co.uk.1789 scientia.demon.co.uk.domain: 42377+ ? localhost. (27) if you put the following line into /etc/hosts, your case should be okay. --- from here ::1 localhost --- to here 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
Wmmm, strangely enough, current getaddrinfo() still specifying AI_CANONNAME inside. (It should be removed to conform current spec, but as far as I checked, still there seems to be apps which got into trouble with that change.) I'm not sure what is meant in above (shin, if possible email me in Japanese privately). - specwise, AI_CANONNAME does not do reverse lookup. it just mean ai_canonname field must be filled in by hp-h_name. - old KAME code did reverse lookup by mistake. - current KAME code (and freebsd-current code) does not perform reverse lookup. So I believe what Ben is seeing as a problem is forward lookup for IPv6 address. Because getaddrinfo uses following calls, getipnodebyname(hostname, AF_INET6) getipnodebyname(hostname, AF_INET) actual search order will be like this (Ben prefers /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 Ben dislikes the second item on the above. NOTE: all existing getaddrinfo code (BIND8 = NRL, BIND9, KAME) has the same problem. To address this right I think there needs to be a big rewrite in src/lib/libc/net (can we meet 4.0 deadline with it? I'm not sure). 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
I'm not sure what is meant in above (shin, if possible email me in Japanese privately). Woops sorry, just replace AI_CANNONNAME with AI_ADDRCONFIG. Now I see what you meant. Thanks. Then maybe getipnodebyname() misbehaving? 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
lookup /etc/hosts for IPv6 address lookup DNS for IPv6 address --- lookup /etc/hosts for IPv4 address lookup DNS for IPv4 address Ben dislikes the second item on the above. What I dislike really is looking up the unqualified name in the root domain *before* checking the qualified name for an IPv4 address. Is something like this possible, for unqualified names? assume query "foo", default domain is "domain" ... lookup "foo" in /etc/hosts for either address type lookup "foo.domain." in DNS () lookup "foo.domain." in DNS (A) lookup "foo." in DNS () lookup "foo." in DNS (A) this seems the best to me, but I wouldn't know if it's a) easy, b) possible, c) standards conforming. I'm not sure where /etc/hosts would go. As I said, the above order makes more sense. However, to do the above we need a MAJOR rewrite in src/lib/libc/net. BIND9 does not address this problem either. Let us (KAME) think what is the best solution in long-term, and short-term. More description can be found in NetBSD PR I've replied (URL attached in one of previous emails). 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
As I said, the above order makes more sense. However, to do the above we need a MAJOR rewrite in src/lib/libc/net. BIND9 does not address this problem either. Let us (KAME) think what is the best solution in long-term, and short-term. ok. For now I've found the really simple solution (I knew there would be one) I should have found straight away... add IPv6 addresses to the DNS for the hosts on my network, as IPv4-mapped addresses, i.e. magnesium A 192.168.91.34 :::192.168.91.34 I would prefer putting that onto /etc/hosts, if you need to. since :::192.168.91.34 form is internal to host (must not appear on wire) 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: INET6 and fxp
FWIW this doesn't happen with my card: fxp0: Intel InBusiness 10/100 Ethernet port 0x1000-0x103f mem 0xf400-0xf40 f,0xf410-0xf4100fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a fxp0: supplying EUI64: 00:90:27:ff:fe:d1:83:6a fxp0: starting DAD for fe80:0001::0290:27ff:fed1:836a fxp0: DAD complete for fe80:0001::0290:27ff:fed1:836a - no duplicates found 'course I don't actually use the card for internet access, just a local lan and the occasional IPv6 testing. (from what I've heard) the symptom highly depends on chip revision so you are lucky. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INET6 and fxp
Yes, I am trying to repeat it in my environment. (But it doesn't necessarily happens on all card which use fxp driver. Also, seems to happen with some delicate timing...) I heard that changing driver not to use interrupt is complete fix, though I am not so good at driver issue. More precisely, "changing driver not to use interrupt during multicast filter setup". netbsd - fxp driver does not use interrupt during multicast filter setup so it is not affected openbsd - includes workaround in sys/net/if.c (as referenced in the thread) 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: IPv6 testing...willing to help
I suppose something going wrong when multiple mbuf cluster is used for encrypted TCP connection. Because as I tried to cat several different sized files, catting files bigger than around 2048(mbuf cluster size) minus protocol header size seems to cause the problem. Because mbuf cluster could be shared by multiple outstanding packets, it might be encrypted by multiple times. I'll investigate this further. I think we have already fixed this in the past, by deep-copying cluster mbufs... ipsec_copypkt() in sys/netinet6/ipsec.c. i'm running telnet chargen all the time between kame/bsdi3 and kame/netbsd and having no problem. note that there are differences among *BSD for checking for shared clusters. 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
Re: wide char support
Do you guys have any testable, even if it's not ready for prime time? I need wchar.h and the wcs* functions for a project for FreeBSD. You want me to have this, I think. David said he had something ready to play with (I think) but I haven't heard from him yet. We have some code fragment, with small wchar-compliant application to play with. This is not integrated into src/lib/whatever yet. I'll be supplying URL for those who would like test this (sorry not on the mailing list...), so contact me if interested. itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
