From linimon at FreeBSD.org Sun Nov 1 08:34:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 1 08:34:30 2009 Subject: kern/140142: [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 Message-ID: <200911010834.nA18YNop022250@freefall.freebsd.org> Old Synopsis: FreeBSD 7.2-amd64 panic w/IPv6 New Synopsis: [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 1 08:33:55 UTC 2009 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=140142 From onemda at gmail.com Sun Nov 1 09:09:20 2009 From: onemda at gmail.com (Paul B Mahol) Date: Sun Nov 1 09:09:26 2009 Subject: if_ndis patch In-Reply-To: <1257014422.2113.6.camel@localhost> References: <3a142e750910300852n276d009bsefea73b3ee4db176@mail.gmail.com> <1257014422.2113.6.camel@localhost> Message-ID: <3a142e750911010109t7d1c9148t264e168a3a2bd47a@mail.gmail.com> On 10/31/09, Coleman Kane wrote: > Paul, > > Did you get to send this to sam@, etc ? Negative, now let @net know about it too. > On Fri, 2009-10-30 at 16:52 +0100, Paul B Mahol wrote: >> Hi, >> >> There is no point to do scanning how it is currently done: >> >> Index: if_ndis.c >> =================================================================== >> --- if_ndis.c (revision 198675) >> +++ if_ndis.c (working copy) >> @@ -3398,11 +3398,8 @@ >> struct ifnet *ifp = ic->ic_ifp; >> struct ndis_softc *sc = ifp->if_softc; >> struct ieee80211vap *vap; >> - struct ieee80211_scan_state *ss; >> - ndis_80211_ssid ssid; >> int error, len; >> >> - ss = ic->ic_scan; >> vap = TAILQ_FIRST(&ic->ic_vaps); >> >> if (!NDIS_INITIALIZED(sc)) { >> @@ -3411,20 +3408,6 @@ >> return; >> } >> >> - len = sizeof(ssid); >> - bzero((char *)&ssid, len); >> - if (ss->ss_nssid == 0) >> - ssid.ns_ssidlen = 1; >> - else { >> - /* Perform a directed scan */ >> - ssid.ns_ssidlen = ss->ss_ssid[0].len; >> - bcopy(ss->ss_ssid[0].ssid, ssid.ns_ssid, ssid.ns_ssidlen); >> - } >> - >> - error = ndis_set_info(sc, OID_802_11_SSID, &ssid, &len); >> - if (error) >> - DPRINTF(("%s: set ESSID failed\n", __func__)); >> - >> len = 0; >> error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN, >> NULL, &len); From nrml at att.net Sun Nov 1 17:27:12 2009 From: nrml at att.net (Gabe) Date: Sun Nov 1 17:27:19 2009 Subject: IPSEC NAT-T Message-ID: <744755.49863.qm@web83805.mail.sp1.yahoo.com> Hello, What's the latest "stable" patch available for the latest 7.x source? thanks From nvass9573 at gmx.com Sun Nov 1 20:41:14 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Sun Nov 1 20:41:20 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEC599F.90202@keff.org> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> <4AEB911E.1070104@keff.org> <4AEC2297.40805@gmx.com> <4AEC599F.90202@keff.org> Message-ID: <4AEDF25C.2030801@gmx.com> Sebastian Hyrwall wrote: >> You could still use a /32 and then add a route for the other IP via >> the ethernet interface. This is effectively the same with a /31. >> > Does not work, I see, I've checked this on 9.0 and found it working, not on 7.2. Nikos From ask at develooper.com Mon Nov 2 03:37:13 2009 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Mon Nov 2 03:37:21 2009 Subject: carp advskew not 'sticking' Message-ID: Hi everyone, On a set of gw boxes I have 5 carp interfaces. 4 are working fine, but on one for some reason the advskew setting isn't "sticking" (and I get carp2: incorrect hash). I'm running 7.2-STABLE from a few days ago. gw-a# ifconfig carp2 vhid 12 advskew 100 pass abc123 10.0.100.1/24 gw-a# ifconfig carp2 carp2: flags=49 metric 0 mtu 1500 inet 10.0.100.1 netmask 0xffffff00 carp: BACKUP vhid 12 advbase 1 advskew 0 gw-b# ifconfig carp2 vhid 12 advskew 200 pass abc123 10.0.100.1/24 gw-b# ifconfig carp2 carp2: flags=49 metric 0 mtu 1500 inet 10.0.100.1 netmask 0xffffff00 carp: MASTER vhid 12 advbase 1 advskew 0 (notice how advskew is 200 ...) I'm pasting the ifconfig for the parent interfaces (the physical interface and the vlan) and for the other carp interface on the same network below for each host. Any ideas would be greatly appreciated. I don't usually use the /cidr notation on carp interfaces, but I noticed the netmask was wrong before and thought that could be related. How can I get more debug information? Right now all I get is "carp2: incorrect hash" Another related question: I use net.inet.carp.preempt=1; but for some reason this interface gets to "float" to either box without all the other interfaces moving along with it. - ask gw-a# ifconfig vr2 vr2: flags=8943 metric 0 mtu 1500 options=280b ether 00:0d:b9:12:75:ea media: Ethernet autoselect (100baseTX ) status: active gw-a# ifconfig vlan2 vlan2: flags=8943 metric 0 mtu 1500 ether 00:0d:b9:12:75:ea inet 10.0.100.2 netmask 0xffffff00 broadcast 10.0.100.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 102 parent interface: vr2 gw-a# ifconfig carp4 carp4: flags=49 metric 0 mtu 1500 inet 10.0.100.254 netmask 0xffffff00 carp: MASTER vhid 5 advbase 1 advskew 100 gw-a# gw-b# ifconfig vr2 vr2: flags=8943 metric 0 mtu 1500 options=280b ether 00:0d:b9:12:75:3e media: Ethernet autoselect (100baseTX ) status: active gw-b# ifconfig vlan2 vlan2: flags=8943 metric 0 mtu 1500 ether 00:0d:b9:12:75:3e inet 10.0.100.3 netmask 0xffffff00 broadcast 10.0.100.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 102 parent interface: vr2 gw-b# ifconfig carp4 carp4: flags=49 metric 0 mtu 1500 inet 10.0.100.254 netmask 0xffffff00 carp: BACKUP vhid 5 advbase 1 advskew 200 gw-b# From jhell at DataIX.net Mon Nov 2 03:40:54 2009 From: jhell at DataIX.net (jhell) Date: Mon Nov 2 03:41:01 2009 Subject: IPSEC NAT-T In-Reply-To: <744755.49863.qm@web83805.mail.sp1.yahoo.com> References: <744755.49863.qm@web83805.mail.sp1.yahoo.com> Message-ID: On Sun, 1 Nov 2009 12:00, nrml@ wrote: > > > Hello, > > What's the latest "stable" patch available for the latest 7.x source? > > thanks > Checkout http://svn.freebsd.org/base/stable/7 (Subversion Repository) You can also browse back to the root of that tree to get to the ViewVC client to browse the stable source in a way that you might be looking for. -- Sun Nov 1 22:10:51 2009 -0500 jhell From ml at netfence.it Mon Nov 2 07:18:13 2009 From: ml at netfence.it (Andrea Venturoli) Date: Mon Nov 2 07:18:20 2009 Subject: ipfw uid and mpsafenet Message-ID: <4AEE87B2.7010009@netfence.it> Hello. I've got a 6.3 box in which I needed to use debug.mpsafenet=0 in order to avoid deadlocks with ipfw uid rules. I'm thinking of upgrading this to 7.2 and I see the above variable has gone away. Does this mean it is now safe to use such ipfw rules? The last things I could find wrt this matter is this thread: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2007-07/msg00108.html, but it's from 2007... Any other caveat? bye & Thanks av. From bugmaster at FreeBSD.org Mon Nov 2 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 2 11:09:00 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200911021106.nA2B6x7i033672@freefall.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/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 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/139559 net [tun] several tun(4) interfaces can be created with sa 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/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e 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 0xffffff004127b00 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 o kern/138676 net [route] after buildworld not work local routes [regres 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 net TCP 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/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f 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 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 358 problems total. From achilov-rn at askd.ru Mon Nov 2 12:58:30 2009 From: achilov-rn at askd.ru (Rashid N. Achilov) Date: Mon Nov 2 12:58:37 2009 Subject: How much similar interfaces Message-ID: <200911021847.48193.achilov-rn@askd.ru> How much similar interfaces can I create? (i.e. tun0, tun1, tun2... tunN) -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), JID: citycat4@jabber.org OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A From barney_cordoba at yahoo.com Mon Nov 2 13:40:07 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Mon Nov 2 13:40:13 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ADDDA2C.3020206@mail.ru> Message-ID: <274298.85978.qm@web63908.mail.re1.yahoo.com> --- On Tue, 10/20/09, rihad wrote: > From: rihad > Subject: Re: dummynet dropping too many packets > To: freebsd-net@freebsd.org > Date: Tuesday, October 20, 2009, 11:41 AM > I'm so happy today: finally running a > "ifp->if_snd.ifq_drv_maxlen = 4096;" and HZ=4000 kernel > with 4100+ online users @500+ mbps, and, most importantly, > with absolutely 0 drops since boot time! ;-) Even if drops > do come in, I'll know where to look first. I'd like to > express my gratitude to Robert Watson for pointing out the > "ifnet transmit queue sizes" issue, to others who suggested > the problem might be in dummynet's burstiness, and yet to > others who tried hard to help with other suggestions. Thank > you, folks! Tomorrow I'm going to suggest to my boss to > donate some $$$ to the FreeBSD Foundation: http://www.freebsdfoundation.org/donate/ Seems to me that spending money on a real packetshaper would be a better investment than donating to compromise on the free stuff (not that I'd want to discourage anyone from contributing to FreeBSD generally). Your problem is that at high traffic levels you need to reduce traffic flows, not just delay it as dummynet does. The entire point of traffic shaping is to smooth out your traffic flows; not to make it so choppy that you have packets sitting in a transmit queue for 1/2 millisecond in addition to the dummynet delays. While dummynet may not be dropping packets, you have packets being dropped in TCP stacks throughout your customer base, most likely. Barney From kurt.buff at gmail.com Mon Nov 2 20:12:39 2009 From: kurt.buff at gmail.com (Kurt Buff) Date: Mon Nov 2 20:12:46 2009 Subject: Sangoma drops FreeBSD support - is there a replacment? Message-ID: I've got a couple of their A301 DS3 cards (one in production, one as backup on the shelf), and the one in production is working fine for now, but since Sangoma have dropped support for FreeBSD across the board, I'm looking for an alternative. Anyone know of a good DS3 replacement card that supports FreeBSD? Kurt From thomas at gibfest.dk Mon Nov 2 21:09:55 2009 From: thomas at gibfest.dk (Thomas Rasmussen) Date: Mon Nov 2 21:10:03 2009 Subject: "route get" returning error on classful networks Message-ID: <4AEF47E2.7010304@gibfest.dk> Gentlemen, While writing a script to do some route table maintenance on a firewall I stumbled on to something curious (all network numbers are examples): ===================================================== $ route get 35.0.0.0 route: writing to routing socket: No such process $ route -n get 35.0.0.1 route to: 35.0.0.1 destination: default mask: default gateway: 10.10.0.1 interface: lagg0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 ===================================================== It seems "route get" returns an error when asked to look up the route to a network with the network .0 ip as the lookup key. This follows classful network boundaries, and is somewhat easier to demonstrate than to explain: ===================================================== class A: $ route get 9.0.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 9.1.0.0 > /dev/null 2>&1 ; echo $? 0 class B: $ route get 130.0.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 130.1.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 130.1.1.0 > /dev/null 2>&1 ; echo $? 0 class C: $ route get 200.0.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 200.1.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 200.1.1.0 > /dev/null 2>&1 ; echo $? 1 $ route get 200.1.1.1 > /dev/null 2>&1 ; echo $? 0 ===================================================== This happens on Freebsd 6-7-8 on all machines I have access to. The error message is confusing and suggests there is a problem writing to the routing table which is not what I am doing at all. Is this a bug, or can somebody offer an explanation for this ? Thank you! :) Thomas Rasmussen From linimon at FreeBSD.org Tue Nov 3 02:15:07 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Nov 3 02:15:14 2009 Subject: kern/140066: [bwi] install report for 8.0 RC 2 (multiple problems) Message-ID: <200911030215.nA32F7bt028924@freefall.freebsd.org> Old Synopsis: install report for 8.0 RC 2 New Synopsis: [bwi] install report for 8.0 RC 2 (multiple problems) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 3 02:10:29 UTC 2009 Responsible-Changed-Why: Reassigning this PR to -net because it contains information about a bwi problem. To submitter: handling this kind of PR is a bit problematic for us, since it lists several different problems. There really isn't one person/group who works on "overall usability issues". (I'll accept a criticism that there *should* be, but FreeBSD is a volunteer project, so all I can do is advocate for more people to work on such issues.) In the meantime you may be able to find help with certain problems in the FreeBSD Forums, or, if you are more traditional, the freebsd- questions@ mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=140066 From egrosbein at rdtc.ru Tue Nov 3 04:32:20 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Tue Nov 3 04:32:26 2009 Subject: dummynet dropping too many packets In-Reply-To: <274298.85978.qm@web63908.mail.re1.yahoo.com> References: <274298.85978.qm@web63908.mail.re1.yahoo.com> Message-ID: <4AEFAC6E.5080805@rdtc.ru> Barney Cordoba wrote: > Your problem is that at high traffic levels you need to reduce traffic > flows, not just delay it as dummynet does. Dummynet does not "just adds delay". > The entire point of traffic > shaping is to smooth out your traffic flows; not to make it so choppy > that you have packets sitting in a transmit queue for 1/2 millisecond > in addition to the dummynet delays. While dummynet may not be dropping > packets, you have packets being dropped in TCP stacks throughout your > customer base, most likely. If you followed the thread, you known that rihad tried GRED. The problem was not due to exceeded bandwidth but in inadequate interface-level FIFO queue length. And no way to adjust it without a patch. This makes me think we should have general user interface for setting the queue length for any network interface just like Cisco 'hold-queue' command does. For now, only some drivers (e.g., em(4)) have such option. From kalin at el.net Tue Nov 3 04:57:01 2009 From: kalin at el.net (kalin m) Date: Tue Nov 3 04:57:09 2009 Subject: ral driver Message-ID: <4AEFB781.90409@el.net> hi all.... is this resolved in current or head? http://lists.freebsd.org/pipermail/freebsd-bugs/2009-May/035231.html i have this ral card that drops off after about 15 min or so and have the same symptoms as described in that bug report.. thank you... From kalin at el.net Tue Nov 3 05:48:28 2009 From: kalin at el.net (kalin m) Date: Tue Nov 3 05:48:35 2009 Subject: Marvell 88E8057 In-Reply-To: <20091024215219.GF6050@michelle.cdnetworks.com> References: <4AE2780F.4080600@el.net> <20091024214640.GE6050@michelle.cdnetworks.com> <20091024215219.GF6050@michelle.cdnetworks.com> Message-ID: <4AEFC390.2090600@el.net> hi pyun... and all.... after a few hours i'm sorry to report that the card is visible but not usable (yet?!). here is what i have done so far: 1. got the files from http://svn.freebsd.org/viewvc/base/head/sys/dev/ 2. applied the patch that pyun provided. 3. replaced if_maddr_rlock(ifp) with IF_ADDR_UNLOCK(ifp) in if_msk.c - two instances. 4. replaced the files in /usr/src/sys/dev for mii and msk with he new ones on the freebsd 7.2 machine. 5. recompiled the kernel.. here is what i get: from dmesg at boot: mskc0: port 0xde00-0xdeff mem 0xfddfc000-0xfddfffff irq 18 at device 0.0 on pci2 mskc0: unknown device: id=0xba, rev=0x00 device_attach: mskc0 attach returned 6 cant find what 6 stands for but it's not good.. pciconf -lvvv: mskc0@pci0:2:0:0: class=0x020000 card=0x51131297 chip=0x438011ab rev=0x10 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' class = network subclass = ethernet if i put if_msk_load="YES" in loader.conf dmesg says: module_register: module msk/miibus already exists! Module msk/miibus failed to register: 17 module_register: module mskc/msk already exists! Module mskc/msk failed to register: 17 module_register: module pci/mskc already exists! Module pci/mskc failed to register: 17 ifconfig doesn't see it. sysinstall does not see it. now what?! thanks... Pyun YongHyeon wrote: > On Sat, Oct 24, 2009 at 02:46:40PM -0700, Pyun YongHyeon wrote: > >> On Fri, Oct 23, 2009 at 11:44:15PM -0400, kalin m wrote: >> >>> hi all.. >>> >>> does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? >>> >>> according to the kernel list of drivers (7.2) marvell chips are driven >>> by the msk driver. but it doesn't show up in pciconf, dmesg or >>> sysinstall.... >>> strangely enough 88E8057 is not in the list in man msk. although 88E8056 >>> and 88E8058 are. is this just bad luck?! >>> >>> >> I think 88E8057(Yukon Ultra 2) is the latest chipset from Marvell >> and no one ever expressed his/her willingness to try experiment >> patch. I guess msk(4) in HEAD has all required features to support >> 88E8057. Would you try attached patch? >> >> The patch was generated against HEAD. If you have to use 7.2-RELEASE >> copy the following files from HEAD and apply attached patch. >> >> /usr/src/sys/dev/msk/if_msk.c >> /usr/src/sys/dev/msk/if_mskreg.h >> /usr/src/sys/dev/mii/miidevs >> /usr/src/sys/dev/mii/e1000phy.c >> /usr/src/sys/dev/mii/e1000phyreg.c >> > ^^^^^^^^^^^^^^ > It should be read e1000phyreg.h > From glenbarner at australia.edu Tue Nov 3 06:58:55 2009 From: glenbarner at australia.edu (glenn Barber) Date: Tue Nov 3 06:59:18 2009 Subject: dummynet dropping too many packets Message-ID: <5794edfe0911022258r25d1ea0cr9d503c36575273f4@mail.gmail.com> >Seems to me that spending money on a real packetshaper would be a >better investment than donating to compromise on the free stuff (not >that I'd want to discourage anyone from contributing to FreeBSD >generally). >Your problem is that at high traffic levels you need to reduce traffic >flows, not just delay it as dummynet does. The entire point of traffic >shaping is to smooth out your traffic flows; not to make it so choppy >that you have packets sitting in a transmit queue for 1/2 millisecond >in addition to the dummynet delays. While dummynet may not be dropping >packets, you have packets being dropped in TCP stacks throughout your >customer base, most likely. >Barney Packetshaper? It can't work over 300M/s. From vanhu at FreeBSD.org Tue Nov 3 10:41:17 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Nov 3 10:41:23 2009 Subject: IPSEC NAT-T In-Reply-To: <744755.49863.qm@web83805.mail.sp1.yahoo.com> References: <744755.49863.qm@web83805.mail.sp1.yahoo.com> Message-ID: <20091103104114.GA97006@zeninc.net> On Sun, Nov 01, 2009 at 09:00:30AM -0800, Gabe wrote: > Hello, Hi. > What's the latest "stable" patch available for the latest 7.x source? Stable patches, to be used with ipsec-tools 0.7 branch, are available here: http://people.freebsd.org/~vanhu/NAT-T/ As we're working on backporting FreeBSD / ipsec-tools HEAD works on STABLE/7 branch, I haven't generated a new one for a while, let me know if the latest public patch has some issues. Yvan. From nrml at att.net Tue Nov 3 11:50:45 2009 From: nrml at att.net (Gabe) Date: Tue Nov 3 11:50:51 2009 Subject: IPSEC NAT-T In-Reply-To: <20091103104114.GA97006@zeninc.net> References: <744755.49863.qm@web83805.mail.sp1.yahoo.com> <20091103104114.GA97006@zeninc.net> Message-ID: <926589.56887.qm@web83812.mail.sp1.yahoo.com> ----- Original Message ---- > From: VANHULLEBUS Yvan > To: Gabe > Cc: freebsd-net@freebsd.org > Sent: Tue, November 3, 2009 2:41:14 AM > Subject: Re: IPSEC NAT-T > > On Sun, Nov 01, 2009 at 09:00:30AM -0800, Gabe wrote: > > Hello, > > Hi. > > > > What's the latest "stable" patch available for the latest 7.x source? > > Stable patches, to be used with ipsec-tools 0.7 branch, are available > here: > http://people.freebsd.org/~vanhu/NAT-T/ > > As we're working on backporting FreeBSD / ipsec-tools HEAD works on > STABLE/7 branch, I haven't generated a new one for a while, let me > know if the latest public patch has some issues. > > > Yvan. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Yeah the latest patch did not work on the latest source, it would not allow make buildkernel to succeed. I worked around it by using the latest 7.2-RELEASE. From dfilter at FreeBSD.ORG Tue Nov 3 13:00:10 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Nov 3 13:02:22 2009 Subject: kern/138999: commit references a PR Message-ID: <200911031300.nA3D0AF5019032@freefall.freebsd.org> The following reply was made to PR kern/138999; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138999: commit references a PR Date: Tue, 3 Nov 2009 12:52:49 +0000 (UTC) Author: kib Date: Tue Nov 3 12:52:35 2009 New Revision: 198853 URL: http://svn.freebsd.org/changeset/base/198853 Log: If socket buffer space appears to be lower then sum of count of already prepared bytes and next portion of transfer, inner loop of kern_sendfile() aborts, not preparing next mbuf for socket buffer, and not modifying any outer loop invariants. The thread loops in the outer loop forever. Instead of breaking from inner loop, prepare only bytes that fit into the socket buffer space. In collaboration with: pho Reviewed by: bz PR: kern/138999 MFC after: 2 weeks Modified: head/sys/kern/uipc_syscalls.c Modified: head/sys/kern/uipc_syscalls.c ============================================================================== --- head/sys/kern/uipc_syscalls.c Tue Nov 3 12:03:13 2009 (r198852) +++ head/sys/kern/uipc_syscalls.c Tue Nov 3 12:52:35 2009 (r198853) @@ -2037,20 +2037,12 @@ retry_space: rem = obj->un_pager.vnp.vnp_size - uap->offset - fsbytes - loopbytes; xfsize = omin(rem, xfsize); + xfsize = omin(space - loopbytes, xfsize); if (xfsize <= 0) { VM_OBJECT_UNLOCK(obj); done = 1; /* all data sent */ break; } - /* - * Don't overflow the send buffer. - * Stop here and send out what we've - * already got. - */ - if (space < loopbytes + xfsize) { - VM_OBJECT_UNLOCK(obj); - break; - } /* * Attempt to look up the page. Allocate _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From linimon at FreeBSD.org Tue Nov 3 14:17:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Nov 3 14:27:53 2009 Subject: kern/140245: [ath] [panic] Kernel panic during network activity on device ath in 7.2-RELEASE-p4 Message-ID: <200911031417.nA3EHS1O088001@freefall.freebsd.org> Old Synopsis: Kernel panic during network activity on device ath in 7.2-RELEASE-p4 New Synopsis: [ath] [panic] Kernel panic during network activity on device ath in 7.2-RELEASE-p4 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 3 14:17:17 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140245 From ask at develooper.com Tue Nov 3 15:37:13 2009 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue Nov 3 15:47:53 2009 Subject: carp advskew not 'sticking' In-Reply-To: References: Message-ID: On Nov 1, 2009, at 19:09, Ask Bj?rn Hansen wrote: > On a set of gw boxes I have 5 carp interfaces. 4 are working fine, > but on one for some reason the advskew setting isn't "sticking" (and > I get carp2: incorrect hash). I'm running 7.2-STABLE from a few > days ago. > > gw-a# ifconfig carp2 vhid 12 advskew 100 pass abc123 10.0.100.1/24 > gw-a# ifconfig carp2 > carp2: flags=49 metric 0 mtu 1500 > inet 10.0.100.1 netmask 0xffffff00 > carp: BACKUP vhid 12 advbase 1 advskew 0 > > gw-b# ifconfig carp2 vhid 12 advskew 200 pass abc123 10.0.100.1/24 > gw-b# ifconfig carp2 > carp2: flags=49 metric 0 mtu 1500 > inet 10.0.100.1 netmask 0xffffff00 > carp: MASTER vhid 12 advbase 1 advskew 0 Hi everyone, Just for the sake of the archives: I'm not 100% sure, but I think this was caused by another set of boxes mistakenly on the same vlan with the same vhid. - ask From ask at develooper.com Tue Nov 3 15:47:16 2009 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue Nov 3 15:51:24 2009 Subject: DHCP client not getting IP address from Time Warner Message-ID: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> Hi everyone, After years with Speakeasy at home I'm trying out Time Warner Cable (we live too far from the CO to get good DSL speeds). On OS X I plug-in and get an IP from their DHCP server: http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt On FreeBSD their DHCP server seems to just ignore me (but I see lots of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've tried with both the standard dhclient and the isc dhclient from ports. 00:00:24:c9:23:c1 is my FreeBSD box (Soekris 5501 with vr ethernet): http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd.txt The OS X dump was made with dhcpdump 1.7 and sudo tcpdump -i en0 -s 1518 -lenx port bootps or port bootpc | ./ dhcpdump The FreeBSD one with "dhcpdump -i vr1". Below is a tcpdump of one of the DHCP requests. Any ideas would be greatly appreciated. - ask 15:46:02.424186 00:00:24:c9:23:c1 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:24:c9:23:c1, length 300 0x0000: 4510 0148 0000 0000 1011 a996 0000 0000 0x0010: ffff ffff 0044 0043 0134 43bb 0101 0600 0x0020: ea65 7a82 0000 0000 0000 0000 0000 0000 0x0030: 0000 0000 0000 0000 0000 24c9 23c1 0000 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d 0x0110: 0701 0000 24c9 23c1 0c05 6777 2d62 6e37 0x0120: 0801 1c02 7903 0f06 0cff 0000 0000 0000 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 0x0140: 0000 0000 0000 0000 From aman.jassal at esigetel.fr Tue Nov 3 16:21:58 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Tue Nov 3 16:22:05 2009 Subject: DHCP client not getting IP address from Time Warner In-Reply-To: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> References: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> Message-ID: <26570.83.206.131.26.1257265307.squirrel@webmail.esigetel.fr> Hello, The logs display something that I find very disturbing. In the dhcpdump log, the DHCPDISCOVER message your interface sends an erroneous MAC address, there is a "01:" that is added in front of the actual MAC address of your interface. What is sent in the discover message is "01:00:..." instead of "00:00:...". Then what happens explains itself : the DHCP server will send a DHCPOFFER by using the requesting client's MAC address, but since the given MAC address is wrong, he broadcasts it (which I don't think is the behaviour that is expected in normal cases...). I think this is also why the client doesn't emit a DHCPREQUEST (which is emitted by the client to confirm that it is choosing the proposed settings from the server, and implicitly turning down any other offers made by other servers). I'll look into it when I get back home (at work right now). If possible : could you try to connect your Time Warner cable with another interface ? Or the same one as the one you used under Mac OS X (that way we would see if we get the same behaviour, regardless of the network interface chosen) ? Kind regards, Aman Jassal Le Mar 3 novembre 2009 16:47, Ask Bj?rn Hansen a ?crit : > Hi everyone, > > > After years with Speakeasy at home I'm trying out Time Warner Cable > (we live too far from the CO to get good DSL speeds). > > > On OS X I plug-in and get an IP from their DHCP server: > > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt > > > On FreeBSD their DHCP server seems to just ignore me (but I see lots > of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've tried > with both the standard dhclient and the isc dhclient from ports. > > 00:00:24:c9:23:c1 is my FreeBSD box (Soekris 5501 with vr ethernet): > > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd.txt > > > The OS X dump was made with dhcpdump 1.7 and > > > sudo tcpdump -i en0 -s 1518 -lenx port bootps or port bootpc | ./ dhcpdump > > > The FreeBSD one with "dhcpdump -i vr1". > > > Below is a tcpdump of one of the DHCP requests. > > > Any ideas would be greatly appreciated. > > > > - ask > > > > 15:46:02.424186 00:00:24:c9:23:c1 > ff:ff:ff:ff:ff:ff, ethertype IPv4 > (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 00:00:24:c9:23:c1, length 300 > 0x0000: 4510 0148 0000 0000 1011 a996 0000 0000 > 0x0010: ffff ffff 0044 0043 0134 43bb 0101 0600 > 0x0020: ea65 7a82 0000 0000 0000 0000 0000 0000 > 0x0030: 0000 0000 0000 0000 0000 24c9 23c1 0000 > 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d > 0x0110: 0701 0000 24c9 23c1 0c05 6777 2d62 6e37 > 0x0120: 0801 1c02 7903 0f06 0cff 0000 0000 0000 > 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0140: 0000 0000 0000 0000 > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From barney at databus.com Tue Nov 3 17:05:04 2009 From: barney at databus.com (Barney Wolff) Date: Tue Nov 3 17:06:26 2009 Subject: DHCP client not getting IP address from Time Warner In-Reply-To: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> References: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> Message-ID: <20091103162737.GA93090@pit.databus.com> Power-cycle your cable box, leaving it off for a few minutes. Cable co's seem to check the MAC, and take a while to forget the previous one. On Tue, Nov 03, 2009 at 07:47:14AM -0800, Ask Bjrn Hansen wrote: > Hi everyone, > > After years with Speakeasy at home I'm trying out Time Warner Cable > (we live too far from the CO to get good DSL speeds). > > On OS X I plug-in and get an IP from their DHCP server: > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt > > On FreeBSD their DHCP server seems to just ignore me (but I see lots > of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've > tried with both the standard dhclient and the isc dhclient from ports. From ask at develooper.com Tue Nov 3 17:15:12 2009 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue Nov 3 17:15:19 2009 Subject: DHCP client not getting IP address from Time Warner In-Reply-To: <26570.83.206.131.26.1257265307.squirrel@webmail.esigetel.fr> References: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> <26570.83.206.131.26.1257265307.squirrel@webmail.esigetel.fr> Message-ID: On Nov 3, 2009, at 8:21, JASSAL Aman wrote: > Hello, > > The logs display something that I find very disturbing. > In the dhcpdump log, the DHCPDISCOVER message your interface sends an > erroneous MAC address, there is a "01:" that is added in front of the > actual MAC address of your interface. What is sent in the discover > message > is "01:00:..." instead of "00:00:...". Hi Aman, Yeah - I should have pointed that out. I tried forcing it to be correct with interface "vr1" { send dhcp-client-identifier 00:00:24:c9:23:c1; } to no effect. http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd-2.txt > Then what happens explains itself : the DHCP server will send a > DHCPOFFER > by using the requesting client's MAC address, but since the given MAC > address is wrong, he broadcasts it (which I don't think is the > behaviour > that is expected in normal cases...). I thought the broadcasts were misguided responses to me, too, at first -- but looking further I think it's just broadcasting when it's giving (or not) IPs to other clients. I've no idea why it does that. I only included one, but in http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt you can see that on OS X I get the weird replies to ff:ff:ff:ff:ff:ff, too. I also noticed that OS X adds two extra options in the request: OPTION: 57 ( 2) Maximum DHCP message size 1500 OPTION: 51 ( 4) IP address leasetime 7776000 (12w6d) Just to test how can I make dhclient add those, too? > I think this is also why the client doesn't emit a DHCPREQUEST > (which is > emitted by the client to confirm that it is choosing the proposed > settings > from the server, and implicitly turning down any other offers made by > other servers). > > I'll look into it when I get back home (at work right now). If > possible : > could you try to connect your Time Warner cable with another > interface ? > Or the same one as the one you used under Mac OS X (that way we > would see > if we get the same behaviour, regardless of the network interface > chosen) > ? The Soekris box only has vr interfaces; the OS X NIC is in my laptop so unless I install FreeBSD on there I won't be able to test that. :-) I did actually try one of the other vr interfaces on the Soekris box with the same result (they work fine with isc-dhcp running on another FreeBSD box). - ask From ask at develooper.com Tue Nov 3 17:15:56 2009 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue Nov 3 17:16:02 2009 Subject: DHCP client not getting IP address from Time Warner In-Reply-To: <20091103162737.GA93090@pit.databus.com> References: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> <20091103162737.GA93090@pit.databus.com> Message-ID: On Nov 3, 2009, at 8:27, Barney Wolff wrote: > Power-cycle your cable box, leaving it off for a few minutes. > Cable co's seem to check the MAC, and take a while to forget > the previous one. Hah - yeah, I tried that, too. No difference. (Plugging in one of the macs and then another seems to work fine, too). Thanks for the idea though. - ask From pyunyh at gmail.com Tue Nov 3 18:28:21 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Nov 3 18:28:27 2009 Subject: Marvell 88E8057 In-Reply-To: <4AEFC390.2090600@el.net> References: <4AE2780F.4080600@el.net> <20091024214640.GE6050@michelle.cdnetworks.com> <20091024215219.GF6050@michelle.cdnetworks.com> <4AEFC390.2090600@el.net> Message-ID: <20091103182739.GE1256@michelle.cdnetworks.com> On Tue, Nov 03, 2009 at 12:45:52AM -0500, kalin m wrote: > > hi pyun... and all.... > > after a few hours i'm sorry to report that the card is visible but not > usable (yet?!). here is what i have done so far: > > 1. got the files from http://svn.freebsd.org/viewvc/base/head/sys/dev/ > 2. applied the patch that pyun provided. > 3. replaced if_maddr_rlock(ifp) with IF_ADDR_UNLOCK(ifp) in if_msk.c - > two instances. > 4. replaced the files in /usr/src/sys/dev for mii and msk with he new > ones on the freebsd 7.2 machine. > 5. recompiled the kernel.. > > here is what i get: > > from dmesg at boot: > > mskc0: port 0xde00-0xdeff mem > 0xfddfc000-0xfddfffff irq 18 at device 0.0 on pci2 > mskc0: unknown device: id=0xba, rev=0x00 > device_attach: mskc0 attach returned 6 > > cant find what 6 stands for but it's not good.. > Sorry, there was a check that keep 88E8057 from attaching. I've regenerated patch. -------------- next part -------------- Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 198812) +++ sys/dev/msk/if_msk.c (working copy) @@ -223,6 +223,8 @@ "Marvell Yukon 88E8071 Gigabit Ethernet" }, { VENDORID_MARVELL, DEVICEID_MRVL_436C, "Marvell Yukon 88E8072 Gigabit Ethernet" }, + { VENDORID_MARVELL, DEVICEID_MRVL_4380, + "Marvell Yukon 88E8057 Gigabit Ethernet" }, { VENDORID_DLINK, DEVICEID_DLINK_DGE550SX, "D-Link 550SX Gigabit Ethernet" }, { VENDORID_DLINK, DEVICEID_DLINK_DGE560SX, @@ -237,7 +239,9 @@ "Yukon EX", "Yukon EC", "Yukon FE", - "Yukon FE+" + "Yukon FE+", + "Yukon Supreme", + "Yukon Ultra 2" }; static int mskc_probe(device_t); @@ -1144,6 +1148,7 @@ case CHIP_ID_YUKON_EC_U: case CHIP_ID_YUKON_EX: case CHIP_ID_YUKON_FE_P: + case CHIP_ID_YUKON_UL_2: CSR_WRITE_2(sc, B0_CTST, Y2_HW_WOL_OFF); /* Enable all clocks. */ @@ -1647,7 +1652,8 @@ sc->msk_hw_rev = (CSR_READ_1(sc, B2_MAC_CFG) >> 4) & 0x0f; /* Bail out if chip is not recognized. */ if (sc->msk_hw_id < CHIP_ID_YUKON_XL || - sc->msk_hw_id > CHIP_ID_YUKON_FE_P) { + sc->msk_hw_id > CHIP_ID_YUKON_UL_2 || + sc->msk_hw_id == CHIP_ID_YUKON_SUPR) { device_printf(dev, "unknown device: id=0x%02x, rev=0x%02x\n", sc->msk_hw_id, sc->msk_hw_rev); mtx_destroy(&sc->msk_mtx); @@ -1746,6 +1752,10 @@ sc->msk_clock = 156; /* 156 Mhz */ sc->msk_pflags |= MSK_FLAG_JUMBO; break; + case CHIP_ID_YUKON_UL_2: + sc->msk_clock = 156; /* 156 Mhz */ + sc->msk_pflags |= MSK_FLAG_JUMBO; + break; default: sc->msk_clock = 156; /* 156 Mhz */ break; Index: sys/dev/msk/if_mskreg.h =================================================================== --- sys/dev/msk/if_mskreg.h (revision 198812) +++ sys/dev/msk/if_mskreg.h (working copy) @@ -144,6 +144,7 @@ #define DEVICEID_MRVL_436A 0x436A #define DEVICEID_MRVL_436B 0x436B #define DEVICEID_MRVL_436C 0x436C +#define DEVICEID_MRVL_4380 0x4380 /* * D-Link gigabit ethernet device ID @@ -891,6 +892,8 @@ #define CHIP_ID_YUKON_EC 0xb6 /* Chip ID for YUKON-2 EC */ #define CHIP_ID_YUKON_FE 0xb7 /* Chip ID for YUKON-2 FE */ #define CHIP_ID_YUKON_FE_P 0xb8 /* Chip ID for YUKON-2 FE+ */ +#define CHIP_ID_YUKON_SUPR 0xb9 /* Chip ID for YUKON-2 Supreme */ +#define CHIP_ID_YUKON_UL_2 0xba /* Chip ID for YUKON-2 Ultra 2 */ #define CHIP_REV_YU_XL_A0 0 /* Chip Rev. for Yukon-2 A0 */ #define CHIP_REV_YU_XL_A1 1 /* Chip Rev. for Yukon-2 A1 */ From jhb at FreeBSD.org Tue Nov 3 20:29:28 2009 From: jhb at FreeBSD.org (John Baldwin) Date: Tue Nov 3 20:29:34 2009 Subject: Small bug with TCP zero windows Message-ID: <200911031529.26514.jhb@FreeBSD.org> Several years ago Dillon added a feature to TCP that casued soreceive() to send an ACK right away if data was drained from a TCP socket that had previously advertised a zero-sized window. The current code requires the receive window to be exactly zero for this to kick in. If window scaling is enabled and the window is smaller than the scale, then the effective window that is advertised is zero. However, in that case the zero-sized window handling is not enabled because the window is not exactly zero. The patch below changes the code to check the raw window value against zero. Arguably it could check 'th_win' directly instead if folks would prefer that. Index: tcp_output.c =================================================================== --- tcp_output.c (revision 198794) +++ tcp_output.c (working copy) @@ -992,7 +992,7 @@ * to read more data than can be buffered prior to transmitting on * the connection. */ - if (recwin == 0) + if (recwin >> tp->rcv_scale == 0) tp->t_flags |= TF_RXWIN0SENT; else tp->t_flags &= ~TF_RXWIN0SENT; -- John Baldwin From bzeeb-lists at lists.zabbadoz.net Tue Nov 3 21:30:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Nov 3 21:30:16 2009 Subject: Small bug with TCP zero windows In-Reply-To: <200911031529.26514.jhb@FreeBSD.org> References: <200911031529.26514.jhb@FreeBSD.org> Message-ID: <20091103212129.F37440@maildrop.int.zabbadoz.net> On Tue, 3 Nov 2009, John Baldwin wrote: > Several years ago Dillon added a feature to TCP that casued soreceive() to > send an ACK right away if data was drained from a TCP socket that had > previously advertised a zero-sized window. The current code requires the > receive window to be exactly zero for this to kick in. If window scaling is > enabled and the window is smaller than the scale, then the effective window > that is advertised is zero. However, in that case the zero-sized window > handling is not enabled because the window is not exactly zero. The patch > below changes the code to check the raw window value against zero. Arguably > it could check 'th_win' directly instead if folks would prefer that. hmm, looking a few lines up, there is a htons() there as well; obviously doesn't matter for 0. th_win is set to something different for SYNs. I guess what you are doing is ok, and even though it is not needed, I feel that it would be easier to read it with an extra pair of (). > Index: tcp_output.c > =================================================================== > --- tcp_output.c (revision 198794) > +++ tcp_output.c (working copy) > @@ -992,7 +992,7 @@ > * to read more data than can be buffered prior to transmitting on > * the connection. > */ > - if (recwin == 0) > + if (recwin >> tp->rcv_scale == 0) > tp->t_flags |= TF_RXWIN0SENT; > else > tp->t_flags &= ~TF_RXWIN0SENT; > > -- Bjoern A. Zeeb It will not break if you know what you are doing. From aman.jassal at esigetel.fr Wed Nov 4 08:18:59 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Wed Nov 4 08:19:06 2009 Subject: DHCP client not getting IP address from Time Warner Message-ID: <63471.83.206.131.26.1257322728.squirrel@webmail.esigetel.fr> Hello Ask, Sorry for getting back to you so late T_T... I've never faced a MAC address problem before, so I must say I was quite surprised when I saw your logs yesterday evening. I'm not sure what the nature of the problem exactly is (I didn't have time to reproduce it yesterday evening either >_<), I would suggest that you create your own dhclient.conf file (-> /etc/dhclient.conf) and specify the options you want to send in the DHCPDISCOVER message yourself. The dhclient program starts by reading what is specified in this file. You could try sending : send { dhcp-client-identifier "your MAC address" ip-address "whatever IP address is topologically correct and with the defined range of address the server can allocate" } With this, you clearly specify the MAC and the IP address you are requesting (it is the parameters in the options field). You can also specify other parameters if you wish to. When you forced it, the MAC address was the good one, so that is good sign. In the last log you sent (dhcp-freebsd-2.txt), the server is sending back DHCPNAK messages, which occur in only 2 cases : either the client is requesting an address that is topologically incorrect, or the lease of the requested address has expired. But this, to me, looks like the DHCP server was slightly confused about what was going on :) Just try power-cycling your Time Warner device, so that he doesn't have any record of any address. If you specify clearly the options in your dhcpdiscover message by setting them in the dhclient.conf, there's no reason the DHCP server will reject your message. Whenever I configure my connection settings manually, I just type : # dhclient iwn0 (My interface uses iwn driver), and that works perfectly... I don't even have a dhclient.conf file ! Hopefully it (setting up dhclient.conf) helps. Kind regards, Aman Jassal Le Mar 3 novembre 2009 18:15, Ask Bj?rn Hansen a ?crit : > > On Nov 3, 2009, at 8:21, JASSAL Aman wrote: > > >> Hello, >> >> >> The logs display something that I find very disturbing. >> In the dhcpdump log, the DHCPDISCOVER message your interface sends an >> erroneous MAC address, there is a "01:" that is added in front of the >> actual MAC address of your interface. What is sent in the discover >> message is "01:00:..." instead of "00:00:...". > > Hi Aman, > > > Yeah - I should have pointed that out. I tried forcing it to be > correct with > > interface "vr1" { send dhcp-client-identifier 00:00:24:c9:23:c1; } > > > to no effect. > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd-2.txt > > >> Then what happens explains itself : the DHCP server will send a >> DHCPOFFER >> by using the requesting client's MAC address, but since the given MAC >> address is wrong, he broadcasts it (which I don't think is the behaviour >> that is expected in normal cases...). > > I thought the broadcasts were misguided responses to me, too, at first > -- but looking further I think it's just broadcasting when it's giving > (or not) IPs to other clients. I've no idea why it does that. >%20 > > I only included one, but in > http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt > you can see that on OS X I get the weird replies to ff:ff:ff:ff:ff:ff, too. > > > I also noticed that OS X adds two extra options in the request: > > > OPTION: 57 ( 2) Maximum DHCP message size 1500 > OPTION: 51 ( 4) IP address leasetime 7776000 (12w6d) > > > Just to test how can I make dhclient add those, too? > > >>%20I think this is also why the client doesn't emit a DHCPREQUEST >> (which is >> emitted by the client to confirm that it is choosing the proposed >> settings from the server, and implicitly turning down any other offers >> made by other servers). >> >> I'll look into it when I get back home (at work right now). If >> possible : could you try to connect your Time Warner cable with another >> interface ? Or the same one as the one you used under Mac OS X %28that way >> we would see if we get the same behaviour, regardless of the network >> interface chosen) ? >> > > The Soekris box only has vr interfaces; the OS X NIC is in my laptop > so unless I install FreeBSD on there I won't be able to test that. :-) I > did actually try one of the other vr interfaces on the Soekris box with > the same result (they work fine with isc-dhcp running on another FreeBSD > box). > > > - ask > > From jhb at freebsd.org Wed Nov 4 18:17:24 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 4 18:17:41 2009 Subject: Small bug with TCP zero windows In-Reply-To: <20091103212129.F37440@maildrop.int.zabbadoz.net> References: <200911031529.26514.jhb@FreeBSD.org> <20091103212129.F37440@maildrop.int.zabbadoz.net> Message-ID: <200911041317.06793.jhb@freebsd.org> On Tuesday 03 November 2009 4:26:48 pm Bjoern A. Zeeb wrote: > On Tue, 3 Nov 2009, John Baldwin wrote: > > > Several years ago Dillon added a feature to TCP that casued soreceive() to > > send an ACK right away if data was drained from a TCP socket that had > > previously advertised a zero-sized window. The current code requires the > > receive window to be exactly zero for this to kick in. If window scaling is > > enabled and the window is smaller than the scale, then the effective window > > that is advertised is zero. However, in that case the zero-sized window > > handling is not enabled because the window is not exactly zero. The patch > > below changes the code to check the raw window value against zero. Arguably > > it could check 'th_win' directly instead if folks would prefer that. > > hmm, looking a few lines up, there is a htons() there as well; > obviously doesn't matter for 0. th_win is set to something different > for SYNs. I guess what you are doing is ok, and even though it is not > needed, I feel that it would be easier to read it with an extra pair > of (). How about using 'if (th->th_win == htons(0))' for the condition? > > Index: tcp_output.c > > =================================================================== > > --- tcp_output.c (revision 198794) > > +++ tcp_output.c (working copy) > > @@ -992,7 +992,7 @@ > > * to read more data than can be buffered prior to transmitting on > > * the connection. > > */ > > - if (recwin == 0) > > + if (recwin >> tp->rcv_scale == 0) > > tp->t_flags |= TF_RXWIN0SENT; > > else > > tp->t_flags &= ~TF_RXWIN0SENT; > > > > > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > -- John Baldwin From kohls at e.kohls.com Wed Nov 4 18:24:12 2009 From: kohls at e.kohls.com (Kohls.com) Date: Wed Nov 4 18:24:18 2009 Subject: 50% Off SALE + Extra 15% Off Holiday Decor Message-ID: To view the HTML version of this e-mail, copy and paste the link below into the Address field of your Internet browser: http://e.kohls.com/a/tBK79ULBBZVhBB724FRBVGUbA-8/kohl1?t=BK79ULBBZVhBB724FRBVGUbA-8&email=freebsd-net@freebsd.org&i_equity=0 ************************************************************************ 99? Standard Shipping on every item!* Surcharges still apply. ************************************************************************ Take an EXTRA 15% Off** Entire Stock Holiday Decor! Simply enter Promo Code HOLIDAYHOME when you checkout online now through November 5 during our 50% Off Sale! 50% Off Selected Holiday Dinnerware & Table Linens 50% Off Selected Candles & Decorative Accents 50% Off Entire Stock St. Nicholas Square Trim-A-Tree & Home Decor ************************************************************************ Skechers Shape-Ups Shape up while you walk! Designed to: -Promote weight loss -Tone muscles -Improve posture ************************************************************************ Find Kohl's on Facebook! Become a fan to connect with friends and get insider info. ************************************************************************ *Surcharges may apply due to size, weight or special handling required. If your item has a surcharge, it will appear on the product page. **OFFER IS VALID ONLINE ONLY. Offer is not valid in conjunction with any other percent-off discounts. Offer is nontransferable. Promo Code must be entered during checkout on Kohls.com to receive discount. Offer good on all sale-, regular- and clearance-priced merchandise. Offer not valid for price adjustments on prior purchases, on gift card purchases, for payment on a Kohl's Charge account or in conjunction with any other percent-off discounts, including the senior citizen discount. Offer also not valid on purchases of Kohl's Cares for Kids merchandise or other charitable items. Excludes sales tax. This mailbox is unattended, so please do not reply to this message. Instead, e-mail us at myaccount.help@kohls.com, or write to us at Kohl's Department Stores, Attention: Customer Service, N54 W13600 Woodale Drive, Menomonee Falls, WI 53051. If you no longer wish to receive e-mails from Kohls.com, unsubscribe by pasting this link into the Address field of your Internet browser: http://e.kohls.com/a/tBK79ULBBZVhBB724FRBVGUbA-8/kohl14?email=freebsd-net@freebsd.org&email=freebsd-net@freebsd.org Please allow up to seven days for your e-mail address to be removed. 99? Standard Shipping per item offer good now through November 5, 2009. 50% Off Sale prices good now through November 5, 2009. Extra 15% Off Holiday Decor offer good now through November 5, 2009. From kalin at el.net Wed Nov 4 23:46:05 2009 From: kalin at el.net (kalin m) Date: Wed Nov 4 23:46:12 2009 Subject: ral driver In-Reply-To: <4AEFB781.90409@el.net> References: <4AEFB781.90409@el.net> Message-ID: <4AF211A1.3090007@el.net> just a follow up on this. any ideas. can i just get newer/fixed driver? thanks... kalin m wrote: > > > hi all.... > > is this resolved in current or head? > > http://lists.freebsd.org/pipermail/freebsd-bugs/2009-May/035231.html > > i have this ral card that drops off after about 15 min or so and have > the same symptoms as described in that bug report.. > > > thank you... > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From is at rambler-co.ru Thu Nov 5 08:30:04 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Thu Nov 5 08:30:11 2009 Subject: maximum number of outgoing connections In-Reply-To: <20070820163443.GE20183@rambler-co.ru> References: <20070820151142.GA20183@rambler-co.ru> <46C9BF02.5050007@tomjudge.com> <20070820163443.GE20183@rambler-co.ru> Message-ID: <20091105083001.GC87654@rambler-co.ru> On Mon, Aug 20, 2007 at 08:34:43PM +0400, Igor Sysoev wrote: > On Mon, Aug 20, 2007 at 05:19:14PM +0100, Tom Judge wrote: > > > Igor Sysoev wrote: > > >It seems that FreeBSD can not make more than > > > > > >net.inet.ip.portrange.last - net.inet.ip.portrange.first > > > > > >simultaneous outgoing connections, i.e., no more than about 64k. > > > > > >If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then > > >connect() to an external address returns EADDRNOTAVAIL. > > > > > >net.inet.ip.portrange.randomized is 0. > > > > > >sockets, etc. are enough: > > > > > >ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > > >socket: 356, 204809, 13915, 146443, 148189452, 0 > > >inpcb: 180, 204820, 20375, 137277, 147631805, 0 > > >tcpcb: 464, 204800, 13882, 142102, 147631805, 0 > > >tcptw: 48, 41028, 6493, 11213, 29804665, 0 > > > > > >I saw it on 6.2-STABLE. > > > > > > > > > > In an ideal world (Not sure if this is quite correct for FreeBSD) TCP > > connections are tracked with a pair of tupels source-addr:src-port -> > > dst-addr:dst-port > > > > As your always connecting to the same destination service 127.0.0.1:80 > > and always from the same source IP 127.0.0.1 then you only have one > > variable left to change, the source port. If you where to use the hole > > of the whole of the port range minus the reserved ports you would only > > ever be able to make 64512 simultaneous connections. In order to make > > more connections the first thing that you may want to start changing is > > the source IP. If you added a second IP to you lo0 interface (say > > 127.0.0.2) and used a round robin approach to making your out bound > > connections then you could make around 129k outbound connections. > > Connections to 127.0.0.1 were via lo0, external connections are via bge0. > > > I am not sure if there are any other constraints that need to be taken > > into account such as the maximum number of sockets, RAM etc.... > > No, there are no constraints in memory, sockets, mbufs, clusters, etc. > If there's contraint in memory, then FreeBSD simply panics. > If there's contraint in mbuf clusters, then process stucks in zonelimit > state forever. > > I suspect that local address in in_pcbbind_setup() is 0.0.0.0 so there > is 64K limit. Recently I looked the issue again and find (with Ruslan Ermilov's help) that if I set the SO_REUSEADDR option, FreeBSD allows to use the same local port for different connections: 192.168.1.1:5000 > 10.0.0.1:80 192.168.1.1:5000 > 10.0.0.2:80 Linux allows this by default. I believe FreeBSD should set SO_REUSEADDR internally while connect(). BTW, bind()ing socket to a local address does not help. -- Igor Sysoev http://sysoev.ru/en/ From brueffer at FreeBSD.org Thu Nov 5 16:30:56 2009 From: brueffer at FreeBSD.org (brueffer@FreeBSD.org) Date: Thu Nov 5 16:31:03 2009 Subject: kern/138378: [altq] [patch] Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c Message-ID: <200911051630.nA5GUts0071692@freefall.freebsd.org> Synopsis: [altq] [patch] Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c State-Changed-From-To: open->patched State-Changed-By: brueffer State-Changed-When: Thu Nov 5 17:30:26 CET 2009 State-Changed-Why: Committed, thanks! Responsible-Changed-From-To: freebsd-net->brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Thu Nov 5 17:30:26 CET 2009 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=138378 From information at directsource-network.com Thu Nov 5 19:08:18 2009 From: information at directsource-network.com (Build a New Website) Date: Thu Nov 5 19:08:26 2009 Subject: Your New Website is Here Message-ID: In this economy many Small Businesses cannot afford the high costs involved in setting up and running a website. Whether it be the designer or SEO related costs, for many the investment is just too expensive in this current climate. Today there is a Company called WebStarts that will allow you to build a FREE Website that is simple to create and very easy to maintain. For More information click the following URL: http://budurl.com/pe4v Sign Up for your FREE Website Today! From information at directsource-network.com Thu Nov 5 19:08:21 2009 From: information at directsource-network.com (Build a New Website) Date: Thu Nov 5 19:08:43 2009 Subject: Your New Website is Here Message-ID: In this economy many Small Businesses cannot afford the high costs involved in setting up and running a website. Whether it be the designer or SEO related costs, for many the investment is just too expensive in this current climate. Today there is a Company called WebStarts that will allow you to build a FREE Website that is simple to create and very easy to maintain. For More information click the following URL: http://budurl.com/pe4v Sign Up for your FREE Website Today! From information at directsource-network.com Thu Nov 5 19:08:21 2009 From: information at directsource-network.com (Build a New Website) Date: Thu Nov 5 19:08:44 2009 Subject: Your New Website is Here Message-ID: In this economy many Small Businesses cannot afford the high costs involved in setting up and running a website. Whether it be the designer or SEO related costs, for many the investment is just too expensive in this current climate. Today there is a Company called WebStarts that will allow you to build a FREE Website that is simple to create and very easy to maintain. For More information click the following URL: http://budurl.com/pe4v Sign Up for your FREE Website Today! From sobomax at FreeBSD.org Fri Nov 6 01:41:27 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Nov 6 01:41:33 2009 Subject: em0: watchdog timeout when communicating to windows using 9K MTU Message-ID: <4AF3795F.7010103@FreeBSD.org> Hi, My em0 interface repeatedly hangs up with watchdog timeout when communicating to the windows host at MTU 9K. [sobomax@pioneer ~]$ grep em0 /var/run/dmesg.boot em0: port 0xecc0-0xecdf mem 0xfe6e0000-0xfe6fffff,0xfe6d9000-0xfe6d9fff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:22:19:32:87:2f [sobomax@pioneer ~]$ uname -a FreeBSD pioneer.sippysoft.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Sun Oct 4 03:08:04 PDT 2009 root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIONEER amd64 [sobomax@pioneer ~]$ ifconfig em0 em0: flags=8843 metric 0 mtu 9000 options=98 ether 00:22:19:32:87:2f inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 inet6 fec0::1 prefixlen 64 media: Ethernet autoselect (1000baseTX ) status: active [sobomax@pioneer ~]$ dmesg | grep watchd em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting I have managed to make a packet capture right at the time when hang happens. It appears to be that either "MAC Pause" or "TCP Segment of reassembled PDU" is the last packet that goes through before the interface hangs. Here is the screenshot, if somebody wants to take closer look at the actual packets please let me know. http://sobomax.sippysoft.com/~sobomax/ScreenShot527.png Turning off TSO and TXCSUM/RXCSUM has not helped. Bringing MTU down to 1,500 resolved the problem immediately. I have had the same problem happening several times in the past (although I initially attributed it to the bad cable or something like that), so it's definitely not on-off issue. Given popularity of intel/pro chips in today's computers it look like quite serious issue to me. Any help is greatly appreciated. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From linimon at FreeBSD.org Fri Nov 6 04:35:17 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Nov 6 04:35:29 2009 Subject: kern/140326: [em] em0: watchdog timeout when communicating to windows using 9K MTU Message-ID: <200911060435.nA64ZHIi094328@freefall.freebsd.org> Old Synopsis: em0: watchdog timeout when communicating to windows using 9K MTU New Synopsis: [em] em0: watchdog timeout when communicating to windows using 9K MTU Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 6 04:35:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140326 From jfvogel at gmail.com Fri Nov 6 05:10:04 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Nov 6 05:10:11 2009 Subject: kern/140326: em0: watchdog timeout when communicating to windows using 9K MTU Message-ID: <200911060510.nA65A3X1023785@freefall.freebsd.org> The following reply was made to PR kern/140326; it has been noted by GNATS. From: Jack Vogel To: Maxim Sobolev Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows using 9K MTU Date: Thu, 5 Nov 2009 21:05:11 -0800 --0016e6dab0fde1e7870477acc9ad Content-Type: text/plain; charset=ISO-8859-1 Good, that's a start. Now, is there a switch of some sort involved or are you going back to back? Some switches have problems with jumbo frames, there are also some vendors (including our's) interfaces that do not support jumbo frames, so you need to check on that also (I mean the RT). I will check on the Intel adapter tomorrow. Jack On Thu, Nov 5, 2009 at 6:28 PM, Maxim Sobolev wrote: > Jack Vogel wrote: > >> Can't do much unless you adequately identify hardware, on BOTH sides, >> believe >> it or not "windows" is not a sufficient description :) >> >> I need to know what the E1000 hardware is, using pciconf -l, and I also >> need to >> know what is on the Windows side before having a clue on how to repro or >> help >> you. >> > > Jack, > > Thank you for the amazingly fast reply. > > Sure, FreeBSD side is this: > > em0@pci0:0:25:0: class=0x020000 card=0x02761028 chip=0x10de8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > On windows side it's Realtek GiGe card. The system itself is Windows 7 > Ultimate 64-bit edition: > > PCI\VEN_10EC&DEV_8168&SUBSYS_02C01028&REV_03 > > Please let me know if any other information is necessary. > > Regards, > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > T/F: +1-646-651-1110 > Web: http://www.sippysoft.com > MSN: sales@sippysoft.com > Skype: SippySoft > --0016e6dab0fde1e7870477acc9ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good, that's a start. Now, is there a switch of some sort involved or a= re you going
back to back? Some switches have problems with jumbo frames= , there are also
some vendors (including our's) interfaces that do n= ot support jumbo frames, so
you need to check on that also (I mean the RT).

I will check on the = Intel adapter tomorrow.

Jack


O= n Thu, Nov 5, 2009 at 6:28 PM, Maxim Sobolev <sobomax@freebsd.org> wrote:
Jack Vogel wrote:
Can't do much unless you adequately identify hardware, on BOTH sides, b= elieve
it or not "windows" is not a sufficient description :)

I need to know what the E1000 hardware is, using pciconf -l, and I also nee= d to
know what is on the Windows side before having a clue on how to repro or he= lp
you.

Jack,

Thank you for the amazingly fast reply.

Sure, FreeBSD side is this:

em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x02761028 chip=3D0= x10de8086 rev=3D0x02 hdr=3D0x00
=A0 =A0vendor =A0 =A0 =3D 'Intel Corporation'
=A0 =A0class =A0 =A0 =A0=3D network
=A0 =A0subclass =A0 =3D ethernet

On windows side it's Realtek GiGe card. The system itself is Windows 7 = Ultimate 64-bit edition:

PCI\VEN_10EC&DEV_8168&SUBSYS_02C01028&REV_03

Please let me know if any other information is necessary.

Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sipp= ysoft.com
MSN: sales@sippyso= ft.com
Skype: SippySoft

--0016e6dab0fde1e7870477acc9ad-- From sobomax at FreeBSD.org Fri Nov 6 08:40:03 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Nov 6 08:40:10 2009 Subject: kern/140326: em0: watchdog timeout when communicating to windows using 9K MTU Message-ID: <200911060840.nA68e2bl035948@freefall.freebsd.org> The following reply was made to PR kern/140326; it has been noted by GNATS. From: Maxim Sobolev To: Jack Vogel Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows using 9K MTU Date: Fri, 06 Nov 2009 00:30:33 -0800 Jack Vogel wrote: > Good, that's a start. Now, is there a switch of some sort involved or > are you going > back to back? Some switches have problems with jumbo frames, there are also > some vendors (including our's) interfaces that do not support jumbo > frames, so > you need to check on that also (I mean the RT). > > I will check on the Intel adapter tomorrow. Yes, there is switch involved (Cisco/Linksys EG008W ver.3), but I don't think it's related. The problem has really escalated when I installed Windows 7 on this machine yesterday. Before that the same machine with Realtek was running Vista and this problem had happened to me only once or twice in two weeks with the same MTU on both ends. And from the capture it seems like the very specific condition causes this. Unfortunately this box is a gateway for a network, so that I cannot replace hub and try to reproduce the issue. -Maxim From john at dnepro.net Fri Nov 6 09:25:38 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Fri Nov 6 09:25:44 2009 Subject: Permanent arp entry expires in 20 seconds on 8.0-RC2 Message-ID: <20091106092532.GA67155@traktor.dnepro.net> Hello freebsd-network readers! This is on FreeBSD 8.0-RC2 (sys/netinet/in.c is 1.143.2.9.2.1) If I try to set permanent arp entry with "arp -s host etheraddr" and there exists an "incomplete" entry for this host at the moment, then this "permanent" entry will expire in 20 seconds. If I set arp with "arp -S host etheraddr" - it will be really permanent. It looks like with "-s" the flag of incompleteness isn't cleared. Is this a bug or a feature? -- Eugene Perevyazko From sobomax at FreeBSD.org Fri Nov 6 10:00:20 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Nov 6 10:00:26 2009 Subject: kern/140326: em0: watchdog timeout when communicating to windows using 9K MTU Message-ID: <200911061000.nA6A0JbL079989@freefall.freebsd.org> The following reply was made to PR kern/140326; it has been noted by GNATS. From: Maxim Sobolev To: Jack Vogel Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows using 9K MTU Date: Fri, 06 Nov 2009 01:58:52 -0800 Jack, Here is some additional info you might find useful: I have replaced Linksys switch with more "professional" rack-mountable 3Com Baseline 2816 switch and reproduced the issue just as easy by copying large file via SMB from FReeBSD to Windows 7. To me it pretty much rules out any problems with the switch. Hope it helps. -Maxim From attilio at freebsd.org Fri Nov 6 15:17:38 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 15:17:45 2009 Subject: [PATCH] Moving inet_aton() definition into libkern Message-ID: <3bbf2fe10911060645rf59a3e5h392bb8376b861444@mail.gmail.com> [Please don't forget to CC me because I'm not subscribed to net@] This patch moves inet_aton() (specular to inet_ntoa(), already present in libkern) into libkern: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/inet_aton/inet_aton.diff http://www.freebsd.org/~attilio/Sandvine/STABLE_8/inet_aton/inet_aton.c Please note that I did use the inet_aton() already present in stock FreeBSD with just some whitelines adds before the comments (as mandates by style(9)). Please review. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From iprebeg at freebsd.org Fri Nov 6 18:10:10 2009 From: iprebeg at freebsd.org (iprebeg@freebsd.org) Date: Fri Nov 6 18:10:30 2009 Subject: ng_bridge with igmp snooping Message-ID: <20091106180001.GA28830@valeria.zesoi.fer.hr> Hi all I'm sending out first public preview of ng_bridge enhanced with IGMP snooping extensions. Code can be obtained from perforce (/depot/user/iprebeg/ngb) or you can grab tarball from http://trinity.zesoi.fer.hr/~iprebeg/code/ngb.tar.bz2 I would really like to get an early feedback to know in which direction to go with it now. Please send your comments, impressions. Work is done under Marko Zec's menthorship. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091106/c7676d05/attachment.pgp From dfilter at FreeBSD.ORG Fri Nov 6 18:30:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Nov 6 18:30:20 2009 Subject: kern/126924: commit references a PR Message-ID: <200911061830.nA6IU4Ew021933@freefall.freebsd.org> The following reply was made to PR kern/126924; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126924: commit references a PR Date: Fri, 6 Nov 2009 18:28:24 +0000 (UTC) Author: jhb Date: Fri Nov 6 18:28:13 2009 New Revision: 198995 URL: http://svn.freebsd.org/changeset/base/198995 Log: - Use device_printf() instead of printf() with an explicit unit number in the PCI attach routine. - Simplify PCI probe. - Remove no-longer-used 'unit' from an_attach() parameters. PR: kern/126924 Submitted by: gavin Modified: head/sys/dev/an/if_an.c head/sys/dev/an/if_an_isa.c head/sys/dev/an/if_an_pccard.c head/sys/dev/an/if_an_pci.c head/sys/dev/an/if_anreg.h Modified: head/sys/dev/an/if_an.c ============================================================================== --- head/sys/dev/an/if_an.c Fri Nov 6 17:58:44 2009 (r198994) +++ head/sys/dev/an/if_an.c Fri Nov 6 18:28:13 2009 (r198995) @@ -674,7 +674,7 @@ an_init_mpi350_desc(struct an_softc *sc) } int -an_attach(struct an_softc *sc, int unit, int flags) +an_attach(struct an_softc *sc, int flags) { struct ifnet *ifp; int error = EIO; Modified: head/sys/dev/an/if_an_isa.c ============================================================================== --- head/sys/dev/an/if_an_isa.c Fri Nov 6 17:58:44 2009 (r198994) +++ head/sys/dev/an/if_an_isa.c Fri Nov 6 18:28:13 2009 (r198995) @@ -115,7 +115,7 @@ an_attach_isa(device_t dev) sc->an_btag = rman_get_bustag(sc->port_res); sc->an_dev = dev; - error = an_attach(sc, device_get_unit(dev), flags); + error = an_attach(sc, flags); if (error) { an_release_resources(dev); return (error); Modified: head/sys/dev/an/if_an_pccard.c ============================================================================== --- head/sys/dev/an/if_an_pccard.c Fri Nov 6 17:58:44 2009 (r198994) +++ head/sys/dev/an/if_an_pccard.c Fri Nov 6 18:28:13 2009 (r198995) @@ -145,7 +145,7 @@ an_pccard_attach(device_t dev) sc->an_btag = rman_get_bustag(sc->port_res); sc->an_dev = dev; - error = an_attach(sc, device_get_unit(dev), flags); + error = an_attach(sc, flags); if (error) goto fail; Modified: head/sys/dev/an/if_an_pci.c ============================================================================== --- head/sys/dev/an/if_an_pci.c Fri Nov 6 17:58:44 2009 (r198994) +++ head/sys/dev/an/if_an_pci.c Fri Nov 6 18:28:13 2009 (r198995) @@ -103,6 +103,7 @@ struct an_type { static struct an_type an_devs[] = { { AIRONET_VENDORID, AIRONET_DEVICEID_35x, "Cisco Aironet 350 Series" }, + { AIRONET_VENDORID, AIRONET_DEVICEID_MPI350, "Cisco Aironet MPI350" }, { AIRONET_VENDORID, AIRONET_DEVICEID_4500, "Aironet PCI4500" }, { AIRONET_VENDORID, AIRONET_DEVICEID_4800, "Aironet PCI4800" }, { AIRONET_VENDORID, AIRONET_DEVICEID_4xxx, "Aironet PCI4500/PCI4800" }, @@ -133,13 +134,6 @@ an_probe_pci(device_t dev) t++; } - if (pci_get_vendor(dev) == AIRONET_VENDORID && - pci_get_device(dev) == AIRONET_DEVICEID_MPI350) { - device_set_desc(dev, "Cisco Aironet MPI350"); - an_pci_probe(dev); - return(BUS_PROBE_DEFAULT); - } - return(ENXIO); } @@ -149,10 +143,9 @@ an_attach_pci(dev) { u_int32_t command; struct an_softc *sc; - int unit, flags, error = 0; + int flags, error = 0; sc = device_get_softc(dev); - unit = device_get_unit(dev); flags = device_get_flags(dev); if (pci_get_vendor(dev) == AIRONET_VENDORID && @@ -169,7 +162,7 @@ an_attach_pci(dev) command = pci_read_config(dev, PCIR_COMMAND, 4); if (!(command & PCIM_CMD_PORTEN)) { - printf("an%d: failed to enable I/O ports!\n", unit); + device_printf(dev, "failed to enable I/O ports!\n"); error = ENXIO; goto fail; } @@ -178,7 +171,7 @@ an_attach_pci(dev) error = an_alloc_port(dev, sc->port_rid, 1); if (error) { - printf("an%d: couldn't map ports\n", unit); + device_printf(dev, "couldn't map ports\n"); goto fail; } @@ -191,7 +184,7 @@ an_attach_pci(dev) sc->mem_rid = PCIR_BAR(1); error = an_alloc_memory(dev, sc->mem_rid, 1); if (error) { - printf("an%d: couldn't map memory\n", unit); + device_printf(dev, "couldn't map memory\n"); goto fail; } sc->an_mem_btag = rman_get_bustag(sc->mem_res); @@ -202,7 +195,7 @@ an_attach_pci(dev) error = an_alloc_aux_memory(dev, sc->mem_aux_rid, AN_AUX_MEM_SIZE); if (error) { - printf("an%d: couldn't map aux memory\n", unit); + device_printf(dev, "couldn't map aux memory\n"); goto fail; } sc->an_mem_aux_btag = rman_get_bustag(sc->mem_aux_res); @@ -222,7 +215,7 @@ an_attach_pci(dev) NULL, /* lockarg */ &sc->an_dtag); if (error) { - printf("an%d: couldn't get DMA region\n", unit); + device_printf(dev, "couldn't get DMA region\n"); goto fail; } } @@ -230,12 +223,14 @@ an_attach_pci(dev) /* Allocate interrupt */ error = an_alloc_irq(dev, 0, RF_SHAREABLE); if (error) { + device_printf(dev, "couldn't get interrupt\n"); goto fail; } sc->an_dev = dev; - error = an_attach(sc, device_get_unit(dev), flags); + error = an_attach(sc, flags); if (error) { + device_printf(dev, "couldn't attach\n"); goto fail; } @@ -244,6 +239,8 @@ an_attach_pci(dev) */ error = bus_setup_intr(dev, sc->irq_res, INTR_TYPE_NET, NULL, an_intr, sc, &sc->irq_handle); + if (error) + device_printf(dev, "couldn't setup interrupt\n"); fail: if (error) Modified: head/sys/dev/an/if_anreg.h ============================================================================== --- head/sys/dev/an/if_anreg.h Fri Nov 6 17:58:44 2009 (r198994) +++ head/sys/dev/an/if_anreg.h Fri Nov 6 18:28:13 2009 (r198995) @@ -511,7 +511,7 @@ int an_pci_probe (device_t); int an_probe (device_t); int an_shutdown (device_t); void an_resume (device_t); -int an_attach (struct an_softc *, int, int); +int an_attach (struct an_softc *, int); int an_detach (device_t); void an_stop (struct an_softc *); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From jhb at FreeBSD.org Fri Nov 6 18:33:33 2009 From: jhb at FreeBSD.org (jhb@FreeBSD.org) Date: Fri Nov 6 18:33:49 2009 Subject: kern/126924: [an] [patch] printf -> device_printf and simplify probe Message-ID: <200911061833.nA6IXXCL031759@freefall.freebsd.org> Synopsis: [an] [patch] printf -> device_printf and simplify probe State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Fri Nov 6 18:32:46 UTC 2009 State-Changed-Why: Patch applied to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=126924 From delphij at delphij.net Fri Nov 6 19:56:29 2009 From: delphij at delphij.net (Xin LI) Date: Fri Nov 6 19:56:37 2009 Subject: [Take 3] RFC: interface description In-Reply-To: <4A8601CE.5030205@delphij.net> References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> <4A8601CE.5030205@delphij.net> Message-ID: <4AF47F50.5070609@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here is a revised patchset based on previous comments. This version would store the description in kernel space, but struct ifnet would only have a reference to the sbuf storing the description, supporting arbitrary description length. Note that, because we now have a different KPI/API with OpenBSD's counterpart, this patchset would break some stuff like libpcap which expect OpenBSD API. Comments? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr0f08ACgkQi+vbBBjt66CLRwCfcn0b+95uQvAI5k+gs4VdQ6F+ DOcAniPvnqclIoxRbhzxI1uZOivqU/N9 =bB5n -----END PGP SIGNATURE----- -------------- next part -------------- Index: sbin/ifconfig/ifconfig.8 =================================================================== --- sbin/ifconfig/ifconfig.8 (revision 198964) +++ sbin/ifconfig/ifconfig.8 (working copy) @@ -28,7 +28,7 @@ .\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94 .\" $FreeBSD$ .\" -.Dd September 23, 2009 +.Dd November 11, 2009 .Dt IFCONFIG 8 .Os .Sh NAME @@ -258,6 +258,12 @@ Another name for the .Fl alias parameter. +.It Cm description Ar value +Specify a description of the interface. +This can be used to label interfaces in situations where they may +otherwise be difficult to distinguish. +.It Cm -description +Clear the interface description. .It Cm down Mark an interface .Dq down . @@ -2512,6 +2518,10 @@ to use 100baseTX, full duplex Ethernet media options: .Dl # ifconfig xl0 media 100baseTX mediaopt full-duplex .Pp +Label the em0 interface as an uplink: +.Pp +.Dl # ifconfig em0 description \&"Uplink to Gigabit Switch 2\&" +.Pp Create the software network interface .Li gif1 : .Dl # ifconfig gif1 create Index: sbin/ifconfig/ifconfig.c =================================================================== --- sbin/ifconfig/ifconfig.c (revision 198964) +++ sbin/ifconfig/ifconfig.c (working copy) @@ -83,6 +83,8 @@ struct ifreq ifr; char name[IFNAMSIZ]; +char *descr = NULL; +size_t descrlen = 64; int setaddr; int setmask; int doalias; @@ -822,6 +824,36 @@ free(newname); } +/* ARGSUSED */ +static void +setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp) +{ + char *newdescr; + + newdescr = strdup(val); + if (newdescr == NULL) { + warn("no memory to set ifdescr"); + return; + } + ifr.ifr_buffer.buffer = newdescr; + ifr.ifr_buffer.length = strlen(newdescr); + if (ioctl(s, SIOCSIFDESCR, (caddr_t)&ifr) < 0) { + warn("ioctl (set descr)"); + free(newdescr); + return; + } + free(newdescr); +} + +/* ARGSUSED */ +static void +unsetifdescr(const char *val, int value, int s, const struct afswtch *afp) +{ + + setifdescr("", 0, s, 0); +} + #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ @@ -866,6 +898,23 @@ printf(" mtu %d", ifr.ifr_mtu); putchar('\n'); + descr = reallocf(descr, descrlen); + if (descr != NULL) { + do { + ifr.ifr_buffer.buffer = descr; + ifr.ifr_buffer.length = descrlen; + if (ioctl(s, SIOCGIFDESCR, &ifr) == 0) { + if (strlen(descr) > 0) + printf("\tdescription: %s\n", descr); + break; + } + if (errno == ENAMETOOLONG) { + descrlen *= 2; + descr = reallocf(descr, descrlen); + } + } while (errno == ENAMETOOLONG); + } + if (ioctl(s, SIOCGIFCAP, (caddr_t)&ifr) == 0) { if (ifr.ifr_curcap != 0) { printb("\toptions", ifr.ifr_curcap, IFCAPBITS); @@ -1035,6 +1084,10 @@ DEF_CMD("-arp", IFF_NOARP, setifflags), DEF_CMD("debug", IFF_DEBUG, setifflags), DEF_CMD("-debug", -IFF_DEBUG, setifflags), + DEF_CMD_ARG("description", setifdescr), + DEF_CMD_ARG("descr", setifdescr), + DEF_CMD("-description", 0, unsetifdescr), + DEF_CMD("-descr", 0, unsetifdescr), DEF_CMD("promisc", IFF_PPROMISC, setifflags), DEF_CMD("-promisc", -IFF_PPROMISC, setifflags), DEF_CMD("add", IFF_UP, notealias), Index: share/man/man4/netintro.4 =================================================================== --- share/man/man4/netintro.4 (revision 198964) +++ share/man/man4/netintro.4 (working copy) @@ -32,7 +32,7 @@ .\" @(#)netintro.4 8.2 (Berkeley) 11/30/93 .\" $FreeBSD$ .\" -.Dd June 18, 2004 +.Dd November 11, 2009 .Dt NETINTRO 4 .Os .Sh NAME @@ -277,6 +277,15 @@ fields of the .Vt ifreq structure, respectively. +.It Dv SIOCGIFDESCR Fa "struct ifreq *" +Get the interface description, returned in the +.Va ifru_data +field. +.It Dv SIOCSIFDESCR Fa "struct ifreq *" +Set the interface description to the value of the +.Va ifru_data +field, limited to the size of +.Dv IFDESCRSIZE . .It Dv SIOCSIFFLAGS Set interface flags field. If the interface is marked down, Index: sys/kern/kern_jail.c =================================================================== --- sys/kern/kern_jail.c (revision 198964) +++ sys/kern/kern_jail.c (working copy) @@ -3467,6 +3467,7 @@ case PRIV_NET_SETIFMTU: case PRIV_NET_SETIFFLAGS: case PRIV_NET_SETIFCAP: + case PRIV_NET_SETIFDESCR: case PRIV_NET_SETIFNAME : case PRIV_NET_SETIFMETRIC: case PRIV_NET_SETIFPHYS: Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 198964) +++ sys/net/if.c (working copy) @@ -463,6 +463,8 @@ #ifdef MAC mac_ifnet_destroy(ifp); #endif /* MAC */ + if (ifp->if_description != NULL) + sbuf_delete(ifp->if_description); IF_AFDATA_DESTROY(ifp); IF_ADDR_LOCK_DESTROY(ifp); ifq_delete(&ifp->if_snd); @@ -2090,6 +2092,45 @@ ifr->ifr_phys = ifp->if_physical; break; + case SIOCGIFDESCR: + IF_AFDATA_RLOCK(ifp); + if (ifp->if_description == NULL) + error = ENOMSG; + else + error = copystr(sbuf_data(ifp->if_description), + ifr->ifr_buffer.buffer, + ifr->ifr_buffer.length, NULL); + IF_AFDATA_RUNLOCK(ifp); + break; + + case SIOCSIFDESCR: + error = priv_check(td, PRIV_NET_SETIFDESCR); + if (error) + return (error); + + IF_AFDATA_WLOCK(ifp); + if (ifp->if_description == NULL) { + ifp->if_description = sbuf_new_auto(); + if (ifp->if_description == NULL) { + error = ENOMEM; + IF_AFDATA_WUNLOCK(ifp); + break; + } + } else + sbuf_clear(ifp->if_description); + + if (sbuf_copyin(ifp->if_description, ifr->ifr_buffer.buffer, + ifr->ifr_buffer.length) == -1) + error = EFAULT; + + if (error == 0) { + sbuf_finish(ifp->if_description); + getmicrotime(&ifp->if_lastchange); + } + IF_AFDATA_WUNLOCK(ifp); + + break; + case SIOCSIFFLAGS: error = priv_check(td, PRIV_NET_SETIFFLAGS); if (error) Index: sys/net/if.h =================================================================== --- sys/net/if.h (revision 198964) +++ sys/net/if.h (working copy) @@ -56,6 +56,7 @@ * Note: this is the same size as a generic device's external name. */ #define IF_NAMESIZE 16 + #if __BSD_VISIBLE #define IFNAMSIZ IF_NAMESIZE #define IF_MAXUNIT 0x7fff /* historical value */ @@ -294,6 +295,7 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; + struct { size_t length; caddr_t buffer; } ifru_buffer; short ifru_flags[2]; short ifru_index; int ifru_jid; @@ -307,6 +309,7 @@ #define ifr_addr ifr_ifru.ifru_addr /* address */ #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ +#define ifr_buffer ifr_ifru.ifru_buffer /* user supplied buffer with its length */ #define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ #define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ #define ifr_jid ifr_ifru.ifru_jid /* jail/vnet */ Index: sys/net/if_var.h =================================================================== --- sys/net/if_var.h (revision 198964) +++ sys/net/if_var.h (working copy) @@ -198,6 +198,7 @@ void *if_pf_kif; void *if_lagg; /* lagg glue */ u_char if_alloctype; /* if_type at time of allocation */ + struct sbuf *if_description; /* interface description */ /* * Spare fields are added so that we can modify sensitive data @@ -205,7 +206,7 @@ * be used with care where binary compatibility is required. */ char if_cspare[3]; - void *if_pspare[8]; + void *if_pspare[7]; int if_ispare[4]; }; Index: sys/sys/priv.h =================================================================== --- sys/sys/priv.h (revision 198964) +++ sys/sys/priv.h (working copy) @@ -335,6 +335,7 @@ #define PRIV_NET_LAGG 415 /* Administer lagg interface. */ #define PRIV_NET_GIF 416 /* Administer gif interface. */ #define PRIV_NET_SETIFVNET 417 /* Move interface to vnet. */ +#define PRIV_NET_SETIFDESCR 418 /* Set interface description. */ /* * 802.11-related privileges. Index: sys/sys/sockio.h =================================================================== --- sys/sys/sockio.h (revision 198964) +++ sys/sys/sockio.h (working copy) @@ -82,6 +82,8 @@ #define SIOCGIFMAC _IOWR('i', 38, struct ifreq) /* get IF MAC label */ #define SIOCSIFMAC _IOW('i', 39, struct ifreq) /* set IF MAC label */ #define SIOCSIFNAME _IOW('i', 40, struct ifreq) /* set IF name */ +#define SIOCSIFDESCR _IOW('i', 41, struct ifreq) /* set ifnet descr */ +#define SIOCGIFDESCR _IOWR('i', 42, struct ifreq) /* get ifnet descr */ #define SIOCADDMULTI _IOW('i', 49, struct ifreq) /* add m'cast addr */ #define SIOCDELMULTI _IOW('i', 50, struct ifreq) /* del m'cast addr */ From jhb at freebsd.org Fri Nov 6 20:08:40 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 6 20:08:52 2009 Subject: [PATCH] Remove if_watchdog use Message-ID: <200911061508.22482.jhb@freebsd.org> I have a patchset that converts all the remaining users of if_watchdog to using a private callout instead. In some cases the the driver already used a private timer to drive a stats timer and I merely hooked into that timer. In other cases a new callout needed to be added to the driver. Some drivers even abused the if_watchdog interface to provide a stats timer that fired every second. :) For a few drivers I also fixed other things such as busted locking, order-of-operations issues in detach, or just completely busted drivers (fea(4) and fpa(4) which share the pdq backend). Please test. Barring any major screaming and shouting I plan to commit this in a week or so and after that to work on removing the if_watchdog/if_timer stuff from the network stack. The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch Driver details: - an(4) - Locking fixes to not do silly things like drop the lock only to call a function that immediately reacquires the lock. Also removes recursive locking. - Hooks into the stat timer to drive the watchdog timer. - bwi(4), cm(4), ep(4), fatm(4), malo(4), mwl(4), vx(4) - Adds a new private timer to drive the watchdog timer. - ce(4), cp(4), ctau(4), cx(4), lmc(4) - These drivers have two modes, a netgraph mode and an ifnet mode. In the netgraph mode they used a private timer to drive the watchdog. In the ifnet mode they used if_watchdog. Now they just always use the private timer. - de(4) - This driver abused the watchdog interface to manage its once-a-second stat timer. It uses a callout to manage this now instead. - ed(4) - This driver used to provide a hook to allow individual attachments to provide a 'tick' event to be called from an optional stats timer. The stats timer only ran if the tick function pointer was non-NULL and the attachment's tick routine had to call callout_reset(), etc. Now the driver always schedules a stat timer and manages the callout_reset() internally. This timer is used to drive the watchdog and will also call the attachment's 'tick' handler if one is provided. - ixgb(4) - Uses callout_init_mtx() instead of callout_init(..., CALLOUT_MPSAFE). - Remove silly callout handling in a few places (cancelling the callout only to rescheduled it again immediately afterwards). - Hooks into the stat timer to drive the watchdog timer. - lge(4), nve(4), pcn(4) - Hooks into the stat timer to drive the watchdog timer. - my(4) - This driver used the watchdog timer both as a watchdog on transmit and auto-negotiation. To make this simpler and easier to understand I have split this out into two separate timers. One just manages the auto-neg side of things and one is a transmit watchdog. - fea(4), fpa(4) - These two drivers share a common backend, pdq, which was plagued with several issues. I'm quite confident no one has used these drivers in years since the are guaranteed to panic during attach. - Add real locking. Previously these drivers only acquired their lock in their interrupt handler or in the ioctl routine (but too broadly in the latter). No locking was used for the stack calling down into the driver via if_init() or if_start(), for device shutdown or detach. Also, the interrupt handler held the driver lock while calling if_input(). All this stuff should be fixed in the locking changes. - Really fix these drivers to handle if_alloc(). The front-end attachments were using if_initname() before the ifnet was allocated. Fix this by moving some of the duplicated logic from each driver into pdq_ifattach(). While here, make pdq_ifattach() return an error so that the driver just fails to attach if if_alloc() fails rather than panic'ing. - Adds a new private timer to drive the watchdog timer. - sn(4) - Use bus_*() rather than bus_space_*(). - Adds a new private timer to drive the watchdog timer. - Fixup detach. - ste(4), ti(4) - Adds a new private timer to drive the watchdog timer. - Fixup detach. - tl(4), wb(4) - Use bus_*() rather than bus_space_*(). - Hooks into the stat timer to drive the watchdog timer. - Fixup detach. - vge(4) - Overhaul the locking to avoid recursion and add missing locking in a few places. - Don't schedule a task to call vge_start() from contexts that are safe to call vge_start() directly. Just invoke the routine directly instead (this is what all of the other NIC drivers I am familiar with do). Note that vge(4) does not use an interrupt filter handler which is the primary reason some other drivers use tasks. - Adds a new private timer to drive the watchdog timer. - Use bus_*() rather than bus_space_*(). - Fixup detach. - netfront(4) - This doesn't actually implement a watchdog, it just sets if_watchdog to a non-existent function under '#ifdef notyet'. - admsw(4) - This driver is a bit special in that it has no locking at all, not even a poor attempt. :) It also appears to be for a specific MIPS board of some sort. - It has multiple ifnet's for multiple ports, but it only used if_timer and if_watchdog from the first ifnet. For this driver I added a single private timer to replace the if_timer use on the first ifnet. I marked the callout MPSAFE, but the driver really needs to have locking added at which point it could use callout_init_mtx(). -- John Baldwin From qing.li at bluecoat.com Fri Nov 6 23:47:15 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Nov 6 23:47:22 2009 Subject: Permanent arp entry expires in 20 seconds on 8.0-RC2 In-Reply-To: <20091106092532.GA67155@traktor.dnepro.net> References: <20091106092532.GA67155@traktor.dnepro.net> Message-ID: This looks like a bug, I'll fix it once I get some free time later tonight. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Eugene Perevyazko > Sent: Friday, November 06, 2009 1:26 AM > To: freebsd-net@freebsd.org > Subject: Permanent arp entry expires in 20 seconds on 8.0-RC2 > > Hello freebsd-network readers! > > This is on FreeBSD 8.0-RC2 (sys/netinet/in.c is 1.143.2.9.2.1) > > If I try to set permanent arp entry with "arp -s host etheraddr" and > there > exists an "incomplete" entry for this host at the moment, then this > "permanent" > entry will expire in 20 seconds. > > If I set arp with "arp -S host etheraddr" - it will be really > permanent. > > It looks like with "-s" the flag of incompleteness isn't cleared. > > Is this a bug or a feature? > > -- > Eugene Perevyazko > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From pyunyh at gmail.com Sat Nov 7 01:20:23 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Nov 7 01:20:29 2009 Subject: Marvell 88E8057 In-Reply-To: <20091103182739.GE1256@michelle.cdnetworks.com> References: <4AE2780F.4080600@el.net> <20091024214640.GE6050@michelle.cdnetworks.com> <20091024215219.GF6050@michelle.cdnetworks.com> <4AEFC390.2090600@el.net> <20091103182739.GE1256@michelle.cdnetworks.com> Message-ID: <20091107011947.GC1256@michelle.cdnetworks.com> On Tue, Nov 03, 2009 at 10:27:39AM -0800, Pyun YongHyeon wrote: > On Tue, Nov 03, 2009 at 12:45:52AM -0500, kalin m wrote: > > > > hi pyun... and all.... > > > > after a few hours i'm sorry to report that the card is visible but not > > usable (yet?!). here is what i have done so far: > > > > 1. got the files from http://svn.freebsd.org/viewvc/base/head/sys/dev/ > > 2. applied the patch that pyun provided. > > 3. replaced if_maddr_rlock(ifp) with IF_ADDR_UNLOCK(ifp) in if_msk.c - > > two instances. > > 4. replaced the files in /usr/src/sys/dev for mii and msk with he new > > ones on the freebsd 7.2 machine. > > 5. recompiled the kernel.. > > > > here is what i get: > > > > from dmesg at boot: > > > > mskc0: port 0xde00-0xdeff mem > > 0xfddfc000-0xfddfffff irq 18 at device 0.0 on pci2 > > mskc0: unknown device: id=0xba, rev=0x00 > > device_attach: mskc0 attach returned 6 > > > > cant find what 6 stands for but it's not good.. > > > > Sorry, there was a check that keep 88E8057 from attaching. > I've regenerated patch. FYI: Patch committed to HEAD(r199012). From jcmtd at live.com Sat Nov 7 01:28:36 2009 From: jcmtd at live.com (MTDGrafx / AcenSpade) Date: Sat Nov 7 01:28:48 2009 Subject: [MTDGrafx / AcenSpade] You've been added to our mailing list. Message-ID: <3c17973edf86c437aaeb9e57dfd75915@fanbridge.com> You have been added to the MTDGrafx / AcenSpade fan list! If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link: http://www.FanBridge.com/signup/fansignup.php?userid=128805&email=freebsd-net@freebsd.org&confCode=155Bt4b92FhBe139152dU4Yad6 -- This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists. With FanBridge your information is always secure. For more information about FanBridge please visit http://www.FanBridge.com/learn/ -- ***Important: Please be sure to add the email address (jcmtd@live.com) to your safe senders list.*** Here's how: Gmail 1. Click Contacts along the left side of any Gmail page. 2. Click Add Contact. 3. In the primary email address box, type jcmtd@live.com. 4. Click Save. AOL (version 9.0 or higher) 1. Click the Mail menu and select Address Book. 2. In the pop up box, click the Add button. 3. In the "Other E-Mail" field, type jcmtd@live.com. 4. Make our From address the "Primary E-Mail" address by checking the associated check box. 5. Click the Save button. AOL 8.0 1. Open this confirmation email. 2. Click Add Address. 3. Verify the sender's contact information (jcmtd@live.com). 4. Click Save. Yahoo! 1. Click the "addresses" button 2. Select "Add Contact" 3. Save the jcmtd@live.com to your contacts list. Hotmail 1. Click Options. 2. On the left side of the page, click Mail, and then click Junk E-Mail Protection. 3. Click Safe List. 4. Type jcmtd@live.com, and then click Add. Outlook 1. Right-click on a message from jcmtd@live.com. 2. Point to Junk E-mail, and click Add Sender to Safe Senders List. ---------------------------------------- MTDGrafx / AcenSpade sent this email to freebsd-net@freebsd.org Questions? Contact jcmtd@live.com or MTDGrafx / AcenSpade, c/o FanBridge, Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United States Download the toolbar: http://mtdgrafx.fanbridge.com/toolbar Update Your Information - http://fburls.com/15-U5BJ2RXZ Forward to a friend - http://fburls.com/94-1HWnPRCo Unsubscribe - http://fburls.com/43-VjTogMCx Privacy Policy - http://www.FanBridge.com/learn/privacy.php This email message is powered by FanBridge: http://www.FanBridge.com/b.php?id=128805 Powering Valuable Fan Relationships From linimon at FreeBSD.org Sat Nov 7 02:43:15 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 7 02:43:26 2009 Subject: misc/140346: [wlan] High bandwidth use causes loss of wlan connection Message-ID: <200911070243.nA72hE3v050838@freefall.freebsd.org> Old Synopsis: High bandwidth use causes loss of wlan connection New Synopsis: [wlan] High bandwidth use causes loss of wlan connection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 7 02:42:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140346 From gavin at FreeBSD.org Sat Nov 7 14:51:08 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Nov 7 14:51:20 2009 Subject: kern/140358: 8.0RC2: [arp] arp: writing to routing socket: Invalid argument with -S key usage Message-ID: <200911071451.nA7Ep8mD023449@freefall.freebsd.org> Old Synopsis: arp: writing to routing socket: Invalid argument with -S key usage New Synopsis: 8.0RC2: [arp] arp: writing to routing socket: Invalid argument with -S key usage Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Nov 7 14:32:34 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). I can verify this on my machine (19th Oct HEAD) so it's not due to his custom kernel. http://www.freebsd.org/cgi/query-pr.cgi?pr=140358 From weongyo.jeong at gmail.com Sat Nov 7 23:06:03 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sat Nov 7 23:06:10 2009 Subject: LINKSYS WUSB600N, 802.11a/b/g In-Reply-To: References: Message-ID: <20091107230612.GB1406@weongyo> On Wed, Oct 28, 2009 at 10:09:59AM +0100, Ivor Prebeg wrote: > Does anyone know if this usb wifi adapter [LINKSYS WUSB600N, > 802.11a/b/g] works with -CURRENT or 8.0-RC? Maybe no but yes on STABLE_7. I asked Tango who is driver writer about porting run(4) to CURRENT. regards, Weongyo Jeong From moonlightakkiy at yahoo.ca Sun Nov 8 01:19:32 2009 From: moonlightakkiy at yahoo.ca (PseudoCylon) Date: Sun Nov 8 01:19:44 2009 Subject: LINKSYS WUSB600N, 802.11a/b/g Message-ID: <832961.82082.qm@web51802.mail.re2.yahoo.com> ----- Original Message ---- > From: Weongyo Jeong > To: Ivor Prebeg > Cc: freebsd-net@freebsd.org; Tango > Sent: Sat, November 7, 2009 4:06:12 PM > Subject: Re: LINKSYS WUSB600N, 802.11a/b/g > > On Wed, Oct 28, 2009 at 10:09:59AM +0100, Ivor Prebeg wrote: > > Does anyone know if this usb wifi adapter [LINKSYS WUSB600N, > > 802.11a/b/g] works with -CURRENT or 8.0-RC? > > Maybe no but yes on STABLE_7. I asked Tango who is driver writer about > porting run(4) to CURRENT. > > regards, > Weongyo Jeong Hello, I'm the one porting the driver to CURRENT. At this moment it is working without encryption. I'm having trouble writing keys onto h/w. Some how all pipes gets blocked when I try to write keys. (usbd_do_request() never returns) So, you have to wait for the driver little bit longer. Or I can e-mail you half-finished driver if you cannot wait. (about 65KB in tar ball) Regards, Akinori Furukoshi __________________________________________________________________ Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/ From weongyo.jeong at gmail.com Sun Nov 8 11:20:07 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sun Nov 8 11:20:18 2009 Subject: misc/140346: High bandwidth use causes loss of wlan connection Message-ID: <200911081120.nA8BK7ag010599@freefall.freebsd.org> The following reply was made to PR misc/140346; it has been noted by GNATS. From: Weongyo Jeong To: Daniel Casner Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/140346: High bandwidth use causes loss of wlan connection Date: Sun, 8 Nov 2009 02:46:04 -0800 On Fri, Nov 06, 2009 at 07:56:14PM +0000, Daniel Casner wrote: > > >Number: 140346 > >Category: misc > >Synopsis: High bandwidth use causes loss of wlan connection > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Nov 06 20:00:04 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Daniel Casner > >Release: 8.0-BETA3 > >Organization: > Anybots Inc. > >Environment: > 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Mon Aug 31 08:58:35 PDT 2009 root@plutonium:/usr/obj/usr/src.RELENG_8/sys/GENERIC i386 > >Description: > I am using a rum wireless card (Asus WL-167g) wireless card and creating a wlan virtual device from it to connect to a wireless network. This same card worked flawlessly under FreeBSD 7. > > The interface associates with wireless networks just fine, however, any time I try to push a large amount of data over the interface, such as writing a 100Mb file over NFS, the connection will die and not be restored. > > Setting "wlandebug state+scan" it appears that the wlan device is performing background scans and re-associating correctly, however, the operating system does not resume sending packets over the interface. I can not ping from the wireless device or ping it from the out side after the connection dies. > >How-To-Repeat: > Set up a wireless connection, here is an example from my rc.conf > > wlans_rum0="wlan0" > ifconfig_wlan0="ssid Anybots 10.10.10.27 netmask 255.255.255.0" > defaultrouter="10.10.10.20" > > Mount an NFS partition, write a large file over NFS. > > The connection is usually lost fairly quickly. > > > Running: > > ifconfig wlan0 down > ifconfig wlan0 up scan > > Usually restores the connection, however, continuing to try and push a large amount of bandwidth will cause it to die again. It looks it's a known issue and fixed at r198098. Could you please test with it? regards, Weongyo Jeong From emss at free.fr Sun Nov 8 17:48:33 2009 From: emss at free.fr (Eric Masson) Date: Sun Nov 8 17:48:40 2009 Subject: IPSec, nat on enc device In-Reply-To: <86tyxp6vfh.fsf@srvbsdnanssv.interne.kisoft-services.com> (Eric Masson's message of "Sat, 24 Oct 2009 10:35:46 +0200") References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091019200549.GA9766@zeninc.net> <864opuk0e6.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091020174351.T5956@maildrop.int.zabbadoz.net> <86tyxp6vfh.fsf@srvbsdnanssv.interne.kisoft-services.com> Message-ID: <863a4o52mw.fsf@srvbsdnanssv.interne.kisoft-services.com> Eric Masson writes: Hi Bjoern, > Ok, I've never used ipfw so shot in the dark. > > If I had to nat 192.168.85.0/24 to 10.0.0.1 to access 192.168.201.0/24, > I would have to setup the following : > > ipfw add divert natd all from 192.168.85.0/24 to 192.168.201.0/24 in > natd -alias_address 10.0.0.1 > setkey -c << EOD > spdadd 10.0.0.1/32 192.168.201.0/24 any -P out ipsec > esp/tunnel/mygw-theirgw/require ; > spdadd 192.168.201.0/24 10.0.0.1/32 any -P in ipsec > esp/tunnel/theirgw-mygw/require ; > EOD > > Does it seem reasonable or do I miss something ? Seems I miss something, as tests don't work at all. Could you elaborate on incoming nat & ipsec please ? Regards -- J'ai re?u un mail parlant d'un petit gar?on malade. Je l'ai transf?r? ? tous ceux que je connaissais. On me dit que c'est un attrape couillons. Est-ce vrai? Suis-je vraiment aussi con que le pr?tend ma femme? -+-C in GNU - Le plus dur dans le mariage, c'est d'en sortir vivant -+- From bugmaster at FreeBSD.org Mon Nov 9 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 9 11:08:53 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200911091106.nA9B6wUR079066@freefall.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/140358 net 8.0RC2: [arp] arp: writing to routing socket: Invalid 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/139559 net [tun] several tun(4) interfaces can be created with sa 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/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e 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 0xffffff004127b00 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 o kern/138676 net [route] after buildworld not work local routes [regres 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 net TCP 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 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 361 problems total. From alireza.torabi at gmail.com Mon Nov 9 20:45:21 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Mon Nov 9 20:45:27 2009 Subject: Intel WiFi 5100, PANIC 9.0-CURRENT FreeBSD Message-ID: Hi, Can anyone help here please? Thanks -- FreeBSD E4300.sys.local 9.0-CURRENT FreeBSD 9.0-CURRENT #10: Tue Nov 3 17:18:01 GMT 2009 root@E4300.sys.local:/usr/obj/usr/src/sys/E4300 amd64 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex iwn0 (network driver) r = 0 (0xffffff80002fb010) locked @ /usr/src/sys/modules/ iwn/../../dev/iwn/if_iwn.c:2439 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x28 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80564ff1 stack pointer = 0x28:0xffffff8074868ac0 frame pointer = 0x28:0xffffff8074868af0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq258: iwn0) trap number = 12 panic: page fault cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 Uptime: 10m34s Physical memory: 4035 MB Dumping 1302 MB: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xfffffb000cd05004 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffff8074868522 stack pointer = 0x28:0xffffff8074ed1b00 frame pointer = 0x28:0xffffff8074ed1b30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq19: fwohci0+) trap number = 12 panic: page fault cpuid = 1 1287 1271 1255 1239 1223 1207 1191 1175 1159 1143 1127 1111 1095 1079 1063 1047 1031 1015 999 983 96 7 951 935 919 903 887 871 855 839 823 807 791 775 759 743 727 711 695 679 663 647 631 615 599 583 567 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 (kgdb) list *0xffffff8074868522 No source file for address 0xffffff8074868522. (kgdb) list *0xffffffff80564ff1 0xffffffff80564ff1 is in _bus_dmamap_sync (/usr/src/sys/amd64/amd64/busdma_machdep.c:933). 928 bcopy((void *)bpage->datavaddr, 929 (void *)bpage->vaddr, 930 bpage->datacount); 931 bpage = STAILQ_NEXT(bpage, links); 932 } 933 dmat->bounce_zone->total_bounced++; 934 } 935 936 if (op & BUS_DMASYNC_POSTREAD) { 937 while (bpage != NULL) { (kgdb) backtrace #0 doadump () at pcpu.h:223 #1 0xffffffff8030b2e5 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff8030b73c in panic (fmt=0xffffffff805e2379 "%s") at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff805813c8 in trap_fatal (frame=0xffffff00024c2700, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:860 #4 0xffffffff80581ff8 in trap (frame=0xffffff8074868a10) at /usr/src/sys/amd64/amd64/trap.c:348 #5 0xffffffff805684c3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xffffffff80564ff1 in _bus_dmamap_sync (dmat=0xffffff00021f0c80, map=Variable "map" is not availa ble. ) at /usr/src/sys/amd64/amd64/busdma_machdep.c:933 #7 0xffffffff80cac6ae in iwn_notif_intr (sc=0xffffff80002fb000) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:2185 #8 0xffffffff80cacbf5 in iwn_intr (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:2477 #9 0xffffffff802e6375 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1220 #10 0xffffffff802e70f2 in ithread_loop (arg=0xffffff0001d00b40) at /usr/src/sys/kern/kern_intr.c:1233 #11 0xffffffff802e484a in fork_exit (callout=0xffffffff802e7040 , arg=0xffffff0001d00b40, frame=0xffffff8074868c80) at /usr/src/sys/kern/kern_fork.c:843 #12 0xffffffff8056899e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 #13 0x0000000000000000 in ?? () #14 0x0000000000000000 in ?? () #15 0x0000000000000001 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000ceb000 in ?? () #38 0x0000000000000000 in ?? () #39 0xffffffff807fbf00 in affinity () #40 0xffffffff807fcb80 in tdq_cpu () #41 0xffffff00014e1700 in ?? () #42 0xffffff80748686d0 in ?? () #43 0xffffff8074868688 in ?? () #44 0xffffff00024c2700 in ?? () #45 0xffffffff8032e9a0 in sched_switch (td=0xffffff0001d00b40, newtd=0xffffffff802e7040, flags=Variab le "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) From bschmidt at techwires.net Tue Nov 10 07:37:17 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Tue Nov 10 07:37:23 2009 Subject: Intel WiFi 5100, PANIC 9.0-CURRENT FreeBSD In-Reply-To: References: Message-ID: <200911100837.09317.bschmidt@techwires.net> On Monday 09 November 2009 21:45:20 Alireza Torabi wrote: > at /usr/src/sys/amd64/amd64/busdma_machdep.c:933 > #7 0xffffffff80cac6ae in iwn_notif_intr (sc=0xffffff80002fb000) > at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:2185 > #8 0xffffffff80cacbf5 in iwn_intr (arg=Variable "arg" is not available. > ) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:2477 Never seen this one before. Can you reproduce this with code from http://svn.techwires.net/svn/ ? There are few changes at those lines. -- Bernhard From dan at obluda.cz Tue Nov 10 12:50:04 2009 From: dan at obluda.cz (Dan Lukes) Date: Tue Nov 10 12:50:10 2009 Subject: kern/116747: [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 1400 wireless card Message-ID: <200911101250.nAACo3Gp051398@freefall.freebsd.org> The following reply was made to PR kern/116747; it has been noted by GNATS. From: Dan Lukes To: bug-followup@FreeBSD.org, roar.pettersen@FreeBSD.org Cc: Subject: Re: kern/116747: [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 1400 wireless card Date: Tue, 10 Nov 2009 13:48:33 +0100 Just for evidence ... Same problem (unknown NDIS error C000138D then panic) but immediatelly on kernel module load. OS FreeBSD 7.2-RELEASE-p3 card: Atheros AR8131 vendor:device: chip: 1969:1063 card: 1025:0229 NDIS 5.1 windows driver version 1.0.0.26 Dan From ermal.luci at gmail.com Tue Nov 10 15:04:17 2009 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Tue Nov 10 15:04:23 2009 Subject: How does one build ng_vlan(4) inside the kernel?! Message-ID: <9a542da30911100703n5a9abcd8j1ae475483b7ada99@mail.gmail.com> Hello list, i searched for this but could not find an answer. How does one build ng_vlan as part of the kernel? NETGRAPH_VLAN does not exist as an option to include in the kernel and when building ng_vlan as a module and you use a gzipped kernel the module doe snot load since it says kernel is a requirement! Is this something that has slipped over time and option NETGRAPH_VLAN needs to be introduced or i am really missing something!? Regards, -- Ermal From pluknet at gmail.com Tue Nov 10 16:11:48 2009 From: pluknet at gmail.com (pluknet) Date: Tue Nov 10 16:11:54 2009 Subject: How does one build ng_vlan(4) inside the kernel?! In-Reply-To: <9a542da30911100703n5a9abcd8j1ae475483b7ada99@mail.gmail.com> References: <9a542da30911100703n5a9abcd8j1ae475483b7ada99@mail.gmail.com> Message-ID: 2009/11/10 Ermal Lu?i : > Hello list, > > i searched for this but could not find an answer. > How does one build ng_vlan as part of the kernel? > > NETGRAPH_VLAN does not exist as an option to include in the kernel > and when building ng_vlan as a module and you use a gzipped kernel > the module doe snot load since it says kernel is a requirement! > > Is this something that has slipped over time and option > NETGRAPH_VLAN needs to be introduced or i am really missing > something!? Usually an ng node addition is combined with changes to NOTES/files/options. I'm afraid It was left out there accidentally. Ermal, what if you try adding those bits with the patch provided and see how it goes. -- wbr, pluknet -------------- next part -------------- A non-text attachment was scrubbed... Name: ng_vlan_bits.patch Type: application/octet-stream Size: 1016 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091110/5d59c321/ng_vlan_bits.obj From ermal.luci at gmail.com Tue Nov 10 16:41:25 2009 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Tue Nov 10 16:41:32 2009 Subject: How does one build ng_vlan(4) inside the kernel?! In-Reply-To: References: <9a542da30911100703n5a9abcd8j1ae475483b7ada99@mail.gmail.com> Message-ID: <9a542da30911100841x6d10412dtc57af7cbeb65dd88@mail.gmail.com> On Tue, Nov 10, 2009 at 5:11 PM, pluknet wrote: > 2009/11/10 Ermal Lu?i : >> Hello list, >> >> i searched for this but could not find an answer. >> How does one build ng_vlan as part of the kernel? >> >> NETGRAPH_VLAN does not exist as an option to include in the kernel >> and when building ng_vlan as a module and you use a gzipped kernel >> the module doe snot load since it says kernel is a requirement! >> >> Is this something that has slipped over time and option >> NETGRAPH_VLAN needs to be introduced or i am really missing >> something!? > > Usually an ng node addition is combined with changes to NOTES/files/options. > I'm afraid It was left out there accidentally. > Ermal, what if you try adding those bits with the patch provided and > see how it goes. > It looks good. I will test more and give feedback. -- Ermal From jhb at freebsd.org Tue Nov 10 22:03:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Nov 10 22:03:16 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <20091110194048.D61601@ury.york.ac.uk> References: <200911061508.22482.jhb@freebsd.org> <20091110194048.D61601@ury.york.ac.uk> Message-ID: <200911101702.57525.jhb@freebsd.org> On Tuesday 10 November 2009 4:45:03 pm Gavin Atkinson wrote: > On Fri, 6 Nov 2009, John Baldwin wrote: > > > I have a patchset that converts all the remaining users of if_watchdog to > > using a private callout instead. In some cases the the driver already used a > > private timer to drive a stats timer and I merely hooked into that timer. In > > other cases a new callout needed to be added to the driver. Some drivers > > even abused the if_watchdog interface to provide a stats timer that fired > > every second. :) For a few drivers I also fixed other things such as busted > > locking, order-of-operations issues in detach, or just completely busted > > drivers (fea(4) and fpa(4) which share the pdq backend). Please test. > > Barring any major screaming and shouting I plan to commit this in a week or > > so and after that to work on removing the if_watchdog/if_timer stuff from the > > network stack. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch > > > > Driver details: > > - an(4) > > - Locking fixes to not do silly things like drop the lock only to call a > > function that immediately reacquires the lock. Also removes recursive > > locking. > > - Hooks into the stat timer to drive the watchdog timer. > > I managed to get a panic when running wpa_supplicant: > > System call ioctl returning with the following locks held: > exclusive sleep mutex an0 (network driver) r=0 (0xc58fc180) locked @ > /usr/src/sys/dev/an/if_an.c:2341 > panic: witness_warn > > This seems to fix that: > > --- /usr/src/sys/dev/an/if_an.c.orig 2009-11-10 19:26:21.000000000 > +0000 > +++ /usr/src/sys/dev/an/if_an.c 2009-11-10 19:27:24.000000000 +0000 > @@ -2570,6 +2570,9 @@ > an_setdef(sc, &sc->areq); > AN_UNLOCK(sc); > break; > + default: > + AN_UNLOCK(sc); > + break; > } > > /* Ok, thanks. Sadly the ioctl handling probably needs a bit more work since it calls copyin() while holding the an(4) mutex, but I will leave that for another day. > I also get the following LOR on unplug (but see it before your patch too): > > lock order reversal: > 1st 0xc50f5208 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:912 > 2nd 0xc0f9db68 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:569 I think this has to do with the stack in general and is not specific to an(4). > Other than that, the patches to an(4) seem to work as well before your > patch as after, with light TCP traffic and heavy ping traffic. However, > an(4) appears to require a lot of work (unrelated to your patch) to bring > it up to the state of other wireless drivers. Thanks, I will commit the an(4) bits in a bit. > > - ixgb(4) > > - Uses callout_init_mtx() instead of callout_init(..., CALLOUT_MPSAFE). > > - Remove silly callout handling in a few places (cancelling the callout > > only to rescheduled it again immediately afterwards). > > - Hooks into the stat timer to drive the watchdog timer. > > These changes to ixgb_detach() don't compile as ifp is no longer used in > the !DEVICE_POLLING case. > > /usr/src/sys/dev/ixgb/if_ixgb.c: In function 'ixgb_detach': > /usr/src/sys/dev/ixgb/if_ixgb.c:369: warning: unused variable 'ifp' Oops, ixgb isn't in LINT so I keep missing it. I need to just add it to NOTES. Thanks. -- John Baldwin From gavin at FreeBSD.org Tue Nov 10 22:16:25 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 10 22:16:31 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <200911061508.22482.jhb@freebsd.org> References: <200911061508.22482.jhb@freebsd.org> Message-ID: <20091110194048.D61601@ury.york.ac.uk> On Fri, 6 Nov 2009, John Baldwin wrote: > I have a patchset that converts all the remaining users of if_watchdog to > using a private callout instead. In some cases the the driver already used a > private timer to drive a stats timer and I merely hooked into that timer. In > other cases a new callout needed to be added to the driver. Some drivers > even abused the if_watchdog interface to provide a stats timer that fired > every second. :) For a few drivers I also fixed other things such as busted > locking, order-of-operations issues in detach, or just completely busted > drivers (fea(4) and fpa(4) which share the pdq backend). Please test. > Barring any major screaming and shouting I plan to commit this in a week or > so and after that to work on removing the if_watchdog/if_timer stuff from the > network stack. > > The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch > > Driver details: > - an(4) > - Locking fixes to not do silly things like drop the lock only to call a > function that immediately reacquires the lock. Also removes recursive > locking. > - Hooks into the stat timer to drive the watchdog timer. I managed to get a panic when running wpa_supplicant: System call ioctl returning with the following locks held: exclusive sleep mutex an0 (network driver) r=0 (0xc58fc180) locked @ /usr/src/sys/dev/an/if_an.c:2341 panic: witness_warn This seems to fix that: --- /usr/src/sys/dev/an/if_an.c.orig 2009-11-10 19:26:21.000000000 +0000 +++ /usr/src/sys/dev/an/if_an.c 2009-11-10 19:27:24.000000000 +0000 @@ -2570,6 +2570,9 @@ an_setdef(sc, &sc->areq); AN_UNLOCK(sc); break; + default: + AN_UNLOCK(sc); + break; } /* I also get the following LOR on unplug (but see it before your patch too): lock order reversal: 1st 0xc50f5208 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:912 2nd 0xc0f9db68 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:569 KDB: stack backtrace: db_trace_self_wrapper(c0cb835f,e54b1b20,c08e7b55,c08d891b,c0cbb215,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08d891b,c0cbb215,c4d30e18,c4d2a9c0,e54b1b7c,...) at kdb_backtrace+0x29 _witness_debugger(c0cbb215,c0f9db68,c0cbb365,c4d2a9c0,c0cd457d,...) at _witness_debugger+0x25 witness_checkorder(c0f9db68,9,c0cd457d,239,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c0f9db68,0,c0cd457d,239,c5340ba0,...) at _mtx_lock_flags+0xc9 mld_domifdetach(c50f5000,c0db5e54,c0dc0880,e54b1c24,c09532a6,...) at mld_domifdetach+0x2c in6_domifdetach(c50f5000,c5340ba0,390,4be,c50f522c,...) at in6_domifdetach+0x15 if_detach(c50f5000) at if_detach+0x916 ether_ifdetach(c50f5000,0,c0c6cbbc,34f,c555d380,...) at ether_ifdetach+0x3d an_detach(c555d380,c4ead060,c0da0758,a76,e54b1c94,...) at an_detach+0xb5 device_detach(c555d380,0,c0d5a9b8,0,c4ff6500,...) at device_detach+0x8c pccard_detach_card(c4ff6500,c4e3e8bc,c0d5a9b8) at pccard_detach_card+0x44 exca_removal(c4ed2004,0,c0c93731,1da,c8,...) at exca_removal+0x59 cbb_event_thread(c4ed2000,e54b1d38,c0cb02eb,343,c4d81aa0,...) at cbb_event_thread+0x107 fork_exit(c0720cb0,c4ed2000,e54b1d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe54b1d70, ebp = 0 --- an0: detached Other than that, the patches to an(4) seem to work as well before your patch as after, with light TCP traffic and heavy ping traffic. However, an(4) appears to require a lot of work (unrelated to your patch) to bring it up to the state of other wireless drivers. > - ixgb(4) > - Uses callout_init_mtx() instead of callout_init(..., CALLOUT_MPSAFE). > - Remove silly callout handling in a few places (cancelling the callout > only to rescheduled it again immediately afterwards). > - Hooks into the stat timer to drive the watchdog timer. These changes to ixgb_detach() don't compile as ifp is no longer used in the !DEVICE_POLLING case. /usr/src/sys/dev/ixgb/if_ixgb.c: In function 'ixgb_detach': /usr/src/sys/dev/ixgb/if_ixgb.c:369: warning: unused variable 'ifp' Hope that helps, Gavin From gavin at freebsd.org Tue Nov 10 22:49:08 2009 From: gavin at freebsd.org (Gavin Atkinson) Date: Tue Nov 10 22:49:14 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <200911101702.57525.jhb@freebsd.org> References: <200911061508.22482.jhb@freebsd.org> <20091110194048.D61601@ury.york.ac.uk> <200911101702.57525.jhb@freebsd.org> Message-ID: <20091110221339.Y61601@ury.york.ac.uk> On Tue, 10 Nov 2009, John Baldwin wrote: > On Tuesday 10 November 2009 4:45:03 pm Gavin Atkinson wrote: >> I managed to get a panic when running wpa_supplicant: >> >> System call ioctl returning with the following locks held: >> exclusive sleep mutex an0 (network driver) r=0 (0xc58fc180) locked @ >> /usr/src/sys/dev/an/if_an.c:2341 >> panic: witness_warn >> >> This seems to fix that: >> >> --- /usr/src/sys/dev/an/if_an.c.orig 2009-11-10 19:26:21.000000000 >> +0000 >> +++ /usr/src/sys/dev/an/if_an.c 2009-11-10 19:27:24.000000000 +0000 >> @@ -2570,6 +2570,9 @@ >> an_setdef(sc, &sc->areq); >> AN_UNLOCK(sc); >> break; >> + default: >> + AN_UNLOCK(sc); >> + break; >> } >> >> /* > > Ok, thanks. Sadly the ioctl handling probably needs a bit more work since it > calls copyin() while holding the an(4) mutex, but I will leave that for > another day. It actually appears that the above panic is not something that has been introduced with your patch - I can reproduce it on a vanilla system. The above patch fixes it in the original code too. Gavin From mwisnicki at gmail.com Wed Nov 11 01:40:08 2009 From: mwisnicki at gmail.com (=?ISO-8859-2?Q?Marcin_Wi=B6nicki?=) Date: Wed Nov 11 01:40:14 2009 Subject: kern/123429: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-release and 7.0-stable-042008 Message-ID: <200911110140.nAB1e7h0012835@freefall.freebsd.org> The following reply was made to PR kern/123429; it has been noted by GNATS. From: =?ISO-8859-2?Q?Marcin_Wi=B6nicki?= To: bug-followup@FreeBSD.org, wolffire_fl@yahoo.com Cc: Subject: re: kern/123429: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-release and 7.0-stable-042008 Date: Wed, 11 Nov 2009 02:38:15 +0100 I have the same problem on 8.0-RC2/i386 but can workaround it with: hw.pci.mcfg=0 hw.pci.enable_msix=0 in /boot/loader.conf Maybe it's related to amd64/132372 - at least that's where I got the idea. From ru at freebsd.org Wed Nov 11 11:41:56 2009 From: ru at freebsd.org (Ruslan Ermilov) Date: Wed Nov 11 11:42:03 2009 Subject: How does one build ng_vlan(4) inside the kernel?! In-Reply-To: References: <9a542da30911100703n5a9abcd8j1ae475483b7ada99@mail.gmail.com> Message-ID: <20091111110828.GA74407@edoofus.dev.vega.ru> On Tue, Nov 10, 2009 at 07:11:45PM +0300, pluknet wrote: > 2009/11/10 Ermal Lu?i : > > Hello list, > > > > i searched for this but could not find an answer. > > How does one build ng_vlan as part of the kernel? > > > > NETGRAPH_VLAN does not exist as an option to include in the kernel > > and when building ng_vlan as a module and you use a gzipped kernel > > the module doe snot load since it says kernel is a requirement! > > > > Is this something that has slipped over time and option > > NETGRAPH_VLAN needs to be introduced or i am really missing > > something!? > > Usually an ng node addition is combined with changes to NOTES/files/options. > I'm afraid It was left out there accidentally. > Ermal, what if you try adding those bits with the patch provided and > see how it goes. > Committed to -CURRENT. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From pluknet at gmail.com Wed Nov 11 13:49:40 2009 From: pluknet at gmail.com (pluknet) Date: Wed Nov 11 13:49:51 2009 Subject: How does one build ng_vlan(4) inside the kernel?! In-Reply-To: <20091111110828.GA74407@edoofus.dev.vega.ru> References: <9a542da30911100703n5a9abcd8j1ae475483b7ada99@mail.gmail.com> <20091111110828.GA74407@edoofus.dev.vega.ru> Message-ID: 2009/11/11 Ruslan Ermilov : > On Tue, Nov 10, 2009 at 07:11:45PM +0300, pluknet wrote: >> 2009/11/10 Ermal Lu?i : >> > Hello list, >> > >> > i searched for this but could not find an answer. >> > How does one build ng_vlan as part of the kernel? >> > >> > NETGRAPH_VLAN does not exist as an option to include in the kernel >> > and when building ng_vlan as a module and you use a gzipped kernel >> > the module doe snot load since it says kernel is a requirement! >> > >> > Is this something that has slipped over time and option >> > NETGRAPH_VLAN needs to be introduced or i am really missing >> > something!? >> >> Usually an ng node addition is combined with changes to NOTES/files/options. >> I'm afraid It was left out there accidentally. >> Ermal, what if you try adding those bits with the patch provided and >> see how it goes. >> > Committed to -CURRENT. Thanks! -- wbr, pluknet From 000.fbsd at quip.cz Wed Nov 11 16:38:57 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Nov 11 16:39:06 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AEB2571.7090006@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> Message-ID: <4AFAE428.5090907@quip.cz> Tom Judge wrote: > Tom Judge wrote: >> David Christensen wrote: >>>>> The next test is to diable the LOM's management firmware >>>> but boot to >>>>> an active network. > > After disabling the management firmware and doing 1 cold reboot and 3 > warms all worked correctly. > > After re enabling the firmware and doing 1 cold reboot and 3 warms, the > cold works correctly and the warms all failed. > > Tom >>>>> Finally, the routine bce_print_adapter_info() in HEAD >>>> prints out both >>>>> the bootcode and management firmware versions. If you can >>>> get those >>>>> same changes into your release I'd like to see the versions >>>> reported >>>>> on your system. >>>>> >>>> Here is the info from a boot of 8.0 RC2. >>>> >>>> ASIC: 0x57092003 >>>> B/C: 5.0.6 >>>> Rev: C0 >>>> Bus: PCIe x4, 2.5Gb/s >>>> Flags: MSI|MFW >>>> MFW: NCS 2.0.3 >>>> >>>> And looking at this it seems dells update CD was not up to date >>>> enough and I only got 5.0.6 firmware not 5.0.9. >>> >>> The package version and the bootcode version are similar but >>> they are not the same. The bootcode you have (v5.0.6) is >>> sufficient to fix the problem. >>> >> >> Ok just checked in the life cycle manager and it has 5.0.9 installed >> my bad. >> >> Running the other test now. Hi, we have two new Dell R610 machines with four bce NICs (only bce0 is connected at this time). I tried cold (power cycle in iDRAC) and warm reboot (shutdown -r now), NIC is working on every reboot, but I am still seeing messages: bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! bce0: link state changed to UP This is on FreeBSD 7.2-RELEASE-p4 amd64 I also see "PHY write timeout" on shutdown time for each NIC. Other than the log messages, I see no problems with bce NIC, but I have not tested it with any high load. I did not upgraded FW or anything else. What can I do to help with solving this issue? Miroslav Lachman From davidch at broadcom.com Wed Nov 11 17:12:32 2009 From: davidch at broadcom.com (David Christensen) Date: Wed Nov 11 17:12:39 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AFAE428.5090907@quip.cz> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> Hi, > we have two new Dell R610 machines with four bce NICs (only > bce0 is connected at this time). I tried cold (power cycle in > iDRAC) and warm reboot (shutdown -r now), NIC is working on > every reboot, but I am still seeing messages: > > bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! > bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! > bce0: link state changed to UP > > This is on FreeBSD 7.2-RELEASE-p4 amd64 > > I also see "PHY write timeout" on shutdown time for each NIC. > > Other than the log messages, I see no problems with bce NIC, > but I have not tested it with any high load. > > I did not upgraded FW or anything else. > > What can I do to help with solving this issue? You'll need to upgrade to 7-STABLE. Dave From tom at tomjudge.com Wed Nov 11 17:34:02 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Nov 11 17:34:08 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AFAF542.8050004@tomjudge.com> David Christensen wrote: > Hi, >> we have two new Dell R610 machines with four bce NICs (only >> bce0 is connected at this time). I tried cold (power cycle in >> iDRAC) and warm reboot (shutdown -r now), NIC is working on >> every reboot, but I am still seeing messages: >> >> bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! >> bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! >> bce0: link state changed to UP >> >> This is on FreeBSD 7.2-RELEASE-p4 amd64 >> >> I also see "PHY write timeout" on shutdown time for each NIC. >> >> Other than the log messages, I see no problems with bce NIC, >> but I have not tested it with any high load. >> >> I did not upgraded FW or anything else. >> >> What can I do to help with solving this issue? > > You'll need to upgrade to 7-STABLE. > > Dave Hi David, Is there any progress on this issue? We can provide access to hardware with this fault (Specifically the R610). Thanks, Tom From information at directsource-network.com Thu Nov 12 14:38:47 2009 From: information at directsource-network.com (Direct Source Network) Date: Thu Nov 12 14:39:06 2009 Subject: Direct Source Network | Expat Jobs Announcements Message-ID: DIRECT SOURCE NETWORK | Expat Recruitment Services C-Level and Senior Management Jobs within the Telecoms, Financial Services & Banking, Oil & Gas and Alternative Energy Sectors. For regular updates about job opportunities, visit: http://www.directsource-network.com DIRECT SOURCE NETWORK | EXPAT JOBS DIRECT TO YOUR INBOX From information at directsource-network.com Thu Nov 12 14:38:51 2009 From: information at directsource-network.com (Direct Source Network) Date: Thu Nov 12 14:39:07 2009 Subject: Direct Source Network | Expat Jobs Announcements Message-ID: DIRECT SOURCE NETWORK | Expat Recruitment Services C-Level and Senior Management Jobs within the Telecoms, Financial Services & Banking, Oil & Gas and Alternative Energy Sectors. For regular updates about job opportunities, visit: http://www.directsource-network.com DIRECT SOURCE NETWORK | EXPAT JOBS DIRECT TO YOUR INBOX From information at directsource-network.com Thu Nov 12 14:38:52 2009 From: information at directsource-network.com (Direct Source Network) Date: Thu Nov 12 14:39:07 2009 Subject: Direct Source Network | Expat Jobs Announcements Message-ID: DIRECT SOURCE NETWORK | Expat Recruitment Services C-Level and Senior Management Jobs within the Telecoms, Financial Services & Banking, Oil & Gas and Alternative Energy Sectors. For regular updates about job opportunities, visit: http://www.directsource-network.com DIRECT SOURCE NETWORK | EXPAT JOBS DIRECT TO YOUR INBOX From 000.fbsd at quip.cz Thu Nov 12 17:46:47 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Nov 12 17:46:53 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AFC4A02.8080503@quip.cz> David Christensen wrote: > Hi, >> we have two new Dell R610 machines with four bce NICs (only >> bce0 is connected at this time). I tried cold (power cycle in >> iDRAC) and warm reboot (shutdown -r now), NIC is working on >> every reboot, but I am still seeing messages: >> >> bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! >> bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY write timeout! >> bce0: link state changed to UP >> >> This is on FreeBSD 7.2-RELEASE-p4 amd64 >> >> I also see "PHY write timeout" on shutdown time for each NIC. >> >> Other than the log messages, I see no problems with bce NIC, >> but I have not tested it with any high load. >> >> I did not upgraded FW or anything else. >> >> What can I do to help with solving this issue? > > You'll need to upgrade to 7-STABLE. > > Dave Thank you! Todays 7-STABLE seems fine. FreeBSD 7.2-STABLE #1: Thu Nov 12 17:20:36 CET 2009 GENERIC amd64 bce0 has firmware 5.0.9 and is attached to brgphy instead of previous ukphy. bce0: mem 0xd6000000-0xd7ffffff irq 36 at device 0.0 on pci1 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto No more "PHY write timeout" messages on shutdown or bootup. So problem seems solved by 7-STABLE. Miroslav Lachman From davidch at broadcom.com Thu Nov 12 21:34:12 2009 From: davidch at broadcom.com (David Christensen) Date: Thu Nov 12 21:34:19 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AFAF542.8050004@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> > Is there any progress on this issue? We can provide access > to hardware with this fault (Specifically the R610). I haven't been able to reproduce it on the r710 I have in house. Checking with other groups now to see if they have one a I can use, though I'm not sure why the system would make a difference for this particular issue. Just wanted to confirm that you're using the driver built into the kernel (as opposed to a module) and that a warm boot means running the "reboot" or "shutdown -r" commands while a cold boot means pressing the front panel power button or using the DRAC to power down the system. Dave From tom at tomjudge.com Thu Nov 12 22:04:34 2009 From: tom at tomjudge.com (Tom Judge) Date: Thu Nov 12 22:04:41 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AFC862B.6060805@tomjudge.com> David Christensen wrote: >> Is there any progress on this issue? We can provide access >> to hardware with this fault (Specifically the R610). > > I haven't been able to reproduce it on the r710 I have in house. > Checking with other groups now to see if they have one a I can > use, though I'm not sure why the system would make a difference > for this particular issue. Just wanted to confirm that you're > using the driver built into the kernel (as opposed to a module) > and that a warm boot means running the "reboot" or "shutdown -r" > commands while a cold boot means pressing the front panel > power button or using the DRAC to power down the system. > > Dave Hi Dave, Thanks for the update. All these are true. warm - shutdown -r now cold - from the power button (iDRACs are not configured yet). bce is compiled into the kernel (tested with GENERIC kernel from 8-RC2 as well as 7.1 with the 7.2 driver plus the split header patch). For the record we also have not been able to reproduce the issue on the R710 only the R610. Tom From philip at freebsd.org Fri Nov 13 07:51:35 2009 From: philip at freebsd.org (Philip Paeps) Date: Fri Nov 13 07:51:41 2009 Subject: DHCP client not getting IP address from Time Warner In-Reply-To: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> References: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> Message-ID: <20091113075133.GO8230@rincewind.paeps.cx> On 2009-11-03 07:47:14 (-0800), Ask Bj?rn Hansen wrote: > On FreeBSD their DHCP server seems to just ignore me (but I see lots of > broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've tried with > both the standard dhclient and the isc dhclient from ports. > > 00:00:24:c9:23:c1 is my FreeBSD box (Soekris 5501 with vr ethernet): > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd.txt According to that log-file, the server is not ignoring you at all. You are ignoring the server? Your client sends a DHCPDISCOVER -- for some reason it flips a bit in the client identifier, but that doesn't really matter, since it's just something the client and the server need to agree on -- and the server broadcasts DHCPOFFERS. What I'm not seeing here, are DHCPREQUESTs, which your client needs to send to accept an offer. Strangely, there are DHCPACKs, which suggests the server has seen a DHCPREQUEST. It is very interesting that in the FreeBSD case, the server seems to want to broadcast it's DHCPOFFER and in the OS X case, it unicasts it. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. A budget is trying to figure out how the family next door is doing it. From sdalu at sdalu.com Fri Nov 13 11:42:46 2009 From: sdalu at sdalu.com (Stephane D'Alu) Date: Fri Nov 13 11:42:53 2009 Subject: pf & tcpdump Message-ID: <4AFD4632.5090207@sdalu.com> Is there a way to have tcpdump only showing packed that have pass the filtering rules, so to check that firewall rules were correctly written and not letting unwanted packets in. Sincerly -- Stephane D'Alu From smithi at nimnet.asn.au Fri Nov 13 12:42:12 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Nov 13 12:42:19 2009 Subject: pf & tcpdump In-Reply-To: <4AFD4632.5090207@sdalu.com> References: <4AFD4632.5090207@sdalu.com> Message-ID: <20091113230319.R58089@sola.nimnet.asn.au> On Fri, 13 Nov 2009, Stephane D'Alu wrote: > Is there a way to have tcpdump only showing packed that have pass the > filtering rules, so to check that firewall rules were correctly written and > not letting unwanted packets in. tcpdump sees packets before they're passed to the firewall coming in, and after the firewall going out. Lack of response to inbound packets that the firewall is supposed to block is usually a good sign .. Easiest way to see firewall rules are working is to add logging to them. cheers, Ian From sdalu at sdalu.com Fri Nov 13 12:51:04 2009 From: sdalu at sdalu.com (Stephane D'Alu) Date: Fri Nov 13 12:51:11 2009 Subject: pf & tcpdump In-Reply-To: <20091113230319.R58089@sola.nimnet.asn.au> References: <4AFD4632.5090207@sdalu.com> <20091113230319.R58089@sola.nimnet.asn.au> Message-ID: <4AFD5635.3080104@sdalu.com> On 13/11/2009 13:08, Ian Smith wrote: > On Fri, 13 Nov 2009, Stephane D'Alu wrote: > > Is there a way to have tcpdump only showing packed that have pass the > > filtering rules, so to check that firewall rules were correctly written and > > not letting unwanted packets in. > > tcpdump sees packets before they're passed to the firewall coming in, > and after the firewall going out. Lack of response to inbound packets > that the firewall is supposed to block is usually a good sign .. > > Easiest way to see firewall rules are working is to add logging to them. > So if I understand correctly, there is no way in tcpdump to only select the packets "going out after the firewall" thanks -- Stephane From smithi at nimnet.asn.au Fri Nov 13 13:27:53 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Nov 13 13:28:00 2009 Subject: pf & tcpdump In-Reply-To: <4AFD5635.3080104@sdalu.com> References: <4AFD4632.5090207@sdalu.com> <20091113230319.R58089@sola.nimnet.asn.au> <4AFD5635.3080104@sdalu.com> Message-ID: <20091113235940.L58089@sola.nimnet.asn.au> On Fri, 13 Nov 2009, Stephane D'Alu wrote: > On 13/11/2009 13:08, Ian Smith wrote: > > On Fri, 13 Nov 2009, Stephane D'Alu wrote: > > > Is there a way to have tcpdump only showing packed that have pass the > > > filtering rules, so to check that firewall rules were correctly > > written and > > > not letting unwanted packets in. > > > > tcpdump sees packets before they're passed to the firewall coming in, > > and after the firewall going out. Lack of response to inbound packets > > that the firewall is supposed to block is usually a good sign .. > > > > Easiest way to see firewall rules are working is to add logging to them. > > > > So if I understand correctly, there is no way in tcpdump to only select the > packets "going out after the firewall" Not sure I'm following you; thought you were referring to incoming packets above? From tcpdump(1): dir qualifiers specify a particular transfer direction to and/or from id. Possible directions are src, dst, src or dst and src and dst. E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If there is no dir qualifier, src or dst is assumed. all packets "going out after the firewall" on an interface are visible, you can filter to those you're looking for. Or do I miss your meaning? cheers, Ian From sdalu at sdalu.com Fri Nov 13 14:04:47 2009 From: sdalu at sdalu.com (Stephane D'Alu) Date: Fri Nov 13 14:04:53 2009 Subject: pf & tcpdump In-Reply-To: <20091113235940.L58089@sola.nimnet.asn.au> References: <4AFD4632.5090207@sdalu.com> <20091113230319.R58089@sola.nimnet.asn.au> <4AFD5635.3080104@sdalu.com> <20091113235940.L58089@sola.nimnet.asn.au> Message-ID: <4AFD677A.8030000@sdalu.com> On 13/11/2009 14:27, Ian Smith wrote: > On Fri, 13 Nov 2009, Stephane D'Alu wrote: > > On 13/11/2009 13:08, Ian Smith wrote: > > > [...] > > > tcpdump sees packets before they're passed to the firewall coming in, > > > and after the firewall going out. Lack of response to inbound packets > > > that the firewall is supposed to block is usually a good sign .. > > > > > > Easiest way to see firewall rules are working is to add logging to them. > > > > > > > So if I understand correctly, there is no way in tcpdump to only select the > > packets "going out after the firewall" > I wrongly interpreted the last part of your answer as "packets going out of the firewall processing" instead of "packets going out of the interface" So now I understand, adding logging to the firewall is the only option left. Sincerly -- Stephane From ndenev at gmail.com Fri Nov 13 14:15:10 2009 From: ndenev at gmail.com (Nikolay Denev) Date: Fri Nov 13 14:15:16 2009 Subject: pf & tcpdump In-Reply-To: <4AFD5635.3080104@sdalu.com> References: <4AFD4632.5090207@sdalu.com> <20091113230319.R58089@sola.nimnet.asn.au> <4AFD5635.3080104@sdalu.com> Message-ID: <34A73B3A-CEDA-4DB8-A3B1-5D06442D4279@gmail.com> On Nov 13, 2009, at 2:51 PM, Stephane D'Alu wrote: > On 13/11/2009 13:08, Ian Smith wrote: >> On Fri, 13 Nov 2009, Stephane D'Alu wrote: >> > Is there a way to have tcpdump only showing packed that have pass the >> > filtering rules, so to check that firewall rules were correctly written and >> > not letting unwanted packets in. >> >> tcpdump sees packets before they're passed to the firewall coming in, >> and after the firewall going out. Lack of response to inbound packets >> that the firewall is supposed to block is usually a good sign .. >> >> Easiest way to see firewall rules are working is to add logging to them. >> > > So if I understand correctly, there is no way in tcpdump to only select the packets "going out after the firewall" > > thanks > > -- > Stephane > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" You can add logging to the rules as already suggested and then sniff with tcpdump on the pflog(4) device. Regards, Niki Denev From ermal.luci at gmail.com Fri Nov 13 14:27:03 2009 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Fri Nov 13 14:27:09 2009 Subject: Ng_ether and its hook names. Message-ID: <9a542da30911130626w5f5b4d51n7dc289dcc9a0bff3@mail.gmail.com> Hello, is there any reason that ng_ether does not have a event handler for interface changes? I am asking this since it would be reasonable to expect that when an interface name changes or an interface disappears ng_ether does the right action of renaming the hook or removing altogether. If it is a thing to be done, who should review the patch before commit? Regards, -- Ermal From gigabyte.tmn at gmail.com Fri Nov 13 16:15:36 2009 From: gigabyte.tmn at gmail.com (Dmitriy Zamuraev) Date: Fri Nov 13 16:15:43 2009 Subject: pf & tcpdump References: <4AFD4632.5090207@sdalu.com> Message-ID: <002401ca6479$7e2031e0$1e010a0a@in72.ru> > Is there a way to have tcpdump only showing packed that have pass the > filtering rules, so to check that firewall rules were correctly written > and not letting unwanted packets in. > use pflog(4) device From jhb at freebsd.org Fri Nov 13 17:54:01 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 13 17:54:07 2009 Subject: ifnet renaming interacts badly with vlans Message-ID: <200911131244.58819.jhb@freebsd.org> So first the problem I am trying to solve. I would like to give meaningful aliases to interfaces and vlans on interfaces. For example, suppose I would I have em0 with a vlan of 112, but I would like to call em0, "foo" and em0.112, "foo.bar". One can do this if you do things in this order: ifconfig em0 name foo ifconfig foo.112 create ifconfig foo.112 name foo.bar However, our rc.d scripts want to create all cloned interfaces before applying renames, so to attempt to do this in /etc/rc.conf you would use something like: cloned_interfaces="em0.112" ifconfig_em0_name="foo" ifconfig_em0_112_name="foo.bar" However, this ends up doing a sequence more like: ifconfig em0.112 create ifconfig em0 name foo ifconfig em0.112 name foo.bar Unfortuantely, this sequence breaks em0.112 at the second step. The reason is that when em0 is renamed, the kernel actaully fires off event handlers claiming that the em0 ifnet has been detached and that a new foo ifnet has been attached. When this happens, the em0.112 vlan ifnet is orphaned. I think this is a bug in how renames are handled. Specifically, I don't think renaming an interface should always have the same semantics as if I had physically removed an interface and then later added it back. One alternative would be to instead broadcast a single "rename" event when an interface is renamed and things that cared about interface names (such as firewall rules) could still honor those events, but other subsystems might choose to ignore said events (e.g. vlan devices). Another alternative might be to use two different events ('ifnet_removed_name' and 'ifnet_added_name'). Subsystems that care about the name changing could reuse their existing detached/attached handlers for those two events without needing to change the event handlers themselves. A separate issue if the eventhandlers were changed is if we should use a different routing socket message when an interface is renamed or if it we should still claim that an interface has gone away and then come back. Given that we don't flush addresses from an interface when the name changes or even the ifindex it seems a bit disingenous to claim that the interface has detached and then reattached. -- John Baldwin From davej at wsnet.co.za Sat Nov 14 21:53:19 2009 From: davej at wsnet.co.za (Dave Johnson) Date: Sat Nov 14 21:53:25 2009 Subject: bce network card drivers Message-ID: <4AFF1767.1090802@wsnet.co.za> Hi al Installed 7.1 earlier and did a kernel update(after a src update) to 7.2. The network cards appear to have stopped working. They are using the "bce" driver Do they to have to patched? Regards -- From linimon at FreeBSD.org Sun Nov 15 05:24:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 15 05:24:13 2009 Subject: kern/140564: [wpi] Problem with Intel(R) PRO/Wireless 3945ABG Message-ID: <200911150524.nAF5O0hx006533@freefall.freebsd.org> Old Synopsis: Problem with Intel(R) PRO/Wireless 3945ABG New Synopsis: [wpi] Problem with Intel(R) PRO/Wireless 3945ABG Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 15 05:23:32 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140564 From CQG00620 at nifty.ne.jp Sun Nov 15 05:37:07 2009 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Sun Nov 15 05:37:14 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <200911061508.22482.jhb@freebsd.org> References: <200911061508.22482.jhb@freebsd.org> Message-ID: <20091115051758.8D4C892950@mail1.asahi-net.or.jp> Hi, I've tested the following NICs with your patch on CURRENT, and they works fine. Thanks! * Corega FastEther PCI-TX (DEC 21140-AF) de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 12 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: Ethernet address: 00:00:f4:xx:xx:xx de0: [ITHREAD] * Acer ALN-201C (Realtek RTL8029AS) ed0: port 0xe000-0xe01f irq 12 at device 15.0 on pci0 ed0: Ethernet address: 00:60:67:xx:xx:xx ed0: [ITHREAD] At Fri, 6 Nov 2009 15:08:22 -0500, John Baldwin wrote: > I have a patchset that converts all the remaining users of if_watchdog to > using a private callout instead. In some cases the the driver already used a > private timer to drive a stats timer and I merely hooked into that timer. In > other cases a new callout needed to be added to the driver. Some drivers > even abused the if_watchdog interface to provide a stats timer that fired > every second. :) For a few drivers I also fixed other things such as busted > locking, order-of-operations issues in detach, or just completely busted > drivers (fea(4) and fpa(4) which share the pdq backend). Please test. > Barring any major screaming and shouting I plan to commit this in a week or > so and after that to work on removing the if_watchdog/if_timer stuff from the > network stack. > > The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch (snip) --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From gavin at FreeBSD.org Sun Nov 15 20:19:30 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Nov 15 20:19:42 2009 Subject: bin/140571: [patch] ifconfig(8) does not set country DE Message-ID: <200911152019.nAFKJTNB009699@freefall.freebsd.org> Old Synopsis: ifconfig does not set country DE New Synopsis: [patch] ifconfig(8) does not set country DE State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Sun Nov 15 20:08:14 UTC 2009 State-Changed-Why: To submitter: Can you test http://people.freebsd.org/~gavin/PRs/140571.diff and make sure it fixes things for you? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Nov 15 20:08:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=140571 From linimon at FreeBSD.org Sun Nov 15 20:46:12 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 15 20:46:24 2009 Subject: kern/140567: [ath] [patch] ath is not worked on my notebook PC Message-ID: <200911152046.nAFKkCX6036545@freefall.freebsd.org> Synopsis: [ath] [patch] ath is not worked on my notebook PC Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 15 20:45:59 UTC 2009 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=140567 From alexbestms at wwu.de Mon Nov 16 02:00:07 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 16 02:00:14 2009 Subject: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Message-ID: <200911160200.nAG207fA001906@freefall.freebsd.org> The following reply was made to PR kern/128598; it has been noted by GNATS. From: Alexander Best To: , Cc: Subject: Re: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Date: Mon, 16 Nov 2009 02:52:51 +0100 (CET) i was getting this warning too with my pci ath(4) card, but recently the warning disappeared. i think this got fixed in HEAD and 8-stable (probably 8.0 too). alex From dirk.meyer at dinoex.sub.org Mon Nov 16 08:00:13 2009 From: dirk.meyer at dinoex.sub.org (Dirk Meyer) Date: Mon Nov 16 08:00:27 2009 Subject: bin/140571: [patch] ifconfig(8) does not set country DE Message-ID: <200911160800.nAG80C5s043460@freefall.freebsd.org> The following reply was made to PR bin/140571; it has been noted by GNATS. From: dirk.meyer@dinoex.sub.org (Dirk Meyer) To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: bin/140571: [patch] ifconfig(8) does not set country DE Date: Mon, 16 Nov 2009 08:54:35 +0100 The patch at http://people.freebsd.org/~gavin/PRs/140571.diff does fix the problem. DEB does match DEBUG DE can now selected and metahces the country D does match the first entry found (DEBUG), which is okay. # ifconfig wlan0 country DEB # ifconfig wlan0 wlan0: flags=8c02 metric 0 mtu 1500 ether 00:21:6b:a9:e4:22 inet6 fe80::221:6bff:fea9:e422%wlan0 prefixlen 64 scopeid 0x6 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) regdomain DEBUG authmode WPA1+WPA2/802.11i privacy OFF txpower 30 bmiss 10 scanvalid 60 wme # ifconfig wlan0 country DE # ifconfig wlan0 wlan0: flags=8c02 metric 0 mtu 1500 ether 00:21:6b:a9:e4:22 inet6 fe80::221:6bff:fea9:e422%wlan0 prefixlen 64 scopeid 0x6 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) regdomain ETSI country DE authmode WPA1+WPA2/802.11i privacy OFF txpower 30 bmiss 10 scanvalid 60 wme # ifconfig wlan0 country D # ifconfig wlan0 wlan0: flags=8c02 metric 0 mtu 1500 ether 00:21:6b:a9:e4:22 inet6 fe80::221:6bff:fea9:e422%wlan0 prefixlen 64 scopeid 0x6 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) regdomain DEBUG authmode WPA1+WPA2/802.11i privacy OFF txpower 30 bmiss 10 scanvalid 60 wme Thanks for the quick response. kind regards - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org] From linimon at FreeBSD.org Mon Nov 16 08:40:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Nov 16 08:40:10 2009 Subject: kern/140597: [request] implement Lost Retransmission Detection Message-ID: <200911160840.nAG8e37W082281@freefall.freebsd.org> Old Synopsis: Lost Retransmission Detection New Synopsis: [request] implement Lost Retransmission Detection State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Mon Nov 16 08:39:23 UTC 2009 State-Changed-Why: Mark suspended awaiting patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 16 08:39:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140597 From ask at develooper.com Mon Nov 16 10:35:13 2009 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Mon Nov 16 10:35:39 2009 Subject: DHCP client not getting IP address from Time Warner In-Reply-To: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> References: <36028DC7-4A90-4680-83ED-301FBE15F09C@develooper.com> Message-ID: <13160026-88A5-42F7-8431-54D624AA7B7F@develooper.com> On Nov 3, 2009, at 7:47, Ask Bj?rn Hansen wrote: > On FreeBSD their DHCP server seems to just ignore me (but I see lots of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've tried with both the standard dhclient and the isc dhclient from ports. Hi everyone, I just wanted to follow-up on my own mail to tell that the problem is "solved". Cloning the mac address from my mac seemed to work once, but not consistently. I never found out exactly what the OS X and the FreeBSD dhcp client are doing differently, but after turning off the cable modem again for a longer while the FreeBSD dhcp client got an IP. For some reason it appears that OS X is able to "move" the IP to another mac address/client much faster; but honestly after getting it working on the FreeBSD box I didn't want to fuzz with it anymore as it's working where I want it now. Thanks to everyone who helped with suggestions, questions and advice! - ask -- http://develooper.com/ - http://askask.com/ From kalin at el.net Mon Nov 16 10:48:52 2009 From: kalin at el.net (kalin m) Date: Mon Nov 16 10:49:03 2009 Subject: secure adhoc Message-ID: <4B012E13.8070206@el.net> hi all... i wrote this to the general questions list without much success. trying my luck here... wondering if somebody has done vpn between a bsd box and a portable device running windows mobile. is it possible? looking at the wireless networking off the handbook gives a direct example with 2 bsd machines. the bsd machine and the wireless device are hooked up now adhoc. they always going to be close to each other and there is no need of infrastructure mode at present time. if vpn is an overkill in this case what would be the best way to lock down the adhoc connection to be only between this two piers and isolate anybody else that wants to get on... thanks From bugmaster at FreeBSD.org Mon Nov 16 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 16 11:08:55 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200911161106.nAGB6vZF011238@freefall.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 -------------------------------------------------------------------------------- s kern/140597 net [request] implement Lost Retransmission Detection f 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/140358 net 8.0RC2: [arp] arp: writing to routing socket: Invalid 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/139559 net [tun] several tun(4) interfaces can be created with sa 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/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e 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 0xffffff004127b00 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 o kern/138676 net [route] after buildworld not work local routes [regres 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 net TCP 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 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 365 problems total. From attilio at freebsd.org Mon Nov 16 15:07:00 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 16 15:07:07 2009 Subject: [PATCH] libtacplus bugfix Message-ID: <3bbf2fe10911160706y9fb30e6iedb599cb8a6e2743@mail.gmail.com> [Please CC me as I'm not subscribed to -net@] In tac_get_av_value() empty attributes should be handled like 0-lenght strings while in the current code they are handled as unset attributes. This patch implements the (probabilly) desired semantic: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/libtacplus/taclib.diff This patch has been contributed back by Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Mon Nov 16 15:09:45 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 16 15:09:51 2009 Subject: [PATCH] Fix a socket leak in libfetch Message-ID: <3bbf2fe10911160709h39df3542v49644f11939d80cf@mail.gmail.com> [Please CC me as I'm not subscribed to -net@] In ftp_request(), after a successfully established connection, subsequent errors can bring to a socket leak. This patch should fix that: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/libfetch/ftp.diff This patch has been contributed back by Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Mon Nov 16 15:15:11 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 16 15:15:17 2009 Subject: [PATCH] Add idrop report to netstat Message-ID: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> [Please CC me as I'm not subscribed to -net@] This patch allows to show the informations about packets droped on input for interfaces on netstat: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff This patch as been contributed back from Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From des at des.no Mon Nov 16 15:27:47 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 16 15:27:53 2009 Subject: [PATCH] Fix a socket leak in libfetch In-Reply-To: <3bbf2fe10911160709h39df3542v49644f11939d80cf@mail.gmail.com> (Attilio Rao's message of "Mon, 16 Nov 2009 16:09:42 +0100") References: <3bbf2fe10911160709h39df3542v49644f11939d80cf@mail.gmail.com> Message-ID: <86y6m6o5fy.fsf@ds4.des.no> Attilio Rao writes: > In ftp_request(), after a successfully established connection, > subsequent errors can bring to a socket leak. > This patch should fix that: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/libfetch/ftp.diff Thanks, Attilio. Please commit the patch. DES -- Dag-Erling Sm?rgrav - des@des.no From gigabyte.tmn at gmail.com Mon Nov 16 18:05:19 2009 From: gigabyte.tmn at gmail.com (Dmitriy Zamuraev) Date: Mon Nov 16 18:05:25 2009 Subject: bsnmpd HighCounters on if_lagg Message-ID: <001201ca66e7$5a3e20a0$1e010a0a@in72.ru> I have BRAS based on FreeBSD 7.2 and mpd 5.3 and three NIC's grouped into if_lagg with LACP, I need to monitor bandwidth with bsnmpd and cacti, by default lagg interface baud rate is 10Mbitps, so bsnmpd can't collect Counter64 on this interface. I'm modify if_lagg.c file: function lagg_link_state(): u_long new_baudrate; SLIST_FORAECH(lp, &sc_ports, lp_entries) if (lp->lp_link_state == LINK_STATE_UP) new_baudrate += lp->lp_ifp->if_baudrate; sc->sc_ifp->if_baudrate = new_baudrate; So, bsnmpd shows ifHighSpeed and ifHC(In|Out)Octets. I'm happy. Also i have if_vlan interfaces over the if_lagg, and vlan interfaces have baud rate 10Mbitps too. I don't need Counter64 functionality on vlan interfaces, but i think develop this functionality is difficult. Please, tell me who needs this functionality. From pyunyh at gmail.com Mon Nov 16 18:24:55 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 16 18:25:02 2009 Subject: [PATCH] Add idrop report to netstat In-Reply-To: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> References: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> Message-ID: <20091116182423.GD1262@michelle.cdnetworks.com> On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote: > [Please CC me as I'm not subscribed to -net@] > > This patch allows to show the informations about packets droped on > input for interfaces on netstat: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff > > This patch as been contributed back from Sandvine Incorporated. > Comments, reviews and testing are welcome. > Doesn't -d of netstat(1) show the same information? From attilio at freebsd.org Mon Nov 16 22:04:22 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 16 22:05:17 2009 Subject: [PATCH] Add idrop report to netstat In-Reply-To: <20091116182423.GD1262@michelle.cdnetworks.com> References: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> <20091116182423.GD1262@michelle.cdnetworks.com> Message-ID: <3bbf2fe10911161404s4c5870a4pe0afbb890e0fdde2@mail.gmail.com> 2009/11/16 Pyun YongHyeon : > On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote: >> [Please CC me as I'm not subscribed to -net@] >> >> This patch allows to show the informations about packets droped on >> input for interfaces on netstat: >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff >> >> This patch as been contributed back from Sandvine Incorporated. >> Comments, reviews and testing are welcome. >> > > Doesn't -d of netstat(1) show the same information? Am I wrong or "-d" prints the drops on the output path? The patch provides information on the input drops. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From pyunyh at gmail.com Mon Nov 16 23:39:01 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 16 23:39:08 2009 Subject: [PATCH] Add idrop report to netstat In-Reply-To: <3bbf2fe10911161404s4c5870a4pe0afbb890e0fdde2@mail.gmail.com> References: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> <20091116182423.GD1262@michelle.cdnetworks.com> <3bbf2fe10911161404s4c5870a4pe0afbb890e0fdde2@mail.gmail.com> Message-ID: <20091116233828.GG1262@michelle.cdnetworks.com> On Mon, Nov 16, 2009 at 11:04:20PM +0100, Attilio Rao wrote: > 2009/11/16 Pyun YongHyeon : > > On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote: > >> [Please CC me as I'm not subscribed to -net@] > >> > >> This patch allows to show the informations about packets droped on > >> input for interfaces on netstat: > >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff > >> > >> This patch as been contributed back from Sandvine Incorporated. > >> Comments, reviews and testing are welcome. > >> > > > > Doesn't -d of netstat(1) show the same information? > > Am I wrong or "-d" prints the drops on the output path? > The patch provides information on the input drops. > struct if_data { /* generic interface information */ u_char ifi_type; /* ethernet, tokenring, etc */ u_char ifi_physical; /* e.g., AUI, Thinnet, 10base-T, etc */ [...] u_long ifi_iqdrops; /* dropped on input, this interface */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ u_long ifi_noproto; /* destined for unsupported protocol */ u_long ifi_hwassist; /* HW offload capabilities, see IFCAP */ time_t ifi_epoch; /* uptime at attach or stat reset */ struct timeval ifi_lastchange; /* time of last administrative change */ }; > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Mon Nov 16 23:56:26 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 16 23:56:32 2009 Subject: [PATCH] Add idrop report to netstat In-Reply-To: <20091116233828.GG1262@michelle.cdnetworks.com> References: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> <20091116182423.GD1262@michelle.cdnetworks.com> <3bbf2fe10911161404s4c5870a4pe0afbb890e0fdde2@mail.gmail.com> <20091116233828.GG1262@michelle.cdnetworks.com> Message-ID: <3bbf2fe10911161556h6fb602a6qe5043fea590e7800@mail.gmail.com> 2009/11/17 Pyun YongHyeon : > On Mon, Nov 16, 2009 at 11:04:20PM +0100, Attilio Rao wrote: >> 2009/11/16 Pyun YongHyeon : >> > On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote: >> >> [Please CC me as I'm not subscribed to -net@] >> >> >> >> This patch allows to show the informations about packets droped on >> >> input for interfaces on netstat: >> >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff >> >> >> >> This patch as been contributed back from Sandvine Incorporated. >> >> Comments, reviews and testing are welcome. >> >> >> > >> > Doesn't -d of netstat(1) show the same information? >> >> Am I wrong or "-d" prints the drops on the output path? >> The patch provides information on the input drops. >> > > struct if_data { > /* generic interface information */ > u_char ifi_type; /* ethernet, tokenring, etc */ > u_char ifi_physical; /* e.g., AUI, Thinnet, 10base-T, etc */ > [...] > u_long ifi_iqdrops; /* dropped on input, this interface */ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > u_long ifi_noproto; /* destined for unsupported protocol */ > u_long ifi_hwassist; /* HW offload capabilities, see IFCAP */ > time_t ifi_epoch; /* uptime at attach or stat reset */ > struct timeval ifi_lastchange; /* time of last administrative change */ > }; Err, but dflag does print out if_snd.ifq_drops. Infact: @if.c:sidewaysintpr() [...] if (!first) { show_stat("lu", 10, ifnet.if_ipackets - ip->ift_ip, 1); show_stat("lu", 5, ifnet.if_ierrors - ip->ift_ie, 1); show_stat("lu", 10, ifnet.if_ibytes - ip->ift_ib, 1); show_stat("lu", 10, ifnet.if_opackets - ip->ift_op, 1); show_stat("lu", 5, ifnet.if_oerrors - ip->ift_oe, 1); show_stat("lu", 10, ifnet.if_obytes - ip->ift_ob, 1); show_stat("NRSlu", 5, ifnet.if_collisions - ip->ift_co, 1); if (dflag) show_stat("LSu", 5, ifnet.if_snd.ifq_drops - ip->ift_dr, 1); } [...] if (!first) { show_stat("lu", 10, sum->ift_ip - total->ift_ip, 1); show_stat("lu", 5, sum->ift_ie - total->ift_ie, 1); show_stat("lu", 10, sum->ift_ib - total->ift_ib, 1); show_stat("lu", 10, sum->ift_op - total->ift_op, 1); show_stat("lu", 5, sum->ift_oe - total->ift_oe, 1); show_stat("lu", 10, sum->ift_ob - total->ift_ob, 1); show_stat("NRSlu", 5, sum->ift_co - total->ift_co, 1); if (dflag) show_stat("LSu", 5, sum->ift_dr - total->ift_dr, 1); } Which is defined in sys/net/if_var.h as: struct ifnet { void *if_softc; /* pointer to driver state */ void *if_l2com; /* pointer to protocol bits */ struct vnet *if_vnet; /* pointer to network stack instance */ [...] int if_drv_flags; /* driver-managed status flags */ struct ifaltq if_snd; /* output queue (includes altq) */ const u_int8_t *if_broadcastaddr; /* linklevel broadcast bytestring */ [...] }; Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From pluknet at gmail.com Tue Nov 17 00:29:05 2009 From: pluknet at gmail.com (pluknet) Date: Tue Nov 17 00:29:12 2009 Subject: [PATCH] Add idrop report to netstat In-Reply-To: <3bbf2fe10911161556h6fb602a6qe5043fea590e7800@mail.gmail.com> References: <3bbf2fe10911160715m34fc0ba4hc13af02541405491@mail.gmail.com> <20091116182423.GD1262@michelle.cdnetworks.com> <3bbf2fe10911161404s4c5870a4pe0afbb890e0fdde2@mail.gmail.com> <20091116233828.GG1262@michelle.cdnetworks.com> <3bbf2fe10911161556h6fb602a6qe5043fea590e7800@mail.gmail.com> Message-ID: 2009/11/17 Attilio Rao : > 2009/11/17 Pyun YongHyeon : >> On Mon, Nov 16, 2009 at 11:04:20PM +0100, Attilio Rao wrote: >>> 2009/11/16 Pyun YongHyeon : >>> > On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote: >>> >> [Please CC me as I'm not subscribed to -net@] >>> >> >>> >> This patch allows to show the informations about packets droped on >>> >> input for interfaces on netstat: >>> >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff >>> >> >>> >> This patch as been contributed back from Sandvine Incorporated. >>> >> Comments, reviews and testing are welcome. >>> >> >>> > >>> > Doesn't -d of netstat(1) show the same information? >>> >>> Am I wrong or "-d" prints the drops on the output path? >>> The patch provides information on the input drops. >>> >> >> struct if_data { >> ? ? ? ?/* generic interface information */ >> ? ? ? ?u_char ?ifi_type; ? ? ? ? ? ? ? /* ethernet, tokenring, etc */ >> ? ? ? ?u_char ?ifi_physical; ? ? ? ? ? /* e.g., AUI, Thinnet, 10base-T, etc */ >> [...] >> ? ? ? ?u_long ?ifi_iqdrops; ? ? ? ? ? ?/* dropped on input, this interface */ >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> ? ? ? ?u_long ?ifi_noproto; ? ? ? ? ? ?/* destined for unsupported protocol */ >> ? ? ? ?u_long ?ifi_hwassist; ? ? ? ? ? /* HW offload capabilities, see IFCAP */ >> ? ? ? ?time_t ?ifi_epoch; ? ? ? ? ? ? ?/* uptime at attach or stat reset */ >> ? ? ? ?struct ?timeval ifi_lastchange; /* time of last administrative change */ >> }; > > Err, but dflag does print out if_snd.ifq_drops. Infact: > > @if.c:sidewaysintpr() > > [...] > ? ? ? ? ? ? ? ?if (!first) { > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, ifnet.if_ipackets - ip->ift_ip, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 5, ifnet.if_ierrors - ip->ift_ie, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, ifnet.if_ibytes - ip->ift_ib, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, ifnet.if_opackets - ip->ift_op, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 5, ifnet.if_oerrors - ip->ift_oe, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, ifnet.if_obytes - ip->ift_ob, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("NRSlu", 5, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?ifnet.if_collisions - ip->ift_co, 1); > ? ? ? ? ? ? ? ? ? ? ? ?if (dflag) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?show_stat("LSu", 5, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ifnet.if_snd.ifq_drops - ip->ift_dr, 1); > ? ? ? ? ? ? ? ?} > [...] > ? ? ? ? ? ? ? if (!first) { > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, sum->ift_ip - total->ift_ip, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 5, sum->ift_ie - total->ift_ie, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, sum->ift_ib - total->ift_ib, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, sum->ift_op - total->ift_op, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 5, sum->ift_oe - total->ift_oe, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("lu", 10, sum->ift_ob - total->ift_ob, 1); > ? ? ? ? ? ? ? ? ? ? ? ?show_stat("NRSlu", 5, sum->ift_co - total->ift_co, 1); > ? ? ? ? ? ? ? ? ? ? ? ?if (dflag) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?show_stat("LSu", 5, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sum->ift_dr - total->ift_dr, 1); > ? ? ? ? ? ? ? ?} > > > Which is defined in sys/net/if_var.h as: > > struct ifnet { > ? ? ? ?void ? ?*if_softc; ? ? ? ? ? ? ?/* pointer to driver state */ > ? ? ? ?void ? ?*if_l2com; ? ? ? ? ? ? ?/* pointer to protocol bits */ > ? ? ? ?struct vnet *if_vnet; ? ? ? ? ? /* pointer to network stack instance */ > [...] > ? ? ? ?int ? ? if_drv_flags; ? ? ? ? ? /* driver-managed status flags */ > ? ? ? ?struct ?ifaltq if_snd; ? ? ? ? ?/* output queue (includes altq) */ > ? ? ? ?const u_int8_t *if_broadcastaddr; /* linklevel broadcast bytestring */ > [...] > }; ifq_drops != *_iqdrops Historically *_iqdrops was designed strictly to record falure to allocate a buffer on Rx chain (or so). while ifq_drops was for logically higher level: output and (some kind of) input ifnet queue shortage stats. [and that's recorded in the earlier BSD's. Though, input queue was replaced later with netisr magics in if_ethersubr.c, though it still possible to track the roots in struct netist_work{ nw_len..nw_qlimit..nw_drops }). -- wbr, pluknet From linimon at FreeBSD.org Tue Nov 17 03:26:25 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Nov 17 03:26:32 2009 Subject: kern/140619: [ifnet] [patch] refine obsolete if_var.h comments describing ifnet->if_poll_slowq Message-ID: <200911170326.nAH3QPRj058318@freefall.freebsd.org> Old Synopsis: refine obsolete if_var.h comments describing ifnet->if_poll_slowq New Synopsis: [ifnet] [patch] refine obsolete if_var.h comments describing ifnet->if_poll_slowq Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 17 03:26:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140619 From jhb at freebsd.org Tue Nov 17 14:31:29 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Nov 17 14:31:52 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <20091115051758.8D4C892950@mail1.asahi-net.or.jp> References: <200911061508.22482.jhb@freebsd.org> <20091115051758.8D4C892950@mail1.asahi-net.or.jp> Message-ID: <200911170930.52556.jhb@freebsd.org> On Sunday 15 November 2009 12:17:57 am WATANABE Kazuhiro wrote: > Hi, > > I've tested the following NICs with your patch on CURRENT, and they > works fine. Thanks! > > * Corega FastEther PCI-TX (DEC 21140-AF) > > de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 12 at device 15.0 on pci0 > de0: 21140A [10-100Mb/s] pass 2.2 > de0: Ethernet address: 00:00:f4:xx:xx:xx > de0: [ITHREAD] > > * Acer ALN-201C (Realtek RTL8029AS) > > ed0: port 0xe000-0xe01f irq 12 at device 15.0 on pci0 > ed0: Ethernet address: 00:60:67:xx:xx:xx > ed0: [ITHREAD] Great, thanks for testing! -- John Baldwin From leonardo at procergs.rs.gov.br Tue Nov 17 15:11:30 2009 From: leonardo at procergs.rs.gov.br (Leonardo Reginin) Date: Tue Nov 17 15:11:37 2009 Subject: OSPF and ifconfig -alias problem Message-ID: <4B02B90B.6090407@procergs.rs.gov.br> Hello fellows. I have a FreeBSD 5.1 ( it's old, I know ) and a Zebra 0.95a version providing ospf dynamic routing. Recently I added an IP alias to the interface where the ospf is acting and everything went OK. When a removed the IP alias - ifconfig bge0 -alias .... - the server lost all the routes learned to that interface. The interface did not went down. I googled a lot and did not find an explanation. Excuse me if this isn't the most appropriated list to post my question. -- Att, Leonardo Reginin =============================================================== PROCERGS - Cia. Processamento de Dados do Estado do RS DPR/SSR - Divis?o de Produ??o/Setor de Suporte e Projeto Redes Fone: 55(xx51)3210-3138 =============================================================== From linimon at FreeBSD.org Tue Nov 17 15:50:05 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Nov 17 15:50:11 2009 Subject: kern/140634: [vlan] destroying if_lagg interface with if_vlan members causing 100% usage by ifconfig Message-ID: <200911171550.nAHFo4qQ038534@freefall.freebsd.org> Old Synopsis: destroying if_lagg interface with if_vlan members causing 100% usage by ifconfig New Synopsis: [vlan] destroying if_lagg interface with if_vlan members causing 100% usage by ifconfig Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 17 15:49:37 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140634 From linimon at FreeBSD.org Tue Nov 17 23:05:13 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Nov 17 23:05:27 2009 Subject: kern/140647: [em] [patch] e1000 driver does not correctly handle multicast promiscuous mode with 128 or more multicast addresses Message-ID: <200911172305.nAHN5DFi015428@freefall.freebsd.org> Old Synopsis: [patch] e1000 driver does not correctly handle multicast promiscuous mode with 128 or more multicast addresses New Synopsis: [em] [patch] e1000 driver does not correctly handle multicast promiscuous mode with 128 or more multicast addresses Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 17 23:04:37 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140647 From jonlooney at gmail.com Tue Nov 17 23:10:05 2009 From: jonlooney at gmail.com (Jonathan Looney) Date: Tue Nov 17 23:10:14 2009 Subject: kern/140647: [patch] e1000 driver does not correctly handle multicast promiscuous mode with 128 or more multicast addresses Message-ID: <200911172310.nAHNA4kp015658@freefall.freebsd.org> The following reply was made to PR kern/140647; it has been noted by GNATS. From: Jonathan Looney To: bug-followup@freebsd.org, freebsd-bugs@freebsd.org Cc: Subject: Re: kern/140647: [patch] e1000 driver does not correctly handle multicast promiscuous mode with 128 or more multicast addresses Date: Tue, 17 Nov 2009 17:36:07 -0500 --001485f9a72c8aa5b3047898c0e5 Content-Type: multipart/alternative; boundary=001485f9a72c8aa5ac047898c0e3 --001485f9a72c8aa5ac047898c0e3 Content-Type: text/plain; charset=ISO-8859-1 Here are the files used with mtest to recreate this problem. (Hopefully, they won't get mangled by the mail system.) If you need more information, please let me know. -Jon --001485f9a72c8aa5ac047898c0e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here are the files used with mtest to recreate this problem.=A0 (Hopefully,= they won't get mangled by the mail system.)

