Re: Understanding multiple IPv6 interfaces under 8.0 (fwd)
Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 décembre 2009 22:58, Dennis Glatting a écrit : > > > Elmer# netstat -rn > Routing tables > > > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS > lo0 => default fd7c:3f2b:e791:1::1 > UGSbce0 > ::1 ::1 UH > lo0 :::0.0.0.0/96 ::1 UGRS > lo0 fd7c:3f2b:e791:1::/64 link#1U > bce0 fd7c:3f2b:e791:1::ac13:a0alink#1UHS > lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2UHS > lo0 fe80::/10 ::1 UGRS > lo0 fe80::%bce0/64link#1U > bce0 fe80::213:72ff:fe60:ac52%bce0 link#1UHS > lo0 fe80::%bce1/64link#2U > bce1 fe80::213:72ff:fe60:ac50%bce1 link#2UHS > lo0 fe80::%lo0/64 link#3U > lo0 fe80::1%lo0 link#3UHS > lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U > bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > bce1 ff01:3::/32 ::1 U > lo0 ff02::/16 ::1 UGRS > lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U > bce0 ff02::%bce1/32fd7c:3f2b:e791:1:0:1:ac13:a0a U > bce1 ff02::%lo0/32 ::1 U > lo0 > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with "route add *your parameters*" or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. > > Elmer's rc.config: > > > ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" > ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" > ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu > 8192" > ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never used this myself so I can't really comment, and I can't say if there aren't any sort of "interferences" with what you're trying to do. > > > The router (cisco): > > > interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 > enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > Just a side-note, I'm not sure if it will be really useful to you, but you could give it a try if you want to. Have you tried using your Cisco router as a Router Advertisement Daemon ? That way, addresses would be built automatically and you could see how both interfaces react to such advertisements. I hope this helps. Aman Jassal Wisdom comes from experience. Experience comes from a lack of wisdom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: patch: ndisusb: show device description on attach
On Saturday 12 December 2009 13:18:53 Paul B Mahol wrote: > --- /sys/dev/if_ndis/if_ndis_usb.c 2009-11-25 21:49:03.0 + > +++ if_ndis_usb.c 2009-12-12 12:17:27.0 + > @@ -165,6 +165,7 @@ > driver_object *drv; > int devidx = 0; > > + device_set_usb_desc(self); > db = uaa->driver_ivar; > sc = (struct ndis_softc *)dummy; > sc->ndis_dev = self; The patch looks good. Just commit it! --HPS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/141414 net[vge] vge(4) problem on 8.0-RELEASE o kern/141376 net[ndis] [patch] fix broken scan by passing ies and ies_ o kern/141314 netNetwork Performance has decreased by 30% [regression] o kern/141285 net[em] hangs down/up intel nic during creating vlan o kern/141276 net[vge] Strange behavior with vge gigabit ethernet adapt o kern/141256 net[iwn] iwn(4) causes page fault on interface up o kern/141023 net[carp] CARP arp replays with wrong src mac o kern/140970 net[bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net[ath] [panic] privileged instruction fault o kern/140778 net[em] randomly panic in vlan/em o kern/140742 netrum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net[em] [patch] Fast irq registration in em driver o kern/140684 net[bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net[em] [patch] e1000 driver does not correctly handle mu o kern/140634 net[vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net[ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net[request] implement Lost Retransmission Detection o bin/140571 net[patch] ifconfig(8) does not set country DE o kern/140567 net[ath] [patch] ath is not worked on my notebook PC o kern/140564 net[wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net[wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net[em] em0: watchdog timeout when communicating to windo o kern/140245 net[ath] [panic] Kernel panic during network activity on o kern/140142 net[ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net[bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net[bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net[iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net[bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net[ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net[ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net[patch] arp(8) add option to remove static entries lis o kern/139268 net[if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net[arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net[fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net[lagg] + wlan boot timing (EBUSY) o kern/139079 net[wpi] Failure to attach wpi(4) o kern/139058 net[ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net[libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net[dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net[panic] sbflush_internal: cc 0 || mb 0xff004127b00 o kern/138739 net[wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net[bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net[rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net[lo] FreeBSD does not assign linklocal address to loop f kern/138666 net[multicast] [panic] not working multicast through igmp o kern/138660 net[igb] igb driver troubles in 8.0-BETA4 o kern/138652 netTCP window scaling value calculated incorrectly? o kern/138620 net[lagg] [patch] lagg port bpf-writes blocked o kern/138427 net[wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net[gre] gre(4) interface does not come up after reboot o kern/138332 net[tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net[panic] kernel panic when udp benchmark test used as r o kern/138177 net[ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net[tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net[netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net[patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net[sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net[rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net[netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 netifconfig(8): various problems with "vlan_device.vlan_i o k
Re: kern/141376: [ndis] [patch] fix broken scan by passing ies and ies_len pointer to net80211
Synopsis: [ndis] [patch] fix broken scan by passing ies and ies_len pointer to net80211 State-Changed-From-To: open->closed State-Changed-By: rpaulo State-Changed-When: Mon Dec 14 18:43:44 UTC 2009 State-Changed-Why: fixed, thanks http://www.freebsd.org/cgi/query-pr.cgi?pr=141376 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141376: commit references a PR
The following reply was made to PR kern/141376; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/141376: commit references a PR
Date: Mon, 14 Dec 2009 18:43:47 + (UTC)
Author: rpaulo
Date: Mon Dec 14 18:43:27 2009
New Revision: 200524
URL: http://svn.freebsd.org/changeset/base/200524
Log:
Pass all IEs to net80211.
PR: 141376
Submitted by:Paul
MFC after: 1 week
Modified:
head/sys/dev/if_ndis/if_ndis.c
Modified: head/sys/dev/if_ndis/if_ndis.c
==
--- head/sys/dev/if_ndis/if_ndis.c Mon Dec 14 18:43:18 2009
(r200523)
+++ head/sys/dev/if_ndis/if_ndis.c Mon Dec 14 18:43:27 2009
(r200524)
@@ -3299,24 +3299,11 @@ ndis_scan_results(struct ndis_softc *sc)
efrm = frm + wb->nwbx_ielen;
if (efrm - frm < 12)
goto done;
- sp.tstamp = frm;
- frm += 8;
- sp.bintval = le16toh(*(uint16_t *)frm);
- frm += 2;
- sp.capinfo = le16toh(*(uint16_t *)frm);
- frm += 2;
-
- /* Grab variable length ies */
- while (efrm - frm > 1) {
- if (efrm - frm < frm[1] + 2)
- break;
- switch (*frm) {
- case IEEE80211_ELEMID_RSN:
- sp.rsn = frm;
- break;
- }
- frm += frm[1] + 2;
- }
+ sp.tstamp = frm;frm += 8;
+ sp.bintval = le16toh(*(uint16_t *)frm); frm += 2;
+ sp.capinfo = le16toh(*(uint16_t *)frm); frm += 2;
+ sp.ies = frm;
+ sp.ies_len = efrm - frm;
}
done:
DPRINTF(("scan: bssid %s chan %dMHz (%d/%d) rssi %d\n",
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
I will take a look at it later today. -- Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Dennis Glatting > Sent: Sunday, December 13, 2009 1:59 PM > To: freebsd-net@freebsd.org > Subject: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > I am having a problem diagnosing a multiple IPv6 interfaces problem. > Any > hint is appreciated. > > OS: > > Elmer# uname -a FreeBSD Elmer 8.0-STABLE FreeBSD 8.0-STABLE #94: Fri > Dec 11 > 17:24:09 MST 2009 r...@elmer:/usr/src/sys/amd64/compile/ELMER amd64 > > > I have two interfaces on the same switch fabric. They both reside > within > the same prefix. One is IPv4/IPv6 and the other strictly IPv6. The > purpose > of these two interfaces is the "normal" stuff and a "bulk data net." > The > bulk data net is merely an Ethernet intreface with a larger MTU to aid > back-up (incoming data) and otehr tasks. The interfaces are defiend as > follows: > > Elmer# ifconfig -a > bce0: flags=8843 metric 0 mtu > 1500 > > options=1bb ,TSO4> > ether 00:13:72:60:ac:52 > inet 172.19.10.10 netmask 0xff00 broadcast 172.19.10.255 > inet6 fe80::213:72ff:fe60:ac52%bce0 prefixlen 64 scopeid 0x1 > inet6 fd7c:3f2b:e791:1::ac13:a0a prefixlen 64 > nd6 options=3 > media: Ethernet 1000baseT > status: active > bce1: flags=8843 metric 0 mtu > 8192 > > options=1bb ,TSO4> > ether 00:13:72:60:ac:50 > inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a prefixlen 64 > inet6 fe80::213:72ff:fe60:ac50%bce1 prefixlen 64 scopeid 0x2 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff00 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > nd6 options=3 > > Bce1 is the bulk data net. I can ping6 a host out the bce0 interface > and > get a response. However, though I can send ping6 packets out bce1 to > the > same host, that host cannot discover the MAC for bce1. For example: > > Elmer# ping6 -S fd7c:3f2b:e791:1::ac13:a0a docs.penx.com > PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1::ac13:a0a --> > fd7c:3f2b:e791:1::ac13:a15 > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=0 hlim=64 time=0.301 > ms > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=1 hlim=64 time=0.224 > ms > > Elmer# ping6 -S fd7c:3f2b:e791:1:0:1:ac13:a0a docs.penx.com > PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > fd7c:3f2b:e791:1::ac13:a15 > > (nothing returned). > > > Docs# tcpdump -n -q ip6 and not tcp and not udp > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > 13:11:05.557252 IP6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > fd7c:3f2b:e791:1::ac13:a15: ICMP6, echo request, seq 55, length 16 > 13:11:05.557275 IP6 fd7c:3f2b:e791:1::ac13:a15 > ff02::1:ff13:a0a: > ICMP6, neighbor solicitation, who has fd7c:3f2b:e791:1:0:1:ac13:a0a, > length 32 > > (and so on) > > Note: Docs: > bge0: flags=8843 metric 0 mtu > 1500 > options=9b > ether 00:11:85:ee:02:54 > inet 172.19.10.21 netmask 0xff00 broadcast 172.19.10.255 > inet6 fe80::211:85ff:feee:254%bge0 prefixlen 64 scopeid 0x1 > inet6 fd7c:3f2b:e791:1::ac13:a15 prefixlen 64 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > > > If I watch the bce1 interface on Elmer using TCPdump in another window > session, it is seeing the solicitation, at least via tcpdump; but no > response as to who has fd7c:3f2b:e791:1:0:1:ac13:a0a. > > I've included other data below. I am at a loss to understand why the > bce1 > interface isn't being advertised on the fabric. I am an IPv6 newbie. I > have a router on the network. > > > Elmer# ndp -an > Neighbor Linklayer Address Netif Expire > S Flags > fe80::213:72ff:fe60:ac50%bce10:13:72:60:ac:50bce1 permanent > R > fd7c:3f2b:e791:1:0:1:ac13:a0a0:13:72:60:ac:50bce1 permanent > R > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bce0 12s > R > fe80::213:72ff:fe60:ac52%bce00:13:72:60:ac:52bce0 permanent > R > fd7c:3f2b:e791:1::1 0:17:95:25:5c:90bce0 23h58m20s > S R > fe80::217:95ff:fe25:5c90%bce00:17:95:25:5c:90bce0 23h59m22s > S R > fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52bce0 permanent > R > > > Docs# ndp -an > Neighbor Linklayer Address Netif Expire > S Flags > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bge0 permanent > R > fd7c:3f2b:e791:1::1 0:17:95:25:5c:90bge0 2s > D R > fe80::211:85ff:feee:254%bge0 0:11:85:ee:2:54 bge0 permanent > R > fe80::217:95ff:fe25:5c90%bge00:17:95:25:5c
Re: kern/139079: commit references a PR
The following reply was made to PR kern/139079; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/139079: commit references a PR
Date: Mon, 14 Dec 2009 19:18:15 + (UTC)
Author: gavin
Date: Mon Dec 14 19:18:02 2009
New Revision: 200530
URL: http://svn.freebsd.org/changeset/base/200530
Log:
Don't panic on failure to attach if we fail before or during the
if_alloc() of ifp. This fixes the panic reported in the PR, but
not the attach failure.
PR: kern/139079
Tested by: Steven Noonan
Reviewed by: thompsa
Approved by: ed (mentor)
MFC after: 2 weeks`
Modified:
head/sys/dev/wpi/if_wpi.c
Modified: head/sys/dev/wpi/if_wpi.c
==
--- head/sys/dev/wpi/if_wpi.c Mon Dec 14 19:08:11 2009(r200529)
+++ head/sys/dev/wpi/if_wpi.c Mon Dec 14 19:18:02 2009(r200530)
@@ -713,13 +713,14 @@ wpi_detach(device_t dev)
{
struct wpi_softc *sc = device_get_softc(dev);
struct ifnet *ifp = sc->sc_ifp;
- struct ieee80211com *ic = ifp->if_l2com;
+ struct ieee80211com *ic;
int ac;
- ieee80211_draintask(ic, &sc->sc_restarttask);
- ieee80211_draintask(ic, &sc->sc_radiotask);
-
if (ifp != NULL) {
+ ic = ifp->if_l2com;
+
+ ieee80211_draintask(ic, &sc->sc_restarttask);
+ ieee80211_draintask(ic, &sc->sc_radiotask);
wpi_stop(sc);
callout_drain(&sc->watchdog_to);
callout_drain(&sc->calib_to);
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Not seeing data on an unnumbered interface...
All, I'm having a very strange problem. I'm running ntop - the unnumbered interface is not receiving any data. Running 'tcpdump -i em0' also gets no data. I am really baffled - I've tried it against a switch that I know has a correctly configured mirror port, as I have ntop running on another machine and that works fine in the same port, but it's running 7.1-RELEASE. Anyone have thoughts on this? # uname -a FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # cat /etc/rc.conf hostname="zntop.mycompany.com" ifconfig_rl0="DHCP" ntpdate_enable="YES" ntpdate_flags="-b 192.168.10.191" sshd_enable="YES" ntop_enable="YES" ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" zntop# ifconfig em0: flags=8902 metric 0 mtu 1500 options=9b ether 00:1b:21:04:2a:c5 media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0c:46:b3:43:53 inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 Kurt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
Not familiar with ntop, but I notice below that the em interface is not UP, what if you `ifup em0` ? Jack On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: > All, > > I'm having a very strange problem. I'm running ntop - the unnumbered > interface is not receiving any data. > > Running 'tcpdump -i em0' also gets no data. I am really baffled - I've > tried it against a switch that I know has a correctly configured > mirror port, as I have ntop running on another machine and that works > fine in the same port, but it's running 7.1-RELEASE. > > Anyone have thoughts on this? > > > # uname -a > FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat > Nov 21 15:48:17 UTC 2009 > r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > # cat /etc/rc.conf > hostname="zntop.mycompany.com" > ifconfig_rl0="DHCP" > ntpdate_enable="YES" > ntpdate_flags="-b 192.168.10.191" > sshd_enable="YES" > ntop_enable="YES" > ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" > > zntop# ifconfig > em0: flags=8902 metric 0 mtu 1500 >options=9b >ether 00:1b:21:04:2a:c5 >media: Ethernet autoselect (100baseTX ) >status: active > rl0: flags=8843 metric 0 mtu 1500 >options=8 >ether 00:0c:46:b3:43:53 >inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 >media: Ethernet autoselect (100baseTX ) >status: active > lo0: flags=8049 metric 0 mtu 16384 >options=3 >inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >inet6 ::1 prefixlen 128 >inet 127.0.0.1 netmask 0xff00 > > > Kurt > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
Sigh. Yes, that works. So, to expose even more of my ignorance, any thoughts on why it isn't up at boot? Kurt On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: > Not familiar with ntop, but I notice below that the em interface is not UP, > what > if you `ifup em0` ? > > Jack > > > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: >> >> All, >> >> I'm having a very strange problem. I'm running ntop - the unnumbered >> interface is not receiving any data. >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've >> tried it against a switch that I know has a correctly configured >> mirror port, as I have ntop running on another machine and that works >> fine in the same port, but it's running 7.1-RELEASE. >> >> Anyone have thoughts on this? >> >> >> # uname -a >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >> Nov 21 15:48:17 UTC 2009 >> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> # cat /etc/rc.conf >> hostname="zntop.mycompany.com" >> ifconfig_rl0="DHCP" >> ntpdate_enable="YES" >> ntpdate_flags="-b 192.168.10.191" >> sshd_enable="YES" >> ntop_enable="YES" >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" >> >> zntop# ifconfig >> em0: flags=8902 metric 0 mtu 1500 >> options=9b >> ether 00:1b:21:04:2a:c5 >> media: Ethernet autoselect (100baseTX ) >> status: active >> rl0: flags=8843 metric 0 mtu 1500 >> options=8 >> ether 00:0c:46:b3:43:53 >> inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> options=3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff00 >> >> >> Kurt >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Running rtadvd or DHCPv6 server via if_bridge interface
On 12/10/2009 10:51 PM, Chris Cowart wrote: > Bruce Cran wrote: >> I have a router configured using if_bridge with a 4-port NIC that's >> serving addresses over DHCP. I'd like to add in either rtadvd or >> DHCPv6, but neither work because the bridge interface doesn't have an >> IPv6 link-local address. Is there a way around this, or is it not >> possible to serve IPv6 addresses over if_bridge interfaces? > > It's totally doable; you just have to assigned a link-local address to > the bridge. There are some reasons why one isn't defined by default, > which somebody more knowledgeable about the challenges in the > implementation can highlight. > > Here's my configuration from rc.conf: > > ipv6_ifconfig_bridge0="2001:470:8337:10::1/64" > ipv6_ifconfig_bridge0_alias0="fe80::2%bridge0 prefixlen 64" > > Once you're doing that, rtadvd will start doing the right thing. My workaround was to enumerate each bridge member in rc.conf: rtadvd_interfaces="vlan1 wlan0" -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: Not seeing data on an unnumbered interface...
Usually assigning an address will bring it up, but you arent doing that, I am pretty sure using a pseudo device will always necessitating explicitly bringing it up, at least i know that is the case for VLANs also. Jack On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: > Sigh. Yes, that works. > > So, to expose even more of my ignorance, any thoughts on why it isn't > up at boot? > > Kurt > > On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: > > Not familiar with ntop, but I notice below that the em interface is not > UP, > > what > > if you `ifup em0` ? > > > > Jack > > > > > > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: > >> > >> All, > >> > >> I'm having a very strange problem. I'm running ntop - the unnumbered > >> interface is not receiving any data. > >> > >> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've > >> tried it against a switch that I know has a correctly configured > >> mirror port, as I have ntop running on another machine and that works > >> fine in the same port, but it's running 7.1-RELEASE. > >> > >> Anyone have thoughts on this? > >> > >> > >> # uname -a > >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat > >> Nov 21 15:48:17 UTC 2009 > >> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > >> > >> # cat /etc/rc.conf > >> hostname="zntop.mycompany.com" > >> ifconfig_rl0="DHCP" > >> ntpdate_enable="YES" > >> ntpdate_flags="-b 192.168.10.191" > >> sshd_enable="YES" > >> ntop_enable="YES" > >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W > 0" > >> > >> zntop# ifconfig > >> em0: flags=8902 metric 0 mtu 1500 > >>options=9b > >>ether 00:1b:21:04:2a:c5 > >>media: Ethernet autoselect (100baseTX ) > >>status: active > >> rl0: flags=8843 metric 0 mtu > 1500 > >>options=8 > >>ether 00:0c:46:b3:43:53 > >>inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 > >>media: Ethernet autoselect (100baseTX ) > >>status: active > >> lo0: flags=8049 metric 0 mtu 16384 > >>options=3 > >>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > >>inet6 ::1 prefixlen 128 > >>inet 127.0.0.1 netmask 0xff00 > >> > >> > >> Kurt > >> ___ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
Interesting. I'm doing nothing really very different on my 7.1R box, but don't have this issue. Oh, well - just something to keep in mind, I suppose. Kurt On Mon, Dec 14, 2009 at 11:48, Jack Vogel wrote: > Usually assigning an address will bring it up, but you arent doing that, I > am > pretty sure using a pseudo device will always necessitating explicitly > bringing > it up, at least i know that is the case for VLANs also. > > Jack > > > On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: >> >> Sigh. Yes, that works. >> >> So, to expose even more of my ignorance, any thoughts on why it isn't >> up at boot? >> >> Kurt >> >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >> > Not familiar with ntop, but I notice below that the em interface is not >> > UP, >> > what >> > if you `ifup em0` ? >> > >> > Jack >> > >> > >> > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: >> >> >> >> All, >> >> >> >> I'm having a very strange problem. I'm running ntop - the unnumbered >> >> interface is not receiving any data. >> >> >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've >> >> tried it against a switch that I know has a correctly configured >> >> mirror port, as I have ntop running on another machine and that works >> >> fine in the same port, but it's running 7.1-RELEASE. >> >> >> >> Anyone have thoughts on this? >> >> >> >> >> >> # uname -a >> >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >> >> Nov 21 15:48:17 UTC 2009 >> >> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> >> >> # cat /etc/rc.conf >> >> hostname="zntop.mycompany.com" >> >> ifconfig_rl0="DHCP" >> >> ntpdate_enable="YES" >> >> ntpdate_flags="-b 192.168.10.191" >> >> sshd_enable="YES" >> >> ntop_enable="YES" >> >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W >> >> 0" >> >> >> >> zntop# ifconfig >> >> em0: flags=8902 metric 0 mtu 1500 >> >> options=9b >> >> ether 00:1b:21:04:2a:c5 >> >> media: Ethernet autoselect (100baseTX ) >> >> status: active >> >> rl0: flags=8843 metric 0 mtu >> >> 1500 >> >> options=8 >> >> ether 00:0c:46:b3:43:53 >> >> inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 >> >> media: Ethernet autoselect (100baseTX ) >> >> status: active >> >> lo0: flags=8049 metric 0 mtu 16384 >> >> options=3 >> >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> >> inet6 ::1 prefixlen 128 >> >> inet 127.0.0.1 netmask 0xff00 >> >> >> >> >> >> Kurt >> >> ___ >> >> freebsd-net@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > >> > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
Hmmm, well there's a LOT of shared code changes between 7.1 and 8, and this sounds like something in the device init. I don't really have time to look into the difference right now, you'll just have to live with the difference, sorry :) Jack On Mon, Dec 14, 2009 at 11:52 AM, Kurt Buff wrote: > Interesting. > > I'm doing nothing really very different on my 7.1R box, but don't have > this issue. > > Oh, well - just something to keep in mind, I suppose. > > Kurt > > On Mon, Dec 14, 2009 at 11:48, Jack Vogel wrote: > > Usually assigning an address will bring it up, but you arent doing that, > I > > am > > pretty sure using a pseudo device will always necessitating explicitly > > bringing > > it up, at least i know that is the case for VLANs also. > > > > Jack > > > > > > On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: > >> > >> Sigh. Yes, that works. > >> > >> So, to expose even more of my ignorance, any thoughts on why it isn't > >> up at boot? > >> > >> Kurt > >> > >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: > >> > Not familiar with ntop, but I notice below that the em interface is > not > >> > UP, > >> > what > >> > if you `ifup em0` ? > >> > > >> > Jack > >> > > >> > > >> > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff > wrote: > >> >> > >> >> All, > >> >> > >> >> I'm having a very strange problem. I'm running ntop - the unnumbered > >> >> interface is not receiving any data. > >> >> > >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - > I've > >> >> tried it against a switch that I know has a correctly configured > >> >> mirror port, as I have ntop running on another machine and that works > >> >> fine in the same port, but it's running 7.1-RELEASE. > >> >> > >> >> Anyone have thoughts on this? > >> >> > >> >> > >> >> # uname -a > >> >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat > >> >> Nov 21 15:48:17 UTC 2009 > >> >> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > >> >> > >> >> # cat /etc/rc.conf > >> >> hostname="zntop.mycompany.com" > >> >> ifconfig_rl0="DHCP" > >> >> ntpdate_enable="YES" > >> >> ntpdate_flags="-b 192.168.10.191" > >> >> sshd_enable="YES" > >> >> ntop_enable="YES" > >> >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 > -W > >> >> 0" > >> >> > >> >> zntop# ifconfig > >> >> em0: flags=8902 metric 0 mtu > 1500 > >> >>options=9b > >> >>ether 00:1b:21:04:2a:c5 > >> >>media: Ethernet autoselect (100baseTX ) > >> >>status: active > >> >> rl0: flags=8843 metric 0 mtu > >> >> 1500 > >> >>options=8 > >> >>ether 00:0c:46:b3:43:53 > >> >>inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 > >> >>media: Ethernet autoselect (100baseTX ) > >> >>status: active > >> >> lo0: flags=8049 metric 0 mtu 16384 > >> >>options=3 > >> >>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > >> >>inet6 ::1 prefixlen 128 > >> >>inet 127.0.0.1 netmask 0xff00 > >> >> > >> >> > >> >> Kurt > >> >> ___ > >> >> freebsd-net@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> >> To unsubscribe, send any mail to " > freebsd-net-unsubscr...@freebsd.org" > >> > > >> > > > > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
Heh. Not a problem. Kurt On Mon, Dec 14, 2009 at 11:57, Jack Vogel wrote: > Hmmm, well there's a LOT of shared code changes between 7.1 and 8, and this > sounds like something in the device init. I don't really have time to look > into the > difference right now, you'll just have to live with the difference, sorry > :) > > Jack > > > On Mon, Dec 14, 2009 at 11:52 AM, Kurt Buff wrote: >> >> Interesting. >> >> I'm doing nothing really very different on my 7.1R box, but don't have >> this issue. >> >> Oh, well - just something to keep in mind, I suppose. >> >> Kurt >> >> On Mon, Dec 14, 2009 at 11:48, Jack Vogel wrote: >> > Usually assigning an address will bring it up, but you arent doing that, >> > I >> > am >> > pretty sure using a pseudo device will always necessitating explicitly >> > bringing >> > it up, at least i know that is the case for VLANs also. >> > >> > Jack >> > >> > >> > On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: >> >> >> >> Sigh. Yes, that works. >> >> >> >> So, to expose even more of my ignorance, any thoughts on why it isn't >> >> up at boot? >> >> >> >> Kurt >> >> >> >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >> >> > Not familiar with ntop, but I notice below that the em interface is >> >> > not >> >> > UP, >> >> > what >> >> > if you `ifup em0` ? >> >> > >> >> > Jack >> >> > >> >> > >> >> > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff >> >> > wrote: >> >> >> >> >> >> All, >> >> >> >> >> >> I'm having a very strange problem. I'm running ntop - the unnumbered >> >> >> interface is not receiving any data. >> >> >> >> >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - >> >> >> I've >> >> >> tried it against a switch that I know has a correctly configured >> >> >> mirror port, as I have ntop running on another machine and that >> >> >> works >> >> >> fine in the same port, but it's running 7.1-RELEASE. >> >> >> >> >> >> Anyone have thoughts on this? >> >> >> >> >> >> >> >> >> # uname -a >> >> >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >> >> >> Nov 21 15:48:17 UTC 2009 >> >> >> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> >> >> >> >> # cat /etc/rc.conf >> >> >> hostname="zntop.mycompany.com" >> >> >> ifconfig_rl0="DHCP" >> >> >> ntpdate_enable="YES" >> >> >> ntpdate_flags="-b 192.168.10.191" >> >> >> sshd_enable="YES" >> >> >> ntop_enable="YES" >> >> >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 >> >> >> -W >> >> >> 0" >> >> >> >> >> >> zntop# ifconfig >> >> >> em0: flags=8902 metric 0 mtu >> >> >> 1500 >> >> >> options=9b >> >> >> ether 00:1b:21:04:2a:c5 >> >> >> media: Ethernet autoselect (100baseTX ) >> >> >> status: active >> >> >> rl0: flags=8843 metric 0 mtu >> >> >> 1500 >> >> >> options=8 >> >> >> ether 00:0c:46:b3:43:53 >> >> >> inet 192.168.24.51 netmask 0xff00 broadcast >> >> >> 192.168.24.255 >> >> >> media: Ethernet autoselect (100baseTX ) >> >> >> status: active >> >> >> lo0: flags=8049 metric 0 mtu 16384 >> >> >> options=3 >> >> >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> >> >> inet6 ::1 prefixlen 128 >> >> >> inet 127.0.0.1 netmask 0xff00 >> >> >> >> >> >> >> >> >> Kurt >> >> >> ___ >> >> >> freebsd-net@freebsd.org mailing list >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> >> To unsubscribe, send any mail to >> >> >> "freebsd-net-unsubscr...@freebsd.org" >> >> > >> >> > >> > >> > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Buff wrote: > Sigh. Yes, that works. > > So, to expose even more of my ignorance, any thoughts on why it isn't > up at boot? > /etc/rc.conf: ifconfig_em0="UP" > Kurt > > On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >> Not familiar with ntop, but I notice below that the em interface is not UP, >> what >> if you `ifup em0` ? >> >> Jack >> >> >> On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: >>> All, >>> >>> I'm having a very strange problem. I'm running ntop - the unnumbered >>> interface is not receiving any data. >>> >>> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've >>> tried it against a switch that I know has a correctly configured >>> mirror port, as I have ntop running on another machine and that works >>> fine in the same port, but it's running 7.1-RELEASE. >>> >>> Anyone have thoughts on this? >>> >>> >>> # uname -a >>> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >>> Nov 21 15:48:17 UTC 2009 >>> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> # cat /etc/rc.conf >>> hostname="zntop.mycompany.com" >>> ifconfig_rl0="DHCP" >>> ntpdate_enable="YES" >>> ntpdate_flags="-b 192.168.10.191" >>> sshd_enable="YES" >>> ntop_enable="YES" >>> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" >>> >>> zntop# ifconfig >>> em0: flags=8902 metric 0 mtu 1500 >>>options=9b >>>ether 00:1b:21:04:2a:c5 >>>media: Ethernet autoselect (100baseTX ) >>>status: active >>> rl0: flags=8843 metric 0 mtu 1500 >>>options=8 >>>ether 00:0c:46:b3:43:53 >>>inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 >>>media: Ethernet autoselect (100baseTX ) >>>status: active >>> lo0: flags=8049 metric 0 mtu 16384 >>>options=3 >>>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>>inet6 ::1 prefixlen 128 >>>inet 127.0.0.1 netmask 0xff00 >>> >>> >>> Kurt >>> ___ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" - -- TJU13-ARIN -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJp0eAAoJEMSwVS7lr0OdTRcIAIoEqsw+3Va6QSRDsCpOyVZY q/QdmlMQ9hLV5KM9VakXxQAyaLSAzqmF9l3YdAtfoDsTdOwVzzi+XpVIQa4pxRLE a8XWjkIc8xXHXwq30tqJa75EZuExhvGjZqaB8nhMEpvTWodYF1OcoP8OfaXHc9ZO RsC9jl6pIRbcR83AsTH+ZK8g2hzKvNEDT1Uw9/RfK7X/Fa3Jzkdb2041fIzQEsel 4FCuNGUbmu2noDGPN06zMCGUCLwukWzuAq13DuzX+1B4UgrJf4fVfDuESA3SWlr3 kvCZllDIWmcfsKnaUmkQ80qRVJws0hjZAfjHWYk6tHFIMzxVp5MOx+Lyumq6WEQ= =aTAi -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Not seeing data on an unnumbered interface...
Oh, good grief. That's way too easy. How can I be l33t if it's that simple? Thanks. Kurt On Mon, Dec 14, 2009 at 12:16, Tom Judge wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kurt Buff wrote: >> Sigh. Yes, that works. >> >> So, to expose even more of my ignorance, any thoughts on why it isn't >> up at boot? >> > > /etc/rc.conf: > > ifconfig_em0="UP" > > > > >> Kurt >> >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >>> Not familiar with ntop, but I notice below that the em interface is not UP, >>> what >>> if you `ifup em0` ? >>> >>> Jack >>> >>> >>> On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: All, I'm having a very strange problem. I'm running ntop - the unnumbered interface is not receiving any data. Running 'tcpdump -i em0' also gets no data. I am really baffled - I've tried it against a switch that I know has a correctly configured mirror port, as I have ntop running on another machine and that works fine in the same port, but it's running 7.1-RELEASE. Anyone have thoughts on this? # uname -a FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # cat /etc/rc.conf hostname="zntop.mycompany.com" ifconfig_rl0="DHCP" ntpdate_enable="YES" ntpdate_flags="-b 192.168.10.191" sshd_enable="YES" ntop_enable="YES" ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" zntop# ifconfig em0: flags=8902 metric 0 mtu 1500 options=9b ether 00:1b:21:04:2a:c5 media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0c:46:b3:43:53 inet 192.168.24.51 netmask 0xff00 broadcast 192.168.24.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 Kurt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > - -- > TJU13-ARIN > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.13 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJLJp0eAAoJEMSwVS7lr0OdTRcIAIoEqsw+3Va6QSRDsCpOyVZY > q/QdmlMQ9hLV5KM9VakXxQAyaLSAzqmF9l3YdAtfoDsTdOwVzzi+XpVIQa4pxRLE > a8XWjkIc8xXHXwq30tqJa75EZuExhvGjZqaB8nhMEpvTWodYF1OcoP8OfaXHc9ZO > RsC9jl6pIRbcR83AsTH+ZK8g2hzKvNEDT1Uw9/RfK7X/Fa3Jzkdb2041fIzQEsel > 4FCuNGUbmu2noDGPN06zMCGUCLwukWzuAq13DuzX+1B4UgrJf4fVfDuESA3SWlr3 > kvCZllDIWmcfsKnaUmkQ80qRVJws0hjZAfjHWYk6tHFIMzxVp5MOx+Lyumq6WEQ= > =aTAi > -END PGP SIGNATURE- > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0)
Any idea how to debug problem mentioned in the subject line? Command used to load stock driver: kldload if_cxgb.ko Thanks, Jack Goral CONFIDENTIALITY WARNING: This email including any attachments may contain privileged or confidential information and is for the sole use of the intended recipient(s). Any unauthorized use or disclosure of this communication is prohibited. This e-mail may also be subject to specific non-disclosure and confidentiality provisions. The information contained herein is the property of Chopper Trading, LLC. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
Please try the temporary patch at: http://people.freebsd.org/~qingli/nd6-ns.diff and it should fix your problem. -- Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, December 14, 2009 10:59 AM > To: Dennis Glatting; freebsd-net@freebsd.org > Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > I will take a look at it later today. > > -- Qing > > > > -Original Message- > > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > > n...@freebsd.org] On Behalf Of Dennis Glatting > > Sent: Sunday, December 13, 2009 1:59 PM > > To: freebsd-net@freebsd.org > > Subject: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > > > > I am having a problem diagnosing a multiple IPv6 interfaces problem. > > Any > > hint is appreciated. > > > > OS: > > > > Elmer# uname -a FreeBSD Elmer 8.0-STABLE FreeBSD 8.0-STABLE #94: Fri > > Dec 11 > > 17:24:09 MST 2009 r...@elmer:/usr/src/sys/amd64/compile/ELMER amd64 > > > > > > I have two interfaces on the same switch fabric. They both reside > > within > > the same prefix. One is IPv4/IPv6 and the other strictly IPv6. The > > purpose > > of these two interfaces is the "normal" stuff and a "bulk data net." > > The > > bulk data net is merely an Ethernet intreface with a larger MTU to > aid > > back-up (incoming data) and otehr tasks. The interfaces are defiend > as > > follows: > > > > Elmer# ifconfig -a > > bce0: flags=8843 metric 0 mtu > > 1500 > > > > > options=1bb > ,TSO4> > > ether 00:13:72:60:ac:52 > > inet 172.19.10.10 netmask 0xff00 broadcast 172.19.10.255 > > inet6 fe80::213:72ff:fe60:ac52%bce0 prefixlen 64 scopeid 0x1 > > inet6 fd7c:3f2b:e791:1::ac13:a0a prefixlen 64 > > nd6 options=3 > > media: Ethernet 1000baseT > > status: active > > bce1: flags=8843 metric 0 mtu > > 8192 > > > > > options=1bb > ,TSO4> > > ether 00:13:72:60:ac:50 > > inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a prefixlen 64 > > inet6 fe80::213:72ff:fe60:ac50%bce1 prefixlen 64 scopeid 0x2 > > nd6 options=3 > > media: Ethernet autoselect (1000baseT ) > > status: active > > lo0: flags=8049 metric 0 mtu 16384 > > options=3 > > inet 127.0.0.1 netmask 0xff00 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > nd6 options=3 > > > > Bce1 is the bulk data net. I can ping6 a host out the bce0 interface > > and > > get a response. However, though I can send ping6 packets out bce1 to > > the > > same host, that host cannot discover the MAC for bce1. For example: > > > > Elmer# ping6 -S fd7c:3f2b:e791:1::ac13:a0a docs.penx.com > > PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1::ac13:a0a --> > > fd7c:3f2b:e791:1::ac13:a15 > > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=0 hlim=64 > time=0.301 > > ms > > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=1 hlim=64 > time=0.224 > > ms > > > > Elmer# ping6 -S fd7c:3f2b:e791:1:0:1:ac13:a0a docs.penx.com > > PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > > fd7c:3f2b:e791:1::ac13:a15 > > > > (nothing returned). > > > > > > Docs# tcpdump -n -q ip6 and not tcp and not udp > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode > > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > > 13:11:05.557252 IP6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > > fd7c:3f2b:e791:1::ac13:a15: ICMP6, echo request, seq 55, length 16 > > 13:11:05.557275 IP6 fd7c:3f2b:e791:1::ac13:a15 > ff02::1:ff13:a0a: > > ICMP6, neighbor solicitation, who has fd7c:3f2b:e791:1:0:1:ac13:a0a, > > length 32 > > > > (and so on) > > > > Note: Docs: > > bge0: flags=8843 metric 0 mtu > > 1500 > > options=9b > > ether 00:11:85:ee:02:54 > > inet 172.19.10.21 netmask 0xff00 broadcast 172.19.10.255 > > inet6 fe80::211:85ff:feee:254%bge0 prefixlen 64 scopeid 0x1 > > inet6 fd7c:3f2b:e791:1::ac13:a15 prefixlen 64 > > nd6 options=3 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > > > If I watch the bce1 interface on Elmer using TCPdump in another > window > > session, it is seeing the solicitation, at least via tcpdump; but no > > response as to who has fd7c:3f2b:e791:1:0:1:ac13:a0a. > > > > I've included other data below. I am at a loss to understand why the > > bce1 > > interface isn't being advertised on the fabric. I am an IPv6 newbie. > I > > have a router on the network. > > > > > > Elmer# ndp -an > > Neighbor Linklayer Address Netif Expire > > S Flags > > fe80::213:72ff:fe60:ac50%bce10:13:72:60:ac:50bce1 > permanent > > R > > fd7c:3f2b:e791:1:0:1:ac13:a0a0:13:72:60:ac:50bce1 > permanent > > R > > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bce0 12s > > R > > fe80::213:72ff:fe6
RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
> > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > expecting bce1 rather than lo0, I suppose you were as well :) > This loopback route is necessary for short circuiting traffic to local address within a node. -- Qing > > If I'm not mistaken, the packets emanating from bce1 go to the loopback > interface, thus not really going out. You can try specifying the route > manually with "route add *your parameters*" or even set it in > /etc/rc.conf > so that it's loaded at boot-time. There's no reason why among 2 > physical > interfaces sharing the same fabric, one can ship packets out and the > other > can't. > > > > > Elmer's rc.config: > > > > > > ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" > > ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" > > ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 > mtu > > 8192" > > ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" > > > > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never > used > this myself so I can't really comment, and I can't say if there aren't > any > sort of "interferences" with what you're trying to do. > > > > > > > The router (cisco): > > > > > > interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 > > enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > > > > Just a side-note, I'm not sure if it will be really useful to you, but > you > could give it a try if you want to. Have you tried using your Cisco > router > as a Router Advertisement Daemon ? That way, addresses would be built > automatically and you could see how both interfaces react to such > advertisements. > > I hope this helps. > > > Aman Jassal > > Wisdom comes from experience. > Experience comes from a lack of wisdom. > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Understanding multiple IPv6 interfaces under 8.0 (fwd)
Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1UHS lo0 fe80::%bce1/64link#2U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2UHS lo0 fe80::%lo0/64 link#3U lo0 fe80::1%lo0 link#3UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with "route add *your parameters*" or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 Elmer# netstat -rn (snip) fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHSbce1 I don't think that is what I want. WHat I think I just said is "host X" is out that door, rather than route net. If, however, I say Docs is out that door, I get: Elmer# route add -inet6 docs.dco.penx.com -iface bce1 add host docs.dco.penx.com: gateway bce1 Elmer# ping6 docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 ping6: sendmsg: Operation not permitted ping6: wrote docs.dco.penx.com 16 chars, ret=-1 Elmer's rc.config: ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu 8192" ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never used this myself so I can't really comment, and I can't say if there aren't any sort of "interferences" with what you're trying to do. I hope what I am specifying is to use the 32 bit IPv4 address as the last 32 bits of the IPv6 address, at least that is how it works out numerically. My numbering scheme for fixed assets is the last 32 bits of the 128 bit IPv6 address is the same as its IPv4 address. The router (cisco): interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) Just a side-note, I'm not sure if it will be really useful to you, but you could give it a try if you want to. Have you tried using your Cisco router as a Router Advertisement Daemon ? That way, addresses would be built automatically and you could see how both interfaces react to such advert
Re: Understanding multiple IPv6 interfaces under 8.0 (fwd)
On Mon, 14 Dec 2009, Tom Pusateri wrote: Does netstat -s show any "bad neighbor solicitation messages" or any other ip6 or icmp6 errors? Yes: Elmer# netstat -s| grep "bad neighbor solicitation" 270 bad neighbor solicitation messages I'm seeing that and though my symptoms may be different, I thought maybe the root cause is the same. Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter
Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 State-Changed-Why: I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141414: [vge] vge(4) problem on 8.0-RELEASE
Synopsis: [vge] vge(4) problem on 8.0-RELEASE State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Dec 14 22:40:55 UTC 2009 State-Changed-Why: I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? You can download the following latest vge(4) files from HEAD and it should build on 8.0-RELEASE. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Dec 14 22:40:55 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=141414 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0)
On Mon, Dec 14, 2009 at 1:30 PM, Jack Goral wrote: > > Any idea how to debug problem mentioned in the subject line? This card is supported in 8-STABLE (r199206 or later). Looks like you're running 8.0 release. You can grab cxgb(4) code from stable and build + run it on your system. Regards, Navdeep > > Command used to load stock driver: > kldload if_cxgb.ko > > Thanks, > Jack Goral > > > > CONFIDENTIALITY WARNING: This email including any attachments may contain > privileged or confidential information and is for the sole use of the > intended recipient(s). Any unauthorized use or disclosure of this > communication is prohibited. This e-mail may also be subject to specific > non-disclosure and confidentiality provisions. The information contained > herein is the property of Chopper Trading, LLC. If you believe that you have > received this email in error, please notify the sender immediately and delete > it from your system. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: > Hello Mr.Glatting, > > Not that I'm an IPv6 genius, but at first sight your problem seems to be a > route-related. I've put comments in-line. > > > Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >> >> >> Elmer# netstat -rn >> Routing tables >> >> >> Internet6: >> Destination Gateway Flags >> Netif Expire >> ::/96 ::1 UGRS >> lo0 => default fd7c:3f2b:e791:1::1 >> UGSbce0 >> ::1 ::1 UH >> lo0 :::0.0.0.0/96 ::1 UGRS >> lo0 fd7c:3f2b:e791:1::/64 link#1U >> bce0 fd7c:3f2b:e791:1::ac13:a0alink#1UHS >> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2UHS >> lo0 fe80::/10 ::1 UGRS >> lo0 fe80::%bce0/64link#1U >> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1UHS >> lo0 fe80::%bce1/64link#2U >> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2UHS >> lo0 fe80::%lo0/64 link#3U >> lo0 fe80::1%lo0 link#3UHS >> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U >> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >> bce1 ff01:3::/32 ::1 U >> lo0 ff02::/16 ::1 UGRS >> lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U >> bce0 ff02::%bce1/32fd7c:3f2b:e791:1:0:1:ac13:a0a U >> bce1 ff02::%lo0/32 ::1 U >> lo0 >> > > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > expecting bce1 rather than lo0, I suppose you were as well :) If I'm not > mistaken, the packets emanating from bce1 go to the loopback interface, > thus not really going out. You can try specifying the route manually > with "route add *your parameters*" or even set it in /etc/rc.conf so > that it's loaded at boot-time. There's no reason why among 2 physical > interfaces sharing the same fabric, one can ship packets out and the > other can't. > I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 Elmer# netstat -rn (snip) fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHSbce1 I don't think that is what I want. WHat I think I just said is "host X" is out that door, rather than route net. If, however, I say Docs is out that door, I get: Elmer# route add -inet6 docs.dco.penx.com -iface bce1 add host docs.dco.penx.com: gateway bce1 Elmer# ping6 docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2
Re: tcp keepalive after fin+ack from client and server
On 12/14/09 5:32 AM, "Julian Elischer" wrote: > Felix J. Ogris wrote: >> Hi, >> >> I am experiencing some strange problem where FreeBSD sometimes starts >> sending tcp keepalives after client and server have sent and ack'ed FINs. >> The server runs 7.1-RELEASE/amd64 with open-vm-tools-nox11-148847 in a >> VMware ESXi 4.0. The client runs a CentOS Linux 2.6.18-164.6.1.el5PAE SMP on >> a bare metal machine. FreeBSD houses a Apache installation with sendfile and >> mmap enabled. The Linux machine runs a homemade monitoring system and starts >> a Perl script every 5 minutes to check if Apache is still alive. I have put >> a tcpdump output on http://ogris.de/keepalive.txt for readability and can >> provide the raw tcpdump file, if needed. Client and server keep sending >> those keepalives for about 2 hours (yielding 300kB/s constantly) if not >> stopped manually by an ipfw rule. lsof shows that no user process has open >> the corresponding sockets anymore, whereas netstat shows established >> connections. >> FreeBSD has loaded ipfw with some keep-state rules, the Linux box has >> iptables disabled. > > > are you sure it isn't the firewall (ipfw) sending keepalives? it is > one of the options with kept state to inject keepalives. > if it didint' see all the FINs for some reason, it may think the > session is still alive. Thanks for the hint - net.inet.ip.fw.dyn_keepalive=0 did the trick. Felix ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
The nd6.c patch is currently compiling. On Mon, 14 Dec 2009, Li, Qing wrote: You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1UHS lo0 fe80::%bce1/64link#2U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2UHS lo0 fe80::%lo0/64 link#3U lo0 fe80::1%lo0 link#3UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with "route add *your parameters*" or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 Elmer# netstat -rn (snip) fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHSbce1 I don't think that is what I want. WHat I think I just said is "host X" is out that door, rather than route net. If, however, I say Docs is out that door, I get: Elmer# route add -inet6 docs.dco.penx.com -iface bce1 add host docs.dco.penx.com: gateway bce1 Elmer# ping6 docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 ping6: sendmsg: Operation not permit
Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter
Would I need to bring the whole system up to HEAD, or can I just add the relevant vge(4) file to my current RELENG_8 system? Thanks, -c On Mon, Dec 14, 2009 at 4:38 PM, wrote: > Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > State-Changed-Why: > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
The patch works. Thanks. On Mon, 14 Dec 2009, Li, Qing wrote: You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1UHS lo0 fe80::%bce1/64link#2U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2UHS lo0 fe80::%lo0/64 link#3U lo0 fe80::1%lo0 link#3UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with "route add *your parameters*" or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 Elmer# netstat -rn (snip) fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHSbce1 I don't think that is what I want. WHat I think I just said is "host X" is out that door, rather than route net. If, however, I say Docs is out that door, I get: Elmer# route add -inet6 docs.dco.penx.com -iface bce1 add host docs.dco.penx.com: gateway bce1 Elmer# ping6 docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 ping6: sendmsg: Operation not permitted ping6: wrote
Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter
On Mon, Dec 14, 2009 at 05:36:19PM -0600, Carey Jones wrote: > Would I need to bring the whole system up to HEAD, or can I just add the > relevant vge(4) file to my current RELENG_8 system? > You can download the following latest vge(4) files from HEAD and it should build on 8.0-RELEASE. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h > Thanks, > > > -c > > On Mon, Dec 14, 2009 at 4:38 PM, wrote: > > > Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter > > > > State-Changed-From-To: open->feedback > > State-Changed-By: yongari > > State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > State-Changed-Why: > > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > > > > > > > > Responsible-Changed-From-To: freebsd-net->yongari > > Responsible-Changed-By: yongari > > Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > Responsible-Changed-Why: > > Grab. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter
Hello, The version from HEAD seems to work better than any of the previous patches I've tried, though it still doesn't seem to get quite the throughput that the adapter managed under RELENG_7. Unfortunately I don't have any quantitative data for you. However, the symptoms from my pr are definitely gone. Thanks, -c On Mon, Dec 14, 2009 at 7:06 PM, Pyun YongHyeon wrote: > On Mon, Dec 14, 2009 at 05:36:19PM -0600, Carey Jones wrote: > > Would I need to bring the whole system up to HEAD, or can I just add the > > relevant vge(4) file to my current RELENG_8 system? > > > > You can download the following latest vge(4) files from HEAD and it > should build on 8.0-RELEASE. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h > > > Thanks, > > > > > > -c > > > > On Mon, Dec 14, 2009 at 4:38 PM, wrote: > > > > > Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter > > > > > > State-Changed-From-To: open->feedback > > > State-Changed-By: yongari > > > State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > > State-Changed-Why: > > > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > > > > > > > > > > > > Responsible-Changed-From-To: freebsd-net->yongari > > > Responsible-Changed-By: yongari > > > Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > > Responsible-Changed-Why: > > > Grab. > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 > > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter
On Mon, Dec 14, 2009 at 08:58:19PM -0600, Carey Jones wrote: > Hello, > > The version from HEAD seems to work better than any of the previous patches > I've tried, though it still doesn't seem to get quite the throughput that > the adapter managed under RELENG_7. Unfortunately I don't have any > quantitative data for you. However, the symptoms from my pr are definitely > gone. > Glad to hear that. I have strong evidence that the vge(4) can't saturate the link for any frame size. I still have no idea why it shows poor TX performance(about 650Mbps) compared to RX(about 930Mbps). The best performance number I can get from my local patch was about 800Mbps which is still very lower than any other gigabit controllers. I'm working on it with various scenarios but I couldn't find clue. > Thanks, ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
8.0R, AMD64 and wpi is giving me major grief
All, I've got a Lenovo t61 with 4gbytes RAM that is giving me fits. It's got a 3945abg chip in it, and it's getting really flaky. I can boot it up, and work at the console for a while, and that seems to work OK, usually. However, today, when I start up my gui (xfce4), wireless just dies on me. For a week before, it would usually run for a while (sometimes days) before dying on me and requiring a reboot. Below is a snippet of /var/log/messages - Does this mean anything to anyone? Is there anything I can do to recover once this happens? Thanks, Kurt Dec 14 07:16:43 grimsqueaker kernel: wlan0: Ethernet address: 00:1f:3c:4d:e2:55 Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 1 Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 3 Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 4 Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification version 10e02 alive 1 Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification version 10e02 alive 1 Dec 14 07:16:43 grimsqueaker kernel: wpi_newstate: INIT -> SCAN flags 0x0 Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-SCAN-RESULTS Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Trying to associate with 00:23:69:82:b2:bf (SSID='5705NE197th' freq=2462 MHz) Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: SCAN -> AUTH flags 0x0 Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8005 cck f ofdm 15 Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: AUTH -> ASSOC flags 0x0 Dec 14 07:16:45 grimsqueaker kernel: Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Associated with 00:23:69:82:b2:bf Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: ASSOC -> RUN flags 0x0 Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8035 Dec 14 07:16:45 grimsqueaker kernel: wlan0: link state changed to UP Dec 14 07:16:45 grimsqueaker kernel: wpi0: need multicast update callback Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: WPA: Key negotiation completed with 00:23:69:82:b2:bf [PTK=CCMP GTK=CCMP] Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-CONNECTED - Connection to 00:23:69:82:b2:bf completed (auth) [id=0 id_str=] Dec 14 07:16:53 grimsqueaker dhclient: New IP Address (wlan0): 192.168.151.104 Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback Dec 14 07:16:53 grimsqueaker dhclient: New Subnet Mask (wlan0): 255.255.255.0 Dec 14 07:16:53 grimsqueaker dhclient: New Broadcast Address (wlan0): 192.168.151.255 Dec 14 07:16:53 grimsqueaker dhclient: New Routers (wlan0): 192.168.151.1 Dec 14 07:17:56 grimsqueaker kernel: drm0: on vgapci0 Dec 14 07:17:56 grimsqueaker kernel: info: [drm] MSI enabled 1 message(s) Dec 14 07:17:56 grimsqueaker kernel: vgapci0: child drm0 requested pci_enable_busmaster Dec 14 07:17:56 grimsqueaker kernel: info: [drm] AGP at 0xe000 256MB Dec 14 07:17:56 grimsqueaker kernel: info: [drm] Initialized i915 1.6.0 20080730 Dec 14 07:17:57 grimsqueaker kernel: drm0: [ITHREAD] Dec 14 07:18:24 grimsqueaker kernel: pid 1424 (xfce4-panel), uid 1001: exited on signal 11 (core dumped) Dec 14 07:25:43 grimsqueaker wpa_supplicant[381]: WPA: Group rekeying completed with 00:23:69:82:b2:bf [GTK=CCMP] Dec 14 07:48:38 grimsqueaker kernel: wpi0: device timeout Dec 14 07:48:39 grimsqueaker kernel: wpi0: could not set power mode ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
patch: bad ipv6 neighbor solicitation
Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, December 14, 2009 3:00 PM > To: Dennis Glatting; JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > You don't need to perform all that route-foo. I believe the root cause > of > this issue may be due to a bit of regression in the IPv6 prefix > management > code, and I am in the process of putting together a permanent fix. > > The issue as it stands today, is due to how the prefix was inserted in > the first place. Since bce0 was configured first, the interface > associated > with the prefix is bce0. Later the reference count on the prefix is > simply incremented when bce1 configures another IPv6 address of the > same prefix. > > When ND6 NS arrives for bce1, due to the interface mismatch of the > prefix > interface against the input interface, the NS packet was considered > invalid and thus dropped. > > Again, in case you didn't see my earlier reply, try the temporary hack > at > http://people.freebsd.org/~qingli/nd6-ns.diff > > until I commit a permanent patch. The problem was easily reproducible > and > I have verified with limited unit testing the patch works. > > -- Qing > > > -Original Message- > From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting > Sent: Mon 12/14/2009 2:03 PM > To: JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > Thanks. Responses in-line. > > > > On Mon, 14 Dec 2009, JASSAL Aman wrote: > > > Hello Mr.Glatting, > > > > Not that I'm an IPv6 genius, but at first sight your problem seems to > be a > > route-related. I've put comments in-line. > > > > > > Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > >> > >> > >> Elmer# netstat -rn > >> Routing tables > >> > >> > >> Internet6: > >> Destination Gateway > Flags > >> Netif Expire > >> ::/96 ::1 UGRS > >> lo0 => default fd7c:3f2b:e791:1::1 > >> UGSbce0 > >> ::1 ::1 UH > >> lo0 :::0.0.0.0/96 ::1 > UGRS > >> lo0 fd7c:3f2b:e791:1::/64 link#1 > U > >> bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 > UHS > >> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > UHS > >> lo0 fe80::/10 ::1 > UGRS > >> lo0 fe80::%bce0/64link#1 > U > >> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > UHS > >> lo0 fe80::%bce1/64link#2 > U > >> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > UHS > >> lo0 fe80::%lo0/64 link#3 > U > >> lo0 fe80::1%lo0 link#3 > UHS > >> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 > U > >> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a > U > >> bce1 ff01:3::/32 ::1 > U > >> lo0 ff02::/16 ::1 > UGRS > >> lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 > U > >> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a > U > >> bce1 ff02::%lo0/32 ::1 > U > >> lo0 > >> > > > > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > > expecting bce1 rather than lo0, I suppose you were as well :) If I'm > not > > mistaken, the packets emanating from bce1 go to the loopback > interface, > > thus not really going out. You can try specifying the route manually > > with "route add *your parameters*" or even set it in /etc/rc.conf so > > that it's loaded at boot-time. There's no reason why among 2 physical > > interfaces sharing the same fabric, one can ship packets out and the > > other can't. > > > > I was wondering about the route however I haven't figured out the trick > to > get what I want. For example: > > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > Elmer# route add > -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > route: writing to routing socket: File exists > add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already > in table > > I did delete the lo0 route before I exected the above command. Also, I > hav
Re: Racoon site-to site
On 2009-12-11 20.23, "Mike Tancsa" wrote:
> At 11:33 AM 12/11/2009, David DeSimone wrote:
>> Jon Otterholm wrote:
>>>
>>> If I restart racoon or wait approximately 30 min the connection is
>>> re-established.
>>
>> Since this is approximately ½of the phase 2 lifetime, you are probably
>> running into lifetime negotiation issues, or PFS issues.
>>
>>> What would be the obvious way to debug this? Any suggestions on what
>>> to tweak appreciated.
>>
>> I would turn up the debugging on racoon to get more information around
>> the time that the tunnel fails.
>>
>>> sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any)
>>> {
>>> pfs_group 1;
>>> lifetimetime3600 sec;
>>> encryption_algorithmdes;
>>> authentication_algorithmhmac_md5,hmac_sha1;
>>> compression_algorithm deflate;
>>> }
>>
>> My hunch is that you have a PFS mismatch, so that the first tunnel
>> negotiates, but the second SA negotiation fails, then the third
>> succeeds, etc.
>
>
> You might also want to turn on DPD (dead peer
> detection) in ipsectools if you dont already have
> it on both sides. Are you really using des for
> the crypto ? Also, when the session is
> negotiated, take a look at the output of
> setkey -D
> and see what was actually negotiated and post it
> here (just make sure you get rid of the info on the E and A lines.
>
> e.g.
> 1.1.1.2 2.2.2.2
> esp mode=tunnel spi=125444787(0x077a22b3) reqid=16416(0x4020)
> E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b
> A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb
>
> ie. mask out the 5cfdbabb and 770cdd7b values
> before posting as thats your crypto :)
>
>
Here is output from setkey -D when we lost connection:
localip remoteip
esp mode=tunnel spi=989823717(0x3aff82e5) reqid=0(0x)
E: des-cbc x x
A: hmac-md5 x x x x
seq=0x09ac replay=4 flags=0x state=mature
created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009
diff: 1703(s) hard: 3600(s) soft: 2880(s)
last: Dec 15 08:26:03 2009 hard: 0(s) soft: 0(s)
current: 400400(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 2476 hard: 0 soft: 0
sadb_seq=1 pid=23175 refcnt=2
remoteip remoteip
esp mode=tunnel spi=117094840(0x06fab9b8) reqid=0(0x)
E: des-cbc x x
A: hmac-md5 x x x x
seq=0x0b73 replay=4 flags=0x state=mature
created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009
diff: 1703(s) hard: 3600(s) soft: 2880(s)
last: Dec 15 08:25:37 2009 hard: 0(s) soft: 0(s)
current: 2960978(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 2931 hard: 0 soft: 0
sadb_seq=0 pid=23175 refcnt=1
//Jon
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
