Re: Show multicast groups joined?
If memory serves me right, Fernando Gont wrote: > What would be the appropriate command to show the IPv6 multicast groups > joined by all/each interface? Try ifmcstat(8). Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 bridge0 link-local address
If memory serves me right, pluknet wrote: > On 15/03/07, Tom Pusateri <[EMAIL PROTECTED]> wrote: >> I've configured a bridge0 interface that bridges fxp0 and em0. >> I have a global IPv6 address configured on it and IPv6 works fine. >> >> # ifconfig bridge0 >> bridge0: flags=8043 mtu 1500 >> inet x.x.x.82 netmask 0xfff0 broadcast x.x.x.95 >> inet6 2001:4877:1777:1001::1 prefixlen 64 >> ether ac:de:48:49:71:91 >> priority 32768 hellotime 2 fwddelay 15 maxage 20 >> member: fxp0 flags=3 >> member: em0 flags=3 > [snip] > > I don't know precisely what's about if_bridge. According to the rfc2373 > (App.A) > it should be similar to: fe80::aede:48ff:fe49:7191%bridge0 > > Hmm.. but if you try the `ifconfig bridge0 inet6 eui64` command, you''ll see: > ifconfig: could not determine link local address Our IPv6 stack explicitly prevents if_bridge(4) interfaces from having link-local addresses. For the rationale behind this, see the commit message for rev. 1.28 of src/sys/netinet6/in6_ifattach.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_ifattach.c This isn't to say that this decision couldn't be revisited, but that's why things are the way they are now. It looks like it'd be a one-line change to enable this, but it's not clear if this is the right thing to do or not. Bruce. signature.asc Description: OpenPGP digital signature
Re: how do you bring IPv6 live without reboot?
If memory serves me right, George Michaelson wrote: > on a 6-STABLE host, I added: > > ipv6_enable="YES" > ipv6_network_interfaces="bge1" > > to rc.conf, and ran /etc/rc.d/network_ipv6 > > this did not bring IPv6 live. rtsol reported problems with get_llflag() > calls. However across reboot, the system came up with IPv6 fine. > > Can somebody explain why this won't work if run after the init sequence > has run to completion? What is the sequence of commands that when run > on an active FreeBSD system causes it to successfully bind to IPv6? Hrm. You might also need to invoke /etc/rc.d/auto_linklocal before (I think it's before?) network_ipv6. This script was recently added (during the 6.2 release cycle) as a part of mitigating some security risks related to IPv6 link-local addresses. Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 Woes...
If memory serves me right, Eric F Crist wrote: > On Jun 25, 2007, at 7:55 PMJun 25, 2007, Bruce M. Simpson wrote: > >> Eric F Crist wrote: >>> My problem isn't getting out to 2001:4980:1::5, it's getting to my >>> LAN, the 2001:4980:1:111::/64 network. My gateway, the machine >>> from which I posted the routing and ifconfig information, is able >>> to ping across the tunnel, and to the internet just fine. Nothing >>> is able to get from the gateway to my LAN, however. Is it a >>> problem with the fxp driver, or perhaps my setup with the ethernet >>> bridging? >> You appear to have a /64 network address on the inside of your v6 >> router. Are you using stateless address auto-configuration? You >> appear to have statically assigned ::145 as a host address on >> that net. >> >> My setup works fine if I ping the network address of my v6 router >> from the v6 enabled hosts in my lab. >> >> When you ping local machines on the inside LAN from that router, do >> you see NDP entries being created? Hi Eric-- First note that I'm a different Bruce than the chap who's been helping thus far. :-) BTW, use "ndp -a" to see this. >> You shouldn't need to use bridging to achieve what you want in this >> scenario, in fact it makes no sense because you want to route v6 >> traffic over the gif, therefore ethernet bridging is not relevant >> here. I'm not quite so sure about this...see below. > First, thanks for taking time to help me through this. Here's some > more information regarding the topography of my network. My FBSD > firewall is running with 'options BRIDGE' in the kernel, and the > following two lines in /etc/sysctl.conf: > > net.link.ether.bridge.enable=1 > net.link.ether.bridge.config=fxp0,fxp1 Your setup is not *too* different from what I have at home in terms of network topology and what you hope to accomplish. (I have a Soekris net4801 run 6.2-STABLE and acting as a filtering bridge between an IPv4 /29 and the rest of the Internet, and also terminating a gif(4) tunnel for IPv6.) > This is so that I don't have to do routing on my firewall. I have a > IPv4 /28 network, so a limited number of IP addresses, this saves one > of those. This system is filtering traffic with PF. That's really > the only reason for the bridging. Also, it does allow me to do > traffic shaping and bandwidth monitoring. This bridging stuff > really, as you said, has nothing to do with my IPv6 configuration > issues. I think the biggest difference between your network and mine is that rather than using options BRIDGE I'm using the if_bridge(4) driver between my "inside" and "outside" network interfaces. The physical interfaces in the bridge are unnumbered and the if_bridge pseudo_interface has IPv4 and IPv6 addresses. The main reason for doing this is that I've seen that bridge(4) can have difficulty determining the correct physical interface to use for packets that originate on the bridging host. I recall having this problem with pfnat. (I don't remember the exact details, but I did some postings to the m0n0wall mailing lists on this topic some time ago...your favorite search engine can probably help find these messages.) I wonder if the problem I've seen with bridge(4) might be related to your IPv6 problems (since you're terminating the tunnel on your firewall). If so, maybe switching to if_bridge(4) as I've described above might help things. In any case, good luck! Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 Woes...
If memory serves me right, Eric F Crist wrote: > On Jun 26, 2007, at 4:32 PMJun 26, 2007, Bruce A. Mah wrote: [big snip] >> I wonder if the problem I've seen with bridge(4) might be related to >> your IPv6 problems (since you're terminating the tunnel on your >> firewall). If so, maybe switching to if_bridge(4) as I've described >> above might help things. >> >> In any case, good luck! > > Bruce! Thanks for all the help! That did the trick! Only one more > thing that's holding me up. Cool...I was half-guessing on this one. > On my gateway, I've got 2001:4980:1:111::145/64 as the primary IP > address. In addition, I've got 2001:4980:1:111::1/128 as an alias. > I can ping/connect to the xxx:145 address, but not the xxx:1 > address. What did I configure wrong? Here's the output of netstat - > r -f inet6: > > Routing tables > > Internet6: > DestinationGateway > FlagsRefs UseMtuNetif Expire > :: localhost.secure-computing.net > UGRS00 16384 lo0 => > default2001:4980:1::5 > UGS 00 1280 gif0 > localhost.secure-computing.net localhost.secure-computing.net > UHL 50 16384 lo0 > :::0.0.0.0 localhost.secure-computing.net > UGRS00 16384 lo0 > 2001:4980:1::4 link#7 > UC 00 1280 gif0 > 2001:4980:1::5 link#7 > UHLW24 1280 gif0 > 2001:4980:1::6 link#7 > UHL 14 1280 lo0 > 2001:4980:1:111:: link#1 > UC 01 1500 fxp0 > 2001:4980:1:111::1 00:06:5b:05:30:19 > UHL 14 1500 lo0 > 2001:4980:1:111::145 00:06:5b:05:30:19 > UHL 24 1500 lo0 > 2001:4980:1:111::147 00:06:5b:38:2e:82 > UHLW1 14 1500 fxp0 > fe80:: localhost.secure-computing.net > UGRS00 16384 lo0 > fe80::%fxp0link#1 > UC 00 1500 fxp0 > fe80::206:5bff:fe05:3019%fxp0 00:06:5b:05:30:19 > UHL 10 1500 lo0 > fe80::%fxp1link#2 > UC 00 1500 fxp1 > fe80::206:5bff:fe05:301a%fxp1 00:06:5b:05:30:1a > UHL 10 1500 lo0 > fe80::%lo0 fe80::1%lo0 > U 00 16384 lo0 > fe80::1%lo0link#3 > UHL 10 16384 lo0 > fe80::%gif0link#7 > UC 00 1280 gif0 > fe80::206:5bff:fe05:3019%gif0 link#7 > UHL 10 1280 lo0 > fe80::%tun0link#8 > UC 00 1500 tun0 > fe80::206:5bff:fe05:3019%tun0 link#8 > UHL 10 1500 lo0 > ff01:1:: link#1 > UC 00 1500 fxp0 > ff01:2:: link#2 > UC 00 1500 fxp1 > ff01:3:: localhost.secure-computing.net > UC 00 16384 lo0 > ff01:7:: link#7 > UC 00 1280 gif0 > ff01:8:: link#8 > UC 00 1500 tun0 > ff02:: localhost.secure-computing.net > UGRS00 16384 lo0 > ff02::%fxp0link#1 > UC 00 1500 fxp0 > ff02::%fxp1link#2 > UC 00 1500 fxp1 > ff02::%lo0 localhost.secure-computing.net > UC 00 16384 lo0 > ff02::%gif0link#7 > UC 00 1280 gif0 > ff02::%tun0link#8 > UC 00 1500 tun0 This is a little odd. If you switched to using if_bridge for bridging, I would have expected to see bridge0 as one of your links. Is it not configured for IPv
ath(4), wpa_supplicant, WPA2, Netgear WG302 problem
I'm having a problem getting a Netgear WG511T in my FreeBSD CURRENT
laptop to do WPA2-PSK with a Netgear WG302 access point. I'm hoping
someone here can give me a nudge in the right direction to help
troubleshoot this.
The laptop is an old Sony Vaio (PCG-Z505HS). The Netgear WG511T
probes thusly:
ath0: mem 0x8800-0x8800 irq 9 at device 0.0 on cardbus0
ath0: [ITHREAD]
ath0: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:0f:b5:af:81:39
ath0: mac 7.9 phy 4.5 radio 5.6
The OS is FreeBSD HEAD as of yesterday, GENERIC kernel. Note that
this has the recent HAL import, as well as wpa_supplicant v0.5.8:
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
The AP is a Netgear WG302 with Firmware 4.2.17. It's configured for
WPA2-PSK. Several other clients can communicate with this AP without
any problems. A slightly sanitized wpa_supplicant.conf is:
-
network={
ssid="kitchenlab.org"
scan_ssid=1
psk="REAL_PSK_REMOVED"
}
-
Some output from wpa_supplicant -dd is below:
-
Starting AP scan (specific SSID)
Scan SSID - hexdump_ascii(len=14):
6b 69 74 63 68 65 6e 6c 61 62 2e 6f 72 67 kitchenlab.org
Received 0 bytes of scan results (6 BSSes)
Scan results: 6
Selecting BSS from priority group 0
Try to find WPA-enabled AP
0: 00:14:6c:6f:2e:7d ssid='kitchenlab.org' wpa_ie_len=0 rsn_ie_len=26 caps=0x31
selected based on RSN IE
selected WPA AP 00:14:6c:6f:2e:7d ssid='kitchenlab.org'
Try to find non-WPA AP
Trying to associate with 00:14:6c:6f:2e:7d (SSID='kitchenlab.org' freq=2412 MHz)
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1
RSN: using IEEE 802.11i/D9.0
WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 2
WPA: clearing AP WPA IE
WPA: set AP RSN IE - hexdump(len=26): 30 18 01 00 00 0f ac 02 02 00 00 0f ac 02
00 0f ac 04 01 00 00 0f ac 02 01 00
WPA: using GTK TKIP
WPA: using PTK CCMP
WPA: using KEY_MGMT WPA-PSK
WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00
0f ac 04 01 00 00 0f ac 02 00 00
No keys have been configured - skip key clearing
wpa_driver_bsd_set_drop_unencrypted: enabled=1
State: SCANNING -> ASSOCIATING
wpa_driver_bsd_associate: ssid 'kitchenlab.org' wpa ie len 22 pairwise 3 group
2 key mgmt 1
wpa_driver_bsd_associate: set PRIVACY 1
Setting authentication timeout: 10 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
RSN: added PMKSA cache candidate 00:14:6c:6f:2e:7d prio 1000
RSN: processing PMKSA candidate list
RSN: not in suitable state for new pre-authentication
Authentication with 00:00:00:00:00:00 timed out.
BSSID 00:14:6c:6f:2e:7d blacklist count incremented to 2
No keys have been configured - skip key clearing
State: ASSOCIATING -> DISCONNECTED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - EAP success=0
Setting scan request: 0 sec 0 usec
State: DISCONNECTED -> SCANNING
-
It's interesting that the WG511T can associate with this AP if both
are configured for WEP, and it can do WPA2 with a Linksys WRT54G
(unknown version). Also I saw superficially similar results while
running 6.2-RELEASE and RELENG_6 on the same hardware. Debugging by
Google hasn't helped me yet either, so I'm running out of ideas.
Any thoughts?
Thanks!
Bruce.
pgp7poBW7USSS.pgp
Description: PGP signature
Re: FreeBSD and Hotspots
[Please wrap your lines to some reasonable line length...thanks.] If memory serves me right, staticblackz wrote: > I am trying to build a hotspot for freebsd I was wondering how > something like this would be made, is there already one out there I > can use. I would need it to redirect users to some web page ran off > apache that can send their logon info to the radius server also > making it so they can't browse the net until they were authenticated > with the radius server. Recent beta versions of m0n0wall (a FreeBSD-based firewall) have captive portal support. I haven't tried this feature personally, but I'm pretty sure there's RADIUS support. http://www.m0n0.ch/wall/ > My other problem is I am trying to set an > orinoco pcmcia card to ap-mode and it won't work it gives me the > error..."ifconfig: SIOCSIFMEDIA (mediaopt): Device not configured" I > have tried many different ways to make this card work and it won't, > I use the command " ifconfig wi0 inet 192.168.0.1 netmask 0xfff0 > ssid my_net channel 11 media DS/11Mbps mediaopt hostap up". If I > switch the device to ath1 for my atheros card ti works fine..I > REALLY need help with these 2 problems As another poster pointed out, I don't think the Hermes-based cards can do hostap mode. The Prism- and Atheros-based cards can. See the wi(4) and ath(4) manual pages for more details. Bruce. pgpN4XDqFNsSc.pgp Description: PGP signature
Re: FreeBSD and Hotspots
On Wed, 2004-07-14 at 20:54, Dinesh Nair wrote: > On Wed, 14 Jul 2004, Bruce A. Mah wrote: > > > If memory serves me right, staticblackz wrote: > > > > > I am trying to build a hotspot for freebsd I was wondering how > > > something like this would be made, is there already one out there I > > > can use. I would need it to redirect users to some web page ran off > > > apache that can send their logon info to the radius server also > > > making it so they can't browse the net until they were authenticated > > > with the radius server. > > > > Recent beta versions of m0n0wall (a FreeBSD-based firewall) have > > captive portal support. I haven't tried this feature personally, but > > I'm pretty sure there's RADIUS support. > > there is RADIUS authentication support in m0n0wall's captive portal. > RADIUS accounting will soon be added in, when i've completed testing of > that module. m0n0wall's captive portal also handles pass-through MAC > addresses and IP address, i.e. clients which can pass through the captive > portal without authenticating. Thanks, Dinesh. That sounds very nice...I'll have to check out one of the betas. Hmmm...looks like it's time to go buy another Soekris box... :-) Bruce. signature.asc Description: This is a digitally signed message part
Re: FreeBSD and Hotspots
On Thu, 2004-07-15 at 13:38, staticblackz wrote: > I would have no problem using m0n0wall but I need to be able to have ssh > access to compile othe rprograms needed I am using it on a comouter There is no SSH server on a m0n0wall system. Nor are there compilers. It's been deliberately stripped down to be a firewall. > ...is > there any way to port the captive portal to another freebsd box or to > rebuild m0n0wall to be just like FreeBSD? "It's just software." Dinesh could probably comment on this since he wrote it but I'm sure that it's possible. If you put the words "captive portal freebsd" into your favorite search engine you'll find lots of information, including quite a few implementations. Google is your friend. :-) Bruce. signature.asc Description: This is a digitally signed message part
Re: Quick question about the tired ipf/ipnat/"dmz"/bridge scenario
If memory serves me right, Andrew Heyn wrote: > Quoting http://www.moatware.com/support/docbook/faq-bridge.html, > > 10.8. Why can't hosts on a NATed interface talk to hosts on a bridged > interface? > This frequently happens when someone wants to bridge an interface to their > WAN to use it as a DMZ, and wants to put all of the hosts on their LAN > interface behind a NAT. This is actually a fairly reasonable and natural > thing to want to do. Interesting. This text is part of a document that appears to be, almost verbatim, copied from the documentation from m0n0wall, a FreeBSD-based firewall package. The original is at: http://m0n0.ch/wall/docbook/ I have some thoughts about this, but they're way off-topic for this list. > The problem here is that ipnat and bridging (at least as implemented in > FreeBSD) don't play well together. Packets from the LAN to the DMZ go out > just fine, but in the other direction, it seems like the packets arriving on > the unnumbered bridge interface don't get looked up correctly in the ipnat > state tables. > > I've managed to convince myself that solving this is Really Really Hard > (TM). The irritating thing is that there's no theoretical reason why this > should be difficult...it all comes down to implementation details. > > > Is there any way at all, even with kludges, to get this to work? I'd be > extremely interested if there was any to accomplish this, as specified > above. I wrote this after I implemented m0n0wall's filtered bridging feature and had about a dozen people ask me this question, which is a reasonable question to ask, but tiring after you've heard it more than about five times. :-p My memory is a bit hazy but I think the problem was ipnat doesn't know that packets arriving on the unnumbered bridge interface need to have inbound NAT stuff done to them. It would need to know or figure out that the inbound interface was in a bridging group and that one of the other interfaces in the group was the interface being used for outbound NAT packets. I bet one could probably get this to work, if they were willing to hack up IPFilter and get it to understand the bridge(4) data structures. Bruce. signature.asc Description: This is a digitally signed message part
Re: Difficulties with tcpdrop on FreeBsd 5.3
If memory serves me right, Maxim Konovalov wrote: > On Tue, 22 Mar 2005, 14:08+0200, Sergey wrote: > > How to enable TCPCTL_DROP syscall !? > > The upgrade procedure is described quite well in the handbook and > at the end of /usr/src/UPDATING. To expand on this just a bit: You can't just compile the tcpdrop executable and expect it to work. It requires a newly-built kernel (because there's a teensy bit of kernel support required) and probably resulting minor changes in some system header files. *That's* why you need to run through the source upgrade procedure that Maxim mentioned. Bruce. signature.asc Description: This is a digitally signed message part
Re: issue with route
If memory serves me right, Andre Oppermann wrote: > Oh, BTW. Don't be afraid when you get brucified. Bruce' style > comments are a very valuable learning resource. Everyone of us got > brucified more than once. ;-) (I'm talking about Bruce Evans, bde@) ^ Thanks for clarifying that. :-) BTW I've been brucified too, which I'm sure was a bewildering experience for those who witnessed it. Bruce. signature.asc Description: This is a digitally signed message part
if_bridge and IPv6?
Hi folks-- Can anyone tell me if I should be able to run IPv6 over an if_bridge interface? I'm running RELENG_6 from a few days ago on a Soekris net4801 and have created a bridge0 interface with two of the physical network interfaces (sis0 and sis1) as members. IPv4 seems to work fine over this; I can assign an IPv4 address to bridge0 and everything seems normal. If I assign an IPv6 address to the interface, no IPv6 packets seem to go in or out, and ping6-ing a machine on the same subnet yields: hornet# ping6 other_address PING6(56=40+8+8 nbytes) (net4801_address) --> (other_address) _storelladdr: something odd happens ping6: sendmsg: Invalid argument ping6: wrote tomcat.kitchenlab.org 16 chars, ret=-1 nd6_storelladdr: something odd happens Note that the output above is slightly mangled; I wonder if this has to do with some buffer related to the net4801's serial console being overrun. Anyways. tcpdump-ing in various places shows that ICMPv6 neighbor solicitation packets aren't leaving the net4801. If I try to ping the net4801 from other machines on the subnet, I can see *their* neighbor solicitation packets arrive at the net4801 with tcpdump, but it never (as far as I can tell) sends a response. I wonder if this has to do with IPv6 ND packets being sent as multicast, but that's just a guess. Googling showed that at least on NetBSD 1.6, this didn't work, but I wasn't able to find anything immediately applicable to FreeBSD 6.0-BETA3. :-) Any ideas? Thanks! Bruce. signature.asc Description: This is a digitally signed message part
Re: if_bridge and IPv6?
If memory serves me right, Andrew Thompson wrote: > From what I can tell this is from the bridge itself, does bridging work > between ipv6 hosts on either side of the bridge? Hmm...I haven't tried that yet. Unfortunately I'm not in close proximity to the system in question at the moment, so it'll be a few hours (evening, San Francisco time) until I can try this. I'll test and report back. > I will try and replicate this setup tonight. Many thanks! Bruce. PS. Food for thought: Should bridge devices have IFF_MULTICAST set? Mine doesn't. hornet# ifconfig bridge0 bridge0: flags=41 mtu 1500 inet (foo) netmask 0xff00 inet6 (bar) prefixlen 64 ether ac:de:48:cd:e2:32 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: sis1 flags=3 member: sis0 flags=3 signature.asc Description: This is a digitally signed message part
Re: if_bridge and IPv6?
If memory serves me right, Bruce A. Mah wrote: > If memory serves me right, Andrew Thompson wrote: > > > From what I can tell this is from the bridge itself, does bridging work > > between ipv6 hosts on either side of the bridge? > > Hmm...I haven't tried that yet. Unfortunately I'm not in close > proximity to the system in question at the moment, so it'll be a few > hours (evening, San Francisco time) until I can try this. I'll test and > report back. Bridging of IPv6 packets going between two hosts on either side of the bridge appears to work just fine (to the point where I can do ping6 and ssh across the bridge). > PS. Food for thought: Should bridge devices have IFF_MULTICAST set? > Mine doesn't. > > hornet# ifconfig bridge0 > bridge0: flags=41 mtu 1500 > inet (foo) netmask 0xff00 > inet6 (bar) prefixlen 64 > ether ac:de:48:cd:e2:32 > priority 32768 hellotime 2 fwddelay 15 maxage 20 > member: sis1 flags=3 > member: sis0 flags=3 This looks more and more suspicious to me. IPv6 ND requires multicast to work and there are several explicit checks for IFF_MULTICAST in the IPv6 output path and neighbor discovery code. Bruce. signature.asc Description: This is a digitally signed message part
Re: if_bridge and IPv6?
If memory serves me right, Max Laier wrote: > On Monday 29 August 2005 23:37, Bruce A. Mah wrote: > > If memory serves me right, Andrew Thompson wrote: > > > From what I can tell this is from the bridge itself, does bridging work > > > between ipv6 hosts on either side of the bridge? > > > > Hmm...I haven't tried that yet. Unfortunately I'm not in close > > proximity to the system in question at the moment, so it'll be a few > > hours (evening, San Francisco time) until I can try this. I'll test and > > report back. > > > > > I will try and replicate this setup tonight. > > > > Many thanks! > > Just a quick note: if_bridge does IPv6 filtering (in contrast to the old > bridge code). So you may want to check your settings there. Thanks, that's a good point, and in fact I'll be depending on this functionality eventually. But I haven't gotten around to the point of configuring any filtering yet (am planning on using PF eventually). Just for good measure I tried setting net.link.bridge.pfil_bridge to 0 but that didn't have any effect I could see. Bruce. signature.asc Description: This is a digitally signed message part
Re: if_bridge and IPv6?
If memory serves me right, Andrew Thompson wrote: > On Mon, Aug 29, 2005 at 06:19:42PM -0700, Bruce A. Mah wrote: > > Bridging of IPv6 packets going between two hosts on either side of the > > bridge appears to work just fine (to the point where I can do ping6 and > > ssh across the bridge). > > Good to hear something works :) Well, just for the record (maybe I mentioned this before) ARP and unicast IPv4 work as advertised. So yeah, something works. :-) > > > PS. Food for thought: Should bridge devices have IFF_MULTICAST set? > > > Mine doesn't. > > > > > > hornet# ifconfig bridge0 > > > bridge0: flags=41 mtu 1500 > > > inet (foo) netmask 0xff00 > > > inet6 (bar) prefixlen 64 > > > ether ac:de:48:cd:e2:32 > > > priority 32768 hellotime 2 fwddelay 15 maxage 20 > > > member: sis1 flags=3 > > > member: sis0 flags=3 > > > > This looks more and more suspicious to me. IPv6 ND requires multicast > > to work and there are several explicit checks for IFF_MULTICAST in the > > IPv6 output path and neighbor discovery code. > > I think you are right, i'll look into it. Thanks! If I had some hacking time right now, my first attempt would be to stick this... ifp->if_flags |= IFF_MULTICAST; ...somewhere in bridge_clone_create(). Given how little I actually have worked with FreeBSD's network drivers, this would really be the "Hail Mary" approach and I wasn't feeling quite up to it this evening... :-p Cheers, Bruce. signature.asc Description: This is a digitally signed message part
Re: if_bridge and IPv6?
If memory serves me right, Bruce A. Mah wrote: > If memory serves me right, Andrew Thompson wrote: > > On Mon, Aug 29, 2005 at 06:19:42PM -0700, Bruce A. Mah wrote: [IPv6 over an if_bridge interface didn't work.] > > > Bridging of IPv6 packets going between two hosts on either side of the > > > bridge appears to work just fine (to the point where I can do ping6 and > > > ssh across the bridge). > > > > Good to hear something works :) > > Well, just for the record (maybe I mentioned this before) ARP and > unicast IPv4 work as advertised. So yeah, something works. :-) For anyone who was following along with this, Andrew and I exchanged some private email about this problem, he sent me a patch which I successfully tested, and he committed the solution to HEAD in these files: Revision ChangesPath 1.21 +27 -5 src/sys/net/if_bridge.c 1.198 +1 -1 src/sys/net/if_ethersubr.c 1.28 +1 -4 src/sys/netinet6/in6_ifattach.c 1.55 +2 -0 src/sys/netinet6/nd6.c 1.33 +1 -0 src/sys/netinet6/nd6_nbr.c Thanks to Andrew for his speedy solution! Bruce. signature.asc Description: This is a digitally signed message part
Re: Earthlink IPv6 experiment
If memory serves me right, Doug Barton wrote: > I have been using the experimental IPv6 connection described at > http://www.research.earthlink.net/ipv6/ for some time now, and it works very > well. If anyone is interested in using IPv6 in a real way in FreeBSD, I > would encourage you to give it a try. If you shop around a little it's > fairly easy to pick up a Linksys WRT54G in the $40 range or so. Cool. Another data point, mostly of interest to folks in the San Francisco or Los Angeles areas: sonic.net [1] DSL users have been able to get IPv6 tunnels for a couple years now for no extra charge as an unsupported service...I've been using this feature almost since day one and it plays with FreeBSD very nicely. Cheers, Bruce. [1] Not to turn this post into a commercial, but I'm an extremely satisfied user of this ISP. I'd be happy to give more details off-list. signature.asc Description: This is a digitally signed message part
netstat(1) bug in per-address packet counts?
Hi Joe-- I was playing around with netstat(1) on a recent RELENG_4 machine, and noticed something odd. Apparently, the input packet counter for the IPv6 loopback address never gets incremented (even after some pings, the input packet count on lo0 is still 0): bmah-freebsd-0:netstat% ping6 ::1 PING6(56=40+8+8 bytes) ::1 --> ::1 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.276 ms 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.242 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.239 ms 16 bytes from ::1, icmp_seq=3 hlim=64 time=0.207 ms 16 bytes from ::1, icmp_seq=4 hlim=64 time=0.216 ms ^C --- ::1 ping6 statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.207/0.236/0.276 ms bmah-freebsd-0:netstat% netstat -in Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll fxp0 1500 00:d0:b7:5a:f1:6f 153964 0 133432 0 0 fxp0 1500 171.70.84/23 171.70.84.42 312026 - 322155 - - fxp0 1500 fe80:1::2d0 fe80:1::2d0:b7ff:0 -0 - - gif0* 1280 0 00 0 0 lo0 16384 213161 0 213161 0 0 lo0 16384 fe80:3::1/6 fe80:3::10 -0 - - lo0 16384 ::1/128 ::1 0 -13119 - - lo0 16384 127 127.0.0.1 11295 -11295 - - ppp0* 1500 0 00 0 0 stf0* 1280 0 00 0 0 bmah-freebsd-0:netstat% uname -a FreeBSD bmah-freebsd-0.cisco.com 4.3-BETA FreeBSD 4.3-BETA #2: Mon Mar 19 15:16:43 PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NIMITZ i386 Is it just me? :-) Thanks, Bruce. PGP signature
Re: netstat(1) bug in per-address packet counts?
If memory serves me right, Hajimu UMEMOTO wrote: > >>>>> On Tue, 20 Mar 2001 09:30:47 -0800 > >>>>> Bruce A. Mah <[EMAIL PROTECTED]> said: > > bmah> I was playing around with netstat(1) on a recent RELENG_4 machine, and > bmah> noticed something odd. Apparently, the input packet counter for the > bmah> IPv6 loopback address never gets incremented (even after some pings, > bmah> the input packet count on lo0 is still 0): > > I received the patch and just committed it. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/ip6_input.c.diff?r1=1. > 21&r2=1.22 Nice catch. I thought it would be something like that, but I crashed my -CURRENT kernel when I tried it. Seems that I forgot some of the checks (for null pointers, etc.). Might be nice to get this to RELENG_4, if possible. Thanks much! Bruce. PGP signature
Re: Problem in TCP initialisation of cwnd
If memory serves me right, Julian Elischer wrote: > > One thing that shocked me is that a TCP connection in FreeBSD (at least on > > my machines) > > doesn't begin with a slow start but rather sends a huge amount of packets t > o > > the other end > > (this huge amount only seems to be limited either by the receiver window or > > by the local machine's > > send buffer). It seems that cwnd isn't initialised. > > It is my understanding that it does this only if the destination is considere > d > 'local' > (i.e in the same subnet.) This is my recollection too, but I can't off-hand recall the reference for this (other than looking in the source code). I'm betting that these sysctl variables let one tweak this behavior: net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 65535 Bruce. PGP signature
Re: TTCP, Netperf and TcpBlast Problem
If memory serves me right, Brooks Davis wrote: > On Mon, Apr 30, 2001 at 11:29:05AM -0700, Harkirat Singh wrote: > >=20 > > This is the script file!!. I said that I went to ftp site to see whether > > it (netperf-2.1pl3) is supported for FreeBSD, but I saw all th eother OS > > but there was no reference for FreeBSD. > > Ignore the f*ing ftp site. It looks like there's something wrong with > your network configuration that you can't fetch it, so you may have to > fetch it manualy and place it in /usr/ports/distfiles (you can write > to that, can't you?). It's totally irrelavent that the site doesn't > list FreeBSD as supported, that's what the port is for. It works just > fine here. Actually the problem is that his ports collection is out of date. Looks like the distfile moved. I noticed this when the Makefile snippet didn't match what was in my ports tree. On my machine with a ports collection updated this morning, it fetches and builds just fine. Bruce. PGP signature
Re: TTCP, Netperf and TcpBlast Problem
If memory serves me right, Harkirat Singh wrote: > Thanks for your replies, I am able to install netperf manually. I > understand from various replies that my port tree is old, though this port > collection I got installed from new FBSd CD. Please tell me how to update > this port tree so that in future I do not face this silly problem, if I do > make under /usr/ports then agian it is getting aborted. It's only silly because the distfile moved. It's pretty hard for the CD version of the ports collection to find it if this happens isn't it? The one sentence answer is to use cvsup(1) with a supfile like /usr/share/examples/cvsup/ports-supfile but I'm afraid that if you're not already familiar with using cvsup(1) this may not give you enough information. (Isn't there a FAQ or Handbook section that covers this?) Bruce. PGP signature
Re: How to find the bandwidth between two machines under freeBSD?
If memory serves me right, Mitch Collinsworth wrote: > > On Fri, 30 Mar 2001, Daniel Wong wrote: > > > I'm trying to find out how to get the bandwidth speed for a connection > > between two machines. Programmatically in the kernel. > > http://www.employees.org/~bmah/Software/pchar/ Well that was a nice ego-boost. Thanks. :-) pchar is also in the Ports Collection: /usr/ports/net/pchar There's also a number of other tools such as ttcp in the Ports Collection. They all have varying capabilities and uses, and are useful in different circumstances, depending on what you (Daniel) want to do. (But none of these run in kernel space.) Bruce. PGP signature
CFR: bridge.4 manpage update
Hi -net folk... Awhile back, I was trying to figure out how bridge(4) worked, but discovered that the manpage didn't list all the sysctls necessary to configure the bridge. I filed a PR (22060) asking someone to look into this. I subsequently lost interest in bridge(4), but gained a commit bit, the result being that I own a PR for something I know close to zero about. I've made the following diff against the bridge.4 manpage in -CURRENT. Can someone tell me if this is anywhere close to the state of reality? Thanks for any assistance! Bruce. Index: bridge.4 === RCS file: /home/ncvs/src/share/man/man4/bridge.4,v retrieving revision 1.12 diff -u -r1.12 bridge.4 --- bridge.42001/04/18 15:51:26 1.12 +++ bridge.42001/06/13 21:08:09 @@ -44,6 +44,40 @@ .Ar allow rule if we want ARP and other non-IP packets to flow through the bridge. +.Pp +The bridge configuration is controlled by the +.Bd -literal +net.link.ether.bridge_cfg +.Ed +.Pp +.Nm sysctl +variable. +It consists of a comma-separated list of +.Ar interface:cluster +pairs, where all interfaces with the same +.Ar cluster +number will +be bridged together. +.Pp +Another +.Nm sysctl +variable reinitializes the bridge; this is required if bridged +configurations include loadable interfaces. +After loading new +interface drivers, setting the: +.Bd -literal +net.link.ether.bridge_refresh +.Ed +.Pp +variable to 1 will cause the bridge to reinitialize itself. +.Sh EXAMPLES +.Pp +The following command will cause the ep0 and fxp0 interfaces to be +bridged together, and the fxp1 and de0 interfaces to be bridged +together: +.Bd -literal +sysctl -w net.link.ether.bridge_cfg ep0:0,fxp0:0,fxp1:1,de0:1 +.Ed .Sh BUGS .Pp Care must be taken not to construct loops in the bridge topology. PGP signature
Re: IPV6 panic?
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI= ?= wrote: OK, I got another crash, with symbols and all. This is a 4-STABLE machine from 7 July. > If possible, please let us know > - the kernel configuration file Attached. > - the result of > % ifconfig -a > % ndp -p > % ndp -r > before the crash (I know it is difficult, though.) I scripted this output shortly after the last reboot. I didn't bother santizing...my RFC 1918 IPv4 and site/link-local IPv6 addresses are probably not of use to anybody. :-) intruder:bmah% ndp -p fec0:0:0:1::/64 if=dc0 flags=A vltime=0, pltime=0, expired, ref=1 advertised by fe80::200:c0ff:fecb:bdf2%dc0 (reachable) fe80::%dc0/64 if=dc0 flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0 No advertising router fe80::%lo0/64 if=lo0 flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0 No advertising router intruder:bmah% ndp -r fe80::200:c0ff:fecb:bdf2%dc0 if=dc0, flags=, pref=medium, expire=56m54s intruder:bmah% ifconfig -a dc0: flags=8843 mtu 1500 inet6 fe80::200:f8ff:fe10:7aa2%dc0 prefixlen 64 scopeid 0x1 inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fec0::1:200:f8ff:fe10:7aa2 prefixlen 64 autoconf ether 00:00:f8:10:7a:a2 media: Ethernet autoselect (10baseT/UTP) status: active gif0: flags=8010 mtu 1280 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 stf0: flags=0<> mtu 1280 > as well as the stack trace with debugging symbols. Also attached. Please let me know if there's any other information I can provide. Thanks! Bruce. # # $Id: NIMITZ,v 1.19 2001/01/18 05:59:25 bmah Exp $ # # NIMITZ -- Bruce's semi-generic workstation configuration # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.25 2001/05/13 03:50:01 jlemon Exp $ machine i386 cpu I586_CPU cpu I686_CPU ident NIMITZ maxusers128 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols makeoptions KERNEL=kernel # # Certain applications can grow to be larger than the 128M limit # that FreeBSD initially imposes. Below are some options to # allow that limit to grow to 256MB, and can be increased further # with changing the parameters. MAXDSIZ is the maximum that the # limit can be set to, and the DFLDSIZ is the default value for # the limit. You might want to set the default lower than the # max, and explicitly set the maximum with a shell command for processes # that regularly exceed the limit like INND. # options MAXDSIZ="(256*1024*1024)" options DFLDSIZ="(256*1024*1024)" options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=3000 #Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options
Re: IPV6 panic?
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=
?= wrote:
> Hmm, could you show us the contents of "rt" and "ln" at this point?
(kgdb) print rt
$1 = (struct rtentry *) 0x3
(kgdb) print ln
$2 = (struct llinfo_nd6 *) 0x62
> If possible, it would be helpful to see if the chain of llinfo
> starting at llinfo_nd6, too.
Typos filtered out...if this is supposed to be a circular linked list,
I think I got it all.
(kgdb) print llinfo_nd6
$3 = {ln_next = 0xc1422100, ln_prev = 0xc12d91e0, ln_rt = 0x0, ln_hold = 0x0,
ln_asked = 0, ln_expire = 0, ln_state = 0, ln_router = 0, ln_byhint = 0}
(kgdb) print *(llinfo_nd6.ln_next)
$5 = {ln_next = 0xc1366900, ln_prev = 0xc0388ee0, ln_rt = 0xc15b0100,
ln_hold = 0x0, ln_asked = 0, ln_expire = 995175630, ln_state = 2,
ln_router = 1, ln_byhint = 0}
(kgdb) print *(llinfo_nd6.ln_next)->ln_next
$6 = {ln_next = 0xc1366b80, ln_prev = 0xc1422100, ln_rt = 0xc13a3c00,
ln_hold = 0x0, ln_asked = 0, ln_expire = 0, ln_state = 1, ln_router = 0,
ln_byhint = 0}
(kgdb) print *(llinfo_nd6.ln_next)->ln_next->ln_next
$7 = {ln_next = 0xc12d91e0, ln_prev = 0xc1366900, ln_rt = 0xc139d200,
ln_hold = 0x0, ln_asked = 0, ln_expire = 0, ln_state = 1, ln_router = 0,
ln_byhint = 0}
(kgdb) print *(llinfo_nd6.ln_next)->ln_next->ln_next->ln_next
$8 = {ln_next = 0xc0388ee0, ln_prev = 0xc1366b80, ln_rt = 0xc1308000,
ln_hold = 0x0, ln_asked = 0, ln_expire = 0, ln_state = 1, ln_router = 0,
ln_byhint = 0}
(kgdb) print *(llinfo_nd6.ln_next)->ln_next->ln_next->ln_next->ln_next
$9 = {ln_next = 0xc1422100, ln_prev = 0xc12d91e0, ln_rt = 0x0, ln_hold = 0x0,
ln_asked = 0, ln_expire = 0, ln_state = 0, ln_router = 0, ln_byhint = 0}
(kgdb) print *(llinfo_nd6.ln_next)->ln_next->ln_next->ln_next->ln_next->ln_next
$10 = {ln_next = 0xc1366900, ln_prev = 0xc0388ee0, ln_rt = 0xc15b0100,
ln_hold = 0x0, ln_asked = 0, ln_expire = 995175630, ln_state = 2,
ln_router = 1, ln_byhint = 0}
> And I'd also like to know the result of
> % netstat -rn -M corefile -N kernel_binary
intruder:bmah% sudo netstat -rn -M /var/crash/vmcore.1 -N /usr/obj/usr/src/sys/N
IMITZ/kernel.debug
Password:
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default192.168.1.1UGSc20dc0
127.0.0.1 127.0.0.1 UH 221435lo0
192.168.1 link#1 UC 30dc0 =>
192.168.1.10:0:c0:cb:bd:f2UHLW517908dc0 =>
192.168.1.30:0:f8:10:7a:a2UHLW0 119004lo0
Internet6:
Destination Gateway Flags Netif
Expire
::/96 ::1 UGRSc lo0
=>
default fe80::200:c0ff:fecb:bdf2%dc0 UGc dc0
::1 ::1 UH lo0
:::0.0.0.0/96 ::1 UGRSc lo0
fe80::/10 ::1 UGRSc lo0
fe80::%dc0/64 link#1UC dc0
fe80::200:f8ff:fe10:7aa2%dc0 0:0:f8:10:7a:a2 UHL lo0
fe80::%lo0/64 fe80::1%lo0 Uc lo0
fe80::1%lo0 link#3UHL lo0
fec0::1:200:c0ff:fecb:bdf20:0:c0:cb:bd:f2 UHL dc0
fec0::1:200:f8ff:fe10:7aa20:0:f8:10:7a:a2 UHL lo0
ff01::/32 ::1 U lo0
ff02::/16 link#1UCS dc0
ff02::%dc0/32 link#1UC dc0
ff02::%lo0/32 ::1 UC lo0
Hope this helps...let me know if you need anything else.
Thanks!
Bruce.
PGP signature
Re: IPV6 panic?
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI= ?= wrote: > >>>>> On Mon, 16 Jul 2001 10:16:23 -0700, > >>>>> [EMAIL PROTECTED] (Bruce A. Mah) said: > > (kgdb) print rt > > $1 = (struct rtentry *) 0x3 > > (kgdb) print ln > > $2 = (struct llinfo_nd6 *) 0x62 > > Then rt and ln are surely broken. I have not got the reason yet, > though... Yes, rt in particular caught my eye. > Thanks, then could you try the following command? intruder:bmah% sudo netstat -rna -M /var/crash/vmcore.1 -N /usr/obj/usr/src/sys/NIMITZ/kernel.debug Password: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.1.1UGSc20dc0 65.192.41.10 192.168.1.1UGHW161245dc0 127.0.0.1 127.0.0.1 UH 221435lo0 192.168.1 link#1 UC 30dc0 => 192.168.1.10:0:c0:cb:bd:f2UHLW517908dc0 => 192.168.1.30:0:f8:10:7a:a2UHLW0 119004lo0 216.136.204.18 192.168.1.1UGHW157092dc0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSc lo0 => default fe80::200:c0ff:fecb:bdf2%dc0 UGc dc0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRSc lo0 fe80::/10 ::1 UGRSc lo0 fe80::%dc0/64 link#1UC dc0 fe80::200:f8ff:fe10:7aa2%dc0 0:0:f8:10:7a:a2 UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#3UHL lo0 fec0::1:200:c0ff:fecb:bdf20:0:c0:cb:bd:f2 UHL dc0 fec0::1:200:f8ff:fe10:7aa20:0:f8:10:7a:a2 UHL lo0 ff01::/32 ::1 U lo0 ff02::/16 link#1UCS dc0 ff02::%dc0/32 link#1UC dc0 ff02::%lo0/32 ::1 UC lo0 > Also, please tell us the result of > > % ndp -an intruder:bmah% ndp -an NeighborLinklayer Address Netif ExpireSt Flgs Prbs fe80::200:c0ff:fecb:bdf2%dc00:0:c0:cb:bd:f2 dc0 13h12m41s S R fe80::200:f8ff:fe10:7aa2%dc00:0:f8:10:7a:a2 dc0 permanent R fe80::1%lo0 (incomplete) lo0 permanent R fec0::1:200:c0ff:fecb:bdf2 0:0:c0:cb:bd:f2 dc0 23h57m59s S R fec0::1:200:f8ff:fe10:7aa2 0:0:f8:10:7a:a2 dc0 permanent R I should mention that the machine whose addresses are fe80::200:c0ff:fecb:bdf2%dc0 and fec0::1:200:c0ff:fecb:bdf2 is another FreeBSD 4.3-STABLE box (but running code from before the recent KAME merge). It is advertising the link-local prefix to this subnet. As before, please let me know what else I can do. Thanks! Bruce. PGP signature
Re: IPV6 panic?
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI= ?= wrote: > Please try the following patch for the moment. The patch suppresses > garbage collection of stale neighbor cache entries, but it would not > matter for most users. OK, patch applied, and I'm doing a buildkernel right now. Of course I won't be able to tell you very much if it works. Thanks! Bruce. PGP signature
Re: IPV6 panic?
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI= ?= wrote: > The essential point of this problem is not in the IPv6 stack, but in > net/route.c. > > The attached patch (which you may already have seen) would be a > complete fix to this problem. Please try it. OK. I un-did your workaround, applied the patch you posted to -net, and am now building up a new kernel.stay tuned. Thanks! Bruce. PGP signature
Re: avoiding unnecessary route deletion in rt_fixchange()
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI= ?= wrote: > As suggested in the comments to rt_fixchange(), we need stricter check > in the function, to prevent unintentional route deletion. The > attached is a proposed fix to this problem (for FreeBSD4-STABLE). > Please review it, and merge it to the repository if acceptable. > > This fix will also solve the "IPV6 panic?" problem which was recently > reported in this list. FYI, I've been running with this patch installed on my 4-STABLE box for almost four days now (would have been longer except for a power outage). This is much longer than any of my previous uptimes since this problem started occurring (which were generally on the order of a day or so), so I have at least a warm fuzzy feeling about the code now. Bruce. PGP signature
Re: IPV6 panic?
If memory serves me right, John Hay wrote: > > >> I have had several of these since 6/30, after I cvsup'ed > > >> and rebuilt everything. I have been updating fairly frequently, > > >> but the problem seems to persist. > > > > when does it happen? like, > > - removal of pcmcia card > > - some specific command/activity > > - seeing certain packet > > - not related to command/activity, looks like some sort of timer issue > > - whatever > > Up to now it has been at night when I'm not there. :-) I have enabled > saving of the kernel crashdump, so hopefully I'll catch it next time. I've seen something like this as well (4-STABLE from 7 July). For me, this happens in the middle of the day, when I'm at work (this is one of my home systems). I have a crashdump, but no debugging symbols. :-( Having just realized this, I'm turning them on for my kernel builds. My last crashdump has a tombstone that looks like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3f fault code = supervisor read, page not present instruction pointer = 0x8:0xc01fc074 stack pointer = 0x10:0xce06ff60 frame pointer = 0x10:0xce06ff78 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 373 (setiathome) interrupt mask = trap number = 12 panic: page fault syncing disks... 13 2 done Uptime: 1d0h9m41s dumping to dev #da/0x30001, offset 786456 dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 8 5 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc017a892 in dumpsys () (kgdb) where #0 0xc017a892 in dumpsys () #1 0xc017a6b3 in boot () #2 0xc017aa30 in poweroff_wait () #3 0xc0308991 in trap_fatal () #4 0xc0308669 in trap_pfault () #5 0xc0308223 in trap () #6 0xc01fc074 in nd6_timer () #7 0xc01802c9 in softclock () #8 0xc02fc1af in doreti_swi () #9 0x3263 in ?? () #10 0xef9b in ?? () #11 0x138fe in ?? () #12 0x13a25 in ?? () #13 0x2abb in ?? () #14 0x107e in ?? () Will give more info if/when I get it. Bruce. PGP signature
Re: SACK is available in FreeBSD Release 4.3
If memory serves me right, John Merryweather Cooper wrote: > On 2001.08.21 15:42 Harkirat Singh wrote: > > > > Hello Julian, > > > > As a student while doing my project I surfed a lot for SACK > > patch > > in FreeBSd Release4.3. I felt that if someone like me in need of SACK > > src > > can use it and can save time in writing the code. That was the only > > purpose to send the previous mail in the newsgroup. > > > > I am not sure what do you mean by -current version. > > > > A verions of your code that will compile/run on FreeBSD 5-CURRENT. It's > the bleeding edge developer branch of the FreeBSD code. Someone correct > me if I'm wrong, but I think you'll need to build a -CURRENT machine to > do this. Then ensure/port the code to (hopefully) compile/run on both > 4.3/4.4 and 5. (...picking a random message to reply to...) A meta-point...Harkirat was nice enough to post these diffs publically. He never said anything about committing these to -CURRENT or 4-STABLE, but just put them up for people to look at if they were interested. I don't know if committing them is even something he wants to deal with, although hopefully that *is* the case. I'm worried that he's going to get scared away by all the things that he "has to do". No one else has said it yet, but thanks Harkirat for letting us know about your code. As you know, a number of people have asked about this functionality in the past. I haven't read the code closely yet, but I think it'd be great if this *is* a version that can go into -CURRENT, and eventually 4-STABLE. Peace, Bruce. PGP signature
RFC: MFC M_ZERO usage for bpf.c
Hi--
I've been reading through src/sys/net/bpf.c, and I noticed that the
changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet. Any
objection if I do this? (Nothing broke in my quick testing.)
Thanks,
Bruce.
Index: bpf.c
===
RCS file: /usr/ncvs/src/sys/net/bpf.c,v
retrieving revision 1.59.2.6
diff -u -r1.59.2.6 bpf.c
--- bpf.c 20 Sep 2001 14:31:33 - 1.59.2.6
+++ bpf.c 27 Nov 2001 18:49:45 -
@@ -358,8 +358,7 @@
if (d)
return (EBUSY);
make_dev(&bpf_cdevsw, minor(dev), 0, 0, 0600, "bpf%d", lminor(dev));
- MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK);
- bzero(d, sizeof(*d));
+ MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
dev->si_drv1 = d;
d->bd_bufsize = bpf_bufsize;
d->bd_sig = SIGIO;
@@ -1285,11 +1284,10 @@
u_int dlt, hdrlen;
{
struct bpf_if *bp;
- bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT);
+ bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
if (bp == 0)
panic("bpfattach");
- bp->bif_dlist = 0;
bp->bif_ifp = ifp;
bp->bif_dlt = dlt;
msg04133/pgp0.pgp
Description: PGP signature
Re: RFC: MFC M_ZERO usage for bpf.c
If memory serves me right, "Andrew R. Reiter" wrote: > Just as a note, I decided against MFC'ing this and similar changes because > I didn't feel it was necesary for -STABLE to have this "fix." I agree it's not necessary. I'm reviewing some other BPF patches (which have been sitting in my queue for way too long) and I wanted to sync up bpf.c on HEAD and RELENG_4 a little bit before diving in. Bruce. msg04138/pgp0.pgp Description: PGP signature
Re: RFC: MFC M_ZERO usage for bpf.c
If memory serves me right, "Andrew R. Reiter" wrote: > Yea, I think MFC'ing it would be fine. Don't hesitate to thwap me one if > you guys think I should MFC some things Im not. I'm sure there's plenty of people who'll be just itching to take you up on this offer. :-) :-) :-) Thanks, Bruce. msg04140/pgp0.pgp Description: PGP signature
TCP anomalies (was Re: FreeBSD performing worse than Linux?)
If memory serves me right, Garrett Wollman wrote: > Each trace shows a single large file transfer from a 4.4-stable > machine to my -current desktop over a local-area network. I'm pretty rusty at debugging TCP implementations, but I'll try to contribute something... Your 4.4-STABLE machine, is it from before or after rev 1.107.2.18 of sys/netinet/tcp_input.c? (Mon Nov 12 22:11:24 2001 UTC) I'm not sure how relevant this point is, but some of the anomalies I noticed seem related to fast retransmit (see below). Also...where did you do the trace (i.e. sender, receiver, or a third machine)? > test4 was > aborted about 10% into the transfer so that you have a chance at > looking at the whole thing in xplot. There are multiple pathologies > visible in the results, but a good place to start would be around > :56.44 in test4. test4 was the only trace I looked at. One thing that caught my eye is that the receiver seems to be sending a bunch of dupacks (in some cases, many more than needed to trigger fast retransmit) but no retransmit happens. In *most* cases, the receiver somehow gets the missing data because you can later see it acking later sequence numbers. The first place I saw this was at :41.504152. This looks a little odd, but it *could* be explained by data segments getting misordered somewhere and the dupacks getting lost. Another place to look is the large number of consecutive dupacks starting around :41.978767. I don't know what's happening here, but after a long time (about a second?!?) the sender finally gives up and sends the receiver what it wants. Cheers, Bruce. msg04182/pgp0.pgp Description: PGP signature
Re: TCP Flavour
If memory serves me right, =?iso-8859-1?q?Gavin=20Kenny?= wrote: > What flavour of TCP is standard in the FreeBSD stack, > is it Reno or New Reno, Vegas, Tahoe any others? You didn't say what version of FreeBSD you were concerned with, but 4.3-RELEASE and later versions all use NewReno. Bruce. msg04265/pgp0.pgp Description: PGP signature
Re: TCP Flavour
If memory serves me right, Garrett Wollman wrote: > < said: > > > If memory serves me right, =?iso-8859-1?q?Gavin=20Kenny?= wrote: > > >> What flavour of TCP is standard in the FreeBSD stack, > >> is it Reno or New Reno, Vegas, Tahoe any others? > > > You didn't say what version of FreeBSD you were concerned with, but > > 4.3-RELEASE and later versions all use NewReno. > > Well, um, yes and no. FreeBSD includes the ``NewReno'' algorithm, but > it is probably not appropriate to characterize FreeBSD's TCP stack in > that way. I would say that FreeBSD implementes the FreeBSD flavor of > TCP, which is a unique blend of ideas from many outside efforts, and > is based originally on the 4.4BSD stack. OK, that's a fair characterization. There's more to TCP than the congestion control and retransmission algorithms...other things such as initial sequence number generation (RFC 1948 or some variant thereof), timestamps (RFC 1323), etc. Bruce. msg04267/pgp0.pgp Description: PGP signature
Re: Juniper IOS install woes on FreeBSD machine
If memory serves me right, "Nevin E. Leiby" wrote: > > Umm... doesn't JunOS only run on Juniper hardware (ie. routers)?! > > Though based on the FreeBSD kernel, I'd be surprised if you could > > just run JunOS on a FreeBSD workstation... > ... > > Why would you install JunOS on a workstation? JunOS is developed > > especially for Juniper routers, and I would imagine has drivers writen > > expressly for the hardware that make up a Juniper. > > Understandibly, but we only have access to crisco's 2500s, two or three > 5500s, and thats about it...nothin more than that...=\ We do, however, have > an entire lab full of spare pcs with an abundance of nics, all of which are > compatible with the FreeBSD os... Is there any particular reason that you need to have JunOS for your experiments? Depending on what you want to do, FreeBSD (or your Ciscos) might work just fine for you. > Although similar projects have been duplicated with the Zebra and Linux > Router Project, it seems feasible. Unfortunately, at the moment I cannot > quote any of the previous posts that I have read, a few posts seemed to hint > at the ability to run the juniper code on a freebsd machine without > requiring the juniper hardware. I too express some skepticism that you'll be able to make this work. A Juniper router (well at least the M5 in my lab!) is not just a PC plus some fancy NICs. Do "show chassis hardware" from the CLI on a real Juniper to see what I mean. [snip] > So, wouldn't it be possible to have the freebsd workstation execute the > juniper ios code to have the low-level equivilant of a juniper router?? I think you're a little confused here. IOS is the name of the software that runs on Cisco routers. It's very unusual to have the words "Juniper" and "IOS" next to each other in the same sentence. :-) > I > certainly don't understand all of the specifics, but Im not sure how to go > further from here...It seems as though the only [plausible] option would be > to build the entire junos filesystem as done on a juniper router, then load > the ios image, etc My feeling is that even if this can be made to work, you're largely in uncharted waters. IANAL, but you might also check to make sure you aren't violating some kind of licensing agreement by doing what you're proposing. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IP multicast time and dhcp
If memory serves me right, Eli Dart wrote: > In reply to "Crist J . Clark" <[EMAIL PROTECTED]> : > > > On Tue, Jan 22, 2002 at 05:37:07PM -0800, Eli Dart wrote: > > [snip] > > > Note that the igmp queries are sent to the multicast address > > > 224.0.0.1, so the laptop is seeing multicast traffic. The kernel > > > just seems to think that it doesn't have any multicast groups that it > > > cares about. > > > > Running mrouted(8)? > > Nope. The environment is all PIM-SM. If I restart ntpd after the > interface is up, everything works. It's not (as far as I can tell) a > problem with the multicast infrastructure -- it's local to the laptop. Right, you shouldn't need mrouted(8) or any other multicast routing daemon for IGMP to do the right thing. Hmmm. How about a routing table? Do you have default unicast/ multicast routes? (Did I ask you this before?) Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: 1000baseSX driver support?
If memory serves me right, Matt Wilbur wrote: > I'm trying to figure out if there are *any* 1000baseSX NICs supported in > 4.5-RELEASE? I've tried a GA-621T and a Tigeon (3c985B), with no luck. > LINT suggests that nge will support DP83820 and DP83821 chipsets.. but our > GA621T (with a DP83820) won't work. It suggests that ti will support > Tigon 1 and 2, but our 3c985B doesn't work. I don't know the answer to your question, but I bet you'll have better luck getting an answer if you can express exactly what "doesn't work" means. For example: Does it probe at boot-time? Can you bring the interface up with ifconfig? What happens when you try sending data? Good luck, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode)
[Moving to -net] If memory serves me right, Andrew Gallatin wrote: > > Alternately, it would be a good idea to have a "ip_maxpacketfrags" > > instead of an "ip_maxfragpackets", to put a hard limit on the > > number of mbufs that can be consumed by the fragment reassembly > > process. > > I think this is the best solution. Just for the heck of it, I started reading through ip_input.c to see how hard this would be to do. Haven't got there yet, I saw something odd: the variables ip_nfragpackets and nipq look *awfully* similar. It looks like they both track the number of reassembly queues, because they're initialized to zero, and incremented and decremented at the same time. Their limits (ip_maxfragpackets and maxnipq respectively) are even initialized on consecutive lines. The only difference I can see is that in ip_input(), if nipq > maxnipq, all of the fragments for some other packet in the current hash bucket get dropped (with the wonderfully descriptive comment "gak"). The check for ip_nfragpackets comes in ip_reass(), where if ip_nfragpackets >= ip_maxfragpackets, then we drop the current fragment. (Is it possible that the second check masks the effects of the first?) I couldn't find any obvious explanation in the CVS log for ip_input.c. Am I missing something, or are these two variables basically doing the same thing? Thanks, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode)
If memory serves me right, Bill Fenner wrote: > The problem with the ip_nfragments code is that if space becomes > available in the middle of reception of an entire packet, a queue > will be created to reassemble a packet that will never completely > arrive (since we dropped some of the beginning of it due to no space). > I guess the nipq code has a similar problem: it will gladly free > a queue that contains fragments that go with the next fragment that > arrives. ...but of course the "obvious" solution of only creating the queue when we see a fragment with offset 0 doesn't work, because of the potential of out-of-order delivery. Sigh. > In fact, if datagrams that hash to the same bucket arrive with > interleaved fragments, the nipq code could thrash between the two > packets, creating and deleting a frag queue for each fragment arrival, > dropping both datagrams. Bleah. This is an acid flashback to grad school, when I was measuring TCP performance over ATM switches with too-small drop-tail cell buffers. :-( > To address this kind of problem, it might be worth creating a "drop" > frag queue entry, which is a way to remember that we dropped fragments > from a given datagram so we should drop all the other fragments too. Sounds reasonable, I think. > (I'd also go for modifying the data structures to make it easy to drop > the oldest frag queue.) That's a *lot* harder. We're at least dumping the oldest queue in the hash bucket now (64 buckets, fragment queues in the hundreds). Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: networking fact checking for book
If memory serves me right, Michael Lucas wrote: > OK, damn fool question here, but our docs are not entirely consistent > on this and I need to be sure before I send this book to the printer. > Rather than trawl through the source code for hours and get it wrong, > I'm asking here. > > net.inet.tcp.sendspace= bits or bytes? Bytes...memory allocations take place using this variable. I couldn't find anywhere in sys/netinet/* that actually, explicitly documents the units for this. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Is fetch -6 supposed to work?
If memory serves me right, Doug Barton wrote: > It seems to me that fetch(1) cannot actually fetch files over a v6 > connection. For example, the following works: > > fetch -s -P -6 > http://surfnet.dl.sourceforge.net/sourceforge/xchat/xchat-2.6.0.tar.bz2 > 796768 > > But remove the -s and try to fetch the file and it hangs until it times out: > > xchat-2.6.0.tar.bz2 0% of 778 kB0 Bps > fetch: transfer timed out > fetch: xchat-2.6.0.tar.bz2 appears to be truncated: 0/796768 bytes > > tcpdump on that interface shows no packets flowing between my host and the > remote host while it hangs. > > So, is this supposed to work? Any comments or suggestions? I should also > note that surfing IPv6 sites with my web browser works fine. Hi Doug-- This didn't quite work for me either, though I would have expected it to. (Hmmm...what's the point of "-P" for an HTTP retrieval anyways?) This is on my RELENG_5 desktop: tomcat:bmah% fetch -P -6 http://surfnet.dl.sourceforge.net/sourceforge/xchat/xchat-2.6.0.tar.bz2 fetch: http://surfnet.dl.sourceforge.net/sourceforge/xchat/xchat-2.6.0.tar.bz2: Operation timed out tomcat:bmah% fetch -P -6 http://www.kitchenlab.org/www/bmah/Software/pchar/pchar-1.5.tar.gz pchar-1.5.tar.gz 100% of 114 kB 14 MBps And then on my RELENG_6 laptop: localhost:bmah% fetch -6 http://surfnet.dl.sourceforge.net/sourceforge/xchat/xchat-2.6.0.tar.bz2 xchat-2.6.0.tar.bz2 0% of 778 kB0 Bps fetch: transfer timed out fetch: xchat-2.6.0.tar.bz2 appears to be truncated: 0/796768 bytes localhost:bmah% fetch -6 http://www.kitchenlab.org/www/bmah/Software/pchar/pchar-1.5.tar.gz pchar-1.5.tar.gz 100% of 114 kB 544 kBps www.kitchenlab.org is a dual-stack machine. It's on the same subnet as my desktop and one hop away from my laptop. I suspect that there's something about surfnet.dl.sourceforge.net that's kind of funky (note intensely technical term) but I'm clueless as to why we can't transfer from it. From tcpdump, it looks to me like the three-way handshake works but the transfer hangs after a few packets have been transferred. I'm not sure why. Bruce. signature.asc Description: This is a digitally signed message part
Re: nd6_lookup prints bogus messages with point to point devices
If memory serves me right, Ed Schouten wrote: > On one of the FreeBSD machines we maintain at Dispuut Interlink[1], we > get a lot of messages like these: > > | nd6_lookup: failed to add route for a neighbor(), errno=17 > > The addresses mentioned in the messages are all addresses of endpoint > addresses of point-to-point devices. The nd6_lookup() call in the > function nd6_output() is responsible for it. If you look through > nd6_output(), you see that a couple of lines below the nd6_lookup() call > it doesn't really care when dealing with IFF_POINTOPOINT devices. > > It would be really useful to drop the messages when dealing with point > to point devices, so I write a patch[2] for nd6_lookup() to make it > print the message when not dealing with IFF_POINTOPOINT devices. > > Should I open a PR for this patch? I think that suz@ and ume@ are the people who have worked in this area most recently, hopefully one of them will speak up. You didn't give a lot of details...please give (at a minimum) the version of FreeBSD you're using and more details about the interface over which you're having this problem. I saw this on RELENG_6 sometime after some IPv6 ND changes that were merged in late last year. I have a gif(4) tunnel to my ISP over which I do IPv6. The GIF tunnel was originally configured as a point-to-point interface and I got the same messages you mentioned. My workaround was to configure the gif(4) interface as a /127, which was obviously only possible because the two interface addresses on each end of the tunnel just happened to differ only in their least-significant bits. (I know this isn't the right solution.) Bruce. signature.asc Description: OpenPGP digital signature
Re: nd6_lookup prints bogus messages with point to point devices
If memory serves me right, Ed Schouten wrote: > I'm seeing the messages on the machine in Eindhoven (running RELENG_6 > from a few days/weeks ago), but they also show up on my HEAD machine at > home. Below is the output of `ifconfig gif0` on my machine at home: > > | gif0: flags=8051 mtu 1280 > | tunnel inet 83.181.147.170 --> 193.109.122.244 > | inet6 fe80::202:a5ff:fe58:4927%gif0 prefixlen 64 scopeid 0x7 > | inet6 2001:7b8:310::1 --> 2001:7b8:2ff:a4::1 prefixlen 128 Hi Ed-- Fair enough...the workaround that I did won't work for you because it's not possible to aggregate the two ends of the tunnel into a single /127. > As far as I know, the latest FreeBSD releases show an error message when > assigning an address with a non-128 prefixlen. Actually I thought the problem was just point-to-point tunnel interfaces with a prefix length of 128. I am not sure what to do with your patch (which is what you originally asked about) since I'm not sure what the correct behavior is in this case. In other words, I know something's wrong but I don't know what the right solution is. I'm copying suz@ and ume@ to see if either of them might have any opinion. (Guys, sorry to bother you but could one of you take a look at this thread on net@ and comment? Thanks!) Bruce. signature.asc Description: OpenPGP digital signature
Re: How to Quicken TCP Re-transmission?
If memory serves me right, Mark Allman wrote: >> Thank you for your reminder. Actually, I understand you and >> RFC 2018. What I really concern is how wide support (and being enabled >> by default) SACK has obtained. For we do not always transfer data >> between hosts running FreeBSD and maintained by network expert. > > SACK is quite widely deployed. See: > > Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of > Transport Protocols in the Internet. ACM Computer Communication > Review, 35(2), April 2005. > http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps What a trip, I just read this paper on the train to work this morning. FWIW, I thought this was a well-done study on an interesting topic. A question and a nitpick: Did you try doing any stack fingerprinting to get some idea of the mix of TCP/IP stacks among the servers / clients you examined? The percentages in the commentary on Table 5 in the text (second column of p. 41 in the CCR printing) are sometimes one-off from the percentages actually shown in Table 5. It took me several tries to get through the "huh?!?"-ness of this, though the lack of caffeine in my bloodstream at the time might have been a contributing factor. :-) Cheers, Bruce. signature.asc Description: OpenPGP digital signature
Re: nd6_lookup prints bogus messages with point to point devices
If memory serves me right, George V. Neville-Neil wrote: > After way too long this has been tested and committed to HEAD, with an > MFC timout of 1 week. I have done only limited, aka, ping, testing of > this fix. > > I am currently setting up my own outbound IPv6 network so that I can > do more real world testing of such patches in future. Thanks George and JINMEI-san! I've merged this patch into my local RELENG_6 tree and will give it a try on my IPv6 tunnel endpoint...will report back results. Bruce. signature.asc Description: OpenPGP digital signature
Re: nd6_lookup prints bogus messages with point to point devices
I wrote: > If memory serves me right, George V. Neville-Neil wrote: >> After way too long this has been tested and committed to HEAD, with an >> MFC timout of 1 week. I have done only limited, aka, ping, testing of >> this fix. >> >> I am currently setting up my own outbound IPv6 network so that I can >> do more real world testing of such patches in future. > > Thanks George and JINMEI-san! I've merged this patch into my local > RELENG_6 tree and will give it a try on my IPv6 tunnel endpoint...will > report back results. So far so good...no signs of those error messages after a workday's worth of uptime. Although I can't claim to be a heavy IPv6 user, I would have noticed those messages by now with pre-patch code. I'll keep an eye on it for a few more days, but if you don't hear anything from me, please count me as an "the fix works for me". Thanks again! Bruce. signature.asc Description: OpenPGP digital signature
Re: De-orbitting tcpslice
If memory serves me right, Bruce M Simpson wrote: > We have tcpslice maintained in ports. We have ancient tcpslice in base > system. We have PRs about it. > > I'd like to nuke it in HEAD. > > How does everyone else feel about that before I go off and do it? +1 Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 link-local routes disappear in 6.2-RC1
If memory serves me right, [EMAIL PROTECTED] wrote: > At Thu, 14 Dec 2006 23:27:53 +0100, > Daniel Dvořák wrote: >> Hi all, >> >> >> >> I want back ipv6 link-local routes back, do you know how to do that >> ? I hope this significant change will be in release document for >> 6.2. I did not change rc.conf since release FreeBSD 6.1 in May06. >> > > You need to set > > auto_linklocal="YES" > > in rc.conf Um, are you sure? I thought the idea was that the auto_linklocal script checked ipv6_enable. To the OP: You don't appear to have any other IPv6 interface addresses configured...do you have this line in /etc/rc.conf? ipv6_enable="YES" If not, I'd try adding *that*. Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 link-local routes disappear in 6.2-RC1
If memory serves me right, Daniel Dvořák wrote: > Of course not, because in May and before may and before RC1 it was not needed > at all to have ipv6_enable="YES" to have link-local routes. > > So what needed ? I do not understand. > > auto_linklocal or ipv6_enable ? ipv6_enable="YES" This is documented in the 6.2 release notes. Bruce. signature.asc Description: OpenPGP digital signature
Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression)
The following reply was made to PR kern/107358; it has been noted by GNATS. From: "Bruce A. Mah" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) Date: Tue, 09 Jan 2007 13:33:18 -0800 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig3807A02A1C245B21A0F49067 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Mark Linimon wrote: > Old Synopsis: IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 > New Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regre= ssion) >=20 > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Jan 1 13:28:53 UTC 2007 > Responsible-Changed-Why:=20 > Perhaps someone on -net has an idea. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D107358 This looks to me like it could be a duplicate of kern/103415, which was fixed on HEAD and RELENG_6 (prior to RELENG_6_2 creation, so 6.2 should be OK, as well as both of the 6.2-RC snapshots). If this is true, a possible fix might be to apply revision 1.51.2.10 of src/sys/netinet6/in6= =2Ec. I don't really have an environment conducive to testing 6to4, so this hypothesis is completely untested. Bruce. --enig3807A02A1C245B21A0F49067 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpAoj2MoxcVugUsMRAmvSAKD6Ob8UcClH1vV56IOw8GXRwXoWHACaA/s7 rmEydKBElBocJJ34i1emxK4= =Kppv -END PGP SIGNATURE- --enig3807A02A1C245B21A0F49067-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression)
Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) State-Changed-From-To: open->closed State-Changed-By: bmah State-Changed-When: Wed Jan 10 15:54:57 UTC 2007 State-Changed-Why: Closing this PR, as the problem originally described has been fixed in 6.2 and later versions. Responsible-Changed-From-To: freebsd-net->bmah Responsible-Changed-By: bmah Responsible-Changed-When: Wed Jan 10 15:54:57 UTC 2007 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=107358 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPv6 over gif(4) broken in 6.2-RELEASE?
I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE
and recent 6-STABLE, namely that I can't seem to be able to pass
traffic over them.
Essentially, when I configure a gif interface like this:
# ifconfig gif0 inet6 :::::1 :::::2 prefixlen
128
the interface should add a host route to :::::2
through gif0. This is necessary to be able to pass traffic over the
tunnel, particularly since the source and destination addresses of the
link don't need to have any relationship to each other.
However, this route doesn't get installed on recent 6-STABLE.
Therefore there is no way to get an IPv6 packet to the other end of
the tunnel because there's no route for the destination. The most
obvious symptom is that I try to ping the other tunnel endpoint and
get:
ping6: UDP connect: No route to host
I know this worked on RELENG_6 as of June 2006; my home firewall has
been running this code for months without a hitch. It doesn't work in
6.2-RC2 or 6.2-RELEASE (fresh CD installs on i386, GENERIC kernels),
or this week's RELENG_6 (nanobsd on i386).
I somewhat suspect revs. 1.48.2.15 and 1.48.2.14 to
src/sys/netinet/nd6.c. If I locally revert these two changes (see
diff below), IPv6 over gif(4) works again.
There's another workaround for people stuck in this situation and who
aren't in a position to try this diff. That is to manually install
the host route like this:
# route add -host -inet6 :::::2 -interface gif0 -nostatic
-llinfo
Comments?
Bruce.
Index: nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.48.2.16
diff -u -r1.48.2.16 nd6.c
--- nd6.c 29 Nov 2006 14:00:29 - 1.48.2.16
+++ nd6.c 20 Jan 2007 16:15:28 -
@@ -1316,7 +1316,7 @@
callout_init(&ln->ln_timer_ch, 0);
/* this is required for "ndp" command. - shin */
- if (req == RTM_ADD && (rt->rt_flags & RTF_STATIC)) {
+ if (req == RTM_ADD) {
/*
* gate should have some valid AF_LINK entry,
* and ln->ln_expire should have some lifetime
pgpNabmL1biLi.pgp
Description: PGP signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, Hiroki Sato wrote: > "Bruce A. Mah" <[EMAIL PROTECTED]> wrote > in <[EMAIL PROTECTED]>: > > bm> I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE > bm> and recent 6-STABLE, namely that I can't seem to be able to pass > bm> traffic over them. [snip] > bm> I know this worked on RELENG_6 as of June 2006; my home firewall has > bm> been running this code for months without a hitch. It doesn't work in > bm> 6.2-RC2 or 6.2-RELEASE (fresh CD installs on i386, GENERIC kernels), > bm> or this week's RELENG_6 (nanobsd on i386). > bm> > bm> I somewhat suspect revs. 1.48.2.15 and 1.48.2.14 to > bm> src/sys/netinet/nd6.c. If I locally revert these two changes (see > bm> diff below), IPv6 over gif(4) works again. [snip] > I remember Dimitry Andric reported the same problem on -stable on 30 > Dec, and after he reverted rev.1.48.2.16 it worked fine again. Do > you have the symptom even on 6.2-RELEASE? Since RELENG_6_2_0_RELEASE > did not have the change, I thought there was no problem. > > I will try to reproduce it on my box anyway... Yep, even on 6.2-RELEASE. I did a setup with a couple of machines yesterday (6.2-RC2 and 6.2-RELEASE) that demonstrated the problem. On my 6-STABLE system (which appears to be working fine), I still have the change from 1.48.2.16, I only backed out .15 and .14. I didn't try my diff on the 6.2-RC2 and 6.2-RELEASE machines yet. Hmmm...I was looking for that bug report before, but I couldn't find it. It's not clear to me how 1.48.2.16 is involved...hmmm... Thanks, Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, John Hay wrote: > On Sat, Jan 20, 2007 at 08:29:36AM -0800, Bruce A. Mah wrote: >> I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE >> and recent 6-STABLE, namely that I can't seem to be able to pass >> traffic over them. >> >> Essentially, when I configure a gif interface like this: >> >> # ifconfig gif0 inet6 :::::1 :::::2 >> prefixlen 128 >> >> the interface should add a host route to :::::2 >> through gif0. This is necessary to be able to pass traffic over the >> tunnel, particularly since the source and destination addresses of the >> link don't need to have any relationship to each other. > > I only have one IPv6 over IPv4/gif tunnel and ther I use only my side > of the address, something like this: > > ifconfig gif0 inet6 2001:4200::5::2 prefixlen 64 > > And then bgp on top of this. It seems to work fine on -current built > after my change. I believe the difference between your situation and mine is that your gif0 interface is setup with a prefixlen < 128, which doesn't specifically require a host route to the interface of the destination. This is actually handled specially in several parts of the IPv6 stack. > Well it seems that even my stuff does not always work perfectly with that > change (1.48.2.15), so maybe we should revert it and I will search for > yet other ways to make FreeBSD's IPv6 code to actually work for our stuff. > > My "stuff" is a wireless IPv6 only network running in adhoc mode with > olsrd as the routing protocol. The problem is that all nodes on a subnet > cannot "see" each other, so olsrd needs to add routes to a node through > another node. Sometimes, just to complicate matters a little more, you > would want to have more than one network card in a host, all with the same > subnet address. (For instance on a high site, with sector antennas.) > > The case that I found that still does not work reliably, is if olsrd add > the route and route is not immediately used, then the nd code will time > it out and remove it. > > So, I guess if you guys think I should revert my stuff, just say so. > > And if you have a solution for my problem, just say so too. :-) This sounds kind of interesting! I'm concerned that this bug seems (at least in my testing) to be present in 6.2-RELEASE. I'm not 100% sure what's the right thing to do at this point. Thanks, Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: >>> I remember Dimitry Andric reported the same problem on -stable on 30 >>> Dec, and after he reverted rev.1.48.2.16 it worked fine again. Do >>> you have the symptom even on 6.2-RELEASE? Since RELENG_6_2_0_RELEASE >>> did not have the change, I thought there was no problem. > ... >> On my 6-STABLE system (which appears to be working fine), I still have >> the change from 1.48.2.16, I only backed out .15 and .14. I didn't try >> my diff on the 6.2-RC2 and 6.2-RELEASE machines yet. >> >> Hmmm...I was looking for that bug report before, but I couldn't find it. >> It's not clear to me how 1.48.2.16 is involved...hmmm... > > I originally reported this here: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.html > > and later I found out it was caused by commit 1.48.2.16: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html > > I'll shoot in a regular PR later tonight... Hi Dimitry-- This isn't consistent with what I'm finding. For one thing, rev. 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there anyways. Also, that's not the change I made to my local sources to get my gif(4) tunnel working. Are you sure about this? :-) Thanks! Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, Dimitry Andric wrote:
> Bruce A. Mah wrote:
>>> and later I found out it was caused by commit 1.48.2.16:
>>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html
>> This isn't consistent with what I'm finding. For one thing, rev.
>> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
>> anyways. Also, that's not the change I made to my local sources to get
>> my gif(4) tunnel working. Are you sure about this? :-)
>
> I'm following -STABLE, and 1.48.2.16 is in there. Since it was
> committed on 29 Nov, I suspected it would end up in -RELEASE, but
> apparently not. :)
>
> I explicitly tried reverting just this one commit, and for me it solved
> the problem (i.e. the automagical addition of needed routing entries).
I tried this too and it didn't help. :-(
Just to confirm, you're dealing with a gif(4) interface with an
explicitly-configured destination address and a 128-bit prefixlen, yes?
> So for you, reverting the combination of 1.48.2.14 and .15 works?
Yep. BTW these two changes really go together, so it doesn't really
make sense to revert just one of them (the commit logs implied that this
would be fairly broken in other ways).
> Maybe
> there is something else involved too, for example the route command
> itself?
Not sure what you mean by this exactly...???...
Here's what I've tested so far...in the table below, "work" means that
the host route to the destination got installed correctly and "no work"
means that it didn't.
BaseLocal Patch Result
--- --
6.2-RELEASE Unmodified No work
6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work
6.2-STABLE Unmodified No work
6.2-STABLE Revert nd6.c 1.48.2.{14,15} Work
6.2-STABLE Revert nd6.c 1.48.2.16 No work
I'm going to write up an entry for the 6.2-RELEASE errata notes
documenting the existence of a problem and a workaround. We still need
to figure out exactly what the right fix is. Testing results from other
users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome.
Bruce.
signature.asc
Description: OpenPGP digital signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, JINMEI Tatuya / 神明達哉 wrote: >> On Sun, 21 Jan 2007 09:32:44 +0200, >> John Hay <[EMAIL PROTECTED]> said: > >>> There's another workaround for people stuck in this situation and who >>> aren't in a position to try this diff. That is to manually install >>> the host route like this: >>> >>> # route add -host -inet6 :::::2 -interface gif0 -nostatic >>> -llinfo >>> >>> Comments? > >> Well it seems that even my stuff does not always work perfectly with that >> change (1.48.2.15), so maybe we should revert it and I will search for >> yet other ways to make FreeBSD's IPv6 code to actually work for our stuff. > >> My "stuff" is a wireless IPv6 only network running in adhoc mode with >> olsrd as the routing protocol. The problem is that all nodes on a subnet >> cannot "see" each other, so olsrd needs to add routes to a node through >> another node. Sometimes, just to complicate matters a little more, you >> would want to have more than one network card in a host, all with the same >> subnet address. (For instance on a high site, with sector antennas.) > >> The case that I found that still does not work reliably, is if olsrd add >> the route and route is not immediately used, then the nd code will time >> it out and remove it. > > I think I'm responsible for the troubles. I've been thinking about > how to meet all the requests, and concluded that it's more complicated > than I originally thought. > > I've come across an idea that may solve the problems, but I'll need > more time to implement and test it. > > At the moment, I suggest reverting the 1.48.2.16 change for those who > simply wanted a gif to work. Based on these comments above, I've reverted rev. 1.67, 1.68, 1.69, and 1.70 of nd.c on HEAD. After a bunch more testing I've convinced myself that I think this will solve the problems that we have been seeing, and possibly why some other people's testing yielded counter-intitive results. I'll MFC to STABLE in 3 days. Commit message below... Bruce - bmah2007-01-26 23:22:58 UTC FreeBSD src repository Modified files: sys/netinet6 nd6.c Log: Revert nd6.c revs. 1.67, 1.68, 1.69, 1.70 in an attempt to unbreak IPv6 over point-to-point gif(4) tunnels. These revisions caused a host route to the destination of a point-to-point gif(4) interface to not get installed when the interface and destination addresses were assigned. This caused "no route to host" errors when trying to send traffic over the interface. The first packet arriving inbound over the tunnel, however, would cause the correct route to get installed, allowing subsequent outbound traffic to be routed correctly. gif(4) interfaces with prefix lengths of less than 128 bits (i.e. no explicit destination address assigned) were not affected by this bug. This bug fix is a possible candidate for a 6.2-RELEASE errata note. Approved by:jhay (original committer) Discussed with: jhay, JINMEI Tatuya MFC after: 3 days Revision ChangesPath 1.74 +1 -1 src/sys/netinet6/nd6.c signature.asc Description: OpenPGP digital signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: > I mean that it may be that between -RELEASE and -STABLE, other things > have changed, e.g. network rc scripts, /sbin/route itself, etc, which > may also influence this behaviour. I'm sure more than only nd6.c > changed. :) The testing I did doesn't require any of that stuff, only a kernel, a shell, and ifconfig(8). I'm not aware of anything relevant. (As one of the RE types, I do follow commit mails pretty closely, especially during and just after a release cycle.) > However, for me, with the whole system at -STABLE (as of Jan 11), I > verified the following results again just now: > > nd6.c rev state > - - > 1.48.2.12 works > 1.48.2.13 works > 1.48.2.14 works > 1.48.2.15 works > 1.48.2.16 doesn't work I've convinced myself that this problem needs to be tested in isolation (i.e. you have complete control over both ends of the tunnel) because incoming packets over the tunnel cause the host route to get added automatically if it wasn't there already. After reading the code and discussing this with a couple folks, I've managed to convince myself that 1.48.2.14 and 1.48.2.15 (and their analogues on HEAD) need to go away. I've committed diffs that back these out, and they solve the problem for me in my testing (which I've done with two VMs in isolation). The applicable revisions for nd6.c are 1.74 (HEAD) and 1.48.2.18 (RELENG_6). Updating up to (or beyond) these revisions should clear up the problem. Testing reports from people who were having problems would be appreciated. Bruce. signature.asc Description: OpenPGP digital signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
If memory serves me right, Dimitry Andric wrote: > JINMEI Tatuya / 神明達哉 wrote: >>> Confirmed. I've updated the machine on which I originally had this >>> problem to -STABLE as of today, and the problem has disappeared. >> I thought it was also planned to be incorporated to RELENG_6_2, right? > > I'm not sure if non-security related fixes are considered for release > branches. Also, there's a workaround mentioned on the 6.2 errata page, > under "Known Issues": Yes, we do this (most releases nowadays have at least a couple of errata notices / patches). > http://www.freebsd.org/releases/6.2R/errata.html > > Then again, it's really up to the release engineering team whether they > deem this critical enough. :) Its a joint decision between re@ and [EMAIL PROTECTED] I *am* on re@, and I'd planned on getting this change into RELENG_6_2, but I'm seriously ENOTIME (now trying to type one-handed with my sleeping two-week-old son in the other hand). I'll send a copy of this to re@, hopefully one of us will do this. Cheers, Bruce. signature.asc Description: OpenPGP digital signature
Re: Bridge and NAT problems
If memory serves me right, Andrea Venturoli wrote: > Hello. > I've got the following problem... > My host is configured like this: > > fxp0: internal interface, requires NAT > rl1: public interface, with static IP > xl0: bridged to rl1, with some public IP behind > > ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw > 50 divert 8668 ip from any to any via rl1 > > > Internal <-> Internet works, as Internet <-> Bridged does. > Internal <-> Bridged does not work. > > Let's suppose I'm pinging from the inside to a bridged machine: the ICMP > packet comes in through fxp0 and is allowed, gets NATted going out by > rule 50 and reaches the target hosts (I guess bridging is also happening > to send it out via xl0 instead of rl1). > The target answers to the public IP of this box and the packet comes in > via xl0, so it's not back-NATted and gets lost. > > I then tought of diverting to natd every packet through xl0 (i.e. 60 > divert 8668 ip from any to any via xl0), but this doesn't work either. > The packet gets to natd by means of rule 60, but natd does not recognize > it as an answer to a previously examined packet. > From man pages I understood that natd does not take interface into > account, but only source and destination IP:port. Then, what's wrong? > > Any suggestion? You didn't say which bridging driver or version of FreeBSD you're using, but it sounds to me like you're using bridge(4), right? This is a fairly well known problem, which I wrote a little bit about here: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html (This message describes a scenario with ipf, but it applies equally well I think to ipfw.) If you can, try switching to using if_bridge(4). You (probably) want to assign the public NAT address to the bridge0 interface, and leave the physical interfaces making up the bridges (xl0 and rl1 in your case) unnumbered. I've had good experiences with this type of configuration. Bruce. signature.asc Description: OpenPGP digital signature
Re: Bridge and NAT problems
If memory serves me right, Andrea Venturoli wrote: > Bruce A. Mah wrote: > >> You didn't say which bridging driver or version of FreeBSD you're using, >> but it sounds to me like you're using bridge(4), right? > > Yes. > > > >> This is a >> fairly well known problem, which I wrote a little bit about here: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html >> >> (This message describes a scenario with ipf, but it applies equally well >> I think to ipfw.) > > Read that. > So I guess my analysis was wrong in that I thought natd was not > reconverting packets; from what you say I understand the problem is that > this packets are not diverted to natd, right? > The details are right now beyond my understanding... Without more details it's difficult to say. Not to be overly critical, but "does not work" from your original post isn't real helpful, unfortunately. If you had packet traces of, say, attempted pings, that would give a lot more data to help say exactly what the problem is. It just sounds *very* similar to a problem I spent a lot of time working on. >> If you can, try switching to using if_bridge(4). > > I cannot right now, since I have to wait to be physically at this box, > but I could try in the future. Do you see any drawback? None I can think of. Note that bridge(4) is deprecated in RELENG_6 and is gone entirely from HEAD (in favor of if_bridge(4)). if_bridge(4) is also more featureful and is being actively worked on. >> You (probably) want to >> assign the public NAT address to the bridge0 interface, and leave the >> physical interfaces making up the bridges (xl0 and rl1 in your case) >> unnumbered. I've had good experiences with this type of configuration. > > Ok. > So I would only need to > create the bridge0 interface as per man page > sysctl net.link.bridge.ipfw=1 > sysctl net.link.bridge.pfil_onlyip=0 > change every reference to rl1 in my ipfw ruleset to bridge0 > > Anything else? > Would everything work the same as now (apart from this "feature" which > is causing me troubles)? I think that'll work, yes. (Caveat: If you are doing other filtering in ipfw you might need to make some additional adjustments, but if all you're doing is NAT/divert, "change every reference to rl1 ... to bridge0" should work just fine.) Bruce. signature.asc Description: OpenPGP digital signature
Re: what is wrong with ipv6_defaultrouter ?
If memory serves me right, Jason Arnaute wrote: > (FreeBSD 6.2-RELEASE) > > I have two ipv6 related lines in my /etc/rc.conf: > > ifconfig_em0_alias0="inet6 XXX::2/48" > ipv6_defaultrouter="XXX::1" > > When I boot like this, I do not get a default ipv6 > route in my routing table. 'netstat -rn' shows me a > default route for ipv4, but no default route for ipv6. You probably want to replace that first line with: ipv6_ifconfig_em0="XXX::2/48" Also make sure to set ipv6_enable="YES". Bruce. signature.asc Description: OpenPGP digital signature
Re: what is wrong with ipv6_defaultrouter ?
If memory serves me right, Jason Arnaute wrote: > --- "Bruce A. Mah" <[EMAIL PROTECTED]> wrote: > >> If memory serves me right, Jason Arnaute wrote: >>> (FreeBSD 6.2-RELEASE) >>> >>> I have two ipv6 related lines in my /etc/rc.conf: >>> >>> ifconfig_em0_alias0="inet6 XXX::2/48" >>> ipv6_defaultrouter="XXX::1" >>> >>> When I boot like this, I do not get a default ipv6 >>> route in my routing table. 'netstat -rn' shows me >> a >>> default route for ipv4, but no default route for >> ipv6. >> >> You probably want to replace that first line with: >> >> ipv6_ifconfig_em0="XXX::2/48" >> >> Also make sure to set ipv6_enable="YES". > > > But the ipv6 ifconfig and the ipv6 networking all work > fine without either of those changes. I'd prefer not > to fix anything that isn't broken ... Not having a default route isn't what I'd call "working fine". :-) ipv6_ifconfig_em0 is the documented, supported mechanism for specifying an IPv6 address for your em0 interface at system startup time. The fact that you were able to do this by specifying an interface alias is a happy accident but it's not supported. > Are you suggesting that one or both of those changes > will cause the ipv6_defaultrouter declaration to > suddenly begin working ? Yes. Note that as of 6.2-RELEASE if you don't set ipv6_enable="YES" you might not get a link-local address on any of your network interfaces. This will cause some problems. (This change was made deliberately in order to avoid assigning IPv6 link-local addresses on systems that weren't explicitly configured to enable IPv6.) > Do you use that same ipv6_defaultrouter declaration > in your rc.conf ? Yes. Please read through the rc.conf(5) manpage...there's an explanation of the various ipv6_* variables there. There should be something on this topic in the FreeBSD Handbook as well. Bruce. signature.asc Description: OpenPGP digital signature
Re: CFR: bridge locking
If memory serves me right, Sam Leffler wrote: > One other minor change: I moved the printf "BRIDGE 020214 loaded" under > bootverbose. Can anyone tell me what 020214 means? I recently started using bridge(4) functionality and was wondering about this too. Based on the output of "cvs annotate" and "cvs log", I concluded that it was a datestamp used by Luigi to keep track of which version he was working with (on HEAD, this line was last touched in revision 1.45, which was committed on 15 February 2002). Bruce. pgp0.pgp Description: PGP signature
Re: IPv6 routing
If memory serves me right, paul van den bergen wrote: > I am attempting to set up some static ipv6 routes on my little network. > > example: > > box1 - fec0:0:0:1::1 fec0:0:0:1::2 - box 2 (router) - fec0:0:0:2:1 > fec0:0:0:2:2 - box 3 > > I want to reach from box 1 to box 3 > > no route6d or anything... this is a really simple network. > > sysctl net.inet6.ip6.forwarding=1, net.inet6.ip6.accept_rtadv=0 on box 2 (the > > router) > sysctl net.inet6.ip6.forwarding=0, net.inet6.ip6.accept_rtadv=1 on boxes 1 an > d > 3 (the hosts). > > route add -inet6 -net fec0:0:0:2:: -prefixlen 64 -host fec0:0:0:1::2 > on box1 > > box2 can ping6 to box1 and box3 and vise versa. > > why can't box 1 ping6 box 3? What have I missed? Did you add a route on box3 so that it can reach box1? Remember that ping6 requires two-way connectivity. You set net.inet6.ip6.accept_rtadv=1 on the end hosts...do you have rtadvd running on box2 so that they actually acquire the routes? You haven't really provided enough information to debug the problem. How about the output of ifconfig(8) and the routing tables on all three machines? Bruce. pgp0.pgp Description: PGP signature
Re: bridge with access on both interfaces
If memory serves me right, Ian Smith wrote: > In short, ifconfig appears unwilling to have two NICs covering the same > /24. Can this be set up? I'm also at a bit of a loss with the routing, > so inside packets to the bridge box (ie unbridged packets) are responded > to on the same interface, and outside unbridged packets go only to/from > the gw. Some tcpdumps on both in and outside interfaces suggest an ARP > response problem also, perhaps; no responses on the inside iface at all. Hi Ian-- This may or may not be the source of your problem, but I've been procrastinating on writing this up for a couple months and this was the impetus that pushed me over the edge. In 4-STABLE, there's a bug that prevents ARP from working correctly on unnumbered bridge interfaces when bridging is enabled using the bridge.ko module. Basically, there are some checks in the ARP code that decide when to accept inbound ARP packets. These checks are a little different when the inbound interface is part of a bridge group. Some of these tests are conditional on the BRIDGE preprocessor symbol; this symbol gets defined if "options BRIDGE" is compiled into the kernel but not if you use the bridge.ko module. As a result, ARP packets on unnumbered interfaces get thrown away. The workaround for this problem is just to compile BRIDGE into the kernel. Manuel Kasper and I spent a few cycles working on this trying to make a m0n0wall box into a filtering bridge. For more specifics, see src/sys/netinet/if_ether.c (grep for BRIDGE in this file). Merry Christmas! Bruce. pgp0.pgp Description: PGP signature
Re: Assymetric results from iperf across gigabit link (long)
If memory serves me right, Mike Hunter wrote: > > I switched the two pieces of hardware, and the photons still prefer going > > uphill, so maybe there's a problem with the fiber after all. I'd still > > appreciate any hints on what to ask freebsd to help me figure it out. > > (Yes, we have real fiber test gear, this is more of an experiment.) > > Looks like it was a fiber problem. Go freebsd! Excellent. (Well, assuming that fixing / replacing the fiber is an option.) Personally, I liked my "reluctance to go to Sproul Hall" theory. :-) Bruce. pgp0.pgp Description: PGP signature
Re: Ask about AODV model in OPNET ?????????
On Wed, 2004-05-05 at 13:16, Ahmed Hamada wrote: [lines wrapped for readability] > I am student in facaulty of engineering. My undergraduate project > is "Mobile Ad Hoc Network". I read alot about it and now I want > to make some simulations to verify some points. I want to use > the OPNET in my simulations so I download the academic edition 9.1 > (the free version) but I found it (the academic edition) doesn't > support the ad hoc protocols. "" The other editions support it"" . This has nothing to do with FreeBSD networking, you'll have to ask elsewhere. Bruce. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
