Re: mbuf changes
It's not a big thing but it would be nice to replace the m_next and m_nextpkt fields with queue.h macros. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em(4): discard frame w/o packet header (82547L on Supermicro X7SPA-H) on stable/8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Jack, On 2010/09/17 10:42, Jack Vogel wrote: > Put DDB/KDB into the kernel and get me the stack trace when this > problem happens. Tell me exactly what the hardware is (pciconf). Just wanted to let you know that after putting DDB/KDB into the kernel, the problem vanished mysteriously and I can not provoke the problem any more. I have traversed the changes since the build date to 09/18/2010 (when I built the new kernel) but have no clue what exactly fixed the problem. I have placed pciconf -lv, devinfo -rv, dmesg.boot and acpidump -dt information as well as sysctl dev.em output on the system just in case you will be interested in them: https://neptune.delphij.net/acpi/ Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMpNinAAoJEATO+BI/yjfBf8UH/1M84qigDwbwx2/aNZFurG+k cgpDaBnPwMndMI2w391S5jWOYTqBjcvEBLcNLSpTa/P2DHxSqCH5dFIqyTbDA+X6 k4AjOW0ClUKkT8wxZS/26XHRnqvjAM3p7rPgSQHlWVOubX0OpHZGlv87LIbaiLmj UywPwqOnIYSFPiBX8xhwjM4MSPQatFCuF2nNgmWEFGOokPfPNuKABXyJhwK/A4/X uQ9lLIX1+BmvfzBBLIqJhQWb4FEJsXVV6WyjTkpS7rYqySDcfdPORU+C4oiF87RU udu1BqwO4b7FeyoqBJ2dUUvF85mtsaRBXF5tO8V8QJxvFrHqwnNgMVlC954qu8c= =1zLX -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
On 28 Sep 2010, at 23:27, Doug Barton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 9/22/2010 1:32 PM, Hiroki Sato wrote: > | Hello, > | > | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? > > Well I don't want to be "Mr. Negativity," but I'd like to suggest that > adding this support is the wrong way to go. STF and teredo are > transition mechanisms, and we're currently knee-deep (well maybe > ankle-deep) in the deployment of IPv6. This is only going to pick up > steam in the next few years given the impending run-out of the free /8s > in the IANA pool. I disagree with you and I want to see this going in. Regards, -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
On 9/30/2010 12:13 PM, Rui Paulo wrote: On 28 Sep 2010, at 23:27, Doug Barton wrote: On 9/22/2010 1:32 PM, Hiroki Sato wrote: | Hello, | | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? Well I don't want to be "Mr. Negativity," but I'd like to suggest that adding this support is the wrong way to go. STF and teredo are transition mechanisms, and we're currently knee-deep (well maybe ankle-deep) in the deployment of IPv6. This is only going to pick up steam in the next few years given the impending run-out of the free /8s in the IANA pool. I disagree with you and I want to see this going in. Perhaps you could provide a little more information about the basis for your opinion, as I attempted to do for mine? If for no other reason than to help educate me on why I'm wrong? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ipfw tablearg support for setfib
Hi,
The attached patch supports tablearg options to setfib.
With the patch, you can add rules like
ipfw add 100 setfib tablearg ip from 'table(1)' to any
It help in policy based routing as discussed in this thread.
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=124951+0+archive/2009/freebsd-net/20090426.freebsd-net
Let me know your comments..
Thanks,
Joe
Index: src/sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.159
diff -c -u -r1.159 ipfw2.c
--- src/sbin/ipfw/ipfw2.c 19 Apr 2010 16:35:47 - 1.159
+++ src/sbin/ipfw/ipfw2.c 30 Sep 2010 18:52:41 -
@@ -2833,11 +2833,17 @@
action->opcode = O_SETFIB;
NEED1("missing fib number");
- action->arg1 = strtoul(*av, NULL, 10);
- if (sysctlbyname("net.fibs", &numfibs, &intsize, NULL, 0) == -1)
- errx(EX_DATAERR, "fibs not suported.\n");
- if (action->arg1 >= numfibs) /* Temporary */
- errx(EX_DATAERR, "fib too large.\n");
+ if(isdigit(**av)) {
+ action->arg1 = strtoul(*av, NULL, 10);
+ if (sysctlbyname("net.fibs", &numfibs, &intsize,
+ NULL, 0) == -1)
+ errx(EX_DATAERR, "fibs not suported.\n");
+ if (action->arg1 >= numfibs) /* Temporary */
+ errx(EX_DATAERR, "fib too large.\n");
+ } else if (_substrcmp(*av, "tablearg") == 0)
+ action->arg1 = IP_FW_TABLEARG;
+ else
+ errx(EX_DATAERR, "illegal argument for %s", *(av - 1));
av++;
break;
}
Index: src/sys/netinet/ipfw/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ipfw/ip_fw2.c,v
retrieving revision 1.45
diff -c -u -r1.45 ip_fw2.c
--- src/sys/netinet/ipfw/ip_fw2.c 27 Jul 2010 14:26:34 - 1.45
+++ src/sys/netinet/ipfw/ip_fw2.c 30 Sep 2010 18:52:43 -
@@ -2092,12 +2092,15 @@
done = 1; /* exit outer loop */
break;
- case O_SETFIB:
+ case O_SETFIB: {
+ uint32_t fibnum;
f->pcnt++; /* update stats */
f->bcnt += pktlen;
f->timestamp = time_uptime;
- M_SETFIB(m, cmd->arg1);
- args->f_id.fib = cmd->arg1;
+ fibnum = (cmd->arg1 == IP_FW_TABLEARG)?
+tablearg : cmd->arg1;
+ M_SETFIB(m, fibnum);
+ args->f_id.fib = fibnum;
l = 0; /* exit inner loop */
break;
Index: src/sys/netinet/ipfw/ip_fw_sockopt.c
===
RCS file: /home/ncvs/src/sys/netinet/ipfw/ip_fw_sockopt.c,v
retrieving revision 1.17
diff -c -u -r1.17 ip_fw_sockopt.c
--- src/sys/netinet/ipfw/ip_fw_sockopt.c7 Apr 2010 08:23:58 -
1.17
+++ src/sys/netinet/ipfw/ip_fw_sockopt.c30 Sep 2010 18:52:44 -
@@ -605,7 +605,8 @@
case O_SETFIB:
if (cmdlen != F_INSN_SIZE(ipfw_insn))
goto bad_size;
- if (cmd->arg1 >= rt_numfibs) {
+ if (cmd->arg1 >= rt_numfibs &&
+cmd->arg1 != IP_FW_TABLEARG) {
printf("ipfw: invalid fib number %d\n",
cmd->arg1);
return EINVAL;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
On 30 Sep 2010, at 20:16, Doug Barton wrote: > On 9/30/2010 12:13 PM, Rui Paulo wrote: >> On 28 Sep 2010, at 23:27, Doug Barton wrote: >> >>> On 9/22/2010 1:32 PM, Hiroki Sato wrote: >>> | Hello, >>> | >>> | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? >>> >>> Well I don't want to be "Mr. Negativity," but I'd like to suggest that >>> adding this support is the wrong way to go. STF and teredo are >>> transition mechanisms, and we're currently knee-deep (well maybe >>> ankle-deep) in the deployment of IPv6. This is only going to pick up >>> steam in the next few years given the impending run-out of the free /8s >>> in the IANA pool. >> >> I disagree with you and I want to see this going in. > > Perhaps you could provide a little more information about the basis for your > opinion, as I attempted to do for mine? If for no other reason than to help > educate me on why I'm wrong? I really don't feel like discussion this ad nauseum as your last IPv6 thread, but 6rd is useful and your argument about the timeline for FreeBSD 9.0 doesn't make sense: we can have this on FreeBSD 8-STABLE in a week after this is committed to HEAD. -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mbuf changes
On 9/30/10 10:49 AM, Ryan Stone wrote: It's not a big thing but it would be nice to replace the m_next and m_nextpkt fields with queue.h macros. funny, I've never even thought of that.. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
On 9/30/2010 2:46 PM, Rui Paulo wrote: I really don't feel like discussion this ad nauseum as your last IPv6 thread, but 6rd is useful and your argument about the timeline for FreeBSD 9.0 doesn't make sense: we can have this on FreeBSD 8-STABLE in a week after this is committed to HEAD. Well I was actually trying to make a new start here and avoid discussing the history. In any case I didn't say that 6rd was not useful at all. What I tried to make the case for is that its utility is limited, both in the absolute sense and in the temporal sense; and that because of these limitations the benefits that adding the code bring are outweighed by the costs of maintaining it past what will likely be its useful lifetime. My point about FreeBSD 9 is that if we add the 6rd code today, then release 9.0 in about a year, then support the RELENG_9 branch for 4-6 years that we will still be maintaining code that no one has any use for. Sorry if I wasn't clear. In contrast, the bit of my post that you snipped suggested that a better course of action would be to focus on the areas of our v6 stack that will be used for the lifetime of the protocol, like the performance penalty that currently exists for the v6 loopback device. But that's really all I have to say, and I'd hate to ad nauseate you. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
On Thu, 30 Sep 2010, Doug Barton wrote: Hey, In any case I didn't say that 6rd was not useful at all. What I tried to make the case for is that its utility is limited, both in the absolute sense and in the temporal sense; and that because of these limitations the benefits that adding the code bring are outweighed by the costs of maintaining it past what will likely be its useful lifetime. The maintainance costs are effectively pretty low, especially as it's coming with stf; it's a single line in a kernel config and not many more files but it will have great value to a lot of people the next years. My point about FreeBSD 9 is that if we add the 6rd code today, then release 9.0 in about a year, then support the RELENG_9 branch for 4-6 years that we will still be maintaining code that no one has any use for. Sorry if I wasn't clear. While I would like to live in that kind of world that by mid 10s all the tunneling, transition, .. technologies would be gone, ideally along with legacy IP, I guess you are massively underestimating this from the early adopters point of view; while for some of us things have happened and we are waiting for the world to catch up, for other folks things might not start within the another product lifecycle. I am sure we'll see a lot of different scenarios for quite some time. I would expect that we'll still be shipping that code in at least 12.x. Though completely taken out of context, Dave Ward's words the minute on from there: http://www.youtube.com/watch?v=mXMMBrWRnvc#t=49m54s summarizes some things quite nicely. In contrast, the bit of my post that you snipped suggested that a better course of action would be to focus on the areas of our v6 stack that will be used for the lifetime of the protocol, like the performance penalty that currently exists for the v6 loopback device. I think that noone questions that this will need time as well and so do another 15 things on the IPv6 side but maybe someone is already working on it .. /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ipv6 routing
Hi folks, I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But not from within the LAN. I have: Routed /48: 2001:470:8a86::/48 Routed /64: 2001:470:1f07:b80::/64 On the gateway, I have this: # cat /etc/rtadvd.conf fxp1:\ :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an IP address. (you should be able to ping6 that). Starting rtadvd I get: # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[33958]: fxp1 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default So why that message? And is it the cause of the 'no route to host' message below? rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 15:998571. waiting for inputs or timeout rtadvd[33958]: set timer to 0:4276. waiting for inputs or timeout rtadvd[33958]: RA timer on fxp1 is expired rtadvd[33958]: send RA on fxp1, # of waitings = 0 rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 16:0. waiting for inputs or timeout rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[33958]: set timer to 15:994315. waiting for inputs or timeout From a client on the LAN, I try this: $ ping6 ipv6.google.com ping6: UDP connect: No route to host From the same client (where em0 is the nic) $ netstat -nr -f inet6 | grep em0 fe80::%em0/64 link#1U em0 fe80::21b:21ff:fe51:ab2d%em0 link#1UHS lo0 ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 Uem0 ff02::%em0/32fe80::21b:21ff:fe51:ab2d%em0 Uem0 Can you see something I'm doing wrong? -- Dan Langille - http://langille.org/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipv6 routing
On 9/30/2010 11:06 PM, Dan Langille wrote: Hi folks, I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But not from within the LAN. I have: Routed /48: 2001:470:8a86::/48 Routed /64: 2001:470:1f07:b80::/64 On the gateway, I have this: # cat /etc/rtadvd.conf fxp1:\ :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an IP address. (you should be able to ping6 that). Starting rtadvd I get: # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[33958]: fxp1 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default So why that message? And is it the cause of the 'no route to host' message below? rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 15:998571. waiting for inputs or timeout rtadvd[33958]: set timer to 0:4276. waiting for inputs or timeout rtadvd[33958]: RA timer on fxp1 is expired rtadvd[33958]: send RA on fxp1, # of waitings = 0 rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 16:0. waiting for inputs or timeout rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[33958]: set timer to 15:994315. waiting for inputs or timeout From a client on the LAN, I try this: $ ping6 ipv6.google.com ping6: UDP connect: No route to host From the same client (where em0 is the nic) $ netstat -nr -f inet6 | grep em0 fe80::%em0/64 link#1 U em0 fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 Can you see something I'm doing wrong? I am now convinced the problem is rtadvd. Gateway and internal box are both FreeBSd 8.1-stable. After I issued this command on the server: # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 add net 2001:470:1f07:b80::/64: gateway fxp1 And this one on the internal box: $ sudo route add -inet6 default 2001:470:1f07:b80::1 Password: add net default: gateway 2001:470:1f07:b80::1 ... things started working: $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2001:470:1f07:b80::2 --> 2001:4860:800f::63 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.466 ms 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=23.221 ms ^C --- ipv6.l.google.com ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 23.221/23.343/23.466/0.123 ms Would you agree that rtadvd may be the issue? -- Dan Langille - http://langille.org/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipv6 routing
On 9/30/2010 11:36 PM, Dan Langille wrote: On 9/30/2010 11:06 PM, Dan Langille wrote: Hi folks, I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But not from within the LAN. I have: Routed /48: 2001:470:8a86::/48 Routed /64: 2001:470:1f07:b80::/64 On the gateway, I have this: # cat /etc/rtadvd.conf fxp1:\ :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an IP address. (you should be able to ping6 that). Starting rtadvd I get: # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[33958]: fxp1 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default So why that message? And is it the cause of the 'no route to host' message below? rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 15:998571. waiting for inputs or timeout rtadvd[33958]: set timer to 0:4276. waiting for inputs or timeout rtadvd[33958]: RA timer on fxp1 is expired rtadvd[33958]: send RA on fxp1, # of waitings = 0 rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 16:0. waiting for inputs or timeout rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[33958]: set timer to 15:994315. waiting for inputs or timeout From a client on the LAN, I try this: $ ping6 ipv6.google.com ping6: UDP connect: No route to host From the same client (where em0 is the nic) $ netstat -nr -f inet6 | grep em0 fe80::%em0/64 link#1 U em0 fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 Can you see something I'm doing wrong? I am now convinced the problem is rtadvd. Gateway and internal box are both FreeBSd 8.1-stable. After I issued this command on the server: # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 add net 2001:470:1f07:b80::/64: gateway fxp1 And this one on the internal box: $ sudo route add -inet6 default 2001:470:1f07:b80::1 Password: add net default: gateway 2001:470:1f07:b80::1 ... things started working: $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2001:470:1f07:b80::2 --> 2001:4860:800f::63 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.466 ms 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=23.221 ms ^C --- ipv6.l.google.com ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 23.221/23.343/23.466/0.123 ms Would you agree that rtadvd may be the issue? changing the conf file to this helps with the startup messages: # cat /etc/rtadvd.conf fxp1:\ :addr="2001:470:1f07:b80::":prefixlen#64: In this regard, the handbook may require updating. However, clients on my LAN are unable to get any IPv6 routing information despite having ipv6_enable="YES" in /etc/rc.conf. Running rtsol on the client doesn't get it an IPv6 address. However, we can see that rtadvd is processing the requests; # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[40477]: RA timer on fxp1 is set to 16:0 rtadvd[40477]: set timer to 15:998900. waiting for inputs or timeout rtadvd[40477]: set timer to 0:4953. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 0 rtadvd[40477]: RA timer on fxp1 is set to 16:0 rtadvd[40477]: set timer to 16:0. waiting for inputs or timeout rtadvd[40477]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[40477]: set timer to 15:994797. waiting for inputs or timeout rtadvd[40477]: set timer to 0:4517. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 0 rtadvd[40477]: RA timer on fxp1 is set to 16:0 rtadvd[40477]: set timer to 16:0. waiting for inputs or timeout rtadvd[40477]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[40477]: set timer to 15:994119. waiting for inputs or timeout rtadvd[40477]: RS received from fe80::21b:21ff:fe51:ab2d on fxp1 rtadvd[40477]: set timer to 0:490712. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 1 rtadvd[40477]: RA timer on fxp1 is set to 518:0 rtadvd[40477]: set timer to 518:0. waiting for inputs or timeout rtadvd[40477]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[40477]: set timer to 517:994623. waiting for inputs or timeout rtadvd[40477]: RS received from fe80::21b:21ff:fe51:ab2d on fxp1 rtadvd[40477]: set timer to 0:426786. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 1 rtadvd[40477]: RA timer on fxp1 is set to 239:0 -- Dan Langille - http://langille.org/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@f
Re: ipv6 routing
On 9/30/2010 11:36 PM, Dan Langille wrote: On 9/30/2010 11:06 PM, Dan Langille wrote: Hi folks, I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But not from within the LAN. I have: Routed /48: 2001:470:8a86::/48 Routed /64: 2001:470:1f07:b80::/64 On the gateway, I have this: # cat /etc/rtadvd.conf fxp1:\ :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an IP address. (you should be able to ping6 that). Starting rtadvd I get: # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[33958]: fxp1 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default So why that message? And is it the cause of the 'no route to host' message below? rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 15:998571. waiting for inputs or timeout rtadvd[33958]: set timer to 0:4276. waiting for inputs or timeout rtadvd[33958]: RA timer on fxp1 is expired rtadvd[33958]: send RA on fxp1, # of waitings = 0 rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]: set timer to 16:0. waiting for inputs or timeout rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[33958]: set timer to 15:994315. waiting for inputs or timeout From a client on the LAN, I try this: $ ping6 ipv6.google.com ping6: UDP connect: No route to host From the same client (where em0 is the nic) $ netstat -nr -f inet6 | grep em0 fe80::%em0/64 link#1 U em0 fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 Can you see something I'm doing wrong? I am now convinced the problem is rtadvd. Gateway and internal box are both FreeBSd 8.1-stable. After I issued this command on the server: # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 add net 2001:470:1f07:b80::/64: gateway fxp1 And this one on the internal box: $ sudo route add -inet6 default 2001:470:1f07:b80::1 Password: add net default: gateway 2001:470:1f07:b80::1 I also did this on the client: ifconfig em0 inet6 2001:470:1f07:b80::2/64 add ... things started working: $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2001:470:1f07:b80::2 --> 2001:4860:800f::63 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.466 ms 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=23.221 ms ^C --- ipv6.l.google.com ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 23.221/23.343/23.466/0.123 ms Would you agree that rtadvd may be the issue? -- Dan Langille - http://langille.org/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
On 1 October 2010 06:55, Doug Barton wrote: > In any case I didn't say that 6rd was not useful at all. What I tried to > make the case for is that its utility is limited, both in the absolute sense > and in the temporal sense; and that because of these limitations the > benefits that adding the code bring are outweighed by the costs of > maintaining it past what will likely be its useful lifetime. People are going to be using IPv4 for a number of years. More than IPv6 proponents want or believe. I don't see the harm of doing both this work and improving our IPv6 stack support in general. It's all about choice, right? Adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