If you need more in= formation, please let me know.

-Jon
--001485f9a72c8aa5ac047898c0e3-- --001485f9a72c8aa5b3047898c0e5 Content-Type: application/octet-stream; name=mtest-cmds-step1 Content-Disposition: attachment; filename=mtest-cmds-step1 Content-Transfer-Encoding: base64 X-Attachment-Id: f_g258tiea0 aiAyMjUuMC4wLjEgZW0wCmogMjI1LjAuMC4yIGVtMApqIDIyNS4wLjAuMyBlbTAKaiAyMjUuMC4w LjQgZW0wCmogMjI1LjAuMC41IGVtMApqIDIyNS4wLjAuNiBlbTAKaiAyMjUuMC4wLjcgZW0wCmog MjI1LjAuMC44IGVtMApqIDIyNS4wLjAuOSBlbTAKaiAyMjUuMC4wLjEwIGVtMApqIDIyNS4wLjAu MTEgZW0wCmogMjI1LjAuMC4xMiBlbTAKaiAyMjUuMC4wLjEzIGVtMApqIDIyNS4wLjAuMTQgZW0w CmogMjI1LjAuMC4xNSBlbTAKaiAyMjUuMC4wLjE2IGVtMApqIDIyNS4wLjAuMTcgZW0wCmogMjI1 LjAuMC4xOCBlbTAKaiAyMjUuMC4wLjE5IGVtMApqIDIyNS4wLjAuMjAgZW0wCmogMjI1LjAuMC4y MSBlbTAKaiAyMjUuMC4wLjIyIGVtMApqIDIyNS4wLjAuMjMgZW0wCmogMjI1LjAuMC4yNCBlbTAK aiAyMjUuMC4wLjI1IGVtMApqIDIyNS4wLjAuMjYgZW0wCmogMjI1LjAuMC4yNyBlbTAKaiAyMjUu MC4wLjI4IGVtMApqIDIyNS4wLjAuMjkgZW0wCmogMjI1LjAuMC4zMCBlbTAKaiAyMjUuMC4wLjMx IGVtMApqIDIyNS4wLjAuMzIgZW0wCmogMjI1LjAuMC4zMyBlbTAKaiAyMjUuMC4wLjM0IGVtMApq IDIyNS4wLjAuMzUgZW0wCmogMjI1LjAuMC4zNiBlbTAKaiAyMjUuMC4wLjM3IGVtMApqIDIyNS4w LjAuMzggZW0wCmogMjI1LjAuMC4zOSBlbTAKaiAyMjUuMC4wLjQwIGVtMApqIDIyNS4wLjAuNDEg ZW0wCmogMjI1LjAuMC40MiBlbTAKaiAyMjUuMC4wLjQzIGVtMApqIDIyNS4wLjAuNDQgZW0wCmog MjI1LjAuMC40NSBlbTAKaiAyMjUuMC4wLjQ2IGVtMApqIDIyNS4wLjAuNDcgZW0wCmogMjI1LjAu MC40OCBlbTAKaiAyMjUuMC4wLjQ5IGVtMApqIDIyNS4wLjAuNTAgZW0wCmogMjI1LjAuMC41MSBl bTAKaiAyMjUuMC4wLjUyIGVtMApqIDIyNS4wLjAuNTMgZW0wCmogMjI1LjAuMC41NCBlbTAKaiAy MjUuMC4wLjU1IGVtMApqIDIyNS4wLjAuNTYgZW0wCmogMjI1LjAuMC41NyBlbTAKaiAyMjUuMC4w LjU4IGVtMApqIDIyNS4wLjAuNTkgZW0wCmogMjI1LjAuMC42MCBlbTAKaiAyMjUuMC4wLjYxIGVt MApqIDIyNS4wLjAuNjIgZW0wCmogMjI1LjAuMC42MyBlbTAKaiAyMjUuMC4wLjY0IGVtMApqIDIy NS4wLjAuNjUgZW0wCmogMjI1LjAuMC42NiBlbTAKaiAyMjUuMC4wLjY3IGVtMApqIDIyNS4wLjAu NjggZW0wCmogMjI1LjAuMC42OSBlbTAKaiAyMjUuMC4wLjcwIGVtMApqIDIyNS4wLjAuNzEgZW0w CmogMjI1LjAuMC43MiBlbTAKaiAyMjUuMC4wLjczIGVtMApqIDIyNS4wLjAuNzQgZW0wCmogMjI1 LjAuMC43NSBlbTAKaiAyMjUuMC4wLjc2IGVtMApqIDIyNS4wLjAuNzcgZW0wCmogMjI1LjAuMC43 OCBlbTAKaiAyMjUuMC4wLjc5IGVtMApqIDIyNS4wLjAuODAgZW0wCmogMjI1LjAuMC44MSBlbTAK aiAyMjUuMC4wLjgyIGVtMApqIDIyNS4wLjAuODMgZW0wCmogMjI1LjAuMC44NCBlbTAKaiAyMjUu MC4wLjg1IGVtMApqIDIyNS4wLjAuODYgZW0wCmogMjI1LjAuMC44NyBlbTAKaiAyMjUuMC4wLjg4 IGVtMApqIDIyNS4wLjAuODkgZW0wCmogMjI1LjAuMC45MCBlbTAKaiAyMjUuMC4wLjkxIGVtMApq IDIyNS4wLjAuOTIgZW0wCmogMjI1LjAuMC45MyBlbTAKaiAyMjUuMC4wLjk0IGVtMApqIDIyNS4w LjAuOTUgZW0wCmogMjI1LjAuMC45NiBlbTAKaiAyMjUuMC4wLjk3IGVtMApqIDIyNS4wLjAuOTgg ZW0wCmogMjI1LjAuMC45OSBlbTAK --001485f9a72c8aa5b3047898c0e5 Content-Type: application/octet-stream; name=mtest-cmds-step2 Content-Disposition: attachment; filename=mtest-cmds-step2 Content-Transfer-Encoding: base64 X-Attachment-Id: f_g258tiej1 aiAyMjUuMC4wLjEwMCBlbTAKaiAyMjUuMC4wLjEwMSBlbTAKaiAyMjUuMC4wLjEwMiBlbTAKaiAy MjUuMC4wLjEwMyBlbTAKaiAyMjUuMC4wLjEwNCBlbTAKaiAyMjUuMC4wLjEwNSBlbTAKaiAyMjUu MC4wLjEwNiBlbTAKaiAyMjUuMC4wLjEwNyBlbTAKaiAyMjUuMC4wLjEwOCBlbTAKaiAyMjUuMC4w LjEwOSBlbTAKaiAyMjUuMC4wLjExMCBlbTAKaiAyMjUuMC4wLjExMSBlbTAKaiAyMjUuMC4wLjEx MiBlbTAKaiAyMjUuMC4wLjExMyBlbTAKaiAyMjUuMC4wLjExNCBlbTAKaiAyMjUuMC4wLjExNSBl bTAKaiAyMjUuMC4wLjExNiBlbTAKaiAyMjUuMC4wLjExNyBlbTAKaiAyMjUuMC4wLjExOCBlbTAK aiAyMjUuMC4wLjExOSBlbTAKaiAyMjUuMC4wLjEyMCBlbTAKaiAyMjUuMC4wLjEyMSBlbTAKaiAy MjUuMC4wLjEyMiBlbTAKaiAyMjUuMC4wLjEyMyBlbTAKaiAyMjUuMC4wLjEyNCBlbTAKaiAyMjUu MC4wLjEyNSBlbTAKaiAyMjUuMC4wLjEyNiBlbTAKaiAyMjUuMC4wLjEyNyBlbTAKaiAyMjUuMC4w LjEyOCBlbTAKaiAyMjUuMC4wLjEyOSBlbTAK --001485f9a72c8aa5b3047898c0e5 Content-Type: application/octet-stream; name=mtest-cmds-step3 Content-Disposition: attachment; filename=mtest-cmds-step3 Content-Transfer-Encoding: base64 X-Attachment-Id: f_g258tien2 bCAyMjUuMC4wLjEwMCBlbTAKbCAyMjUuMC4wLjEwMSBlbTAKbCAyMjUuMC4wLjEwMiBlbTAKbCAy MjUuMC4wLjEwMyBlbTAKbCAyMjUuMC4wLjEwNCBlbTAKbCAyMjUuMC4wLjEwNSBlbTAKbCAyMjUu MC4wLjEwNiBlbTAKbCAyMjUuMC4wLjEwNyBlbTAKbCAyMjUuMC4wLjEwOCBlbTAKbCAyMjUuMC4w LjEwOSBlbTAKbCAyMjUuMC4wLjExMCBlbTAKbCAyMjUuMC4wLjExMSBlbTAKbCAyMjUuMC4wLjEx MiBlbTAKbCAyMjUuMC4wLjExMyBlbTAKbCAyMjUuMC4wLjExNCBlbTAKbCAyMjUuMC4wLjExNSBl bTAKbCAyMjUuMC4wLjExNiBlbTAKbCAyMjUuMC4wLjExNyBlbTAKbCAyMjUuMC4wLjExOCBlbTAK bCAyMjUuMC4wLjExOSBlbTAKbCAyMjUuMC4wLjEyMCBlbTAKbCAyMjUuMC4wLjEyMSBlbTAKbCAy MjUuMC4wLjEyMiBlbTAKbCAyMjUuMC4wLjEyMyBlbTAKbCAyMjUuMC4wLjEyNCBlbTAKbCAyMjUu MC4wLjEyNSBlbTAKbCAyMjUuMC4wLjEyNiBlbTAKbCAyMjUuMC4wLjEyNyBlbTAKbCAyMjUuMC4w LjEyOCBlbTAKbCAyMjUuMC4wLjEyOSBlbTAK --001485f9a72c8aa5b3047898c0e5 Content-Type: application/octet-stream; name=mtest-cmds-step4 Content-Disposition: attachment; filename=mtest-cmds-step4 Content-Transfer-Encoding: base64 X-Attachment-Id: f_g258tiep3 aiAyMjUuMC4wLjEwMCBlbTAKaiAyMjUuMC4wLjEwMSBlbTAKaiAyMjUuMC4wLjEwMiBlbTAKaiAy MjUuMC4wLjEwMyBlbTAKaiAyMjUuMC4wLjEwNCBlbTAKaiAyMjUuMC4wLjEwNSBlbTAKaiAyMjUu MC4wLjEwNiBlbTAKaiAyMjUuMC4wLjEwNyBlbTAKaiAyMjUuMC4wLjEwOCBlbTAKaiAyMjUuMC4w LjEwOSBlbTAKaiAyMjUuMC4wLjExMCBlbTAKaiAyMjUuMC4wLjExMSBlbTAKaiAyMjUuMC4wLjEx MiBlbTAKaiAyMjUuMC4wLjExMyBlbTAKaiAyMjUuMC4wLjExNCBlbTAKaiAyMjUuMC4wLjExNSBl bTAKaiAyMjUuMC4wLjExNiBlbTAKaiAyMjUuMC4wLjExNyBlbTAKaiAyMjUuMC4wLjExOCBlbTAK aiAyMjUuMC4wLjExOSBlbTAKaiAyMjUuMC4wLjEyMCBlbTAKaiAyMjUuMC4wLjEyMSBlbTAKaiAy MjUuMC4wLjEyMiBlbTAKaiAyMjUuMC4wLjEyMyBlbTAKaiAyMjUuMC4wLjEyNCBlbTAKaiAyMjUu MC4wLjEyNSBlbTAKaiAyMjUuMC4wLjEyNiBlbTAKaiAyMjUuMC4wLjEyNyBlbTAKaiAyMjUuMC4w LjEyOCBlbTAKaiAyMjUuMC4wLjEyOSBlbTAKaiAyMjUuMC4wLjEzMCBlbTAKaiAyMjUuMC4wLjEz MSBlbTAKaiAyMjUuMC4wLjEzMiBlbTAKaiAyMjUuMC4wLjEzMyBlbTAKaiAyMjUuMC4wLjEzNCBl bTAKaiAyMjUuMC4wLjEzNSBlbTAKaiAyMjUuMC4wLjEzNiBlbTAKaiAyMjUuMC4wLjEzNyBlbTAK aiAyMjUuMC4wLjEzOCBlbTAKaiAyMjUuMC4wLjEzOSBlbTAKaiAyMjUuMC4wLjE0MCBlbTAKaiAy MjUuMC4wLjE0MSBlbTAKaiAyMjUuMC4wLjE0MiBlbTAKaiAyMjUuMC4wLjE0MyBlbTAKaiAyMjUu MC4wLjE0NCBlbTAKaiAyMjUuMC4wLjE0NSBlbTAKaiAyMjUuMC4wLjE0NiBlbTAKaiAyMjUuMC4w LjE0NyBlbTAKaiAyMjUuMC4wLjE0OCBlbTAKaiAyMjUuMC4wLjE0OSBlbTAK --001485f9a72c8aa5b3047898c0e5-- From dougb at FreeBSD.org Tue Nov 17 23:51:04 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Nov 17 23:51:11 2009 Subject: OSPF and ifconfig -alias problem In-Reply-To: <4B02B90B.6090407@procergs.rs.gov.br> References: <4B02B90B.6090407@procergs.rs.gov.br> Message-ID: <4B0336E7.8070800@FreeBSD.org> Leonardo Reginin wrote: > Hello fellows. > > I have a FreeBSD 5.1 ( it's old, I know ) It's well past old. You're unlikely to get any help on this since 5.x is EOL and 5.1 isn't even close to the latest release on that branch. I would be happy to be proven wrong though. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From davidch at broadcom.com Wed Nov 18 02:28:54 2009 From: davidch at broadcom.com (David Christensen) Date: Wed Nov 18 02:29:01 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AFC862B.6060805@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A20E0E802@IRVEXCHCCR01.corp.ad.broadcom.com> > > I haven't been able to reproduce it on the r710 I have in house. > > Checking with other groups now to see if they have one a I can use, > > though I'm not sure why the system would make a difference for this > > particular issue. Just wanted to confirm that you're using > the driver > > built into the kernel (as opposed to a module) and that a warm boot > > means running the "reboot" or "shutdown -r" > > commands while a cold boot means pressing the front panel > power button > > or using the DRAC to power down the system. > > > > Dave > > Hi Dave, > > Thanks for the update. > > All these are true. > > warm - shutdown -r now > cold - from the power button (iDRACs are not configured yet). > > bce is compiled into the kernel (tested with GENERIC kernel > from 8-RC2 as well as 7.1 with the 7.2 driver plus the split > header patch). > > For the record we also have not been able to reproduce the > issue on the R710 only the R610. Still no luck on my r710, even after reverting to the production firmware and blasting broadcast traffic at the interface during reset. Let me check again on an r610. Dave From delphij at gmail.com Wed Nov 18 03:07:40 2009 From: delphij at gmail.com (Xin LI) Date: Wed Nov 18 03:07:47 2009 Subject: [PATCH FOR REVIEW] interface description (revised) Message-ID: Hi, Here is the revised implementation for the interface description feature, based on feedback from src-all@. Some limitations: * Not yet able to send announce through route socket. I need to figure out a proper way to do this, maybe a future feature; * 32-bit vs 64-bit API compatibility. Since the kernel has to copy in a string, is there a clean way to do this? I think we will also need to deal with similar issue with SIOCSIFNAME as well. Cheers, -- Xin LI http://www.delphij.net -------------- next part -------------- A non-text attachment was scrubbed... Name: ifdescr.diff Type: application/octet-stream Size: 14168 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091118/5e73d203/ifdescr.obj From delphij at gmail.com Wed Nov 18 03:08:38 2009 From: delphij at gmail.com (Xin LI) Date: Wed Nov 18 03:08:45 2009 Subject: [PATCH FOR REVIEW] interface description (revised) In-Reply-To: References: Message-ID: Since I'm not pretty sure if gmail will mangle the attachment, here is a downloadable version: http://people.freebsd.org/~delphij/for_review/ifdescr.diff -- Xin LI http://www.delphij.net From rwatson at freebsd.org Wed Nov 18 09:49:18 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Wed Nov 18 09:49:24 2009 Subject: [PATCH FOR REVIEW] interface description (revised) In-Reply-To: References: Message-ID: <01D9CB64-F04C-4506-ACF2-1DE459FC69CD@freebsd.org> On 18 Nov 2009, at 02:39, Xin LI wrote: > Here is the revised implementation for the interface description > feature, based on feedback from src-all@. Hi Xin Li, Thanks for the updated patch. This looks significantly improved. Comments inline. > --- contrib/libpcap/inet.c (revision 199463) > +++ contrib/libpcap/inet.c (working copy) > @@ -403,22 +403,30 @@ add_addr_to_iflist(pcap_if_t **alldevs, const char > pcap_addr_t *curaddr, *prevaddr, *nextaddr; > #ifdef SIOCGIFDESCR > struct ifreq ifrdesc; > +#ifndef IFDESCRSIZE > +#define _IFDESCRSIZE 64 > + char ifdescr[_IFDESCRSIZE]; > +#else > char ifdescr[IFDESCRSIZE]; > +#endif > int s; > -#endif > > -#ifdef SIOCGIFDESCR I'm pretty sure the intent here is that 'int s' be defined regardless of SIOCGIFDESCR, it would be worth confirming that these patches applied to a pre-SIOCGIFDESCR tcpdump compile correctly. We will want to upstream these patches to the vendor so we should make sure the changes are acceptable there. > + descr = reallocf(descr, descrlen); > + if (descr != NULL) { > + do { > + ifr.ifr_buffer.buffer = descr; > + ifr.ifr_buffer.length = descrlen; > + if (ioctl(s, SIOCGIFDESCR, &ifr) == 0) { > + if (strlen(descr) > 0) > + printf("\tdescription: %s\n", descr); > + break; > + } > + if (errno == ENAMETOOLONG) { > + descrlen *= 2; > + descr = reallocf(descr, descrlen); > + } > + } while ((errno == ENAMETOOLONG) && (descr != NULL)); > + } The error non-handling throughout ifconfig worries me; on the whole, your patch seems consistent with the existing model, but here I wonder if we should be printing a warning if reallocf() fails? Perhaps the above loop could be restructured so that there is only a single calling point to reallocf -- perhaps while ((descr = reallocf()) != NULL) { ... }? It might make the invariants a bit more clear. > + DEF_CMD_ARG("description", setifdescr), > + DEF_CMD_ARG("descr", setifdescr), > + DEF_CMD("-description", 0, unsetifdescr), > + DEF_CMD("-descr", 0, unsetifdescr), Does having two undocumented short-form aliases make this more usable? We should either document them or not have them, I guess. > -.Dd June 18, 2004 > +.Dd November 26, 2009 Curious choice of dates. :-) > +.It Dv SIOCGIFDESCR > +Get the interface description, returned in the > +.Va buffer > +field of > +.Va ifru_buffer > +struct. > +The user supplied buffer length should defined in the > +.Va length > +field of > +.Va ifru_buffer > +struct passed in as parameter. > +.It Dv SIOCSIFDESCR > +Set the interface description to the value of the > +.Va buffer > +field of > +.Va ifru_buffer > +struct, with > +.Va length > +field specifying its length. No mention of nul's in the man page yet, but the code now seems much more consistent about including nul's throughout. > + case SIOCGIFDESCR: > + error = 0; > + if (ifr->ifr_buffer.length > ifdescr_maxlen) { > + error = ENOMEM; > + break; > + } I have three worries about this comparison: (1) ifdescr_maxlen is signed, perhaps it should be unsigned? (2) ifdescr_maxlen could be reduced between SIOCSIFDESCR and SIOCGIFDESCR, in which case you can no longer query an interface description even though the kernel is still storing it. (3) The loop logic in the userland ifconfig tool assumes that it is OK to ask for more bytes than the largest description, so it doubles the buffer each time it loops. This means that it may overshoot ifdescr_maxlen leading to the call failing even though a large enough buffer has been passed. One of the reasons that potentially unbounded kernel buffers are so awkward is that they lead to live-locky logic looping trying to grow a buffer using sleeping allocation while grabbing and releasing locks trying to get a buffer that's large enough. Most of the time the other theoretical thread you're racing with won't exist, but this still has to be handled because someday it will. I suggest a loop in which you create an sbuf to match the current length of ifp->if_description, and then after the loop ends and you have a copy, see if it fits in userspace. 99.9999% of the time, userspace will have passed a big enough buffer, and the loop won't be exercised growing the kernel buffer. > + else { > + if (ifr->ifr_buffer.length <= sbuf_len(ifp->if_description)) > + error = ENAMETOOLONG; This may be more clear if it's written as "< sbuf_len(ifp->if_description) + 1". However, if you make the above changes, this goes away, or is at least refactored. > + /* > + * Copy 1 more byte to make sure that the copyout is NUL Often in the BSD source code, the character is 'nul' and the pointer is 'NULL'. > --- sys/net/if_var.h (revision 199463) > +++ sys/net/if_var.h (working copy) > @@ -205,7 +205,8 @@ struct ifnet { > * be used with care where binary compatibility is required. > */ > char if_cspare[3]; > - void *if_pspare[8]; > + void *if_pspare[7]; > + struct sbuf *if_description; /* interface description */ > int if_ispare[4]; > }; I think the conclusion here was that the ifnet spares were a mistake, but I'm not sure how we decided to resolve that mistake. Should we first remove the spares in one commit, and then just append new fields in a separate commit? (Brooks?) > Some limitations: > * Not yet able to send announce through route socket. I need to > figure out a proper way to do this, maybe a future feature; > * 32-bit vs 64-bit API compatibility. Since the kernel has to copy > in a string, is there a clean way to do this? I think we will also > need to deal with similar issue with SIOCSIFNAME as well. I'm not sure there's a clean way to deal with it; pointers embedded in ioctl arguments are becoming more of a problem, so I wonder if the answer isn't to stop introducing any new ones. The Mac OS X kernel is a bit more thorough than us in implementing ioctls, since they more aggressively select kernel based on hardware, and contains a lot of fairly awkward compatibility code switching on whether the process is a 32-bit or 64-bit process and then selecting the right data structure. Maybe John has some thoughts on how to handle that. Robert From jhb at freebsd.org Wed Nov 18 15:12:20 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 18 15:12:47 2009 Subject: [PATCH FOR REVIEW] interface description (revised) In-Reply-To: <01D9CB64-F04C-4506-ACF2-1DE459FC69CD@freebsd.org> References: <01D9CB64-F04C-4506-ACF2-1DE459FC69CD@freebsd.org> Message-ID: <200911181012.07167.jhb@freebsd.org> On Wednesday 18 November 2009 4:49:12 am Robert N. M. Watson wrote: > On 18 Nov 2009, at 02:39, Xin LI wrote: > > + DEF_CMD_ARG("description", setifdescr), > > + DEF_CMD_ARG("descr", setifdescr), > > + DEF_CMD("-description", 0, unsetifdescr), > > + DEF_CMD("-descr", 0, unsetifdescr), > > Does having two undocumented short-form aliases make this more usable? We > should either document them or not have them, I guess. I've found the 'descr' shortcut useful when using a similar patch of this on 7 FWIW. > > + case SIOCGIFDESCR: > > + error = 0; > > + if (ifr->ifr_buffer.length > ifdescr_maxlen) { > > + error = ENOMEM; > > + break; > > + } > > I have three worries about this comparison: > > (1) ifdescr_maxlen is signed, perhaps it should be unsigned? > (2) ifdescr_maxlen could be reduced between SIOCSIFDESCR and SIOCGIFDESCR, > in which case you can no longer query an interface description even though > the kernel is still storing it. > (3) The loop logic in the userland ifconfig tool assumes that it is OK to > ask for more bytes than the largest description, so it doubles the buffer > each time it loops. This means that it may overshoot ifdescr_maxlen leading > to the call failing even though a large enough buffer has been passed. I would use either of the following strategies: 1) Don't check ifdescr_maxlen when fetching a description, only when setting it. If a sysadmin decides to shorten the maximum description length, then they should perhaps shorten any really long descriptions to match. In practice I suspect that sysadmins will not change this on the fly and this policy gives the sanest user experience IMO. 2) Truncate the description copied out to ifdescr_maxlen chars. Also, I'm not sure that using an sbuf rather than a plain char * is actually buying you anything here. You aren't building a string which sbuf is good for. Instead, you are just copying strings around. I would probably not use sbuf at all and would just use copyin/copyout. One issue with 1) for the current code is that you are using it to avoid having userland ask for a really large buffer. Instead, I would change the code to just do something like this (assuming you have a char *): char *buf; size_t len; case SIOCFIGDESCR: error = 0; IF_AFDATA_RLOCK(ifp); for (buf = NULL; buf; ) { if (ifp->if_description == NULL) { error = ENOMSG; break; } len = strlen(ifp->if_description) + 1; IF_AFDATA_RUNLOCK(ifp); buf = malloc(len, M_TEMP, M_WAITOK); IF_AFDATA_RLOCK(ifp); if (len < strlen(description + 1) { free(buf, M_TEMP); buf = NULL; } } if (error == 0) strcpy(buf, ifp->if_desciption); IF_AFDATA_RUNLOCK(ifp); if (error == 0) { if (len > ifr->ifr_buffer.length) error = ENAMETOOLONG; else error = copyout(buf, ifr->ifr_buffer.buffer, len); } if (buf != NULL) free(buf, M_TEMP); break; However, this is a bit complicated, and to be honest, I don't think interface descriptions are a critical path. Robert has already said before that IF_AFDATA_RLOCK() isn't really the "correct" lock but is being abused for this. Given that, I would probably just add a single global sx lock. This has the added advantage that you can just use copyin/copyout directly and skip all the extra complication. I don't think we need the extra concurrency for interface descriptions to make this so complicated. If you used a global sx lock with a simple string for descriptions, the code would end up looking like this: static struct sx ifdescr_lock; SX_SYSINIT(&ifdescr_lock, "ifnet descr"); static MALLOC_DEFINE(M_IFDESCR, "ifdescr", "ifnet descriptions"); char *buf; size_t len; case SIOCGIFDESCR: error = 0; sx_slock(&ifdescr_lock); if (ifp->if_description == NULL) error = ENOMSG; else { len = strlen(ifp->if_description) + 1; if (ifr->ifr_buffer.length < len) error = ENAMETOOLONG; else error = copyout(ifr->ifr_buffer.buffer, ifp->if_description, len); } sx_sunlock(&ifdescr_lock); break; case SIOCSIFDESCR: error = priv_check(); if (error) break; if (ifr->ifr_buffer.length > ifdescr_maxlen) return (ENAMETOOLONG); buf = malloc(ifr->ifr_buffer.length, M_IFDESCR, M_WAITOK | M_ZERO); error = copyin(ifr->ifr_buffer.buffer, buf, ifr->ifr_buffer.length - 1); if (error) { free(buf, M_IFDESCR); break; } sx_xlock(&ifdescr_lock); ifp->if_description = buf; sx_xunlock(&ifdescr_lock); break; Note that this takes approach 1) from above, but it is also a moot point now since the 'get' ioctl doesn't allocate memory anymore. > > Some limitations: > > * Not yet able to send announce through route socket. I need to > > figure out a proper way to do this, maybe a future feature; > > * 32-bit vs 64-bit API compatibility. Since the kernel has to copy > > in a string, is there a clean way to do this? I think we will also > > need to deal with similar issue with SIOCSIFNAME as well. > > I'm not sure there's a clean way to deal with it; pointers embedded in ioctl > arguments are becoming more of a problem, so I wonder if the answer isn't to > stop introducing any new ones. The Mac OS X kernel is a bit more thorough > than us in implementing ioctls, since they more aggressively select kernel > based on hardware, and contains a lot of fairly awkward compatibility code > switching on whether the process is a 32-bit or 64-bit process and then > selecting the right data structure. > > Maybe John has some thoughts on how to handle that. I wouldn't worry about 32-bit compat for this ioctl. The main consumer of this ioctl is going to be ifconfig which will be a native binary. If someone encounters a situation where they need 32-bit compat, then it can be added at that time. -- John Baldwin From rwatson at freebsd.org Wed Nov 18 15:35:40 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Wed Nov 18 15:35:47 2009 Subject: [PATCH FOR REVIEW] interface description (revised) In-Reply-To: <200911181012.07167.jhb@freebsd.org> References: <01D9CB64-F04C-4506-ACF2-1DE459FC69CD@freebsd.org> <200911181012.07167.jhb@freebsd.org> Message-ID: <70A1A5B3-1F19-4AC1-8975-F7E950785BBF@freebsd.org> On 18 Nov 2009, at 15:12, John Baldwin wrote: > However, this is a bit complicated, and to be honest, I don't think interface > descriptions are a critical path. Robert has already said before that > IF_AFDATA_RLOCK() isn't really the "correct" lock but is being abused for > this. Given that, I would probably just add a single global sx lock. This > has the added advantage that you can just use copyin/copyout directly and > skip all the extra complication. I don't think we need the extra concurrency > for interface descriptions to make this so complicated. If you used a global > sx lock with a simple string for descriptions, the code would end up looking > like this: > > static struct sx ifdescr_lock; > SX_SYSINIT(&ifdescr_lock, "ifnet descr"); This strikes me as a good idea -- there won't be much real-world contention on the lock, I'd think, and this greatly simplifies the code. We might think about whether there's other, currently under-synchronized, ifnet meta-data that could be protected usefully with the same lock. > case SIOCSIFDESCR: > error = priv_check(); > if (error) > break; > > if (ifr->ifr_buffer.length > ifdescr_maxlen) > return (ENAMETOOLONG); > > buf = malloc(ifr->ifr_buffer.length, M_IFDESCR, M_WAITOK | > M_ZERO); > error = copyin(ifr->ifr_buffer.buffer, buf, > ifr->ifr_buffer.length - 1); > if (error) { > free(buf, M_IFDESCR); > break; > } > sx_xlock(&ifdescr_lock); > ifp->if_description = buf; > sx_xunlock(&ifdescr_lock); > break; > > Note that this takes approach 1) from above, but it is also a moot point now > since the 'get' ioctl doesn't allocate memory anymore. This code seems pretty reasonable to me, but there's a race here if two threads try to use the set ioctl on the same interface at once. We should test whether ifp->if_description is already set after the sx_xlock() above, and swap pointers, freeing the old one after xunlock(), if so. Robert From jhb at freebsd.org Wed Nov 18 15:44:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 18 15:44:29 2009 Subject: [PATCH FOR REVIEW] interface description (revised) In-Reply-To: <70A1A5B3-1F19-4AC1-8975-F7E950785BBF@freebsd.org> References: <200911181012.07167.jhb@freebsd.org> <70A1A5B3-1F19-4AC1-8975-F7E950785BBF@freebsd.org> Message-ID: <200911181044.08772.jhb@freebsd.org> On Wednesday 18 November 2009 10:35:36 am Robert N. M. Watson wrote: > > On 18 Nov 2009, at 15:12, John Baldwin wrote: > > > However, this is a bit complicated, and to be honest, I don't think interface > > descriptions are a critical path. Robert has already said before that > > IF_AFDATA_RLOCK() isn't really the "correct" lock but is being abused for > > this. Given that, I would probably just add a single global sx lock. This > > has the added advantage that you can just use copyin/copyout directly and > > skip all the extra complication. I don't think we need the extra concurrency > > for interface descriptions to make this so complicated. If you used a global > > sx lock with a simple string for descriptions, the code would end up looking > > like this: > > > > static struct sx ifdescr_lock; > > SX_SYSINIT(&ifdescr_lock, "ifnet descr"); > > This strikes me as a good idea -- there won't be much real-world contention on > the lock, I'd think, and this greatly simplifies the code. We might think about > whether there's other, currently under-synchronized, ifnet meta-data that could > be protected usefully with the same lock. > > > case SIOCSIFDESCR: > > error = priv_check(); > > if (error) > > break; > > > > if (ifr->ifr_buffer.length > ifdescr_maxlen) > > return (ENAMETOOLONG); > > > > buf = malloc(ifr->ifr_buffer.length, M_IFDESCR, M_WAITOK | > > M_ZERO); > > error = copyin(ifr->ifr_buffer.buffer, buf, > > ifr->ifr_buffer.length - 1); > > if (error) { > > free(buf, M_IFDESCR); > > break; > > } > > sx_xlock(&ifdescr_lock); > > ifp->if_description = buf; > > sx_xunlock(&ifdescr_lock); > > break; > > > > Note that this takes approach 1) from above, but it is also a moot point now > > since the 'get' ioctl doesn't allocate memory anymore. > > This code seems pretty reasonable to me, but there's a race here if two threads > try to use the set ioctl on the same interface at once. We should test whether > ifp->if_description is already set after the sx_xlock() above, and swap pointers, > freeing the old one after xunlock(), if so. Actually, it's just a straight up bug. The race with two threads doing a set is a userland race, but what I missed was freeing the old buffer if it existed. One would just modify the end of SIFDESCR case as follows: char *old; sx_xlock(&ifdescr_lock); old = ifp->if_description; ifp->if_description = buf; sx_xunlock(&ifdescr_lock); free(old, M_IFDESCR); break; -- John Baldwin From information at directsource-network.com Wed Nov 18 19:38:45 2009 From: information at directsource-network.com (Direct Source Network) Date: Wed Nov 18 19:38:52 2009 Subject: Direct Source Network | Expat Jobs Announcements Message-ID: DIRECT SOURCE NETWORK | Expat Recruitment Services C-Level and Senior Management Jobs within the Telecoms, Financial Services & Banking, Oil & Gas and Alternative Energy Sectors. For regular updates about job opportunities, visit: http://www.directsource-network.com DIRECT SOURCE NETWORK | EXPAT JOBS DIRECT TO YOUR INBOX From bms at incunabulum.net Thu Nov 19 14:46:27 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Nov 19 14:46:33 2009 Subject: [PATCH] CFR: use refcount(9) in mcast Message-ID: <4B055A17.9080503@incunabulum.net> Look OK? All accesses are covered by a mutex, so the atomic ops aren't really needed -- but it makes for clearer source. -------------- next part -------------- Index: netinet/in_mcast.c =================================================================== --- netinet/in_mcast.c (revision 199528) +++ netinet/in_mcast.c (working copy) @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -396,13 +397,7 @@ inm = inm_lookup(ifp, *group); if (inm != NULL) { - /* - * If we already joined this group, just bump the - * refcount and return it. - */ - KASSERT(inm->inm_refcount >= 1, - ("%s: bad refcount %d", __func__, inm->inm_refcount)); - ++inm->inm_refcount; + refcount_acquire(&inm->inm_refcount); *pinm = inm; return (0); } @@ -443,7 +438,7 @@ panic("%s: ifma %p is inconsistent with %p (%s)", __func__, ifma, inm, inet_ntoa(*group)); #endif - ++inm->inm_refcount; + refcount_acquire(&inm->inm_refcount); *pinm = inm; IF_ADDR_UNLOCK(ifp); return (0); @@ -464,11 +459,12 @@ IF_ADDR_UNLOCK(ifp); return (ENOMEM); } + refcount_init(&inm->inm_refcount, 1); + inm->inm_addr = *group; inm->inm_ifp = ifp; inm->inm_igi = ii->ii_igmp; inm->inm_ifma = ifma; - inm->inm_refcount = 1; inm->inm_state = IGMP_NOT_MEMBER; /* @@ -503,11 +499,8 @@ CTR2(KTR_IGMPV3, "%s: refcount is %d", __func__, inm->inm_refcount); - if (--inm->inm_refcount > 0) { - CTR2(KTR_IGMPV3, "%s: refcount is now %d", __func__, - inm->inm_refcount); + if (refcount_release(&inm->inm_refcount) == 0) return; - } CTR2(KTR_IGMPV3, "%s: freeing inm %p", __func__, inm); Index: netinet/in_var.h =================================================================== --- netinet/in_var.h (revision 199528) +++ netinet/in_var.h (working copy) @@ -403,15 +403,6 @@ return (inm); } -/* Acquire an in_multi record. */ -static __inline void -inm_acquire_locked(struct in_multi *inm) -{ - - IN_MULTI_LOCK_ASSERT(); - ++inm->inm_refcount; -} - /* * Return values for imo_multi_filter(). */ Index: netinet/igmp.c =================================================================== --- netinet/igmp.c (revision 199528) +++ netinet/igmp.c (working copy) @@ -60,7 +60,7 @@ #include #include #include -#include +#include #include #include @@ -2579,7 +2579,7 @@ } else { int retval; - inm_acquire_locked(inm); + refcount_acquire(&inm->inm_refcount); retval = igmp_v3_enqueue_group_record( &inm->inm_scq, inm, 1, 0, 0); Index: netinet6/in6_var.h =================================================================== --- netinet6/in6_var.h (revision 199528) +++ netinet6/in6_var.h (working copy) @@ -713,15 +713,6 @@ return (inm); } -/* Acquire an in6_multi record. */ -static __inline void -in6m_acquire_locked(struct in6_multi *inm) -{ - - IN6_MULTI_LOCK_ASSERT(); - ++inm->in6m_refcount; -} - struct ip6_moptions; struct sockopt; Index: netinet6/mld6.c =================================================================== --- netinet6/mld6.c (revision 199528) +++ netinet6/mld6.c (working copy) @@ -2199,7 +2199,7 @@ } else { int retval; - in6m_acquire_locked(inm); + refcount_acquire(&inm->in6m_refcount); retval = mld_v2_enqueue_group_record( &inm->in6m_scq, inm, 1, 0, 0); Index: netinet6/in6_mcast.c =================================================================== --- netinet6/in6_mcast.c (revision 199528) +++ netinet6/in6_mcast.c (working copy) @@ -50,6 +50,7 @@ #include #include #include +#include #include #include @@ -403,13 +404,7 @@ inm = in6m_lookup_locked(ifp, group); if (inm != NULL) { - /* - * If we already joined this group, just bump the - * refcount and return it. - */ - KASSERT(inm->in6m_refcount >= 1, - ("%s: bad refcount %d", __func__, inm->in6m_refcount)); - ++inm->in6m_refcount; + refcount_acquire(&inm->in6m_refcount); *pinm = inm; goto out_locked; } @@ -449,7 +444,7 @@ panic("%s: ifma %p is inconsistent with %p (%p)", __func__, ifma, inm, group); #endif - ++inm->in6m_refcount; + refcount_acquire(&inm->in6m_refcount); *pinm = inm; goto out_locked; } @@ -470,11 +465,12 @@ error = ENOMEM; goto out_locked; } + refcount_init(&inm->in6m_refcount, 1); + inm->in6m_addr = *group; inm->in6m_ifp = ifp; inm->in6m_mli = MLD_IFINFO(ifp); inm->in6m_ifma = ifma; - inm->in6m_refcount = 1; inm->in6m_state = MLD_NOT_MEMBER; IFQ_SET_MAXLEN(&inm->in6m_scq, MLD_MAX_STATE_CHANGES); @@ -505,11 +501,8 @@ CTR2(KTR_MLD, "%s: refcount is %d", __func__, inm->in6m_refcount); - if (--inm->in6m_refcount > 0) { - CTR2(KTR_MLD, "%s: refcount is now %d", __func__, - inm->in6m_refcount); + if (refcount_release(&inm->in6m_refcount) == 0) return; - } CTR2(KTR_MLD, "%s: freeing inm %p", __func__, inm); From bms at incunabulum.net Thu Nov 19 14:47:53 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Nov 19 14:47:59 2009 Subject: [PATCH] CFR: use refcount(9) in mcast In-Reply-To: <4B055A17.9080503@incunabulum.net> References: <4B055A17.9080503@incunabulum.net> Message-ID: <4B055A6E.2090901@incunabulum.net> Bruce Simpson wrote: > Look OK? > > All accesses are covered by a mutex, so the atomic ops aren't really > needed -- but it makes for clearer source. Missed in mld6.c. From thodoriss at gmail.com Thu Nov 19 15:59:22 2009 From: thodoriss at gmail.com (Thodoris S.) Date: Thu Nov 19 15:59:28 2009 Subject: MPD Multiple PPPoE to same ISP Message-ID: <927edfce0911190736r3f202001h2082052b7922c723@mail.gmail.com> I am trying to make Multiple PPPoE Connections to the Same ISP for Load Balancing reasons my mpd.conf is: default: load adsl0 load adsl1 load adsl2 adsl0: new -i ng0 pppoe0 pppoe0 set iface route default set iface disable on-demand set iface idle 0 set bundle disable multilink set bundle authname "***" set bundle password "***" set bundle no noretry set link keep-alive 10 60 set link max-redial 0 set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns open adsl1: new -i ng1 pppoe1 pppoe1 set iface route default set iface disable on-demand set iface idle 0 set bundle disable multilink set bundle authname "***" set bundle password "***" set bundle no noretry set link keep-alive 10 60 set link max-redial 0 set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns open adsl2: new -i ng2 pppoe2 pppoe2 set iface route default set iface disable on-demand set iface idle 0 set bundle disable multilink set bundle authname "***" set bundle password "***" set bundle no noretry set link keep-alive 10 60 set link max-redial 0 set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns open And mpd.links is: pppoe0: set link type pppoe set pppoe iface em0 set pppoe service "we" set pppoe enable originate set pppoe disable incoming pppoe1: set link type pppoe set pppoe iface em1 set pppoe service "we1" set pppoe enable originate set pppoe disable incoming pppoe2: set link type pppoe set pppoe iface bce1 set pppoe service "we2" set pppoe enable originate set pppoe disable incoming The problem is tha only one (the first logged in) ng interface gets ip assigned to it, all others assigned to lo0 interface and when i am trying to NAT them with PF it gives me this error: /etc/pf.conf:26: could not parse host specification im giving you ifconfig and netstat -nr ifconfig: [root@emperor ~]# ifconfig bce0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1e:c9:db:24:7f inet 192.168.0.1 netmask 0xfffffff8 broadcast 192.168.0.7 media: Ethernet autoselect (1000baseTX ) status: active em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:78:fd:56 inet 192.168.101.1 netmask 0xffffff00 broadcast 192.168.101.255 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:78:fb:41 inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 media: Ethernet autoselect (100baseTX ) status: active bce1: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1e:c9:db:24:7d inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=141 metric 0 mtu 33204 ng0: flags=88d1 metric 0 mtu 1492 inet 11.11.11.11 --> 12.12.12.2 netmask 0xffffffff ng1: flags=88d1 metric 0 mtu 1492 ng2: flags=88d1 metric 0 mtu 1492 nestat -nr: Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.2 UGS 0 13812 bce0 192.168.0.0/29 link#1 UC 0 0 bce0 12.12.12.2 11.11.11.11 UH 0 0 ng0 33.33.33.33 lo0 UHS 0 4797 lo0 22.22.22.22 lo0 UHS 0 1370 lo0 11.11.11.11 lo0 UHS 0 0 lo0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.101.0/24 link#2 UC 0 0 em0 192.168.102.0/24 link#3 UC 0 0 em1 192.168.103.0/24 link#4 UC 0 0 bce1 Can you help me please Thanks in advance Stamatopoulos Theodoros From kww01 at vsnl.net Thu Nov 19 17:30:40 2009 From: kww01 at vsnl.net (Khushi R. P.) Date: Thu Nov 19 17:30:47 2009 Subject: General Awarness - Know the Unknown Facts Message-ID: <397216575062430@hp-fcea0d8fb2a8.mshome.net> Hi, Various unknown facts are listed on the website http://khushiwebworld.com . The unknown facts are really good and I have found it very useful, so thought to share the same with you. They are categorized as 1. Unknown facts 2. Health Facts 3. Ayurveda facts 4. And Many more ? After visiting the website http://khushiwebworld.com you will have awareness towards various unknown facts which is very useful in day to day life. Regards ? Khushi ************************************************************************* Unsubscribe Policy This mail has been sent to freebsd-net@freebsd.org In case if you have received this email accidently and If you prefer not to receive future emails of this type please UNSUBSCRIBE . If this link does not works reply with the subject "Remove" . Report SPAM or forward a copy of this email to spammail@khushiwebworld.com The following physical address is associated with this mailing list Khushi Web World Near Kakoda Industrial Estate Kakoda Curchorem Goa(India) +91-9225905804 **************************************************************************** From davidch at broadcom.com Fri Nov 20 00:56:10 2009 From: davidch at broadcom.com (David Christensen) Date: Fri Nov 20 00:56:17 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AFC862B.6060805@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> > > I haven't been able to reproduce it on the r710 I have in house. > > Checking with other groups now to see if they have one a I can use, > > though I'm not sure why the system would make a difference for this > > particular issue. Just wanted to confirm that you're using > the driver > > built into the kernel (as opposed to a module) and that a warm boot > > means running the "reboot" or "shutdown -r" > > commands while a cold boot means pressing the front panel > power button > > or using the DRAC to power down the system. > > Thanks for the update. > > All these are true. > > warm - shutdown -r now > cold - from the power button (iDRACs are not configured yet). > > bce is compiled into the kernel (tested with GENERIC kernel > from 8-RC2 as well as 7.1 with the 7.2 driver plus the split > header patch). > > For the record we also have not been able to reproduce the > issue on the R710 only the R610. I got hold of an R610 system and I now understand why the issue was difficult to replicate on R710. The R610 ships without Enterprise iDRAC while the R710 ship with the add-in Enterprise iDRAC module. When the module is present the system is managed through the additional RJ45 port but when the module is absent iDRAC traffic will flow through the on-board 5709 adpaters. The error will only occur when management firmware is loaded on the 5709 AND when NC-SI management functionality is enabled. You should be able to confirm this by adding or removing the Enterprise iDRAC module on your systems. Now that I have a failure again I have some ideas to test which might help. Stay tuned. Dave From linimon at FreeBSD.org Fri Nov 20 04:47:14 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Nov 20 04:47:26 2009 Subject: kern/140712: [fxp] fxp driver starts with rxcsum on Message-ID: <200911200447.nAK4lEOf068508@freefall.freebsd.org> Old Synopsis: fxp driver starts with rxcsum on New Synopsis: [fxp] fxp driver starts with rxcsum on Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 20 04:46:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140712 From yongari at FreeBSD.org Fri Nov 20 22:04:32 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Fri Nov 20 22:04:38 2009 Subject: kern/140712: [fxp] fxp driver starts with rxcsum on Message-ID: <200911202204.nAKM4VN5084439@freefall.freebsd.org> Synopsis: [fxp] fxp driver starts with rxcsum on State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Nov 20 22:03:13 UTC 2009 State-Changed-Why: I belive the fix was committed to HEAD(r197586) and MFCed to stable/8 and stable7 but it didn't make it into 8.0-RELEASE. To workaound the issue you can disable Rx checksum offload of fxp0. #ifconfig fxp0 -rxcsum Or download patch from the following URL. http://svn.freebsd.org/viewvc/base/head/sys/dev/fxp/if_fxp.c?r1=197586&r2=197575&view=patch Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Nov 20 22:03:13 UTC 2009 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=140712 From linimon at FreeBSD.org Fri Nov 20 23:10:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Nov 20 23:10:10 2009 Subject: kern/140728: [em] [patch] Fast irq registration in em driver Message-ID: <200911202310.nAKNA3e7036900@freefall.freebsd.org> Old Synopsis: Fast irq registration in em driver New Synopsis: [em] [patch] Fast irq registration in em driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 20 23:09:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140728 From davidch at broadcom.com Sat Nov 21 01:18:01 2009 From: davidch at broadcom.com (David Christensen) Date: Sat Nov 21 01:18:08 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> > > For the record we also have not been able to reproduce the issue on > > the R710 only the R610. > > I got hold of an R610 system and I now understand why the > issue was difficult to replicate on R710. The R610 ships > without Enterprise iDRAC while the R710 ship with the add-in > Enterprise iDRAC module. When the module is present the > system is managed through the additional RJ45 port but when > the module is absent iDRAC traffic will flow through the > on-board 5709 adpaters. > The error will only occur when management firmware is loaded > on the 5709 AND when NC-SI management functionality is enabled. > > You should be able to confirm this by adding or removing the > Enterprise iDRAC module on your systems. Now that I have a > failure again I have some ideas to test which might help. > Stay tuned. Does the attached patch make a difference for you? FYI, I'll be out next week on vacation. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: if_bce.diff Type: application/octet-stream Size: 6947 bytes Desc: if_bce.diff Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091121/a521b101/if_bce.obj From fbsdq at peterk.org Sat Nov 21 01:44:44 2009 From: fbsdq at peterk.org (Peter) Date: Sat Nov 21 01:44:50 2009 Subject: ipfw not blocking inter jail ip traffic Message-ID: <02821228f8c0ffffa3084eed1ad5a624.squirrel@webmail.pknet.net> iH, Have 2 jails and I don't want them to be able to reach other. gulag:#ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 08:00:27:03:18:ea inet 172.20.6.50 netmask 0xffffff00 broadcast 172.20.6.255 inet 172.20.6.209 netmask 0xffffff00 broadcast 172.20.6.255 inet 172.20.6.211 netmask 0xffffff00 broadcast 172.20.6.255 gulag:#ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 10000 deny ip from 172.20.6.209 to 172.20.6.211 10001 deny ip from 172.20.6.211 to 172.20.6.209 40000 deny ip from 172.20.6.209 to any 65000 allow ip from any to any 65535 deny ip from any to any The two jails [.209 and .211] can still ping each other. Even with rule 40000, the .209 jail can ping/ssh to the .211 jail, but of course cannot ping the gateway... If I remove rule '100' from the list, jails are no longer able to ping each other - Although the IPs are on em0, why is the rule with lo0 letting them pass? Does lo0 mean ALL ips assigned to server? or does it mean loopback interface: gulag:#ifconfig lo0 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 ]Peter[ From steve at ibctech.ca Sat Nov 21 14:07:55 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sat Nov 21 14:08:01 2009 Subject: ipfw not blocking inter jail ip traffic In-Reply-To: <02821228f8c0ffffa3084eed1ad5a624.squirrel@webmail.pknet.net> References: <02821228f8c0ffffa3084eed1ad5a624.squirrel@webmail.pknet.net> Message-ID: <4B07F445.3030206@ibctech.ca> Peter wrote: > iH, > > Have 2 jails and I don't want them to be able to reach other. > > gulag:#ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether 08:00:27:03:18:ea > inet 172.20.6.50 netmask 0xffffff00 broadcast 172.20.6.255 > inet 172.20.6.209 netmask 0xffffff00 broadcast 172.20.6.255 > inet 172.20.6.211 netmask 0xffffff00 broadcast 172.20.6.255 > > gulag:#ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 10000 deny ip from 172.20.6.209 to 172.20.6.211 > 10001 deny ip from 172.20.6.211 to 172.20.6.209 > 40000 deny ip from 172.20.6.209 to any > 65000 allow ip from any to any > 65535 deny ip from any to any > > > The two jails [.209 and .211] can still ping each other. > Even with rule 40000, the .209 jail can ping/ssh to the .211 jail, but of > course cannot ping the gateway... > If I remove rule '100' from the list, jails are no longer able to ping > each other - Although the IPs are on em0, why is the rule with lo0 letting > them pass? Because, AFAIK, traffic that stays within the box never crosses the external (ie: non-loopback) interface planes. > Does lo0 mean ALL ips assigned to server? or does it mean > loopback interface: It means loopback interface. Essentially, all traffic that originates and is destined to itself stays within the loopback. Try this: ipfw add 40000 deny all from 172.20.6.211 to 172.20.6.209 via lo0 The following would allow you block access from .211 to ANY other IP (jail) on the box (I *think* it would still permit network destined traffic): ipfw add xxxx deny all from 172.20.6.211 to me HTH, Steve From alexbestms at wwu.de Sat Nov 21 16:40:03 2009 From: alexbestms at wwu.de (Alexander Best) Date: Sat Nov 21 16:40:11 2009 Subject: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Message-ID: <200911211640.nALGe21k087583@freefall.freebsd.org> The following reply was made to PR kern/128598; it has been noted by GNATS. From: Alexander Best To: Cc: Subject: Re: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Date: Sat, 21 Nov 2009 17:33:49 +0100 (CET) this pr can be closed. the originator of this pr informed me that the warning disappeared somewhere between 7.1 and 7.2. alex From nvass9573 at gmx.com Sat Nov 21 17:20:30 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Sat Nov 21 17:20:38 2009 Subject: MPD Multiple PPPoE to same ISP In-Reply-To: <927edfce0911190736r3f202001h2082052b7922c723@mail.gmail.com> References: <927edfce0911190736r3f202001h2082052b7922c723@mail.gmail.com> Message-ID: <4B08214F.8070204@gmx.com> Thodoris S. wrote: > I am trying to make Multiple PPPoE Connections to the Same ISP for > Load Balancing reasons > my mpd.conf is: > default: > load adsl0 > load adsl1 > load adsl2 > > adsl0: > new -i ng0 pppoe0 pppoe0 > set iface route default > set iface disable on-demand > set iface idle 0 > set bundle disable multilink > set bundle authname "***" > set bundle password "***" > set bundle no noretry > set link keep-alive 10 60 > set link max-redial 0 > set link no acfcomp protocomp > set link disable pap chap > set link accept chap > set link mtu 1492 > set ipcp yes vjcomp > set ipcp ranges 0.0.0.0/0.0.0.0/0 > set ipcp enable req-pri-dns > set ipcp enable req-sec-dns > open > > adsl1: > new -i ng1 pppoe1 pppoe1 > set iface route default > set iface disable on-demand > set iface idle 0 > set bundle disable multilink > set bundle authname "***" > set bundle password "***" > set bundle no noretry > set link keep-alive 10 60 > set link max-redial 0 > set link no acfcomp protocomp > set link disable pap chap > set link accept chap > set link mtu 1492 > set ipcp yes vjcomp > set ipcp ranges 0.0.0.0/0.0.0.0/0 > set ipcp enable req-pri-dns > set ipcp enable req-sec-dns > open > > adsl2: > new -i ng2 pppoe2 pppoe2 > set iface route default > set iface disable on-demand > set iface idle 0 > set bundle disable multilink > set bundle authname "***" > set bundle password "***" > set bundle no noretry > set link keep-alive 10 60 > set link max-redial 0 > set link no acfcomp protocomp > set link disable pap chap > set link accept chap > set link mtu 1492 > set ipcp yes vjcomp > set ipcp ranges 0.0.0.0/0.0.0.0/0 > set ipcp enable req-pri-dns > set ipcp enable req-sec-dns > open > > And mpd.links is: > pppoe0: > set link type pppoe > set pppoe iface em0 > set pppoe service "we" > set pppoe enable originate > set pppoe disable incoming > > pppoe1: > set link type pppoe > set pppoe iface em1 > set pppoe service "we1" > set pppoe enable originate > set pppoe disable incoming > > pppoe2: > set link type pppoe > set pppoe iface bce1 > set pppoe service "we2" > set pppoe enable originate > set pppoe disable incoming > > The problem is tha only one (the first logged in) ng interface gets ip > assigned to it, all others assigned to lo0 interface > and when i am trying to NAT them with PF it gives me this error: > /etc/pf.conf:26: could not parse host specification > > im giving you ifconfig and netstat -nr > > ifconfig: > [root@emperor ~]# ifconfig > bce0: flags=8843 metric 0 mtu 1500 > options=1bb > ether 00:1e:c9:db:24:7f > inet 192.168.0.1 netmask 0xfffffff8 broadcast 192.168.0.7 > media: Ethernet autoselect (1000baseTX ) > status: active > em0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:15:17:78:fd:56 > inet 192.168.101.1 netmask 0xffffff00 broadcast 192.168.101.255 > media: Ethernet autoselect (100baseTX ) > status: active > em1: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:15:17:78:fb:41 > inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 > media: Ethernet autoselect (100baseTX ) > status: active > bce1: flags=8843 metric 0 mtu 1500 > options=1bb > ether 00:1e:c9:db:24:7d > inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > pflog0: flags=141 metric 0 mtu 33204 > ng0: flags=88d1 metric > 0 mtu 1492 > inet 11.11.11.11 --> 12.12.12.2 netmask 0xffffffff > ng1: flags=88d1 metric > 0 mtu 1492 > ng2: flags=88d1 metric > 0 mtu 1492 > > nestat -nr: > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.0.2 UGS 0 13812 bce0 > 192.168.0.0/29 link#1 UC 0 0 bce0 > 12.12.12.2 11.11.11.11 UH 0 0 ng0 > 33.33.33.33 lo0 UHS 0 4797 lo0 > 22.22.22.22 lo0 UHS 0 1370 lo0 > 11.11.11.11 lo0 UHS 0 0 lo0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 192.168.101.0/24 link#2 UC 0 0 em0 > 192.168.102.0/24 link#3 UC 0 0 em1 > 192.168.103.0/24 link#4 UC 0 0 bce1 > Could you add to your kernel config "options RADIX_MPATH" and give it a go then? It seems that you try to add a second point-to-point interface with the same destination address. For example: ng0 1.1.1.1 2.2.2.2 and ng1 1.1.1.2 2.2.2.2 etc This is not valid without the aforementioned kernel option. I *think* it will be ok then, but do try and report back to the list your findings. HTH, Nikos From tom at tomjudge.com Sat Nov 21 17:40:59 2009 From: tom at tomjudge.com (Tom Judge) Date: Sat Nov 21 17:41:05 2009 Subject: if_bridge as if_vlan parent Message-ID: <4B0825DD.3000702@tomjudge.com> Hi, I was why I get the following error when trying to create a vlan on top of if_bridge: # ifconfig bridge0 create # ifconfig vlan2 vlan 2 vlandev bridge0 ifconfig: SIOCSETVLAN: Protocol not supported And if there was/is any reason for this to not be supported. Thanks Tom From vwe at FreeBSD.org Sat Nov 21 20:22:41 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sat Nov 21 20:22:47 2009 Subject: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Message-ID: <200911212022.nALKMe41090967@freefall.freebsd.org> Synopsis: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sat Nov 21 20:22:00 UTC 2009 State-Changed-Why: issue seems to have been fixed http://www.freebsd.org/cgi/query-pr.cgi?pr=128598 From josh at tcbug.org Sat Nov 21 23:15:36 2009 From: josh at tcbug.org (Josh Paetzel) Date: Sat Nov 21 23:16:09 2009 Subject: if_bridge as if_vlan parent In-Reply-To: <4B0825DD.3000702@tomjudge.com> References: <4B0825DD.3000702@tomjudge.com> Message-ID: On Nov 21, 2009, at 11:39 AM, Tom Judge wrote: > Hi, > > I was why I get the following error when trying to create a vlan on top of if_bridge: > > # ifconfig bridge0 create > # ifconfig vlan2 vlan 2 vlandev bridge0 > ifconfig: SIOCSETVLAN: Protocol not supported > > > And if there was/is any reason for this to not be supported. > > Thanks > You can create a bridge from a pair of vlan devices.... # ifconfig vlan1 create # ifcconfig vlan2 create # ifconfig bridge0 create # ifconfig vlan1 vlan 1 vlandev em0 # ifconfig vlan2 vlan 2 vlandev em0 # ifconfig bridge0 addm vlan1 addm vlan2 Is that more in line with what you want to do? I'm a little curious what problem set using a bridge as the parent of a vlan solves though. Thanks, Josh Paetzel From bruce at cran.org.uk Sun Nov 22 00:50:03 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Sun Nov 22 00:50:09 2009 Subject: kern/139162: [fwip] [panic] 8.0-RC1 panics if using IP over firewire Message-ID: <200911220050.nAM0o3g2016283@freefall.freebsd.org> The following reply was made to PR kern/139162; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, numisemis@yahoo.com Cc: Subject: Re: kern/139162: [fwip] [panic] 8.0-RC1 panics if using IP over firewire Date: Sun, 22 Nov 2009 00:46:08 +0000 I get the same panic on 9.0-CURRENT from 15th November. Here's a backtrace: callout_reset_on() at callout_reset_on+0x48 arpintr() at arpintr+0xd8e netisr_dispatch_src() at netisr_dispatch_src+0xb8 firewire_input() at firewire_input+0x56c fwip_unicast_input() at fwip_unicast_input+0x13a fwohci_arcv() at fwohci_arcv+0x30b fwohci_task_dma() at fwohci_task_dma+0x751 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8076f73d30, rbp = 0 --- -- Bruce Cran From freebsd-net at adam.gs Sun Nov 22 02:48:58 2009 From: freebsd-net at adam.gs (Adam Jacob Muller) Date: Sun Nov 22 02:49:04 2009 Subject: openbgpd + 8.0 Message-ID: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> Hi, I have an openbgpd running on an 8.0 box where openbgpd crashes (exits silently) whenever an interface on the system (vlan/tun/tap s are dynamically created here) is removed. I've traced the error back to kroute.c:dispatch_rtmsg_addr if ((sa = rti_info[RTAX_DST]) == NULL) { This check is failing, which returns -1, which is passed up (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets exit=1). Unfortunately, this is quickly approaching Any idea what exactly is going on here? I'm not 100% sure but I think this is a regression from 7.x, I don't have any 7.x systems I can test this on at the moment unfortunately. I've subverted this check by, simply, not setting quit=1 in main.c when kr_dispatch_msg() fails, and everything SEEMS to operate normally, i'm kinda curious to hear thoughts on this though... -Adam From tom at tomjudge.com Sun Nov 22 04:55:09 2009 From: tom at tomjudge.com (Tom Judge) Date: Sun Nov 22 04:55:15 2009 Subject: if_bridge as if_vlan parent In-Reply-To: References: <4B0825DD.3000702@tomjudge.com> Message-ID: <4B08C3DC.1080607@tomjudge.com> Josh Paetzel wrote: > On Nov 21, 2009, at 11:39 AM, Tom Judge wrote: > >> Hi, >> >> I was why I get the following error when trying to create a vlan on top of if_bridge: >> >> # ifconfig bridge0 create >> # ifconfig vlan2 vlan 2 vlandev bridge0 >> ifconfig: SIOCSETVLAN: Protocol not supported >> >> >> And if there was/is any reason for this to not be supported. >> >> Thanks >> > > > You can create a bridge from a pair of vlan devices.... > > # ifconfig vlan1 create > # ifcconfig vlan2 create > # ifconfig bridge0 create > # ifconfig vlan1 vlan 1 vlandev em0 > # ifconfig vlan2 vlan 2 vlandev em0 > # ifconfig bridge0 addm vlan1 addm vlan2 > > Is that more in line with what you want to do? > > I'm a little curious what problem set using a bridge as the parent of a vlan solves though. > > You have the problem upside down. I am trying to bridge 2 trunk ports on 2 separate switches with a FreeBSD box, and I would like to access a number of tagged vlans on the trunk with the FreeBSD box. [sw1-1/g1]->[FBSD-em0]-[FBSD-bridge0]-[FBSD-em1]->[sw2-1/g1] / \ [FBSD-vlan2] [FBSD-vlan200] So: ifconfig em0 up ifconfig em1 up ifconfig bridge0 create ifconfig bridge0 addm em0 stp em0 addm em1 stp em1 up ifconfig vlan2 create ifconfig vlan2 10.0.0.1/24 vlan 2 vlandev bridge0 ifconfig vlan200 create ifconfig vlan200 10.9.9.1/24 vlan 200 vlandev bridge0 This will fail when I try to attach the if_vlan's to the if_bridge. Tom From gavin at FreeBSD.org Sun Nov 22 12:11:19 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Nov 22 12:11:25 2009 Subject: kern/140742: rum(4) Two asus-WL167G adapters cannot talk to each other Message-ID: <200911221211.nAMCBJXq049052@freefall.freebsd.org> Old Synopsis: assus-WL167G rum driver New Synopsis: rum(4) Two asus-WL167G adapters cannot talk to each other Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Nov 22 12:08:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=140742 From arved at FreeBSD.org Sun Nov 22 12:52:24 2009 From: arved at FreeBSD.org (=?utf-8?Q?T=C4=B1lman_Linneweh?=) Date: Sun Nov 22 12:52:30 2009 Subject: Intel NIC 0x10f08086 Message-ID: Hi List, Hi Jack! I have an Intel NIC with the pci chip=0x10f08086 rev=0x05 as onboard Card on an "Intel DP55WB" Mainboard. According to Google it is an "82578DC". Now i wonder how to make it work. I tried to add the PCI ID to both em(4) and igb(4) but the attach failed, so it looks like something more is required. Any ideas? regards arved From hartmut.brandt at dlr.de Sun Nov 22 13:21:21 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Sun Nov 22 13:21:28 2009 Subject: ARP regression in releng-8 Message-ID: <20091122130156.F52486@beagle.kn.op.dlr.de> Hi all, I try to figure out something simple like the ARP retransmission timeout to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line 357 of netinet/if_ether.c it says: /* * Return EWOULDBLOCK if we have tried less than arp_maxtries. It * will be masked by ether_output(). Return EHOSTDOWN/EHOSTUNREACH * if we have already sent arp_maxtries ARP requests. Retransmit the * ARP request, but not faster than one request per second. */ Unfortunately the comment about the 1s minimum retransmit interval is there, but the code not. A simple ping -f shows the code transmitting ARP requests every 30 milliseconds, which is not good in my opinion. releng-7 (with the old L2 code) works correctly. BTW, what means the comment on line 282 in the same file? /* XXXXX */ harti From ume at FreeBSD.org Sun Nov 22 15:39:48 2009 From: ume at FreeBSD.org (Hajimu UMEMOTO) Date: Sun Nov 22 15:40:00 2009 Subject: [CFR] unified rc.firewall Message-ID: Hi, The ipfw and ip6fw were unified into ipfw2, now. But, we still have rc.firewall and rc.firewall6. However, there are conflicts with each other, and it confuses the users, IMHO. So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete rc.firewall6 and rc.d/ip6fw. Please review the attached patch. If there is no objection, I'll commit it in next weekend. Sincerely, -------------- next part -------------- A non-text attachment was scrubbed... Name: ipfw-unify.diff Type: application/octet-stream Size: 15490 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091122/8ef84dfa/ipfw-unify.obj -------------- next part -------------- -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From qing.li at bluecoat.com Sun Nov 22 18:34:25 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Nov 22 18:34:32 2009 Subject: ARP regression in releng-8 In-Reply-To: <20091122130156.F52486@beagle.kn.op.dlr.de> References: <20091122130156.F52486@beagle.kn.op.dlr.de> Message-ID: I will look into it and get back to you. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Harti Brandt > Sent: Sunday, November 22, 2009 5:09 AM > To: freebsd-net@freebsd.org > Subject: ARP regression in releng-8 > > Hi all, > > I try to figure out something simple like the ARP retransmission > timeout > to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line > 357 of netinet/if_ether.c it says: > > /* > * Return EWOULDBLOCK if we have tried less than arp_maxtries. > It > * will be masked by ether_output(). Return > EHOSTDOWN/EHOSTUNREACH > * if we have already sent arp_maxtries ARP requests. > Retransmit > the > * ARP request, but not faster than one request per second. > */ > > Unfortunately the comment about the 1s minimum retransmit interval is > there, but the code not. A simple ping -f shows the code transmitting > ARP > requests every 30 milliseconds, which is not good in my opinion. > releng-7 > (with the old L2 code) works correctly. > > BTW, what means the comment on line 282 in the same file? > > /* XXXXX > */ > > harti > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From qing.li at bluecoat.com Sun Nov 22 18:40:10 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Nov 22 18:40:40 2009 Subject: openbgpd + 8.0 In-Reply-To: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> Message-ID: I am not sure if what you are observing is a side effect of svn-r196714. In particular, the code I added for: -------------------- - Routing messages are not generated when adding and removing interface address aliases. -------------------- If my memory serves me right, I put in the above patch for SCTP. I'd be happy to work with you offline and confirm either way... -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Adam Jacob Muller > Sent: Saturday, November 21, 2009 6:33 PM > To: freebsd-net@freebsd.org > Subject: openbgpd + 8.0 > > Hi, > I have an openbgpd running on an 8.0 box where openbgpd crashes (exits > silently) whenever an interface on the system (vlan/tun/tap s are > dynamically created here) is removed. > > > I've traced the error back to kroute.c:dispatch_rtmsg_addr > > if ((sa = rti_info[RTAX_DST]) == NULL) { > > > This check is failing, which returns -1, which is passed up > (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets > exit=1). > Unfortunately, this is quickly approaching > > Any idea what exactly is going on here? > > I'm not 100% sure but I think this is a regression from 7.x, I don't > have any 7.x systems I can test this on at the moment unfortunately. > > I've subverted this check by, simply, not setting quit=1 in main.c when > kr_dispatch_msg() fails, and everything SEEMS to operate normally, i'm > kinda curious to hear thoughts on this though... > > > -Adam > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From qing.li at bluecoat.com Sun Nov 22 18:44:43 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Nov 22 18:44:49 2009 Subject: openbgpd + 8.0 In-Reply-To: References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> Message-ID: Just to be a bit more specific, in r196714 /sys/netinet/in.c: /* QL: XXX 1090 * Report a blank rtentry when a route has not been 1091 * installed for the given interface address. 1092 */ 1093 -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Sunday, November 22, 2009 10:40 AM > To: Adam Jacob Muller; freebsd-net@freebsd.org > Subject: RE: openbgpd + 8.0 > > I am not sure if what you are observing is a side effect of > svn-r196714. In particular, the code I added for: > > -------------------- > - Routing messages are not generated when adding and removing > interface address aliases. > -------------------- > > If my memory serves me right, I put in the above patch for SCTP. > I'd be happy to work with you offline and confirm either way... > > -- Qing > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > net@freebsd.org] On Behalf Of Adam Jacob Muller > > Sent: Saturday, November 21, 2009 6:33 PM > > To: freebsd-net@freebsd.org > > Subject: openbgpd + 8.0 > > > > Hi, > > I have an openbgpd running on an 8.0 box where openbgpd crashes > (exits > > silently) whenever an interface on the system (vlan/tun/tap s are > > dynamically created here) is removed. > > > > > > I've traced the error back to kroute.c:dispatch_rtmsg_addr > > > > if ((sa = rti_info[RTAX_DST]) == NULL) { > > > > > > This check is failing, which returns -1, which is passed up > > (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets > > exit=1). > > Unfortunately, this is quickly approaching > > > > Any idea what exactly is going on here? > > > > I'm not 100% sure but I think this is a regression from 7.x, I don't > > have any 7.x systems I can test this on at the moment unfortunately. > > > > I've subverted this check by, simply, not setting quit=1 in main.c > when > > kr_dispatch_msg() fails, and everything SEEMS to operate normally, > i'm > > kinda curious to hear thoughts on this though... > > > > > > -Adam > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net- > unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From dudu at dudu.ro Sun Nov 22 18:54:25 2009 From: dudu at dudu.ro (Vlad Galu) Date: Sun Nov 22 18:54:34 2009 Subject: openbgpd + 8.0 In-Reply-To: References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> Message-ID: On Sun, Nov 22, 2009 at 8:44 PM, Li, Qing wrote: > Just to be a bit more specific, in r196714 /sys/netinet/in.c: [...] Just wanting to let you know the following behavior changes: 1. Some customers of mine used to run 7.x with quagga. Another app was adding static routes with a nexthop of 127.0.0.1, which were redistributed by quagga to BGP as part of the "redistribute kernel" directive. After upgrading to 8.x, routes are being properly exported upon adding, however quagga doesn't stop announcing them in BGP after they disappear from the kernel route table. "route monitor" sees the RTM_DELETE message, but quagga either doesn't, or just ignores it. The same quagga port version was used on both 7.x and 8.x. 2. Switching to OpenBGPD fixed the above issue, with the notable mention that it doesn't redistribute routes with a nexthop of 127.0.0.1, so we had to rewrite the app for that (127.0.0.1 was hardcoded - INADDR_LOOPBACK). This might be an OpenBGPD check, though. Hope this is useful info. Cheers, Vlad From dougb at FreeBSD.org Sun Nov 22 19:12:27 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Nov 22 19:12:39 2009 Subject: [CFR] unified rc.firewall In-Reply-To: References: Message-ID: <4B098D21.4040607@FreeBSD.org> Hajimu UMEMOTO wrote: > Hi, > > The ipfw and ip6fw were unified into ipfw2, now. But, we still have > rc.firewall and rc.firewall6. However, there are conflicts with each > other, and it confuses the users, IMHO. > So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete > rc.firewall6 and rc.d/ip6fw. > Please review the attached patch. If there is no objection, I'll > commit it in next weekend. Overall I think this is good, and I'm definitely in favor of more integration of IPv6 into the mainstream rather than something that is glued on. A few comments: In rc.firewall you seem to have copied afexists() from network.subr. Is there a reason that you did not simply source that file? That would be the preferred method. Also in that file you call "if afexists inet6" quite a few times. My preference from a performance standpoint would be to call it once, perhaps in a start_precmd then cache the value. And of course, you have regression tested this thoroughly, yes? :) Please include scenarios where there is no INET6 in the kernel as well. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From linimon at FreeBSD.org Sun Nov 22 23:18:39 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 22 23:18:51 2009 Subject: kern/140778: [em] randomly panic in vlan/em Message-ID: <200911222318.nAMNIdOa019436@freefall.freebsd.org> Old Synopsis: randomly panic in vlan/em New Synopsis: [em] randomly panic in vlan/em Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:18:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140778 From linimon at FreeBSD.org Sun Nov 22 23:31:53 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 22 23:32:04 2009 Subject: kern/140796: [ath] [panic] privileged instruction fault Message-ID: <200911222331.nAMNVqJs036982@freefall.freebsd.org> Old Synopsis: panic: privileged instruction fault (ath related) New Synopsis: [ath] [panic] privileged instruction fault Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:31:33 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140796 From nox at jelal.kn-bremen.de Sun Nov 22 23:37:41 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Nov 22 23:37:48 2009 Subject: bridging vs wifi, proxy arp broken on 8.0 rc? (was: Re: Bridged networking for virtualbox on -current?) In-Reply-To: <4B09992F.1080900@shapeshifter.se> References: <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> Message-ID: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> In article <4B09992F.1080900@shapeshifter.se> you write: >Doug Barton wrote: >> Fredrik Lindberg wrote: >>> Doug Barton wrote: >>>> Is bridged networking for vbox supposed to work on -current? It says >>>> on the wiki that it does, but I tried it tonight and couldn't get it >>>> to work. >>>> >>>> I did see one page that suggested trying one of the Intel virtual >>>> nicks, which I did, no luck. >>>> >>>> If this is not supposed to work it would be nice to update the wiki, I >>>> spent quite a bit of time trying to get it to work that I hope was not >>>> wasted. >>>> >>> The short answer is that it should work. The long answer is that >>> it depends, for example it doesn't play nice when trying to >>> bridge a virtual nic with an if_bridge interface. >>> >>> A slightly more verbose description of your environment and what >>> error messages you're seeing would probably help. >> >> Thanks. I'm using an up to date -current, and my outgoing nic is >> wlan0. I followed the instructions on the wiki. I first tried the >> default nic in OSE then I tried the first Intel nic on the list (which >> required downloading drivers of course). >> > >Which type of virtual interface you're using in virtualbox doesn't >matter. However, it hits me that I've actually never really tested >the bridging code with a wireless interface and it looks like you've >hit a bug. I tried to use a wireless interface just now and it >doesn't work, need to look into why though. The problem with bridging and wifi is that on wifi you usually can use only a single mac address... There are ways around this (using nat or routing), and I actually played with the latter using qemu tap networking recently, but couldn't get the most ideal solution working the way I wanted on 8.0 rc - it only worked on 7-stable. (using a sub-subnet of the lan interface for the tap interface + guest, and routing + proxy arp for the guest ip.) I just wanted to try it again on the 8.0 rc box and now even setting up the prox arp entry fails with: arp: writing to routing socket: Invalid argument Commands I tried: arp -s pub only and arp -s auto pub only (both before even configuring the tap interface this time...) Mind you my 8.0 rc checkout is a little old (Sep 29) so maybe I should try updating first (I want to test 8-stable anyway one of these days) - but looking for `arp' in the relevant commitlogs also came up empty. :( (I'm Cc'ing -net just in case, please keep me on the Cc cause I'm not subscribed there...) Cheers, Juergen From dougb at FreeBSD.org Mon Nov 23 00:41:05 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Nov 23 00:41:17 2009 Subject: bridging vs wifi, proxy arp broken on 8.0 rc? In-Reply-To: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> References: <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> Message-ID: <4B09DA1A.2050109@FreeBSD.org> Juergen Lock wrote: > The problem with bridging and wifi is that on wifi you usually can > use only a single mac address... Ok, I'm not heartbroken if it won't work, but it would be nice if the wiki were updated so that no one else wastes time on it like I did last night. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From julian at elischer.org Mon Nov 23 06:08:54 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Nov 23 06:09:03 2009 Subject: if_bridge as if_vlan parent In-Reply-To: <4B08C3DC.1080607@tomjudge.com> References: <4B0825DD.3000702@tomjudge.com> <4B08C3DC.1080607@tomjudge.com> Message-ID: <4B0A26F4.4020803@elischer.org> Tom Judge wrote: > Josh Paetzel wrote: >> On Nov 21, 2009, at 11:39 AM, Tom Judge wrote: >> >>> Hi, >>> >>> I was why I get the following error when trying to create a vlan on >>> top of if_bridge: >>> >>> # ifconfig bridge0 create >>> # ifconfig vlan2 vlan 2 vlandev bridge0 >>> ifconfig: SIOCSETVLAN: Protocol not supported >>> >>> >>> And if there was/is any reason for this to not be supported. >>> >>> Thanks >>> >> >> >> You can create a bridge from a pair of vlan devices.... >> >> # ifconfig vlan1 create >> # ifcconfig vlan2 create >> # ifconfig bridge0 create >> # ifconfig vlan1 vlan 1 vlandev em0 >> # ifconfig vlan2 vlan 2 vlandev em0 >> # ifconfig bridge0 addm vlan1 addm vlan2 >> >> Is that more in line with what you want to do? >> >> I'm a little curious what problem set using a bridge as the parent of >> a vlan solves though. >> >> > You have the problem upside down. > > I am trying to bridge 2 trunk ports on 2 separate switches with a > FreeBSD box, and I would like to access a number of tagged vlans on the > trunk with the FreeBSD box. > > [sw1-1/g1]->[FBSD-em0]-[FBSD-bridge0]-[FBSD-em1]->[sw2-1/g1] > / \ > [FBSD-vlan2] [FBSD-vlan200] > > So: > > ifconfig em0 up > ifconfig em1 up > ifconfig bridge0 create > ifconfig bridge0 addm em0 stp em0 addm em1 stp em1 up > ifconfig vlan2 create > ifconfig vlan2 10.0.0.1/24 vlan 2 vlandev bridge0 > ifconfig vlan200 create > ifconfig vlan200 10.9.9.1/24 vlan 200 vlandev bridge0 > > > This will fail when I try to attach the if_vlan's to the if_bridge. I haven't tried it, but you MAY be able to plumb up some solution to this using the netgraph vlan and bridge nodes. > > Tom > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From kaduk at MIT.EDU Mon Nov 23 07:30:06 2009 From: kaduk at MIT.EDU (Benjamin Kaduk) Date: Mon Nov 23 07:30:12 2009 Subject: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Message-ID: <200911230730.nAN7U5WZ066742@freefall.freebsd.org> The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Mon, 23 Nov 2009 02:25:35 -0500 (EST) On Sun, 22 Nov 2009, Bernhard Schmidt wrote: > On Sunday 01 November 2009 00:24:59 you wrote: >> Indeed, I think I saw a lockup a couple days ago, possibly when >> my card had dissociated and was trying to reassociate. >> >> Thanks for looking into this, > > Seems like your initial fix for that was actually correct, that lock up you > saw there is related to something else. There was an issue with sending null > data frames. > > Can you verify that the LOR is gone with the latest checkout of my repository? > Compile instructions: > http://forums.freebsd.org/showpost.php?p=47627&postcount=16 I upgraded to today's current (which picked up a number of probably-unrelated changes), and then installed the driver from your tree on top of it. No LOR on boot, and I'll let you know if I see any lockups. Thanks, Ben From linimon at FreeBSD.org Mon Nov 23 07:47:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Nov 23 07:47:36 2009 Subject: kern/140684: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot Message-ID: <200911230747.nAN7lN4M090348@freefall.freebsd.org> Old Synopsis: Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot New Synopsis: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 23 07:46:48 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=140684 From bugmaster at FreeBSD.org Mon Nov 23 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 23 11:08:54 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200911231107.nANB70bW070199@freefall.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/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver 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 f 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/140358 net 8.0RC2: [arp] arp: writing to routing socket: Invalid 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/139559 net [tun] several tun(4) interfaces can be created with sa 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/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e 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 0xffffff004127b00 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 o kern/138676 net [route] after buildworld not work local routes [regres 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 net TCP 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 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [if_em] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 371 problems total. From bms at incunabulum.net Mon Nov 23 13:07:49 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Nov 23 13:07:55 2009 Subject: [PATCH] CFR: use refcount(9) in mcast In-Reply-To: <4B055A6E.2090901@incunabulum.net> References: <4B055A17.9080503@incunabulum.net> <4B055A6E.2090901@incunabulum.net> Message-ID: <4B0A890C.2000309@incunabulum.net> After discussion with jhb@, no real need for it. The atomics add instructions which aren't needed as all accesses are covered by a mutex. cheers, BMS From ume at FreeBSD.org Mon Nov 23 15:14:06 2009 From: ume at FreeBSD.org (Hajimu UMEMOTO) Date: Mon Nov 23 15:14:20 2009 Subject: [CFR] unified rc.firewall In-Reply-To: <4B098D21.4040607@FreeBSD.org> References: <4B098D21.4040607@FreeBSD.org> Message-ID: Hi, >>>>> On Sun, 22 Nov 2009 11:12:33 -0800 >>>>> Doug Barton said: dougb> In rc.firewall you seem to have copied afexists() from network.subr. dougb> Is there a reason that you did not simply source that file? That would dougb> be the preferred method. Also in that file you call "if afexists dougb> inet6" quite a few times. My preference from a performance standpoint dougb> would be to call it once, perhaps in a start_precmd then cache the value. Thank you for the comments. Ah, yes, afexists() is only in 9-CURRENT, and is not MFC'ed into 8, yet. So, I thought the patch should be able to work on both 9 and 8, for review. I've changed to source network.subr for afexists(). Calling afexists() several times was not good idea. So, I've changed to call afexists() just once. The new patch is attached. dougb> And of course, you have regression tested this thoroughly, yes? :) dougb> Please include scenarios where there is no INET6 in the kernel as well. Okay, I've tested it on INET6-less kernel, as well. Sincerely, -------------- next part -------------- A non-text attachment was scrubbed... Name: ipfw-unify.diff Type: text/x-patch Size: 15186 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091123/527401d3/ipfw-unify.bin -------------- next part -------------- -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From proks at skylinetele.com Mon Nov 23 15:16:02 2009 From: proks at skylinetele.com (Prokofiev S.P.) Date: Mon Nov 23 15:16:09 2009 Subject: Hangs down/up Intel NIC during creating vlan. Bug em driver ??? Message-ID: <4B0AA2CC.5010205@skylinetele.com> Hi ALL ! I have several servers with FreeBSD 8.0-PRERELEASE on SuperMicro with different Intel NICs. When I create new vlan on em interface ( ifconfig vlan557 create vlandev em0 vlan 557), it hangs down and then up and server becomes inaccessible by ssh, but reply on icmp request. on amd64, custom kernel: em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet on i386, GENERIC kernel: em0@pci0:2:1:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet em1@pci0:2:1:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet /var/log/messages: Nov 23 11:35:49 freebsd kernel: em1: link state changed to DOWN Nov 23 11:35:49 freebsd kernel: vlan557: link state changed to DOWN Nov 23 11:35:52 freebsd kernel: em1: link state changed to UP Nov 23 11:35:52 freebsd kernel: vlan557: link state changed to UP Nov 23 11:36:09 freebsd kernel: em1: link state changed to DOWN Nov 23 11:36:13 freebsd kernel: em1: link state changed to UP From jhb at freebsd.org Mon Nov 23 15:56:18 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 23 15:56:30 2009 Subject: [CFR] unified rc.firewall In-Reply-To: References: <4B098D21.4040607@FreeBSD.org> Message-ID: <200911231056.15247.jhb@freebsd.org> On Monday 23 November 2009 10:13:54 am Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Sun, 22 Nov 2009 11:12:33 -0800 > >>>>> Doug Barton said: > > dougb> In rc.firewall you seem to have copied afexists() from network.subr. > dougb> Is there a reason that you did not simply source that file? That would > dougb> be the preferred method. Also in that file you call "if afexists > dougb> inet6" quite a few times. My preference from a performance standpoint > dougb> would be to call it once, perhaps in a start_precmd then cache the value. > > Thank you for the comments. > Ah, yes, afexists() is only in 9-CURRENT, and is not MFC'ed into 8, > yet. So, I thought the patch should be able to work on both 9 and 8, > for review. I've changed to source network.subr for afexists(). > Calling afexists() several times was not good idea. So, I've changed > to call afexists() just once. > The new patch is attached. > > dougb> And of course, you have regression tested this thoroughly, yes? :) > dougb> Please include scenarios where there is no INET6 in the kernel as well. > > Okay, I've tested it on INET6-less kernel, as well. Some comments I have: @@ -178,6 +212,16 @@ # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me + if [ -n "$net6" ]; then + ${fwcmd} add pass ip6 from me6 to ${net6} + ${fwcmd} add pass ip6 from ${net6} to me6 + fi + + if [ -n "$net6" ]; then + # Allow any link-local multicast traffic + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 + fi Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 rules? @@ -273,6 +329,55 @@ ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + # Stop unique local unicast address on the outside interface + ${fwcmd} add deny ip6 from fc00::/7 to any via ${oif6} + ${fwcmd} add deny ip6 from any to fc00::/7 via ${oif6} + .... Similarly here, why not use 'all' instead of 'ip6'? @@ -291,7 +396,11 @@ ${fwcmd} add pass tcp from any to me 80 setup # Reject&Log all setup of incoming connections from the outside - ${fwcmd} add deny log tcp from any to any in via ${oif} setup + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ + setup proto tcp + fi I would actually not use separate v6 interfaces for the 'simple' firewall but just have 'oif', 'onet', and 'onet_ipv6' variables. Then you don't need this diff at all as the existing rule will work fine. # For services permitted below. ${fwcmd} add pass tcp from me to any established + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from any to any proto tcp established + fi I think this extra rule here isn't needed at all as the first rule should already match all of those packets. # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from me6 to any proto tcp setup + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ + keep-state + fi I think it is more consistent to use 'pass tcp from me6 to any' similar to the IPv4 rules here. It is also shorter and easier to read that way IMO. -- John Baldwin From bzeeb-lists at lists.zabbadoz.net Mon Nov 23 16:15:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Nov 23 16:15:19 2009 Subject: [CFR] unified rc.firewall In-Reply-To: <200911231056.15247.jhb@freebsd.org> References: <4B098D21.4040607@FreeBSD.org> <200911231056.15247.jhb@freebsd.org> Message-ID: <20091123161013.X37440@maildrop.int.zabbadoz.net> On Mon, 23 Nov 2009, John Baldwin wrote: > On Monday 23 November 2009 10:13:54 am Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Sun, 22 Nov 2009 11:12:33 -0800 >>>>>>> Doug Barton said: >> >> dougb> In rc.firewall you seem to have copied afexists() from network.subr. >> dougb> Is there a reason that you did not simply source that file? That > would >> dougb> be the preferred method. Also in that file you call "if afexists >> dougb> inet6" quite a few times. My preference from a performance standpoint >> dougb> would be to call it once, perhaps in a start_precmd then cache the > value. >> >> Thank you for the comments. >> Ah, yes, afexists() is only in 9-CURRENT, and is not MFC'ed into 8, >> yet. So, I thought the patch should be able to work on both 9 and 8, >> for review. I've changed to source network.subr for afexists(). >> Calling afexists() several times was not good idea. So, I've changed >> to call afexists() just once. >> The new patch is attached. >> >> dougb> And of course, you have regression tested this thoroughly, yes? :) >> dougb> Please include scenarios where there is no INET6 in the kernel as > well. >> >> Okay, I've tested it on INET6-less kernel, as well. > > Some comments I have: > > @@ -178,6 +212,16 @@ > # Allow any traffic to or from my own net. > ${fwcmd} add pass all from me to ${net} > ${fwcmd} add pass all from ${net} to me I haven't looked at the entire update but as I see this I shall note unless I missed a fix to ipfw, you need to make that ip and use ip6 and me6 for the new world order. Please make sure that this works as expected in mixed-world scenarios as well as legacy IP and IPv6 only worlds. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From ume at freebsd.org Mon Nov 23 17:27:38 2009 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Mon Nov 23 17:27:52 2009 Subject: [CFR] unified rc.firewall In-Reply-To: <200911231056.15247.jhb@freebsd.org> References: <4B098D21.4040607@FreeBSD.org> <200911231056.15247.jhb@freebsd.org> Message-ID: Hi, >>>>> On Mon, 23 Nov 2009 10:56:14 -0500 >>>>> John Baldwin said: jhb> @@ -178,6 +212,16 @@ jhb> # Allow any traffic to or from my own net. jhb> ${fwcmd} add pass all from me to ${net} jhb> ${fwcmd} add pass all from ${net} to me jhb> + if [ -n "$net6" ]; then jhb> + ${fwcmd} add pass ip6 from me6 to ${net6} jhb> + ${fwcmd} add pass ip6 from ${net6} to me6 jhb> + fi jhb> + jhb> + if [ -n "$net6" ]; then jhb> + # Allow any link-local multicast traffic jhb> + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 jhb> + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 jhb> + fi jhb> Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 jhb> rules? Thank you for the review. The rule is only applicable for IPv6. Rather, I prefer to use 'ip4' explicitly over 'all' or 'ip' here. However, changing 'all' to 'ip4' makes the diff complex. So, I keep 'all' as is. jhb> @@ -273,6 +329,55 @@ jhb> ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} jhb> ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} jhb> jhb> + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then jhb> + # Stop unique local unicast address on the outside interface jhb> + ${fwcmd} add deny ip6 from fc00::/7 to any via ${oif6} jhb> + ${fwcmd} add deny ip6 from any to fc00::/7 via ${oif6} jhb> + jhb> .... jhb> Similarly here, why not use 'all' instead of 'ip6'? Same above. jhb> @@ -291,7 +396,11 @@ jhb> ${fwcmd} add pass tcp from any to me 80 setup jhb> jhb> # Reject&Log all setup of incoming connections from the outside jhb> - ${fwcmd} add deny log tcp from any to any in via ${oif} setup jhb> + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto jhb> tcp jhb> + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then jhb> + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ jhb> + setup proto tcp jhb> + fi jhb> I would actually not use separate v6 interfaces for the 'simple' firewall jhb> but just have 'oif', 'onet', and 'onet_ipv6' variables. Then you don't need jhb> this diff at all as the existing rule will work fine. Yup, it should makes rule simpler. However, many sites still use tunnel for IPv6 connectivity. I think, separating 'oif' and 'oif6' makes such sites happy. So, this diff should make sense, IMHO. jhb> # For services permitted below. jhb> ${fwcmd} add pass tcp from me to any established jhb> + if [ $ipv6_available -eq 0 ]; then jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established jhb> + fi jhb> I think this extra rule here isn't needed at all as the first rule should jhb> already match all of those packets. WORKSTATION type rule is fully dynamic. However, I saw it doesn't work for IPv6 as expected. SSH connection stalls after some period. I suspect keepalive timer doesn't work well for IPv6. So, I changed to use traditional setup/established rule for TCP/IPv6. Further, 'me' doesn't match to IPv6 address. jhb> # Allow any connection out, adding state for each. jhb> ${fwcmd} add pass tcp from me to any setup keep-state jhb> ${fwcmd} add pass udp from me to any keep-state jhb> ${fwcmd} add pass icmp from me to any keep-state jhb> + if [ $ipv6_available -eq 0 ]; then jhb> + ${fwcmd} add pass ip6 from me6 to any proto tcp setup jhb> + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state jhb> + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ jhb> + keep-state jhb> + fi jhb> I think it is more consistent to use 'pass tcp from me6 to any' similar to jhb> the IPv4 rules here. It is also shorter and easier to read that way IMO. I thought similar thing with 'all' vs 'ip4'. Rather, I prefer to change IPv4 rules. However, if 'all' is preferable, I'll change so. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From jfvogel at gmail.com Mon Nov 23 17:29:41 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Nov 23 17:29:48 2009 Subject: Hangs down/up Intel NIC during creating vlan. Bug em driver ??? In-Reply-To: <4B0AA2CC.5010205@skylinetele.com> References: <4B0AA2CC.5010205@skylinetele.com> Message-ID: <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> Custom kernel, well, does it happen on the installed GENERIC kernel, and what is needed to reproduce this, just down/up the interface? And are you saying that it will happen on either the 82573 or the 82546 or just one of them?? Would be nice if this stuff could be discovered earlier :( In any case I will look into it, there is another reported problems with em and vlans as well. Jack 2009/11/23 Prokofiev S.P. > Hi ALL ! > I have several servers with FreeBSD 8.0-PRERELEASE on SuperMicro with > different Intel NICs. When I create new vlan on em interface > ( ifconfig vlan557 create vlandev em0 vlan 557), > it hangs down and then up and server becomes inaccessible by ssh, but reply > on icmp request. > > on amd64, custom kernel: > > em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Corporation 82573E Gigabit Ethernet Controller > (Copper) (82573E)' > class = network > subclass = ethernet > em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > class = network > subclass = ethernet > > on i386, GENERIC kernel: > > em0@pci0:2:1:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > em1@pci0:2:1:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > > /var/log/messages: > > Nov 23 11:35:49 freebsd kernel: em1: link state changed to DOWN > Nov 23 11:35:49 freebsd kernel: vlan557: link state changed to DOWN > Nov 23 11:35:52 freebsd kernel: em1: link state changed to UP > Nov 23 11:35:52 freebsd kernel: vlan557: link state changed to UP > Nov 23 11:36:09 freebsd kernel: em1: link state changed to DOWN > Nov 23 11:36:13 freebsd kernel: em1: link state changed to UP > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From jfvogel at gmail.com Mon Nov 23 17:36:05 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Nov 23 17:36:21 2009 Subject: Intel NIC 0x10f08086 In-Reply-To: References: Message-ID: <2a41acea0911230936n2ed75bcbk34e362a88e70ea7f@mail.gmail.com> This is the new PCH interface, there will be a driver that supports it checked into CURRENT shortly. Cheers, Jack On Sun, Nov 22, 2009 at 4:33 AM, T?lman Linneweh wrote: > Hi List, Hi Jack! > > I have an Intel NIC with the pci chip=0x10f08086 rev=0x05 as onboard Card > on an "Intel DP55WB" Mainboard. > > According to Google it is an "82578DC". > > Now i wonder how to make it work. I tried to add the PCI ID to both em(4) > and igb(4) but the attach failed, so it looks like something more is > required. > > Any ideas? > > regards > arved From jhb at freebsd.org Mon Nov 23 17:55:38 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 23 17:55:49 2009 Subject: [CFR] unified rc.firewall In-Reply-To: References: <200911231056.15247.jhb@freebsd.org> Message-ID: <200911231255.26279.jhb@freebsd.org> On Monday 23 November 2009 12:27:23 pm Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Mon, 23 Nov 2009 10:56:14 -0500 > >>>>> John Baldwin said: > > jhb> @@ -178,6 +212,16 @@ > jhb> # Allow any traffic to or from my own net. > jhb> ${fwcmd} add pass all from me to ${net} > jhb> ${fwcmd} add pass all from ${net} to me > jhb> + if [ -n "$net6" ]; then > jhb> + ${fwcmd} add pass ip6 from me6 to ${net6} > jhb> + ${fwcmd} add pass ip6 from ${net6} to me6 > jhb> + fi > jhb> + > jhb> + if [ -n "$net6" ]; then > jhb> + # Allow any link-local multicast traffic > jhb> + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 > jhb> + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 > jhb> + fi > > jhb> Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 > jhb> rules? > > Thank you for the review. > The rule is only applicable for IPv6. Rather, I prefer to use 'ip4' > explicitly over 'all' or 'ip' here. However, changing 'all' to 'ip4' > makes the diff complex. So, I keep 'all' as is. Hmm, however, using 'all' will work, and while in this case the typing is the same I find it easier to read 'add pass tcp <...>' vs 'add pass ip <...> proto tcp'. I do think they should be consistent regardless. > jhb> # For services permitted below. > jhb> ${fwcmd} add pass tcp from me to any established > jhb> + if [ $ipv6_available -eq 0 ]; then > jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established > jhb> + fi > > jhb> I think this extra rule here isn't needed at all as the first rule should > jhb> already match all of those packets. > > WORKSTATION type rule is fully dynamic. However, I saw it doesn't > work for IPv6 as expected. SSH connection stalls after some period. > I suspect keepalive timer doesn't work well for IPv6. > So, I changed to use traditional setup/established rule for TCP/IPv6. > Further, 'me' doesn't match to IPv6 address. I had missed the me vs any. It is true that the equivalent rule would use me6. I would rather figure out the IPv6 bug so that TCP is treated the same for both protocols instead of having a weaker firewall for IPv6 than IPV4. > jhb> # Allow any connection out, adding state for each. > jhb> ${fwcmd} add pass tcp from me to any setup keep-state > jhb> ${fwcmd} add pass udp from me to any keep-state > jhb> ${fwcmd} add pass icmp from me to any keep-state > jhb> + if [ $ipv6_available -eq 0 ]; then > jhb> + ${fwcmd} add pass ip6 from me6 to any proto tcp setup > jhb> + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state > jhb> + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ > jhb> + keep-state > jhb> + fi > > jhb> I think it is more consistent to use 'pass tcp from me6 to any' similar to > jhb> the IPv4 rules here. It is also shorter and easier to read that way IMO. > > I thought similar thing with 'all' vs 'ip4'. Rather, I prefer to > change IPv4 rules. However, if 'all' is preferable, I'll change so. I do find the shorter version easier to read, and it matches the existing style as well as the examples in the manual page, handbook, etc. -- John Baldwin From administrator at shtorm.com Mon Nov 23 18:01:43 2009 From: administrator at shtorm.com (Yuriy A. Korobko) Date: Mon Nov 23 18:01:51 2009 Subject: Reducing number of interrupts from intel pro 1000 et adapter Message-ID: <1258998140.3015.34.camel@stormi-desktop> Hi, I'd like to know a way to control tx interrupts on intel pro 1000 et adapter with igb driver. Just installed one in the router and systat shows 8-9k rx interrupts and 20k tx interrupts from igb0 and igb1 adapters. Box is a router running freebsd 7.2 release, I've tried default driver from kernel source and latest from intel site, effect is the same with automatic interrupt moderation enabled and disabled. I have the same box with intel pro 1000 pt adapter which have tx(rx)_int_delay sysctls in em driver, I was able to reduce number of tx/rx interrupts to 7-8k per interface and got much more cpu idle because of less context switches with same pps. Interfacae load border# netstat -I igb0 -w 1 input (igb0) output packets errs bytes packets errs bytes colls 41438 0 37923274 51173 0 24539512 0 44827 0 41626876 53408 0 24595412 0 43300 0 39736056 53118 0 24574219 0 43146 0 40399285 53455 0 24368290 0 44827 0 42463307 53921 0 23959752 0 Here is sysctls dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x020000 dev.igb.0.%parent: pci1 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 0 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 1000 dev.igb.0.ave_latency: 4000 dev.igb.0.bulk_latency: 8000 dev.igb.0.rx_processing_limit: 1000 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.4 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=1 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x020000 dev.igb.1.%parent: pci1 dev.igb.1.debug: -1 dev.igb.1.stats: -1 dev.igb.1.flow_control: 0 dev.igb.1.enable_aim: 1 dev.igb.1.low_latency: 1000 dev.igb.1.ave_latency: 4000 dev.igb.1.bulk_latency: 8000 dev.igb.1.rx_processing_limit: 1000 And debug kernel: igb0: Adapter hardware address = 0xc796ec1c kernel: igb0: CTRL = 0x40c00241 RCTL = 0x48002 kernel: igb0: Packet buffer = Tx=0k Rx=0k kernel: igb0: Flow control watermarks high = 63488 low = 61988 kernel: igb0: Queue(0) tdh = 3023, tdt = 3025 kernel: igb0: TX(0) no descriptors avail event = 0 kernel: igb0: TX(0) MSIX IRQ Handled = 3754097484 kernel: igb0: TX(0) Packets sent = 4815628967 kernel: igb0: Queue(0) rdh = 3658, rdt = 3645 kernel: igb0: RX(0) Packets received = 7611879022 kernel: igb0: RX(0) Split Packets = 0 kernel: igb0: RX(0) Byte count = 7013625984942 kernel: igb0: RX(0) MSIX IRQ Handled = 3232986641 kernel: igb0: RX(0) LRO Queued= 0 kernel: igb0: RX(0) LRO Flushed= 0 kernel: igb0: LINK MSIX IRQ Handled = 3 kernel: igb0: Mbuf defrag failed = 0 kernel: igb0: Std mbuf header failed = 0 kernel: igb0: Std mbuf packet failed = 0 kernel: igb0: Driver dropped packets = 0 kernel: igb0: Driver tx dma failure in xmit = 0 kernel: igb1: Adapter hardware address = 0xc796dc1c kernel: igb1: CTRL = 0x40c00241 RCTL = 0x48002 kernel: igb1: Packet buffer = Tx=0k Rx=0k kernel: igb1: Flow control watermarks high = 63488 low = 61988 kernel: igb1: Queue(0) tdh = 4093, tdt = 4093 kernel: igb1: TX(0) no descriptors avail event = 0 kernel: igb1: TX(0) MSIX IRQ Handled = 10882048108 kernel: igb1: TX(0) Packets sent = 31169311987 kernel: igb1: Queue(0) rdh = 2515, rdt = 2513 kernel: igb1: RX(0) Packets received = 30747961847 kernel: igb1: RX(0) Split Packets = 0 kernel: igb1: RX(0) Byte count = 26511993282060 kernel: igb1: RX(0) MSIX IRQ Handled = 4834518320 kernel: igb1: RX(0) LRO Queued= 0 kernel: igb1: RX(0) LRO Flushed= 0 kernel: igb1: LINK MSIX IRQ Handled = 5 kernel: igb1: Mbuf defrag failed = 0 kernel: igb1: Std mbuf header failed = 0 kernel: igb1: Std mbuf packet failed = 0 kernel: igb1: Driver dropped packets = 0 kernel: igb1: Driver tx dma failure in xmit = 0 From ben at b1c1l1.com Mon Nov 23 18:27:51 2009 From: ben at b1c1l1.com (Benjamin Lee) Date: Mon Nov 23 18:28:03 2009 Subject: [CFR] unified rc.firewall In-Reply-To: <200911231255.26279.jhb@freebsd.org> References: <200911231056.15247.jhb@freebsd.org> <200911231255.26279.jhb@freebsd.org> Message-ID: <4B0AD41F.6020709@b1c1l1.com> On 11/23/2009 09:55 AM, John Baldwin wrote: > On Monday 23 November 2009 12:27:23 pm Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Mon, 23 Nov 2009 10:56:14 -0500 >>>>>>> John Baldwin said: >> jhb> # For services permitted below. >> jhb> ${fwcmd} add pass tcp from me to any established >> jhb> + if [ $ipv6_available -eq 0 ]; then >> jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established >> jhb> + fi >> >> jhb> I think this extra rule here isn't needed at all as the first rule should >> jhb> already match all of those packets. >> >> WORKSTATION type rule is fully dynamic. However, I saw it doesn't >> work for IPv6 as expected. SSH connection stalls after some period. >> I suspect keepalive timer doesn't work well for IPv6. >> So, I changed to use traditional setup/established rule for TCP/IPv6. >> Further, 'me' doesn't match to IPv6 address. > > I had missed the me vs any. It is true that the equivalent rule would use > me6. I would rather figure out the IPv6 bug so that TCP is treated the > same for both protocols instead of having a weaker firewall for IPv6 than > IPV4. There is a bug in ipfw send_pkt() that prevents ipfw_tick() from functioning for IPv6. See PR kern/117234. -- Benjamin Lee http://www.b1c1l1.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091123/64886c4e/signature.pgp From nox at jelal.kn-bremen.de Mon Nov 23 18:32:36 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Mon Nov 23 18:32:53 2009 Subject: bridging vs wifi, proxy arp broken on 8.0 rc? (was: Re: Bridged networking for virtualbox on -current?) In-Reply-To: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> References: <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> Message-ID: <20091123182809.GA35896@triton8.kn-bremen.de> On Mon, Nov 23, 2009 at 12:16:58AM +0100, Juergen Lock wrote: > In article <4B09992F.1080900@shapeshifter.se> you write: > >Doug Barton wrote: > >> Fredrik Lindberg wrote: > >>> Doug Barton wrote: > >>>> Is bridged networking for vbox supposed to work on -current? It says > >>>> on the wiki that it does, but I tried it tonight and couldn't get it > >>>> to work. > >>>> > >>>> I did see one page that suggested trying one of the Intel virtual > >>>> nicks, which I did, no luck. > >>>> > >>>> If this is not supposed to work it would be nice to update the wiki, I > >>>> spent quite a bit of time trying to get it to work that I hope was not > >>>> wasted. > >>>> > >>> The short answer is that it should work. The long answer is that > >>> it depends, for example it doesn't play nice when trying to > >>> bridge a virtual nic with an if_bridge interface. > >>> > >>> A slightly more verbose description of your environment and what > >>> error messages you're seeing would probably help. > >> > >> Thanks. I'm using an up to date -current, and my outgoing nic is > >> wlan0. I followed the instructions on the wiki. I first tried the > >> default nic in OSE then I tried the first Intel nic on the list (which > >> required downloading drivers of course). > >> > > > >Which type of virtual interface you're using in virtualbox doesn't > >matter. However, it hits me that I've actually never really tested > >the bridging code with a wireless interface and it looks like you've > >hit a bug. I tried to use a wireless interface just now and it > >doesn't work, need to look into why though. > > The problem with bridging and wifi is that on wifi you usually can > use only a single mac address... There are ways around this (using > nat or routing), and I actually played with the latter using qemu tap > networking recently, but couldn't get the most ideal solution working > the way I wanted on 8.0 rc - it only worked on 7-stable. (using a > sub-subnet of the lan interface for the tap interface + guest, and > routing + proxy arp for the guest ip.) I just wanted to try it again > on the 8.0 rc box and now even setting up the prox arp entry fails > with: > arp: writing to routing socket: Invalid argument > Commands I tried: > arp -s pub only > and > arp -s auto pub only > (both before even configuring the tap interface this time...) > > Mind you my 8.0 rc checkout is a little old (Sep 29) so maybe I should > try updating first (I want to test 8-stable anyway one of these days) - > but looking for `arp' in the relevant commitlogs also came up empty. :( > > (I'm Cc'ing -net just in case, please keep me on the Cc cause I'm > not subscribed there...) I meanwhile found a few arp related commits (it helps if you don't forget to ignore case when searching for `arp'... doh! :) - but I now also grabbed stable/8 and head snapshot isos and tested that arp command there, and found its still broken. :( (The same command without the `only' succeeds but can never work for _this_ use case, right?) How I tested (head snapshot livefs in qemu:) % qemu -m 256 -cdrom 9.0-HEAD-20091123-JPSNAP-i386-dvd1.iso -net nic,model=e1000 -net user -curses [In sysinstall select fixit -> cdrom/dvd, then:] Fixit# mkdir /var/db Fixit# dhclient em0 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 10.0.2.2 DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 10.0.2.15 -- renewal in 43200 seconds. Fixit# arp -s 10.0.2.65 auto pub only using interface em0 for proxy with address 52:54:00:12:34:56 arp: writing to routing socket: Invalid argument Fixit# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 52:54:00:12:34:56 inet6 fe80::5054:ff:fe12:3456%em0 prefixlen 64 scopeid 0x1 inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active Fixit# And as I said stable/8 and 8.0 rc also suffer from the same bug. (sysinstall doesn't seem to have a way to shutdown instead of reboot by itself but you can just `killall qemu' here when finished; if you want less violent redirect the monitor or omit -curses if you have X and in the monitor do `system_powerdown' to press the virtual acpi powerbutton and then hit return in sysinstall to confirm the `abort installation' prompt that should come up.) Thanx, Juergen PS: (Coming back to the actual tap networking on wifi use case:) Of course you could still use static routes on the other lan boxen that need to talk to the guest, or only use one on one box (like your router/ap) and setup proxy arp on that, but thats not nearly as nice as doing proxy arp on the same box that runs the guest. But of course its too late for 8.0 now... PPS: btw there is another use case besides wifi for doing it this way, i.e. routing + (optionally) proxy arp instead of bridging: when you want to protect your lan from stupid guests causing arp trouble etc... From oberman at es.net Mon Nov 23 19:52:51 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Nov 23 19:53:10 2009 Subject: [CFR] unified rc.firewall In-Reply-To: Your message of "Mon, 23 Nov 2009 12:55:25 EST." <200911231255.26279.jhb@freebsd.org> Message-ID: <20091123195249.1518C1CC0E@ptavv.es.net> > From: John Baldwin > Date: Mon, 23 Nov 2009 12:55:25 -0500 > Sender: owner-freebsd-current@freebsd.org > > On Monday 23 November 2009 12:27:23 pm Hajimu UMEMOTO wrote: > > Hi, > > > > >>>>> On Mon, 23 Nov 2009 10:56:14 -0500 > > >>>>> John Baldwin said: > > > > jhb> @@ -178,6 +212,16 @@ > > jhb> # Allow any traffic to or from my own net. > > jhb> ${fwcmd} add pass all from me to ${net} > > jhb> ${fwcmd} add pass all from ${net} to me > > jhb> + if [ -n "$net6" ]; then > > jhb> + ${fwcmd} add pass ip6 from me6 to ${net6} > > jhb> + ${fwcmd} add pass ip6 from ${net6} to me6 > > jhb> + fi > > jhb> + > > jhb> + if [ -n "$net6" ]; then > > jhb> + # Allow any link-local multicast traffic > > jhb> + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 > > jhb> + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 > > jhb> + fi > > > > jhb> Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 > > jhb> rules? > > > > Thank you for the review. > > The rule is only applicable for IPv6. Rather, I prefer to use 'ip4' > > explicitly over 'all' or 'ip' here. However, changing 'all' to 'ip4' > > makes the diff complex. So, I keep 'all' as is. > > Hmm, however, using 'all' will work, and while in this case the typing is the > same I find it easier to read 'add pass tcp <...>' vs > 'add pass ip <...> proto tcp'. I do think they should be consistent > regardless. > > > jhb> # For services permitted below. > > jhb> ${fwcmd} add pass tcp from me to any established > > jhb> + if [ $ipv6_available -eq 0 ]; then > > jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established > > jhb> + fi > > > > jhb> I think this extra rule here isn't needed at all as the first rule should > > jhb> already match all of those packets. > > > > WORKSTATION type rule is fully dynamic. However, I saw it doesn't > > work for IPv6 as expected. SSH connection stalls after some period. > > I suspect keepalive timer doesn't work well for IPv6. > > So, I changed to use traditional setup/established rule for TCP/IPv6. > > Further, 'me' doesn't match to IPv6 address. FWIW, I have been seeing this since the last update of OpenSSH. I never saw it until then. It's a real pain and I'd love to see it fixed. Right now I'm forced to use IPv4 for the jobs that I tunnel in SSH. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From kaduk at MIT.EDU Tue Nov 24 02:30:06 2009 From: kaduk at MIT.EDU (Benjamin Kaduk) Date: Tue Nov 24 02:30:13 2009 Subject: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Message-ID: <200911240230.nAO2U6Ak004167@freefall.freebsd.org> The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Mon, 23 Nov 2009 21:27:15 -0500 (EST) On Mon, 23 Nov 2009, Benjamin Kaduk wrote: > On Sun, 22 Nov 2009, Bernhard Schmidt wrote: >> >> Can you verify that the LOR is gone with the latest checkout of my >> repository? >> Compile instructions: >> http://forums.freebsd.org/showpost.php?p=47627&postcount=16 > > I upgraded to today's current (which picked up a number of probably-unrelated > changes), and then installed the driver from > your tree on top of it. > No LOR on boot, and I'll let you know if I see any lockups. I got a "lockup" (no idea what actually was happening) while in X tonight; nothing useful is in the logs. I'm not even sure if I can blame iwn for it ... I did get a LOR after turning on the hardware wireless switch, though: iwn0: RF switch: radio enabled wlan0: link state changed to UP lock order reversal: 1st 0xffffff800033d018 iwn0_com_lock (iwn0_com_lock) @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3280 2nd 0xffffff8000309010 iwn0 (network driver) @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 iwn_start() at iwn_start+0x35 if_transmit() at if_transmit+0xd6 ieee80211_start() at ieee80211_start+0x3f4 scan_task() at scan_task+0x4c7 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80001ffd30, rbp = 0 --- I don't think I'll have time to look at it particularly soon, though. -Ben Kaduk From proks at skylinetele.com Tue Nov 24 09:52:18 2009 From: proks at skylinetele.com (Prokofiev S.P.) Date: Tue Nov 24 09:52:25 2009 Subject: Hangs down/up Intel NIC during creating vlan. Bug em driver ??? In-Reply-To: <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> References: <4B0AA2CC.5010205@skylinetele.com> <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> Message-ID: <4B0BAC87.7050703@skylinetele.com> It happen on the 82573 and the 82546 depend on vlandev. To reproduce this input command ifconfig vlan557 create vlandev em1 vlan 557 and you may see Nov 23 11:35:49 ...... kernel: em1: link state changed to DOWN Nov 23 11:35:49 ...... kernel: vlan557: link state changed to DOWN Nov 23 11:35:52 ...... kernel: em1: link state changed to UP Nov 23 11:35:52 ...... kernel: vlan557: link state changed to UP Nov 23 11:36:09 ...... kernel: em1: link state changed to DOWN Nov 23 11:36:13 ...... kernel: em1: link state changed to UP For example: em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:06:43:1a media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:06:43:1b media: Ethernet autoselect status: no carrier .... vlan2: flags=8843 metric 0 mtu 1500 options=3 ether 00:1b:21:06:43:1a inet 10.25.224.23 netmask 0xfffffff0 broadcast 10.25.224.31 media: Ethernet autoselect (1000baseT ) status: active vlan: 2 parent interface: em0 input command ifconfig vlan557 create vlandev em0 vlan 557 in /var/log/messages: Nov 24 10:59:37 ....... kernel: em0: link state changed to DOWN Nov 24 10:59:37 ....... kernel: vlan2: link state changed to DOWN Nov 24 10:59:37 ....... kernel: vlan557: link state changed to DOWN Nov 24 10:59:41 ....... kernel: em0: link state changed to UP Nov 24 10:59:41 ....... kernel: vlan2: link state changed to UP Nov 24 10:59:41 ....... kernel: vlan557: link state changed to UP On custom kernel ssh client lost connect and reconnect failure until reboot. This is tcpdump on fail server (10.25.224.23): 11:13:23.559741 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,nop,wscale 8,sackOK,TS val 3107838092 ecr 0], length 0 11:13:23.559771 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107838092], length 0 11:13:26.559555 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,nop,wscale 8,sackOK,TS val 3107841092 ecr 0], length 0 11:13:26.559579 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107841092], length 0 11:13:29.560220 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107841092], length 0 11:13:29.759620 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,nop,wscale 8,sackOK,TS val 3107844292 ecr 0], length 0 11:13:29.759641 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107844292], length 0 11:13:32.760214 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107844292], length 0 11:13:32.959809 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,sackOK,eol], length 0 11:13:32.959829 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:35.960214 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:36.159874 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,sackOK,eol], length 0 11:13:36.159892 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:39.160211 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:39.359940 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,sackOK,eol], length 0 11:13:39.359956 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:42.360212 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 But on client I see only requests without reply. On GENERIC kernel reconnect is success. But down/up interface is not right behavior. Jack Vogel wrote: > Custom kernel, well, does it happen on the installed GENERIC kernel, and > what is needed > to reproduce this, just down/up the interface? And are you saying that it > will happen on > either the 82573 or the 82546 or just one of them?? > > Would be nice if this stuff could be discovered earlier :( In any case I > will look into it, there > is another reported problems with em and vlans as well. > > Jack > > > 2009/11/23 Prokofiev S.P. > > >> Hi ALL ! >> I have several servers with FreeBSD 8.0-PRERELEASE on SuperMicro with >> different Intel NICs. When I create new vlan on em interface >> ( ifconfig vlan557 create vlandev em0 vlan 557), >> it hangs down and then up and server becomes inaccessible by ssh, but reply >> on icmp request. >> >> on amd64, custom kernel: >> >> em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel Corporation 82573E Gigabit Ethernet Controller >> (Copper) (82573E)' >> class = network >> subclass = ethernet >> em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 >> rev=0x00 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' >> class = network >> subclass = ethernet >> >> on i386, GENERIC kernel: >> >> em0@pci0:2:1:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Dual Port Gigabit Ethernet Controller (82546EB)' >> class = network >> subclass = ethernet >> em1@pci0:2:1:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Dual Port Gigabit Ethernet Controller (82546EB)' >> class = network >> subclass = ethernet >> >> /var/log/messages: >> >> Nov 23 11:35:49 freebsd kernel: em1: link state changed to DOWN >> Nov 23 11:35:49 freebsd kernel: vlan557: link state changed to DOWN >> Nov 23 11:35:52 freebsd kernel: em1: link state changed to UP >> Nov 23 11:35:52 freebsd kernel: vlan557: link state changed to UP >> Nov 23 11:36:09 freebsd kernel: em1: link state changed to DOWN >> Nov 23 11:36:13 freebsd kernel: em1: link state changed to UP >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From m.irgiznov at uljanovsk.comstar-r.ru Tue Nov 24 15:30:04 2009 From: m.irgiznov at uljanovsk.comstar-r.ru (Max V. Irgiznov) Date: Tue Nov 24 15:30:11 2009 Subject: kern/118238: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) Message-ID: <200911241530.nAOFU4bx014329@freefall.freebsd.org> The following reply was made to PR kern/118238; it has been noted by GNATS. From: "Max V. Irgiznov" To: , Cc: Subject: Re: kern/118238: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) Date: Tue, 24 Nov 2009 18:09:43 +0300 This bug still exist in FreeBSD 8.0-RELEASE #0: Tue Nov 24 17:24:49 UTC 2009 root@:/usr/obj/usr/src/sys/GENERIC amd64 From ume at freebsd.org Tue Nov 24 15:40:54 2009 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Tue Nov 24 15:41:06 2009 Subject: [CFR] unified rc.firewall In-Reply-To: <4B0AD41F.6020709@b1c1l1.com> References: <200911231056.15247.jhb@freebsd.org> <200911231255.26279.jhb@freebsd.org> <4B0AD41F.6020709@b1c1l1.com> Message-ID: Hi, >>>>> On Mon, 23 Nov 2009 10:27:43 -0800 >>>>> Benjamin Lee said: ben> There is a bug in ipfw send_pkt() that prevents ipfw_tick() from ben> functioning for IPv6. See PR kern/117234. I confirmed that the patch fixed the problem. Thank you for letting me know. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From ceache at gmail.com Tue Nov 24 18:01:59 2009 From: ceache at gmail.com (Charles Henri de Boysson) Date: Tue Nov 24 18:02:06 2009 Subject: Performance issue with new pipe profile feature in FreeBSD 8.0 RELEASE Message-ID: <184b04b20911240940g36621d69hf3ca160a6d122ecc@mail.gmail.com> Hi, I have a simple setup with two computer connected via a FreeBSD bridge running 8.0 RELEASE. I am trying to use dummynet to simulate a wireless network between the two and for that I wanted to use the pipe profile feature of FreeBSD 8.0. But as I was experimenting with the pipe profile feature I ran into some issues. I have setup ipfw to send traffic coming for either interface of the bridge to a respective pipe as follow: # ipfw show 00100 ? ? 0 ? ? ? ? 0 allow ip from any to any via lo0 00200 ? ? 0 ? ? ? ? 0 deny ip from any to 127.0.0.0/8 00300 ? ? 0 ? ? ? ? 0 deny ip from 127.0.0.0/8 to any 01000 ? ? 0 ? ? ? ? 0 pipe 1 ip from any to any via vr0 layer2 01100 ? ? 0 ? ? ? ? 0 pipe 101 ip from any to any via vr4 layer2 65000 ?7089 ? ?716987 allow ip from any to any 65535 ? ? 0 ? ? ? ? 0 deny ip from any to any When I setup my pipes as follow: # ipfw pipe 1 config bw 10Mbit delay 25 mask proto 0 # ipfw pipe 101 config bw 10Mbit delay 25 mask proto 0 # ipfw pipe show 00001: ?10.000 Mbit/s ? 25 ms ? 50 sl. 0 queues (1 buckets) droptail burst: 0 Byte 00101: ?10.000 Mbit/s ? 25 ms ? 50 sl. 0 queues (1 buckets) droptail burst: 0 Byte With this setup, when I try to pass traffic through the bridge with iperf, I obtain the desired speed: iperf reports about 9.7Mbits/sec in UDP mode and 9.5 in TCP mode (I copied and pasted the iperf runs at the end of this email). The problem arise when I setup pipe 1 (the downlink) with an equivalent profile (I tried to simplify it as much as possible). # ipfw pipe 1 config profile test.pipeconf mask proto 0 # ipfw pipe show 00001: 10.000 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail burst: 0 Byte profile: name "test" loss 1.000000 samples 2 00101: 10.000 Mbit/s 25 ms 50 sl. 0 queues (1 buckets) droptail burst: 0 Byte # cat test.pipeconf name test bw 10Mbit loss-level 1.0 samples 2 prob delay 0.0 25 1.0 25 The same iperf TCP tests then collapse to about 500Kbit/s with the same settings (copy and pasted the output of iperf bellow) I can't figure out what is going on. There is no visible load on the bridge. I have an unmodified GENERIC kernel with the following sysctl. net.link.bridge.ipfw: 1 kern.hz: 1000 The bridge configuration is as follow: bridge0: flags=8843 metric 0 mtu 1500 ether 1a:1f:2e:42:74:8d id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr4 flags=143 ? ? ? ?ifmaxaddr 0 port 6 priority 128 path cost 200000 member: vr0 flags=143 ? ? ? ?ifmaxaddr 0 port 2 priority 128 path cost 200000 iperf runs without the profile set: % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 ------------------------------------------------------------ Client connecting to 10.0.0.254, TCP port 5001 Binding to local address 10.1.0.1 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 17.0 MBytes 9.49 Mbits/sec % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit ------------------------------------------------------------ Client connecting to 10.0.0.254, UDP port 5001 Binding to local address 10.1.0.1 Sending 1470 byte datagrams UDP buffer size: 110 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec [ 3] Sent 13382 datagrams [ 3] Server Report: [ 3] 0.0-15.1 sec 17.4 MBytes 9.72 Mbits/sec 0.822 ms 934/13381 (7%) [ 3] 0.0-15.1 sec 1 datagrams received out-of-order iperf runs with the profile set: % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 ------------------------------------------------------------ Client connecting to 10.0.0.254, TCP port 5001 Binding to local address 10.1.0.1 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.7 sec 968 KBytes 505 Kbits/sec % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit ------------------------------------------------------------ Client connecting to 10.0.0.254, UDP port 5001 Binding to local address 10.1.0.1 Sending 1470 byte datagrams UDP buffer size: 110 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec [ 3] Sent 13382 datagrams [ 3] Server Report: [ 3] 0.0-16.3 sec 893 KBytes 449 Kbits/sec 1.810 ms 12757/13379 (95%) Let me know what other information you would need to help me debugging this. In advance, thank you for your help -- Charles-Henri de Boysson From jhb at freebsd.org Tue Nov 24 18:56:07 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Nov 24 18:56:14 2009 Subject: [PATCH] Remove if_watchdog and if_timer Message-ID: <200911241356.05528.jhb@freebsd.org> Now that no drivers in the tree use if_watchdog and if_timer, this patch just removes them completely. Since if_timer was a short that was adjacent to if_index, removing if_timer would have still left a padding hole in the form of a short on all of our current architectures. After discussing this briefly with Brooks I changed if_index to be an int rather than leaving the padding hole. Comments? --- //depot/vendor/freebsd/src/sys/net/if.c 2009/11/12 19:05:14 +++ //depot/user/jhb/cleanup/sys/net/if.c 2009/11/19 22:35:58 @@ -125,10 +125,8 @@ static void if_freemulti(struct ifmultiaddr *); static void if_init(void *); static void if_grow(void); -static void if_check(void *); static void if_route(struct ifnet *, int flag, int fam); static int if_setflag(struct ifnet *, int, int, int *, int); -static void if_slowtimo(void *); static int if_transmit(struct ifnet *ifp, struct mbuf *m); static void if_unroute(struct ifnet *, int flag, int fam); static void link_rtrequest(int, struct rtentry *, struct rt_addrinfo *); @@ -185,11 +183,6 @@ static if_com_alloc_t *if_com_alloc[256]; static if_com_free_t *if_com_free[256]; -/* - * System initialization - */ -SYSINIT(interface_check, SI_SUB_PROTO_IF, SI_ORDER_FIRST, if_check, NULL); - MALLOC_DEFINE(M_IFNET, "ifnet", "interface internals"); MALLOC_DEFINE(M_IFADDR, "ifaddr", "interface address"); MALLOC_DEFINE(M_IFMADDR, "ether_multi", "link-level multicast address"); @@ -375,18 +368,6 @@ V_ifindex_table = e; } -static void -if_check(void *dummy __unused) -{ - - /* - * If at least one interface added during boot uses - * if_watchdog then start the timer. - */ - if (slowtimo_started) - if_slowtimo(0); -} - /* * Allocate a struct ifnet and an index for an interface. A layer 2 * common structure will also be allocated if an allocation routine is @@ -670,18 +651,6 @@ /* Announce the interface. */ rt_ifannouncemsg(ifp, IFAN_ARRIVAL); - - if (!vmove && ifp->if_watchdog != NULL) { - if_printf(ifp, - "WARNING: using obsoleted if_watchdog interface\n"); - - /* - * Note that we need if_slowtimo(). If this happens after - * boot, then call if_slowtimo() directly. - */ - if (atomic_cmpset_int(&slowtimo_started, 0, 1) && !cold) - if_slowtimo(0); - } } static void @@ -1973,39 +1942,6 @@ } /* - * Handle interface watchdog timer routines. Called - * from softclock, we decrement timers (if set) and - * call the appropriate interface routine on expiration. - * - * XXXRW: Note that because timeouts run with Giant, if_watchdog() is called - * holding Giant. - */ -static void -if_slowtimo(void *arg) -{ - VNET_ITERATOR_DECL(vnet_iter); - struct ifnet *ifp; - int s = splimp(); - - VNET_LIST_RLOCK_NOSLEEP(); - IFNET_RLOCK_NOSLEEP(); - VNET_FOREACH(vnet_iter) { - CURVNET_SET(vnet_iter); - TAILQ_FOREACH(ifp, &V_ifnet, if_link) { - if (ifp->if_timer == 0 || --ifp->if_timer) - continue; - if (ifp->if_watchdog) - (*ifp->if_watchdog)(ifp); - } - CURVNET_RESTORE(); - } - IFNET_RUNLOCK_NOSLEEP(); - VNET_LIST_RUNLOCK_NOSLEEP(); - splx(s); - timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); -} - -/* * Map interface name to interface structure pointer, with or without * returning a reference. */ --- //depot/vendor/freebsd/src/sys/net/if_dead.c 2009/04/23 11:55:13 +++ //depot/user/jhb/cleanup/sys/net/if_dead.c 2009/11/19 22:35:58 @@ -70,12 +70,6 @@ return (ENXIO); } -static void -ifdead_watchdog(struct ifnet *ifp) -{ - -} - static int ifdead_resolvemulti(struct ifnet *ifp, struct sockaddr **llsa, struct sockaddr *sa) @@ -107,7 +101,6 @@ ifp->if_input = ifdead_input; ifp->if_start = ifdead_start; ifp->if_ioctl = ifdead_ioctl; - ifp->if_watchdog = ifdead_watchdog; ifp->if_resolvemulti = ifdead_resolvemulti; ifp->if_qflush = ifdead_qflush; ifp->if_transmit = ifdead_transmit; --- //depot/vendor/freebsd/src/sys/net/if_var.h 2009/11/12 19:05:14 +++ //depot/user/jhb/cleanup/sys/net/if_var.h 2009/11/19 22:35:58 @@ -140,8 +140,7 @@ int if_pcount; /* number of promiscuous listeners */ struct carp_if *if_carp; /* carp interface structure */ struct bpf_if *if_bpf; /* packet filter structure */ - u_short if_index; /* numeric abbreviation for this if */ - short if_timer; /* time 'til if_watchdog called */ + u_int if_index; /* numeric abbreviation for this if */ struct ifvlantrunk *if_vlantrunk; /* pointer to 802.1q data */ int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface features & capabilities */ @@ -161,8 +160,6 @@ (struct ifnet *); int (*if_ioctl) /* ioctl routine */ (struct ifnet *, u_long, caddr_t); - void (*if_watchdog) /* timer routine */ - (struct ifnet *); void (*if_init) /* Init routine */ (void *); int (*if_resolvemulti) /* validate/resolve multicast */ -- John Baldwin From pyunyh at gmail.com Tue Nov 24 19:40:57 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Nov 24 19:41:04 2009 Subject: Reducing number of interrupts from intel pro 1000 et adapter In-Reply-To: <1258998140.3015.34.camel@stormi-desktop> References: <1258998140.3015.34.camel@stormi-desktop> Message-ID: <20091124194025.GA1116@michelle.cdnetworks.com> On Mon, Nov 23, 2009 at 07:42:20PM +0200, Yuriy A. Korobko wrote: > Hi, > > I'd like to know a way to control tx interrupts on intel pro 1000 et > adapter with igb driver. Just installed one in the router and systat > shows 8-9k rx interrupts and 20k tx interrupts from igb0 and igb1 > adapters. Box is a router running freebsd 7.2 release, I've tried > default driver from kernel source and latest from intel site, effect is > the same with automatic interrupt moderation enabled and disabled. I I'm also aware of this issue. Here is patch I'm currently experimenting. It seems igb(4) wants to dynamically adjust interrupt moderation on Rx traffic such that this seems to cause lots of Tx interrupts under heavy Rx traffic. I simply disabled that feature and fixed Rx handler not to generate more interrupts. Without Rx handler fix the igb(4) took all CPU cycles under heady load(64 bytes UDP torture test) I couldn't even type a character on console. You can get my patch at the following URL. http://people.freebsd.org/~yongari/igb/igb.buf.patch5 The patch also includes other changes I made so it's somewhat big. Note, please don't apply the patch on production servers it needs more testing. > have the same box with intel pro 1000 pt adapter which have > tx(rx)_int_delay sysctls in em driver, I was able to reduce number of > tx/rx interrupts to 7-8k per interface and got much more cpu idle > because of less context switches with same pps. > I guess you sacrificed latencies. From jfvogel at gmail.com Tue Nov 24 19:59:23 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 24 19:59:29 2009 Subject: Reducing number of interrupts from intel pro 1000 et adapter In-Reply-To: <20091124194025.GA1116@michelle.cdnetworks.com> References: <1258998140.3015.34.camel@stormi-desktop> <20091124194025.GA1116@michelle.cdnetworks.com> Message-ID: <2a41acea0911241159u3b2dab36p66f29724f8cac13@mail.gmail.com> There are significant changes to igb forthcoming, I believe I have fixed the multiqueue problems that exist in it now, and I am working to improve the AIM code so it handles TX and RX (this is still experimental right now though). I hope it addresses your problems. Jack On Tue, Nov 24, 2009 at 11:40 AM, Pyun YongHyeon wrote: > On Mon, Nov 23, 2009 at 07:42:20PM +0200, Yuriy A. Korobko wrote: > > Hi, > > > > I'd like to know a way to control tx interrupts on intel pro 1000 et > > adapter with igb driver. Just installed one in the router and systat > > shows 8-9k rx interrupts and 20k tx interrupts from igb0 and igb1 > > adapters. Box is a router running freebsd 7.2 release, I've tried > > default driver from kernel source and latest from intel site, effect is > > the same with automatic interrupt moderation enabled and disabled. I > > I'm also aware of this issue. Here is patch I'm currently > experimenting. It seems igb(4) wants to dynamically adjust > interrupt moderation on Rx traffic such that this seems to cause > lots of Tx interrupts under heavy Rx traffic. I simply disabled > that feature and fixed Rx handler not to generate more interrupts. > Without Rx handler fix the igb(4) took all CPU cycles under heady > load(64 bytes UDP torture test) I couldn't even type a character > on console. You can get my patch at the following URL. > http://people.freebsd.org/~yongari/igb/igb.buf.patch5 > > The patch also includes other changes I made so it's somewhat big. > Note, please don't apply the patch on production servers it needs > more testing. > > > have the same box with intel pro 1000 pt adapter which have > > tx(rx)_int_delay sysctls in em driver, I was able to reduce number of > > tx/rx interrupts to 7-8k per interface and got much more cpu idle > > because of less context switches with same pps. > > > > I guess you sacrificed latencies. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From rwatson at FreeBSD.org Tue Nov 24 23:07:21 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Nov 24 23:07:29 2009 Subject: [PATCH] Remove if_watchdog and if_timer In-Reply-To: <200911241356.05528.jhb@freebsd.org> References: <200911241356.05528.jhb@freebsd.org> Message-ID: On Tue, 24 Nov 2009, John Baldwin wrote: > Now that no drivers in the tree use if_watchdog and if_timer, this patch > just removes them completely. Since if_timer was a short that was adjacent > to if_index, removing if_timer would have still left a padding hole in the > form of a short on all of our current architectures. After discussing this > briefly with Brooks I changed if_index to be an int rather than leaving the > padding hole. Comments? The if_watchdog/if_timer changes sound good to me, but let's do the if_index change separately, and just add padding in this change. The if_index -> 32-bit chnge is one that's been overdue for a long time, but it's going to have a lot of side effects, so keeping it to its own changesets (which can be backed out if needed more easily) is probably a good idea. Thanks for taking on the watchdog changes! Robert N M Watson Computer Laboratory University of Cambridge > > --- //depot/vendor/freebsd/src/sys/net/if.c 2009/11/12 19:05:14 > +++ //depot/user/jhb/cleanup/sys/net/if.c 2009/11/19 22:35:58 > @@ -125,10 +125,8 @@ > static void if_freemulti(struct ifmultiaddr *); > static void if_init(void *); > static void if_grow(void); > -static void if_check(void *); > static void if_route(struct ifnet *, int flag, int fam); > static int if_setflag(struct ifnet *, int, int, int *, int); > -static void if_slowtimo(void *); > static int if_transmit(struct ifnet *ifp, struct mbuf *m); > static void if_unroute(struct ifnet *, int flag, int fam); > static void link_rtrequest(int, struct rtentry *, struct rt_addrinfo *); > @@ -185,11 +183,6 @@ > static if_com_alloc_t *if_com_alloc[256]; > static if_com_free_t *if_com_free[256]; > > -/* > - * System initialization > - */ > -SYSINIT(interface_check, SI_SUB_PROTO_IF, SI_ORDER_FIRST, if_check, NULL); > - > MALLOC_DEFINE(M_IFNET, "ifnet", "interface internals"); > MALLOC_DEFINE(M_IFADDR, "ifaddr", "interface address"); > MALLOC_DEFINE(M_IFMADDR, "ether_multi", "link-level multicast address"); > @@ -375,18 +368,6 @@ > V_ifindex_table = e; > } > > -static void > -if_check(void *dummy __unused) > -{ > - > - /* > - * If at least one interface added during boot uses > - * if_watchdog then start the timer. > - */ > - if (slowtimo_started) > - if_slowtimo(0); > -} > - > /* > * Allocate a struct ifnet and an index for an interface. A layer 2 > * common structure will also be allocated if an allocation routine is > @@ -670,18 +651,6 @@ > > /* Announce the interface. */ > rt_ifannouncemsg(ifp, IFAN_ARRIVAL); > - > - if (!vmove && ifp->if_watchdog != NULL) { > - if_printf(ifp, > - "WARNING: using obsoleted if_watchdog interface\n"); > - > - /* > - * Note that we need if_slowtimo(). If this happens after > - * boot, then call if_slowtimo() directly. > - */ > - if (atomic_cmpset_int(&slowtimo_started, 0, 1) && !cold) > - if_slowtimo(0); > - } > } > > static void > @@ -1973,39 +1942,6 @@ > } > > /* > - * Handle interface watchdog timer routines. Called > - * from softclock, we decrement timers (if set) and > - * call the appropriate interface routine on expiration. > - * > - * XXXRW: Note that because timeouts run with Giant, if_watchdog() is called > - * holding Giant. > - */ > -static void > -if_slowtimo(void *arg) > -{ > - VNET_ITERATOR_DECL(vnet_iter); > - struct ifnet *ifp; > - int s = splimp(); > - > - VNET_LIST_RLOCK_NOSLEEP(); > - IFNET_RLOCK_NOSLEEP(); > - VNET_FOREACH(vnet_iter) { > - CURVNET_SET(vnet_iter); > - TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > - if (ifp->if_timer == 0 || --ifp->if_timer) > - continue; > - if (ifp->if_watchdog) > - (*ifp->if_watchdog)(ifp); > - } > - CURVNET_RESTORE(); > - } > - IFNET_RUNLOCK_NOSLEEP(); > - VNET_LIST_RUNLOCK_NOSLEEP(); > - splx(s); > - timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > -} > - > -/* > * Map interface name to interface structure pointer, with or without > * returning a reference. > */ > --- //depot/vendor/freebsd/src/sys/net/if_dead.c 2009/04/23 11:55:13 > +++ //depot/user/jhb/cleanup/sys/net/if_dead.c 2009/11/19 22:35:58 > @@ -70,12 +70,6 @@ > return (ENXIO); > } > > -static void > -ifdead_watchdog(struct ifnet *ifp) > -{ > - > -} > - > static int > ifdead_resolvemulti(struct ifnet *ifp, struct sockaddr **llsa, > struct sockaddr *sa) > @@ -107,7 +101,6 @@ > ifp->if_input = ifdead_input; > ifp->if_start = ifdead_start; > ifp->if_ioctl = ifdead_ioctl; > - ifp->if_watchdog = ifdead_watchdog; > ifp->if_resolvemulti = ifdead_resolvemulti; > ifp->if_qflush = ifdead_qflush; > ifp->if_transmit = ifdead_transmit; > --- //depot/vendor/freebsd/src/sys/net/if_var.h 2009/11/12 19:05:14 > +++ //depot/user/jhb/cleanup/sys/net/if_var.h 2009/11/19 22:35:58 > @@ -140,8 +140,7 @@ > int if_pcount; /* number of promiscuous listeners */ > struct carp_if *if_carp; /* carp interface structure */ > struct bpf_if *if_bpf; /* packet filter structure */ > - u_short if_index; /* numeric abbreviation for this if */ > - short if_timer; /* time 'til if_watchdog called */ > + u_int if_index; /* numeric abbreviation for this if */ > struct ifvlantrunk *if_vlantrunk; /* pointer to 802.1q data */ > int if_flags; /* up/down, broadcast, etc. */ > int if_capabilities; /* interface features & capabilities */ > @@ -161,8 +160,6 @@ > (struct ifnet *); > int (*if_ioctl) /* ioctl routine */ > (struct ifnet *, u_long, caddr_t); > - void (*if_watchdog) /* timer routine */ > - (struct ifnet *); > void (*if_init) /* Init routine */ > (void *); > int (*if_resolvemulti) /* validate/resolve multicast */ > > -- > John Baldwin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From will at FreeBSD.org Wed Nov 25 00:06:27 2009 From: will at FreeBSD.org (will@FreeBSD.org) Date: Wed Nov 25 00:06:34 2009 Subject: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 Message-ID: <200911250006.nAP06QkS069688@freefall.freebsd.org> Synopsis: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 State-Changed-From-To: analyzed->closed State-Changed-By: will State-Changed-When: Wed Nov 25 00:05:19 UTC 2009 State-Changed-Why: Fixed in r199770 (HEAD). http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 From dfilter at FreeBSD.ORG Wed Nov 25 00:10:02 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Nov 25 00:10:09 2009 Subject: bin/118987: commit references a PR Message-ID: <200911250010.nAP0A2C2069782@freefall.freebsd.org> The following reply was made to PR bin/118987; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/118987: commit references a PR Date: Wed, 25 Nov 2009 00:01:12 +0000 (UTC) Author: will Date: Wed Nov 25 00:00:57 2009 New Revision: 199770 URL: http://svn.freebsd.org/changeset/base/199770 Log: Make ``ifconfig -l ether'' only list interfaces that speak Ethernet. PR: 118987 Approved by: ken (mentor) Modified: head/sbin/ifconfig/ifconfig.c Modified: head/sbin/ifconfig/ifconfig.c ============================================================================== --- head/sbin/ifconfig/ifconfig.c Tue Nov 24 22:37:04 2009 (r199769) +++ head/sbin/ifconfig/ifconfig.c Wed Nov 25 00:00:57 2009 (r199770) @@ -147,7 +147,7 @@ main(int argc, char *argv[]) struct ifaddrs *ifap, *ifa; struct ifreq paifr; const struct sockaddr_dl *sdl; - char options[1024], *cp; + char options[1024], *cp, *namecp = NULL; const char *ifname; struct option *p; size_t iflen; @@ -294,7 +294,7 @@ main(int argc, char *argv[]) sdl = (const struct sockaddr_dl *) ifa->ifa_addr; else sdl = NULL; - if (cp != NULL && strcmp(cp, ifa->ifa_name) == 0) + if (cp != NULL && strcmp(cp, ifa->ifa_name) == 0 && !namesonly) continue; iflen = strlcpy(name, ifa->ifa_name, sizeof(name)); if (iflen >= sizeof(name)) { @@ -308,16 +308,32 @@ main(int argc, char *argv[]) continue; if (uponly && (ifa->ifa_flags & IFF_UP) == 0) continue; - ifindex++; /* * Are we just listing the interfaces? */ if (namesonly) { + if (namecp == cp) + continue; + if (afp != NULL) { + /* special case for "ether" address family */ + if (!strcmp(afp->af_name, "ether")) { + if (sdl == NULL || + sdl->sdl_type != IFT_ETHER || + sdl->sdl_alen != ETHER_ADDR_LEN) + continue; + } else { + if (ifa->ifa_addr->sa_family != afp->af_af) + continue; + } + } + namecp = cp; + ifindex++; if (ifindex > 1) printf(" "); fputs(name, stdout); continue; } + ifindex++; if (argc > 0) ifconfig(argc, argv, 0, afp); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From tom at tomjudge.com Wed Nov 25 00:58:51 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Nov 25 00:58:58 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4B0C80FB.5040901@tomjudge.com> David Christensen wrote: >>> For the record we also have not been able to reproduce the issue on >>> the R710 only the R610. >> I got hold of an R610 system and I now understand why the >> issue was difficult to replicate on R710. The R610 ships >> without Enterprise iDRAC while the R710 ship with the add-in >> Enterprise iDRAC module. When the module is present the >> system is managed through the additional RJ45 port but when >> the module is absent iDRAC traffic will flow through the >> on-board 5709 adpaters. >> The error will only occur when management firmware is loaded >> on the 5709 AND when NC-SI management functionality is enabled. >> >> You should be able to confirm this by adding or removing the >> Enterprise iDRAC module on your systems. Now that I have a >> failure again I have some ideas to test which might help. >> Stay tuned. > > Does the attached patch make a difference for you? > > FYI, I'll be out next week on vacation. > Hi David, This patch seems to do the trick, on at least one of the R610's that we have. Just did cold boot, 5 warm boots, cold boot, 5 warm boots and have not had any issues. Thanks Tom