From owner-freebsd-net@FreeBSD.ORG Sun Nov 20 00:47:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 315A1106566B; Sun, 20 Nov 2011 00:47:20 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA058FC08; Sun, 20 Nov 2011 00:47:19 +0000 (UTC) Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 19 Nov 2011 16:47:19 -0800 Received: from [192.168.4.185] (88.96.1.126) by webmail.SolarFlare.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 19 Nov 2011 16:47:18 -0800 Message-ID: <1321750026.2885.236.camel@deadeye> From: Ben Hutchings To: Philip Paeps Date: Sun, 20 Nov 2011 00:47:06 +0000 In-Reply-To: References: <1321652051.2883.76.camel@bwh-desktop> Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3-2 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [88.96.1.126] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005 X-TM-AS-Result: No--23.460000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-OriginalArrivalTime: 20 Nov 2011 00:47:19.0303 (UTC) FILETIME=[F4FD4170:01CCA71D] Cc: freebsd-net@freebsd.org, marius@freebsd.org Subject: Re: sfxge: Remove interrupt self-test code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 00:47:20 -0000 On Sat, 2011-11-19 at 11:20 +0200, Philip Paeps wrote: > On 18 Nov 2011, at 23:34, Ben Hutchings wrote: > > sfxge: Remove interrupt self-test code > > > > It's not currently used; it didn't build on 32-bit and the previous > > build fix is incorrect. If we really implement self-tests we can do > > this again properly. > > Committed. Thanks! > > Have you had a chance to see if the driver still works on i386? If so, > I'll enable it again in the i386 build, now that it compiles again. I really need to find or set up a new test image with i386. But I can say that a quick test by running: make MACHINE=i386 MACHINE_CPUARCH=i386 CC='cc -m32' in sys/modules/sfxge now successfully compiles all object files (but the linker gives up due to mismatched architectures). Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 06:21:40 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D402B1065674 for ; Mon, 21 Nov 2011 06:21:40 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2AEC48FC20 for ; Mon, 21 Nov 2011 06:21:39 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id pAL6Lco1076353 for ; Mon, 21 Nov 2011 13:21:38 +0700 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4EC9EDED.10005@grosbein.pp.ru> Date: Mon, 21 Nov 2011 13:21:33 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: dummynet(4) kernel process CPU usage monitoring X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 06:21:40 -0000 Hi! How do I give out dummynet's CPU usage via SNMP? Preferable as ever-incrementing raw counter. I already use bsnmpd and its plugin bsnmp-ucd. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 11:07:10 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B71151065672 for ; Mon, 21 Nov 2011 11:07:10 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A4BAE8FC12 for ; Mon, 21 Nov 2011 11:07:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pALB7AZB053637 for ; Mon, 21 Nov 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pALB79L4053635 for freebsd-net@FreeBSD.org; Mon, 21 Nov 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Nov 2011 11:07:09 GMT Message-Id: <201111211107.pALB79L4053635@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 11:07:10 -0000 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/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net [patch] Enhancement: add SO_PROTO to socket.h o kern/162201 net [ip] [patch] multicast forwarding cache hash always al o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161908 net [netgraph] [patch] ng_vlan update for QinQ support o kern/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph 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 o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 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/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/138620 net [lagg] [patch] lagg port bpf-writes blocked 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 if_adata/ 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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i 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/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... 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/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c 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/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/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network 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 f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes 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 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/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) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection 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/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. 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 kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) 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/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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] [security] ppp(8): fix local stack overflow in 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/120966 net [rum] kernel panic with if_rum and WPA encryption 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 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 o kern/118727 net [netgraph] [patch] [request] add new ng_pf module 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 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/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 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/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to 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/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/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/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) 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 o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack 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 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 s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu 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/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat 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 p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if 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 a kern/71474 net [route] route lookup does not skip interfaces marked d 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/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong 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/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps 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 f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 383 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 12:01:27 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C011065679 for ; Mon, 21 Nov 2011 12:01:27 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7B18FC25 for ; Mon, 21 Nov 2011 12:01:26 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pALC1OY9096564; Mon, 21 Nov 2011 16:01:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pALC1Nu5096563; Mon, 21 Nov 2011 16:01:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 21 Nov 2011 16:01:23 +0400 From: Gleb Smirnoff To: Alexander Wittig Message-ID: <20111121120123.GC81136@FreeBSD.org> References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> <20111110065135.GS71907@FreeBSD.org> <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD 9 and ARP multicast source address error messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 12:01:27 -0000 Alexander, On Thu, Nov 10, 2011 at 12:42:15PM -0500, Alexander Wittig wrote: A> > Can you try attached patch. It reduces severity level of all ARP A> > messages, that can be triggered by packet on network, with expection to A> > "using my IP address". A> > A> > With default syslog.conf, now ARP errors won't get to console. A> > A> > Also, the multicast message lacked "\n" newline character, that's why, A> > I suppose, syslogd failed to coalesce a number of messages into a single A> > entry "last message repeated X times". A> A> Thank you very much for the patch, and for making this particular message a bit more helpful by including the MAC address. A> I tried it and indeed it stops the messages from going to the console. But the default syslog.conf still logs each one in /var/log/messages and they also show up in dmsg output. These happen quite frequently, so even on a not so busy network they will drown out almost everything else going on in dmsg or /var/log/messages. Unfortunately, having two (or more) different machines use these will prevent syslogd from combining messages into "last message repeated X times": A> A> /var/log/messages: A> [...] A> Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast A> Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast A> Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast A> Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast A> [...] Okay, I will apply patch. A> I'm not an expert on networking, but is this condition of ignoring such an ARP packet really a noteworthy event? I.e. is this something that should not occur in "normal" operation according to the ARP specifications? If this is mostly for kernel developers, maybe it should only be enabled in debug kernel builds? Nope, this isn't for kernel developers only but for sysadmins. Some bad traffic is present in your network, and it should be noticed by sysadmin, that's why LOG_NOTICE severity left. However, I understand how annoying it is when you are in a bad network, you don't admin it, you can't fix it and your logging system is too chatty. I am thinking of some generic way of supperssing or ratelimiting all logged events that can be triggered by host on LAN or even by remote host. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 13:29:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D11106566B for ; Mon, 21 Nov 2011 13:29:50 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id A90348FC0C for ; Mon, 21 Nov 2011 13:29:50 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 05D5C9DC41E for ; Mon, 21 Nov 2011 14:29:49 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 14:29:47 +0100 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 13:29:51 -0000 (Sent to freebsd-bugs as well, copied here for discussion, if needed) =09 Sorry for the brief report and the scarce details. The f****ing form = insists on rejecting the captcha after one hour writing a report.=20 So, in short: If TCP_MD5 is available on the system, options IPSEC options TCP_SIGNATURE #include support for RFC 2385 device crypto Turns out openbgpd can't receive BGP connections.=20 The error is in the session.c file, line 148, function = setup_listeners(u_int *la_cnt). Code snippet: opt =3D 1; if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG, &opt, sizeof(opt)) =3D=3D -1) { if (errno =3D=3D ENOPROTOOPT) { /* system w/o = md5sig */ log_warnx("md5sig not available, = disabling"); sysdep.no_md5sig =3D 1; } else fatal("setsockopt TCP_MD5SIG"); } This is wrong. Regardless of the configuration, this code activates = TCP_MD5 for the socket and leaves it enabled. This is what happens: 14:04:33.009212 IP 10.0.0.2.36610 > 10.0.0.1.179: Flags [S], seq = 1941690122, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 115224 ecr 0], length 0 14:04:33.009267 IP 10.0.0.1.179 > 10.0.0.2.36610: Flags [S.], seq = 2935503211, ack 1941690123, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 4192648161 ecr 115224,nop,nop,md5shared secret not = supplied with -M, can't check - a360f2c9a9f96a582ccbabe79418105c], = length 0 The daemon receiving the connection is replying with TCP_MD5, even = though there's no TCP_MD5 option set in the bgpd.conf file. Removing this code (or placing it outside of the loop, creating a = temporary socket just to enable TCP_MD5 on it and using it to detect the = availability of TCP_MD5) works: 14:04:35.395447 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [S], seq = 366635408, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 220116 ecr 0], length 0 14:04:35.395490 IP 10.0.0.2.179 > 10.0.0.1.45119: Flags [S.], seq = 1226417253, ack 366635409, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 511187362 ecr 220116], length 0 14:04:35.395584 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [.], ack 1, win = 1040, options [nop,nop,TS val 220116 ecr 511187362], length 0 14:04:35.396072 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [P.], seq 1:46, = ack 1, win 1040, options [nop,nop,TS val 220116 ecr 511187362], length = 45: BGP, length: 45 14:04:35.397031 IP 10.0.0.2.179 > 10.0.0.1.45119: Flags [P.], seq 1:50, = ack 46, win 1040, options [nop,nop,TS val 511187362 ecr 220116], length = 49: BGP, length: 49 14:04:35.397381 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [P.], seq 46:65, = ack 50, win 1040, options [nop,nop,TS val 220116 ecr 511187362], length = 19: BGP, length: 19 Sorry for the terse report. It was very detailed, but lost. Borja. From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 16:12:14 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1936D1065673 for ; Mon, 21 Nov 2011 16:12:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C60878FC15 for ; Mon, 21 Nov 2011 16:12:13 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so4092891vbb.13 for ; Mon, 21 Nov 2011 08:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=nuMBwNbm5za1ZyX9bABQLE+S7yEdzRbVJH5GW8Ryr94=; b=ZdbJpfYXi5ZXvy63xs6CnsAITb8O3HTLqD918yAoCm0mdfcwOSH+0BfWzJTWkXBPXg aB2YMk06XsG0uRb3nJJM8F1ErEoqryAwDnp2KnsHWb/PBaYDEmhT/MQTXMa02KNGWTtW ryVNd4scnGCAZYdkYfVusLmtoQmVafzENQrS0= MIME-Version: 1.0 Received: by 10.52.34.211 with SMTP id b19mr15763736vdj.112.1321890556185; Mon, 21 Nov 2011 07:49:16 -0800 (PST) Received: by 10.52.101.132 with HTTP; Mon, 21 Nov 2011 07:49:16 -0800 (PST) Date: Mon, 21 Nov 2011 15:49:16 +0000 Message-ID: From: "Paul B. Mahol" To: net Content-Type: multipart/mixed; boundary=20cf3079bf3c088d6d04b240a1f2 Cc: Subject: [PATCH] ndis: safe fpu on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:12:14 -0000 --20cf3079bf3c088d6d04b240a1f2 Content-Type: text/plain; charset=ISO-8859-1 Hi, This patch should fix panic on amd64 when using ndis with drivers which make use of fpu registers. --20cf3079bf3c088d6d04b240a1f2 Content-Type: text/x-diff; charset=US-ASCII; name="fpu.diff" Content-Disposition: attachment; filename="fpu.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 ZGlmZiAtLWdpdCBhL3N5cy9jb21wYXQvbmRpcy9rZXJuX3dpbmRydi5jIGIvc3lzL2NvbXBhdC9u ZGlzL2tlcm5fd2luZHJ2LmMKaW5kZXggNTU3Mjk4OC4uMWE5M2I1NCAxMDA2NDQKLS0tIGEvc3lz L2NvbXBhdC9uZGlzL2tlcm5fd2luZHJ2LmMKKysrIGIvc3lzL2NvbXBhdC9uZGlzL2tlcm5fd2lu ZHJ2LmMKQEAgLTU1LDYgKzU1LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2lmZGVmIF9f aTM4Nl9fCiAjaW5jbHVkZSA8bWFjaGluZS9zZWdtZW50cy5oPgogI2VuZGlmCisjaWZkZWYgX19h bWQ2NF9fCisjaW5jbHVkZSA8bWFjaGluZS9mcHUuaD4KKyNlbmRpZgogCiAjaW5jbHVkZSA8ZGV2 L3VzYi91c2IuaD4KIApAQCAtNjEzLDYgKzYxNiw4NiBAQCB3aW5kcnZfd3JhcChmdW5jLCB3cmFw LCBhcmdjbnQsIGZ0eXBlKQogCiAJcmV0dXJuICgwKTsKIH0KKwordWludDY0X3QKK194ODZfNjRf Y2FsbDEodm9pZCAqZm4sIHVpbnQ2NF90IGEpCit7CisJc3RydWN0IGZwdV9rZXJuX2N0eCBmcHVf Y3R4X3NhdmU7CisJdWludDY0X3QgcmV0OworCisJZnB1X2tlcm5fZW50ZXIoY3VydGhyZWFkLCAm ZnB1X2N0eF9zYXZlLCBGUFVfS0VSTl9OT1JNQUwpOworCXJldCA9IHg4Nl82NF9jYWxsMShmbiwg YSk7CisJZnB1X2tlcm5fbGVhdmUoY3VydGhyZWFkLCAmZnB1X2N0eF9zYXZlKTsKKworCXJldHVy biAocmV0KTsKK30KKwordWludDY0X3QKK194ODZfNjRfY2FsbDIodm9pZCAqZm4sIHVpbnQ2NF90 IGEsIHVpbnQ2NF90IGIpCit7CisJc3RydWN0IGZwdV9rZXJuX2N0eCBmcHVfY3R4X3NhdmU7CisJ dWludDY0X3QgcmV0OworCisJZnB1X2tlcm5fZW50ZXIoY3VydGhyZWFkLCAmZnB1X2N0eF9zYXZl LCBGUFVfS0VSTl9OT1JNQUwpOworCXJldCA9IHg4Nl82NF9jYWxsMihmbiwgYSwgYik7CisJZnB1 X2tlcm5fbGVhdmUoY3VydGhyZWFkLCAmZnB1X2N0eF9zYXZlKTsKKworCXJldHVybiAocmV0KTsK K30KKwordWludDY0X3QKK194ODZfNjRfY2FsbDModm9pZCAqZm4sIHVpbnQ2NF90IGEsIHVpbnQ2 NF90IGIsIHVpbnQ2NF90IGMpCit7CisJc3RydWN0IGZwdV9rZXJuX2N0eCBmcHVfY3R4X3NhdmU7 CisJdWludDY0X3QgcmV0OworCisJZnB1X2tlcm5fZW50ZXIoY3VydGhyZWFkLCAmZnB1X2N0eF9z YXZlLCBGUFVfS0VSTl9OT1JNQUwpOworCXJldCA9IHg4Nl82NF9jYWxsMyhmbiwgYSwgYiwgYyk7 CisJZnB1X2tlcm5fbGVhdmUoY3VydGhyZWFkLCAmZnB1X2N0eF9zYXZlKTsKKworCXJldHVybiAo cmV0KTsKK30KKwordWludDY0X3QKK194ODZfNjRfY2FsbDQodm9pZCAqZm4sIHVpbnQ2NF90IGEs IHVpbnQ2NF90IGIsIHVpbnQ2NF90IGMsIHVpbnQ2NF90IGQpCit7CisJc3RydWN0IGZwdV9rZXJu X2N0eCBmcHVfY3R4X3NhdmU7CisJdWludDY0X3QgcmV0OworCisJZnB1X2tlcm5fZW50ZXIoY3Vy dGhyZWFkLCAmZnB1X2N0eF9zYXZlLCBGUFVfS0VSTl9OT1JNQUwpOworCXJldCA9IHg4Nl82NF9j YWxsNChmbiwgYSwgYiwgYywgZCk7CisJZnB1X2tlcm5fbGVhdmUoY3VydGhyZWFkLCAmZnB1X2N0 eF9zYXZlKTsKKworCXJldHVybiAocmV0KTsKK30KKwordWludDY0X3QKK194ODZfNjRfY2FsbDUo dm9pZCAqZm4sIHVpbnQ2NF90IGEsIHVpbnQ2NF90IGIsIHVpbnQ2NF90IGMsIHVpbnQ2NF90IGQs CisgICAgdWludDY0X3QgZSkKK3sKKwlzdHJ1Y3QgZnB1X2tlcm5fY3R4IGZwdV9jdHhfc2F2ZTsK Kwl1aW50NjRfdCByZXQ7CisKKwlmcHVfa2Vybl9lbnRlcihjdXJ0aHJlYWQsICZmcHVfY3R4X3Nh dmUsIEZQVV9LRVJOX05PUk1BTCk7CisJcmV0ID0geDg2XzY0X2NhbGw1KGZuLCBhLCBiLCBjLCBk LCBlKTsKKwlmcHVfa2Vybl9sZWF2ZShjdXJ0aHJlYWQsICZmcHVfY3R4X3NhdmUpOworCisJcmV0 dXJuIChyZXQpOworfQorCit1aW50NjRfdAorX3g4Nl82NF9jYWxsNih2b2lkICpmbiwgdWludDY0 X3QgYSwgdWludDY0X3QgYiwgdWludDY0X3QgYywgdWludDY0X3QgZCwKKyAgICB1aW50NjRfdCBl LCB1aW50NjRfdCBmKQoreworCXN0cnVjdCBmcHVfa2Vybl9jdHggZnB1X2N0eF9zYXZlOworCXVp bnQ2NF90IHJldDsKKworCWZwdV9rZXJuX2VudGVyKGN1cnRocmVhZCwgJmZwdV9jdHhfc2F2ZSwg RlBVX0tFUk5fTk9STUFMKTsKKwlyZXQgPSB4ODZfNjRfY2FsbDYoZm4sIGEsIGIsIGMsIGQsIGUs IGYpOworCWZwdV9rZXJuX2xlYXZlKGN1cnRocmVhZCwgJmZwdV9jdHhfc2F2ZSk7CisKKwlyZXR1 cm4gKHJldCk7Cit9CiAjZW5kaWYgLyogX19hbWQ2NF9fICovCiAKIApkaWZmIC0tZ2l0IGEvc3lz L2NvbXBhdC9uZGlzL3BlX3Zhci5oIGIvc3lzL2NvbXBhdC9uZGlzL3BlX3Zhci5oCmluZGV4IDg0 ZTAxNjIuLjI3NmFkMWMgMTAwNjQ0Ci0tLSBhL3N5cy9jb21wYXQvbmRpcy9wZV92YXIuaAorKysg Yi9zeXMvY29tcGF0L25kaXMvcGVfdmFyLmgKQEAgLTQ2MCwyMiArNDYwLDI5IEBAIGV4dGVybiB1 aW50NjRfdCB4ODZfNjRfY2FsbDUodm9pZCAqLCB1aW50NjRfdCwgdWludDY0X3QsIHVpbnQ2NF90 LCB1aW50NjRfdCwKIGV4dGVybiB1aW50NjRfdCB4ODZfNjRfY2FsbDYodm9pZCAqLCB1aW50NjRf dCwgdWludDY0X3QsIHVpbnQ2NF90LCB1aW50NjRfdCwKIAl1aW50NjRfdCwgdWludDY0X3QpOwog Ci0KLSNkZWZpbmUJTVNDQUxMMShmbiwgYSkJCQkJCQlcCi0JeDg2XzY0X2NhbGwxKChmbiksICh1 aW50NjRfdCkoYSkpCi0jZGVmaW5lCU1TQ0FMTDIoZm4sIGEsIGIpCQkJCQlcCi0JeDg2XzY0X2Nh bGwyKChmbiksICh1aW50NjRfdCkoYSksICh1aW50NjRfdCkoYikpCi0jZGVmaW5lCU1TQ0FMTDMo Zm4sIGEsIGIsIGMpCQkJCQlcCi0JeDg2XzY0X2NhbGwzKChmbiksICh1aW50NjRfdCkoYSksICh1 aW50NjRfdCkoYiksCQlcCi0JKHVpbnQ2NF90KShjKSkKLSNkZWZpbmUJTVNDQUxMNChmbiwgYSwg YiwgYywgZCkJCQkJCVwKLQl4ODZfNjRfY2FsbDQoKGZuKSwgKHVpbnQ2NF90KShhKSwgKHVpbnQ2 NF90KShiKSwJCVwKK3VpbnQ2NF90IF94ODZfNjRfY2FsbDEodm9pZCAqLCB1aW50NjRfdCk7Cit1 aW50NjRfdCBfeDg2XzY0X2NhbGwyKHZvaWQgKiwgdWludDY0X3QsIHVpbnQ2NF90KTsKK3VpbnQ2 NF90IF94ODZfNjRfY2FsbDModm9pZCAqLCB1aW50NjRfdCwgdWludDY0X3QsIHVpbnQ2NF90KTsK K3VpbnQ2NF90IF94ODZfNjRfY2FsbDQodm9pZCAqLCB1aW50NjRfdCwgdWludDY0X3QsIHVpbnQ2 NF90LCB1aW50NjRfdCk7Cit1aW50NjRfdCBfeDg2XzY0X2NhbGw1KHZvaWQgKiwgdWludDY0X3Qs IHVpbnQ2NF90LCB1aW50NjRfdCwgdWludDY0X3QsCisgICAgdWludDY0X3QpOwordWludDY0X3Qg X3g4Nl82NF9jYWxsNih2b2lkICosIHVpbnQ2NF90LCB1aW50NjRfdCwgdWludDY0X3QsIHVpbnQ2 NF90LAorICAgIHVpbnQ2NF90LCB1aW50NjRfdCk7CisKKyNkZWZpbmUJTVNDQUxMMShmbiwgYSkJ CQkJCQkJXAorCV94ODZfNjRfY2FsbDEoKGZuKSwgKHVpbnQ2NF90KShhKSkKKyNkZWZpbmUJTVND QUxMMihmbiwgYSwgYikJCQkJCQlcCisJX3g4Nl82NF9jYWxsMigoZm4pLCAodWludDY0X3QpKGEp LCAodWludDY0X3QpKGIpKQorI2RlZmluZQlNU0NBTEwzKGZuLCBhLCBiLCBjKQkJCQkJCVwKKwlf eDg2XzY0X2NhbGwzKChmbiksICh1aW50NjRfdCkoYSksICh1aW50NjRfdCkoYiksICh1aW50NjRf dCkoYykpCisjZGVmaW5lCU1TQ0FMTDQoZm4sIGEsIGIsIGMsIGQpCQkJCQkJXAorCV94ODZfNjRf Y2FsbDQoKGZuKSwgKHVpbnQ2NF90KShhKSwgKHVpbnQ2NF90KShiKSwJCVwKIAkodWludDY0X3Qp KGMpLCAodWludDY0X3QpKGQpKQotI2RlZmluZQlNU0NBTEw1KGZuLCBhLCBiLCBjLCBkLCBlKQkJ CQlcCi0JeDg2XzY0X2NhbGw1KChmbiksICh1aW50NjRfdCkoYSksICh1aW50NjRfdCkoYiksCQlc CisjZGVmaW5lCU1TQ0FMTDUoZm4sIGEsIGIsIGMsIGQsIGUpCQkJCQlcCisJX3g4Nl82NF9jYWxs NSgoZm4pLCAodWludDY0X3QpKGEpLCAodWludDY0X3QpKGIpLAkJXAogCSh1aW50NjRfdCkoYyks ICh1aW50NjRfdCkoZCksICh1aW50NjRfdCkoZSkpCi0jZGVmaW5lCU1TQ0FMTDYoZm4sIGEsIGIs IGMsIGQsIGUsIGYpCQkJCVwKLQl4ODZfNjRfY2FsbDYoKGZuKSwgKHVpbnQ2NF90KShhKSwgKHVp bnQ2NF90KShiKSwJCVwKKyNkZWZpbmUJTVNDQUxMNihmbiwgYSwgYiwgYywgZCwgZSwgZikJCQkJ CVwKKwlfeDg2XzY0X2NhbGw2KChmbiksICh1aW50NjRfdCkoYSksICh1aW50NjRfdCkoYiksCQlc CiAJKHVpbnQ2NF90KShjKSwgKHVpbnQ2NF90KShkKSwgKHVpbnQ2NF90KShlKSwgKHVpbnQ2NF90 KShmKSkKIAogI2VuZGlmIC8qIF9fYW1kNjRfXyAqLwo= --20cf3079bf3c088d6d04b240a1f2-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 21:51:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3669106564A for ; Mon, 21 Nov 2011 21:51:46 +0000 (UTC) (envelope-from pete@nrth.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id A8F568FC08 for ; Mon, 21 Nov 2011 21:51:46 +0000 (UTC) Received: from cpc4-nrte22-2-0-cust419.8-4.cable.virginmedia.com ([86.22.217.164] helo=tooms.nrth.lab) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RSbSl-000Cig-Lr for freebsd-net@freebsd.org; Mon, 21 Nov 2011 21:31:39 +0000 Received: from purity.nrth.lab ([10.20.30.5]) by tooms.nrth.lab with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RSbSk-0000N4-Bh for freebsd-net@freebsd.org; Mon, 21 Nov 2011 21:31:38 +0000 Received: from localhost.nrth.lab ([127.0.0.1] helo=purity.nrth.lab) by purity.nrth.lab with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RSbSm-0001yr-2H for freebsd-net@freebsd.org; Mon, 21 Nov 2011 21:31:40 +0000 Received: (from pete@localhost) by purity.nrth.lab (8.14.4/8.14.4/Submit) id pALLVeLn007616 for freebsd-net@freebsd.org; Mon, 21 Nov 2011 21:31:40 GMT (envelope-from pete@nrth.org) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.22.217.164 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18kpliLK9wphEC4XsGDihs8v7A2Xzm020k= From: Pete To: freebsd-net@freebsd.org Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-mnwHBEfc3tlWJhlnwJ0v" Organization: nrth.org Date: Mon, 21 Nov 2011 21:31:39 +0000 Message-ID: <1321911099.6148.11.camel@purity.nrth.lab> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Subject: Restarting Network Services Without Rebooting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 21:51:47 -0000 --=-mnwHBEfc3tlWJhlnwJ0v Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Apologies for the incorrect post to mailing.freebsd.questions newsgroup :( ) Hello, Occasionally I'm disconnected from my cable ISP (Virginmedia) which is making me wonder whether or not it's my fault most of the time or just occasional 'glitches' with the cable connection. I have a FreeBSD 8.2 firewall/router box (a Pentium 4 2.8GHz PC clone) which has two NICs installed. PF is running on this box. I've recently added the following two rules to my /etc/pf.conf in order to help with DHCP allocations. pass in quick log (all) on $ext_if inet proto tcp from any port 67:68 to any port 67:68 keep state flags S/SA=20 pass in quick log (all) on $ext_if inet proto udp from any port 67:68 to any port 67:68 keep state I have to say that 90% of the time this firewall/router box runs flawlessly. The above DHCP 'additions' to the /etc/pf.conf have only been made today so time will tell whether there's any noticeable difference. Today I had another outage (before the firewall DHCP additions were made) and I got to thinking about how I could restart the network services on my firewall/router box without rebooting the machine itself. After some searching I found the following commands which didn't produce any errors, but I was left with no IP address assigned to my Internet- facing NIC ($ext_if, which is actually 'sis0'). /etc/rc.d/netif restart && /etc/rc.d/routing restart If I reboot this machine it *always* configures the network correctly, providing that there's no problem with the ISP's connection. Does anyone know what I'm doing wrong here ? Are there more or fewer commands needed to simulate the effect a reboot of a FreeBSD 8.2 box would have on general networking ? Should I have included /etc/rc.d/dhclient in the above command line as well ? Thanks for your time. Regards, Pete. --=-mnwHBEfc3tlWJhlnwJ0v Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITAjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGYTCCBUmg AwIBAgIDAmK8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNDA1MTMyNjM5WhcNMTIwNDA1MDUyNDU5WjCBizEgMB4GA1UEDRMXMzk3MDM4LTBEUFVMYzZG M2ljMjFKRWcxHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxHDAaBgkqhkiG9w0BCQEWDXBldGVAbnJ0aC5vcmcw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW1XIHQo4nGUvvsiXovn9ZI4Hg9rGo4jqz 3+mTrq+r9L/JBbVCFYR7L8z3hA6m18omLCl2rx1jXgfGAjdQHeqQOjCowIUPDDmC2np6sXpT8Anj HPbiR+tA2S26s+9e8p6eXt0bOysHhNh2zbEo2WpqA7igk5HySg3BVUwMUwEWPcJuJAsDgQTvJZa5 lpU1O1iMvDJMwpJyX4CX1X/cRXYXlzwdXFZeqZ31jkadY5JY+tmTyzu9jelvdFtJj69kvJcm0LwN e07Fq0w0BQaWDw2/pQNiZOe0fIlPC0/u3PvZXkxs38uvcuYVILn4n34Hf6oZGFjZwns4xRi6ahdh Ni15AgMBAAGjggLJMIICxTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFCG4mes1r10nLjNaT+SAy/WbdU20MB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBgGA1UdEQQRMA+BDXBldGVAbnJ0aC5vcmcwggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20v aW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGR TGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhl IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8v Y3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUF BzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNh LmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQAD ggEBACHSekrCZILA4Z2hTLnJAQFmg0O+BDKtfXXKoHIiE6SbkI80+suBxY3x68mgJ8qdtgIVMLwa htlUAYdC7rbjKlXHyhh4DzsJJk6Ljj5T99h7Tz/Pz7oSWri9AF7HE/idYtrQ8eg60qwqIvtUatxg mXJGjrZoKDrciJ3YEWu3RtqBoKLMsdEWacSkZxSV45wFKMflW4rJ6O0T6kaIaegMH1wccyGvxYSe km7UqoRNnB7Ay7XEFTm8zBXdhnGsDp569NvCk36TWQ/+kXpa/ZOEURChjjuHYI+zm6JzPM29JdiB 9nqbePN+ykRzq9krHi8Iv5+Z8U7V0UJSAi+pz9o1EKAwggZhMIIFSaADAgECAgMCYrwwDQYJKoZI hvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMTA0MDUxMzI2MzlaFw0x MjA0MDUwNTI0NTlaMIGLMSAwHgYDVQQNExczOTcwMzgtMERQVUxjNkYzaWMyMUpFZzEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRpZmlj YXRlIE1lbWJlcjEcMBoGCSqGSIb3DQEJARYNcGV0ZUBucnRoLm9yZzCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANbVcgdCjicZS++yJei+f1kjgeD2sajiOrPf6ZOur6v0v8kFtUIVhHsv zPeEDqbXyiYsKXavHWNeB8YCN1Ad6pA6MKjAhQ8MOYLaenqxelPwCeMc9uJH60DZLbqz717ynp5e 3Rs7KweE2HbNsSjZamoDuKCTkfJKDcFVTAxTARY9wm4kCwOBBO8llrmWlTU7WIy8MkzCknJfgJfV f9xFdheXPB1cVl6pnfWORp1jklj62ZPLO72N6W90W0mPr2S8lybQvA17TsWrTDQFBpYPDb+lA2Jk 57R8iU8LT+7c+9leTGzfy69y5hUgufiffgd/qhkYWNnCezjFGLpqF2E2LXkCAwEAAaOCAskwggLF MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUIbiZ6zWvXScuM1pP5IDL9Zt1TbQwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO 8tS4UYIwGAYDVR0RBBEwD4ENcGV0ZUBucnRoLm9yZzCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYB BAGBtTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0 eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9wb2xpY3kucGRmMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAIdJ6SsJkgsDhnaFM uckBAWaDQ74EMq19dcqgciITpJuQjzT6y4HFjfHryaAnyp22AhUwvBqG2VQBh0LutuMqVcfKGHgP OwkmTouOPlP32HtPP8/PuhJauL0AXscT+J1i2tDx6DrSrCoi+1Rq3GCZckaOtmgoOtyIndgRa7dG 2oGgosyx0RZpxKRnFJXjnAUox+Vbisno7RPqRohp6AwfXBxzIa/FhJ6SbtSqhE2cHsDLtcQVObzM Fd2GcawOnnr028KTfpNZD/6Relr9k4RREKGOO4dgj7ObonM8zb0l2IH2ept4837KRHOr2SseLwi/ n5nxTtXRQlICL6nP2jUQoDGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwJivDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xMTExMjEyMTMxMzlaMCMGCSqGSIb3DQEJBDEWBBSNvDgTox2qG5aGRuPIS5zMxcu2 czCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwJivDCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAmK8MA0G CSqGSIb3DQEBAQUABIIBAI8E75Dswg4dAC2TjdgfzefdvUqluEwyOvIA0kdiskpYAktF3v6oNm+D vcYMcruaJL/puCtiqUyuS3IzKNzeNX9gdApOeiecGUiEmSi/aVUECLj3xQReHDOtyAcamxSDlyHH 0uYBSz9CO8/5dmwx2jAUGIw4UdYN4qJQxVnjhJUUDotkTPLKGJXCs6GdvK20BgzltNP9wKOips3a uHZmGu8MjZACci74kAoaS53Qw0WwtKw2AwBGMvAEqlqiXjI5AHVeNtkpdvTJnusupuS+xdfGEiVE 631k1PWWCoeSFqDc4DeKTuANltYMXiTyxMNF+TpgoXLlzBKGays8IZT77WwAAAAAAAA= --=-mnwHBEfc3tlWJhlnwJ0v-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 22:35:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B593E1065672 for ; Mon, 21 Nov 2011 22:35:18 +0000 (UTC) (envelope-from pete@nrth.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7E74C8FC16 for ; Mon, 21 Nov 2011 22:35:18 +0000 (UTC) Received: from cpc4-nrte22-2-0-cust419.8-4.cable.virginmedia.com ([86.22.217.164] helo=tooms.nrth.lab) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RScSL-0001WM-KS for freebsd-net@freebsd.org; Mon, 21 Nov 2011 22:35:17 +0000 Received: from purity.nrth.lab ([10.20.30.5]) by tooms.nrth.lab with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RScSK-0000Vt-I2 for freebsd-net@freebsd.org; Mon, 21 Nov 2011 22:35:16 +0000 Received: from localhost.nrth.lab ([127.0.0.1] helo=purity.nrth.lab) by purity.nrth.lab with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RScSM-0002ES-83 for freebsd-net@freebsd.org; Mon, 21 Nov 2011 22:35:18 +0000 Received: (from pete@localhost) by purity.nrth.lab (8.14.4/8.14.4/Submit) id pALMZIfh008583 for freebsd-net@freebsd.org; Mon, 21 Nov 2011 22:35:18 GMT (envelope-from pete@nrth.org) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.22.217.164 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/liOuJ/rNXQ4BCKPnYuN4zapQhedoMI8M= From: Pete To: freebsd-net@freebsd.org Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-x/5bP/gamX77mx/C73dQ" Organization: nrth.org Date: Mon, 21 Nov 2011 22:35:18 +0000 Message-ID: <1321914918.6148.20.camel@purity.nrth.lab> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Subject: Re: Restarting Network Services Without Rebooting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 22:35:18 -0000 --=-x/5bP/gamX77mx/C73dQ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2011-11-21 at 13:54 -0800, Robison, Dave wrote: > try >=20 > sh /etc/netstart This worked a treat. Thank you. Regards, Pete. --=-x/5bP/gamX77mx/C73dQ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITAjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGYTCCBUmg AwIBAgIDAmK8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNDA1MTMyNjM5WhcNMTIwNDA1MDUyNDU5WjCBizEgMB4GA1UEDRMXMzk3MDM4LTBEUFVMYzZG M2ljMjFKRWcxHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxHDAaBgkqhkiG9w0BCQEWDXBldGVAbnJ0aC5vcmcw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW1XIHQo4nGUvvsiXovn9ZI4Hg9rGo4jqz 3+mTrq+r9L/JBbVCFYR7L8z3hA6m18omLCl2rx1jXgfGAjdQHeqQOjCowIUPDDmC2np6sXpT8Anj HPbiR+tA2S26s+9e8p6eXt0bOysHhNh2zbEo2WpqA7igk5HySg3BVUwMUwEWPcJuJAsDgQTvJZa5 lpU1O1iMvDJMwpJyX4CX1X/cRXYXlzwdXFZeqZ31jkadY5JY+tmTyzu9jelvdFtJj69kvJcm0LwN e07Fq0w0BQaWDw2/pQNiZOe0fIlPC0/u3PvZXkxs38uvcuYVILn4n34Hf6oZGFjZwns4xRi6ahdh Ni15AgMBAAGjggLJMIICxTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFCG4mes1r10nLjNaT+SAy/WbdU20MB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBgGA1UdEQQRMA+BDXBldGVAbnJ0aC5vcmcwggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20v aW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGR TGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhl IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8v Y3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUF BzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNh LmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQAD ggEBACHSekrCZILA4Z2hTLnJAQFmg0O+BDKtfXXKoHIiE6SbkI80+suBxY3x68mgJ8qdtgIVMLwa htlUAYdC7rbjKlXHyhh4DzsJJk6Ljj5T99h7Tz/Pz7oSWri9AF7HE/idYtrQ8eg60qwqIvtUatxg mXJGjrZoKDrciJ3YEWu3RtqBoKLMsdEWacSkZxSV45wFKMflW4rJ6O0T6kaIaegMH1wccyGvxYSe km7UqoRNnB7Ay7XEFTm8zBXdhnGsDp569NvCk36TWQ/+kXpa/ZOEURChjjuHYI+zm6JzPM29JdiB 9nqbePN+ykRzq9krHi8Iv5+Z8U7V0UJSAi+pz9o1EKAwggZhMIIFSaADAgECAgMCYrwwDQYJKoZI hvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMTA0MDUxMzI2MzlaFw0x MjA0MDUwNTI0NTlaMIGLMSAwHgYDVQQNExczOTcwMzgtMERQVUxjNkYzaWMyMUpFZzEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRpZmlj YXRlIE1lbWJlcjEcMBoGCSqGSIb3DQEJARYNcGV0ZUBucnRoLm9yZzCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANbVcgdCjicZS++yJei+f1kjgeD2sajiOrPf6ZOur6v0v8kFtUIVhHsv zPeEDqbXyiYsKXavHWNeB8YCN1Ad6pA6MKjAhQ8MOYLaenqxelPwCeMc9uJH60DZLbqz717ynp5e 3Rs7KweE2HbNsSjZamoDuKCTkfJKDcFVTAxTARY9wm4kCwOBBO8llrmWlTU7WIy8MkzCknJfgJfV f9xFdheXPB1cVl6pnfWORp1jklj62ZPLO72N6W90W0mPr2S8lybQvA17TsWrTDQFBpYPDb+lA2Jk 57R8iU8LT+7c+9leTGzfy69y5hUgufiffgd/qhkYWNnCezjFGLpqF2E2LXkCAwEAAaOCAskwggLF MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUIbiZ6zWvXScuM1pP5IDL9Zt1TbQwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO 8tS4UYIwGAYDVR0RBBEwD4ENcGV0ZUBucnRoLm9yZzCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYB BAGBtTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0 eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9wb2xpY3kucGRmMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAIdJ6SsJkgsDhnaFM uckBAWaDQ74EMq19dcqgciITpJuQjzT6y4HFjfHryaAnyp22AhUwvBqG2VQBh0LutuMqVcfKGHgP OwkmTouOPlP32HtPP8/PuhJauL0AXscT+J1i2tDx6DrSrCoi+1Rq3GCZckaOtmgoOtyIndgRa7dG 2oGgosyx0RZpxKRnFJXjnAUox+Vbisno7RPqRohp6AwfXBxzIa/FhJ6SbtSqhE2cHsDLtcQVObzM Fd2GcawOnnr028KTfpNZD/6Relr9k4RREKGOO4dgj7ObonM8zb0l2IH2ept4837KRHOr2SseLwi/ n5nxTtXRQlICL6nP2jUQoDGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwJivDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xMTExMjEyMjM1MThaMCMGCSqGSIb3DQEJBDEWBBRTsDUeR2QU18TtPOh+ElfVmDgQ PzCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwJivDCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAmK8MA0G CSqGSIb3DQEBAQUABIIBAEAzQlDdCXIFNuFoQULJguGkgxBhSGp4wPtCo/0olTqSl8YPP6q7mSTU rP6kkVCLfuziUcnKH7NYCmVvRNnuDLRUL0Q0NX1rINiQ8foT1rPbJy1i9heUm0pKf7EiYmWRua4m O/mhjq3lG1JBNxpKduLKGR15XOyCeJejhUUe2rImlldACaxip1ykO/Pqoqh4TLHiIcUSp/O40La6 9xRtW6jd4m6tOkxChY1CX7ws4EmuXQ3UTQRUNqhS6QuvlnfjmzEdKmkawpvZQpClPgDA2zHPxUKM 3KjnNPrxSHEVaufBty9TMN43CC9mgBi7uNKzGHowxSlKfIisTc4xvFhQ6gwAAAAAAAA= --=-x/5bP/gamX77mx/C73dQ-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 22 09:55:36 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4409106564A for ; Tue, 22 Nov 2011 09:55:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 603548FC13 for ; Tue, 22 Nov 2011 09:55:35 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAM9XxIA009154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Nov 2011 11:34:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAM9XxUo038019; Tue, 22 Nov 2011 11:33:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAM9Xvs2038018; Tue, 22 Nov 2011 11:33:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Nov 2011 11:33:57 +0200 From: Kostik Belousov To: "Paul B. Mahol" Message-ID: <20111122093357.GJ50300@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9EaoY5q4DBbNhnWp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: net Subject: Re: [PATCH] ndis: safe fpu on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 09:55:37 -0000 --9EaoY5q4DBbNhnWp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 21, 2011 at 03:49:16PM +0000, Paul B. Mahol wrote: > Hi, >=20 > This patch should fix panic on amd64 when using ndis with drivers > which make use of fpu registers. Do not allocate fpu_kern_ctx on stack. Its size is 528 bytes on amd64 right now, and potentially can grow after AVX support is finished. --9EaoY5q4DBbNhnWp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7LbIUACgkQC3+MBN1Mb4i9XwCgu2RECzSFo3LnNSIIfE+o1c2f 0n8AoOVq/oemIH8gjI1/Ae7jPmPn38c8 =Ieg1 -----END PGP SIGNATURE----- --9EaoY5q4DBbNhnWp-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 22 06:59:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA131065674 for ; Tue, 22 Nov 2011 06:59:18 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f58.mail.ru (f58.mail.ru [217.69.128.75]) by mx1.freebsd.org (Postfix) with ESMTP id 759248FC0A for ; Tue, 22 Nov 2011 06:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=Q5pJEvIEUxEZxcYlDA6pKZUwilnPXrDGkDwhQ0zd4QA=; b=lPrwbTDW4JyHFT3CVkDJl2ozXWS7zICQ0+yU/394QCz9jdH0DfTts/A1iGE05OjAIlPbZOH5HfMhnghyl7dnbPMQtVuW46lc/7mWhfYuE5NUjP4nD4iX1GlPeTbkYfvT; Received: from mail by f58.mail.ru with local id 1RSkK2-0004kJ-00; Tue, 22 Nov 2011 10:59:14 +0400 Received: from [95.32.146.70] by e.mail.ru with HTTP; Tue, 22 Nov 2011 10:59:14 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: =?UTF-8?B?WW9uZ0h5ZW9uIFBZVU4=?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [95.32.146.70] Date: Tue, 22 Nov 2011 10:59:14 +0400 References: <20111101180135.GD6914@michelle.cdnetworks.com> <20111102020532.GF6914@michelle.cdnetworks.com> In-Reply-To: <20111102020532.GF6914@michelle.cdnetworks.com> X-Priority: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Tue, 22 Nov 2011 12:12:08 +0000 Cc: freebsd-net@freebsd.org Subject: Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 06:59:18 -0000 SGkhIFNvbWUgZGF5cyBiYWNrIEkgcHV0IGNhcmQgaW4gV2luNyBtYWNoaW5lLiAKV2luNyBoYW5n IG93biBuZXR3b3JrIHN1YnN5c3RlbSBpZiBjb25uZWN0ZWQgdG8gZ2lnYWJpdCBzd2l0Y2guIApJ IHRyaWVkIGxhc3QgbmlnaHQgeW91ciBwYXRjaGVzLiBOb3cgd2hlbiBwdXQgaW4gZ2lnYWJpdCBz d2l0Y2ggbm8gaGFuZ3Mgb3IgZXJyb3JzLCAKYnV0IGxpbmsgKGF1dG9kZXRlY3QpIDEwMG1iaXQv cyBhbmQgd29yayBnb29kLiAKSSB0aGluayBJIGJvdWdodCBidWdneSBuZXR3b3JrIGNhcmRzIDoo KC4KCgoKSW5kZXg6IHN5cy9kZXYvbWlpL2lwMTAwMHBoeS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9k ZXYvbWlpL2lwMTAwMHBoeS5jCShyZXZpc2lvbiAyMjc1MDEpCisrKyBzeXMvZGV2L21paS9pcDEw MDBwaHkuYwkod29ya2luZyBjb3B5KQpAQCAtMzI0LDcgKzMyNCw2IEBACiAJUEhZX1dSSVRFKHNj LCBJUDEwMDBQSFlfTUlJX0FOQVIsIHJlZyB8IElQMTAwMFBIWV9BTkFSX0NTTUEpOwogCiAJcmVn ID0gSVAxMDAwUEhZXzEwMDBDUl8xMDAwVCB8IElQMTAwMFBIWV8xMDAwQ1JfMTAwMFRfRkRYOwot CXJlZyB8PSBJUDEwMDBQSFlfMTAwMENSX01BU1RFUjsKIAlQSFlfV1JJVEUoc2MsIElQMTAwMFBI WV9NSUlfMTAwMENSLCByZWcpOwogCVBIWV9XUklURShzYywgSVAxMDAwUEhZX01JSV9CTUNSLCAo SVAxMDAwUEhZX0JNQ1JfRkRYIHwKIAkgICAgSVAxMDAwUEhZX0JNQ1JfQVVUT0VOIHwgSVAxMDAw UEhZX0JNQ1JfU1RBUlRORUcpKTsKCgpJbmRleDogc3lzL2Rldi92Z2UvaWZfdmdlLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2Rldi92Z2UvaWZfdmdlLmMJKHJldmlzaW9uIDIyNzUwMSkKKysrIHN5cy9k ZXYvdmdlL2lmX3ZnZS5jCSh3b3JraW5nIGNvcHkpCkBAIC0xNzMsNiArMTczLDcgQEAKIHN0YXRp YyB2b2lkCXZnZV9mcmVlYnVmcyhzdHJ1Y3QgdmdlX3NvZnRjICopOwogc3RhdGljIHZvaWQJdmdl X2lmbWVkaWFfc3RzKHN0cnVjdCBpZm5ldCAqLCBzdHJ1Y3QgaWZtZWRpYXJlcSAqKTsKIHN0YXRp YyBpbnQJdmdlX2lmbWVkaWFfdXBkKHN0cnVjdCBpZm5ldCAqKTsKK3N0YXRpYyBpbnQJdmdlX2lm bWVkaWFfdXBkX2xvY2tlZChzdHJ1Y3QgdmdlX3NvZnRjICopOwogc3RhdGljIHZvaWQJdmdlX2lu aXQodm9pZCAqKTsKIHN0YXRpYyB2b2lkCXZnZV9pbml0X2xvY2tlZChzdHJ1Y3QgdmdlX3NvZnRj ICopOwogc3RhdGljIHZvaWQJdmdlX2ludHIodm9pZCAqKTsKQEAgLTE4MCw3ICsxODEsNiBAQAog c3RhdGljIGludAl2Z2VfaW9jdGwoc3RydWN0IGlmbmV0ICosIHVfbG9uZywgY2FkZHJfdCk7CiBz dGF0aWMgdm9pZAl2Z2VfbGlua19zdGF0Y2hnKHZvaWQgKik7CiBzdGF0aWMgaW50CXZnZV9taWli dXNfcmVhZHJlZyhkZXZpY2VfdCwgaW50LCBpbnQpOwotc3RhdGljIHZvaWQJdmdlX21paWJ1c19z dGF0Y2hnKGRldmljZV90KTsKIHN0YXRpYyBpbnQJdmdlX21paWJ1c193cml0ZXJlZyhkZXZpY2Vf dCwgaW50LCBpbnQsIGludCk7CiBzdGF0aWMgdm9pZAl2Z2VfbWlpcG9sbF9zdGFydChzdHJ1Y3Qg dmdlX3NvZnRjICopOwogc3RhdGljIHZvaWQJdmdlX21paXBvbGxfc3RvcChzdHJ1Y3QgdmdlX3Nv ZnRjICopOwpAQCAtMTkwLDYgKzE5MCw3IEBACiBzdGF0aWMgaW50CXZnZV9yeF9saXN0X2luaXQo c3RydWN0IHZnZV9zb2Z0YyAqKTsKIHN0YXRpYyBpbnQJdmdlX3J4ZW9mKHN0cnVjdCB2Z2Vfc29m dGMgKiwgaW50KTsKIHN0YXRpYyB2b2lkCXZnZV9yeGZpbHRlcihzdHJ1Y3QgdmdlX3NvZnRjICop Oworc3RhdGljIHZvaWQJdmdlX3NldG1lZGlhKHN0cnVjdCB2Z2Vfc29mdGMgKik7CiBzdGF0aWMg dm9pZAl2Z2Vfc2V0dmxhbihzdHJ1Y3QgdmdlX3NvZnRjICopOwogc3RhdGljIHZvaWQJdmdlX3Nl dHdvbChzdHJ1Y3QgdmdlX3NvZnRjICopOwogc3RhdGljIHZvaWQJdmdlX3N0YXJ0KHN0cnVjdCBp Zm5ldCAqKTsKQEAgLTIxOCw3ICsyMTksNiBAQAogCS8qIE1JSSBpbnRlcmZhY2UgKi8KIAlERVZN RVRIT0QobWlpYnVzX3JlYWRyZWcsCXZnZV9taWlidXNfcmVhZHJlZyksCiAJREVWTUVUSE9EKG1p aWJ1c193cml0ZXJlZywJdmdlX21paWJ1c193cml0ZXJlZyksCi0JREVWTUVUSE9EKG1paWJ1c19z dGF0Y2hnLAl2Z2VfbWlpYnVzX3N0YXRjaGcpLAogCiAJeyAwLCAwIH0KIH07CkBAIC0xMDk5LDEw ICsxMDk5LDExIEBACiAJCWdvdG8gZmFpbDsKIAl9CiAKKwl2Z2VfbWlpcG9sbF9zdGFydChzYyk7 CiAJLyogRG8gTUlJIHNldHVwICovCiAJZXJyb3IgPSBtaWlfYXR0YWNoKGRldiwgJnNjLT52Z2Vf bWlpYnVzLCBpZnAsIHZnZV9pZm1lZGlhX3VwZCwKIAkgICAgdmdlX2lmbWVkaWFfc3RzLCBCTVNS X0RFRkNBUE1BU0ssIHNjLT52Z2VfcGh5YWRkciwgTUlJX09GRlNFVF9BTlksCi0JICAgIDApOwor CSAgICBNSUlGX0RPUEFVU0UpOwogCWlmIChlcnJvciAhPSAwKSB7CiAJCWRldmljZV9wcmludGYo ZGV2LCAiYXR0YWNoaW5nIFBIWXMgZmFpbGVkXG4iKTsKIAkJZ290byBmYWlsOwpAQCAtMTY2MCwz MCArMTY2MSw0MSBAQAogewogCXN0cnVjdCB2Z2Vfc29mdGMgKnNjOwogCXN0cnVjdCBpZm5ldCAq aWZwOwotCXN0cnVjdCBtaWlfZGF0YSAqbWlpOworCXVpbnQ4X3QgcGh5c3RzOwogCiAJc2MgPSB4 c2M7CiAJaWZwID0gc2MtPnZnZV9pZnA7CiAJVkdFX0xPQ0tfQVNTRVJUKHNjKTsKLQltaWkgPSBk ZXZpY2VfZ2V0X3NvZnRjKHNjLT52Z2VfbWlpYnVzKTsKIAotCW1paV9wb2xsc3RhdChtaWkpOwot CWlmICgoc2MtPnZnZV9mbGFncyAmIFZHRV9GTEFHX0xJTkspICE9IDApIHsKLQkJaWYgKCEobWlp LT5taWlfbWVkaWFfc3RhdHVzICYgSUZNX0FDVElWRSkpIHsKKwlwaHlzdHMgPSBDU1JfUkVBRF8x KHNjLCBWR0VfUEhZU1RTMCk7CisJaWYgKChwaHlzdHMgJiBWR0VfUEhZU1RTX1JFU0VUU1RTKSA9 PSAwKSB7CisJCWlmICgocGh5c3RzICYgVkdFX1BIWVNUU19MSU5LKSA9PSAwKSB7CiAJCQlzYy0+ dmdlX2ZsYWdzICY9IH5WR0VfRkxBR19MSU5LOwogCQkJaWZfbGlua19zdGF0ZV9jaGFuZ2Uoc2Mt PnZnZV9pZnAsCiAJCQkgICAgTElOS19TVEFURV9ET1dOKTsKLQkJfQotCX0gZWxzZSB7Ci0JCWlm IChtaWktPm1paV9tZWRpYV9zdGF0dXMgJiBJRk1fQUNUSVZFICYmCi0JCSAgICBJRk1fU1VCVFlQ RShtaWktPm1paV9tZWRpYV9hY3RpdmUpICE9IElGTV9OT05FKSB7CisJCX0gZWxzZSB7CiAJCQlz Yy0+dmdlX2ZsYWdzIHw9IFZHRV9GTEFHX0xJTks7CiAJCQlpZl9saW5rX3N0YXRlX2NoYW5nZShz Yy0+dmdlX2lmcCwKIAkJCSAgICBMSU5LX1NUQVRFX1VQKTsKKwkJCUNTUl9XUklURV8xKHNjLCBW R0VfQ1JDMiwgVkdFX0NSMl9GRFhfVFhGTE9XQ1RMX0VOQUJMRSB8CisJCQkgICAgVkdFX0NSMl9G RFhfUlhGTE9XQ1RMX0VOQUJMRSk7CisJCQlpZiAoKHBoeXN0cyAmIFZHRV9QSFlTVFNfRkRYKSAh PSAwKSB7CisJCQkJaWYgKChwaHlzdHMgJiBWR0VfUEhZU1RTX1RYRkxPV0NBUCkgIT0gMCkKKwkJ CQkJQ1NSX1dSSVRFXzEoc2MsIFZHRV9DUlMyLAorCQkJCQkgICAgVkdFX0NSMl9GRFhfVFhGTE9X Q1RMX0VOQUJMRSk7CisJCQkJaWYgKChwaHlzdHMgJiBWR0VfUEhZU1RTX1JYRkxPV0NBUCkgIT0g MCkKKwkJCQkJQ1NSX1dSSVRFXzEoc2MsIFZHRV9DUlMyLAorCQkJCQkgICAgVkdFX0NSMl9GRFhf UlhGTE9XQ1RMX0VOQUJMRSk7CisJCQl9CiAJCQlpZiAoIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+ aWZfc25kKSkKIAkJCQl2Z2Vfc3RhcnRfbG9ja2VkKGlmcCk7CiAJCX0KIAl9CisJLyoKKwkgKiBS ZXN0YXJ0IE1JSSBhdXRvLXBvbGxpbmcgYmVjYXVzZSBsaW5rIHN0YXRlIGNoYW5nZSBpbnRlcnJ1 cHQKKwkgKiB3aWxsIGRpc2FibGUgaXQuCisJICovCisJdmdlX21paXBvbGxfc3RhcnQoc2MpOwog fQogCiAjaWZkZWYgREVWSUNFX1BPTExJTkcKQEAgLTIwMjgsNiArMjA0MCw3IEBACiAJICovCiAJ dmdlX3N0b3Aoc2MpOwogCXZnZV9yZXNldChzYyk7CisJdmdlX21paXBvbGxfc3RhcnQoc2MpOwog CiAJLyoKIAkgKiBJbml0aWFsaXplIHRoZSBSWCBhbmQgVFggZGVzY3JpcHRvcnMgYW5kIG1idWZz LgpAQCAtMjA5OSwxMCArMjExMiwxNyBAQAogCXZnZV9yeGZpbHRlcihzYyk7CiAJdmdlX3NldHZs YW4oc2MpOwogCi0JLyogRW5hYmxlIGZsb3cgY29udHJvbCAqLworCS8qIEluaXRpYWxpemUgcGF1 c2UgdGltZXIuICovCisJQ1NSX1dSSVRFXzIoc2MsIFZHRV9UWF9QQVVTRV9USU1FUiwgMHhGRkZG KTsKKwkvKgorCSAqIEluaXRpYWxpemUgZmxvdyBjb250cm9sIHBhcmFtZXRlcnMuCisJICogIFRY IFhPTiBoaWdoIHRocmVzaG9sZCA6IDQ4CisJICogIFRYIHBhdXNlIGxvdyB0aHJlc2hvbGQgOiAy NAorCSAqICBEaXNhYmxlIGhhbGQtZHVwbGV4IGZsb3cgY29udHJvbAorCSAqLworCUNTUl9XUklU RV8xKHNjLCBWR0VfQ1JDMiwgMHhGRik7CisJQ1NSX1dSSVRFXzEoc2MsIFZHRV9DUlMyLCBWR0Vf Q1IyX1hPTl9FTkFCTEUgfCAweDBCKTsKIAotCUNTUl9XUklURV8xKHNjLCBWR0VfQ1JTMiwgMHg4 Qik7Ci0KIAkvKiBFbmFibGUganVtYm8gZnJhbWUgcmVjZXB0aW9uIChpZiBkZXNpcmVkKSAqLwog CiAJLyogU3RhcnQgdGhlIE1BQy4gKi8KQEAgLTIxMjksNyArMjE0OSw3IEBACiAJQ1NSX1dSSVRF XzEoc2MsIFZHRV9DUlMzLCBWR0VfQ1IzX0lOVF9HTVNLKTsKIAogCXNjLT52Z2VfZmxhZ3MgJj0g flZHRV9GTEFHX0xJTks7Ci0JbWlpX21lZGlhY2hnKG1paSk7CisJdmdlX2lmbWVkaWFfdXBkX2xv Y2tlZChzYyk7CiAKIAlpZnAtPmlmX2Rydl9mbGFncyB8PSBJRkZfRFJWX1JVTk5JTkc7CiAJaWZw LT5pZl9kcnZfZmxhZ3MgJj0gfklGRl9EUlZfT0FDVElWRTsKQEAgLTIxNDMsMTQgKzIxNjMsMjgg QEAKIHZnZV9pZm1lZGlhX3VwZChzdHJ1Y3QgaWZuZXQgKmlmcCkKIHsKIAlzdHJ1Y3QgdmdlX3Nv ZnRjICpzYzsKLQlzdHJ1Y3QgbWlpX2RhdGEgKm1paTsKIAlpbnQgZXJyb3I7CiAKIAlzYyA9IGlm cC0+aWZfc29mdGM7CiAJVkdFX0xPQ0soc2MpOworCWVycm9yID0gdmdlX2lmbWVkaWFfdXBkX2xv Y2tlZChzYyk7CisJVkdFX1VOTE9DSyhzYyk7CisKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3Rh dGljIGludAordmdlX2lmbWVkaWFfdXBkX2xvY2tlZChzdHJ1Y3QgdmdlX3NvZnRjICpzYykKK3sK KwlzdHJ1Y3QgbWlpX2RhdGEgKm1paTsKKwlzdHJ1Y3QgbWlpX3NvZnRjICptaWlzYzsKKwlpbnQg ZXJyb3I7CisKIAltaWkgPSBkZXZpY2VfZ2V0X3NvZnRjKHNjLT52Z2VfbWlpYnVzKTsKKwlMSVNU X0ZPUkVBQ0gobWlpc2MsICZtaWktPm1paV9waHlzLCBtaWlfbGlzdCkKKwkJUEhZX1JFU0VUKG1p aXNjKTsKKwl2Z2Vfc2V0bWVkaWEoc2MpOwogCWVycm9yID0gbWlpX21lZGlhY2hnKG1paSk7Ci0J VkdFX1VOTE9DSyhzYyk7CiAKIAlyZXR1cm4gKGVycm9yKTsKIH0KQEAgLTIxNzksMTMgKzIyMTMs MTEgQEAKIH0KIAogc3RhdGljIHZvaWQKLXZnZV9taWlidXNfc3RhdGNoZyhkZXZpY2VfdCBkZXYp Cit2Z2Vfc2V0bWVkaWEoc3RydWN0IHZnZV9zb2Z0YyAqc2MpCiB7Ci0Jc3RydWN0IHZnZV9zb2Z0 YyAqc2M7CiAJc3RydWN0IG1paV9kYXRhICptaWk7CiAJc3RydWN0IGlmbWVkaWFfZW50cnkgKmlm ZTsKIAotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwogCW1paSA9IGRldmljZV9nZXRfc29m dGMoc2MtPnZnZV9taWlidXMpOwogCWlmZSA9IG1paS0+bWlpX21lZGlhLmlmbV9jdXI7CiAKQEAg LTIyMTksNyArMjI1MSw3IEBACiAJCX0KIAkJYnJlYWs7CiAJZGVmYXVsdDoKLQkJZGV2aWNlX3By aW50ZihkZXYsICJ1bmtub3duIG1lZGlhIHR5cGU6ICV4XG4iLAorCQlkZXZpY2VfcHJpbnRmKHNj LT52Z2VfZGV2LCAidW5rbm93biBtZWRpYSB0eXBlOiAleFxuIiwKIAkJICAgIElGTV9TVUJUWVBF KGlmZS0+aWZtX21lZGlhKSk7CiAJCWJyZWFrOwogCX0KQEAgLTI3NzIsNiArMjgwNCw5IEBACiAJ CQlicmVhazsKIAkJfQogCX0KKwkvKiBDbGVhciBmb3JjZWQgTUFDIHNwZWVkL2R1cGxleCBjb25m aWd1cmF0aW9uLiAqLworCUNTUl9DTFJCSVRfMShzYywgVkdFX0RJQUdDVEwsIFZHRV9ESUFHQ1RM X01BQ0ZPUkNFKTsKKwlDU1JfQ0xSQklUXzEoc2MsIFZHRV9ESUFHQ1RMLCBWR0VfRElBR0NUTF9G RFhGT1JDRSk7CiAJdmdlX21paWJ1c193cml0ZXJlZyhzYy0+dmdlX2Rldiwgc2MtPnZnZV9waHlh ZGRyLCBNSUlfMTAwVDJDUiwgMCk7CiAJdmdlX21paWJ1c193cml0ZXJlZyhzYy0+dmdlX2Rldiwg c2MtPnZnZV9waHlhZGRyLCBNSUlfQU5BUiwKIAkgICAgQU5BUl9UWF9GRCB8IEFOQVJfVFggfCBB TkFSXzEwX0ZEIHwgQU5BUl8xMCB8IEFOQVJfQ1NNQSk7Cgo= From owner-freebsd-net@FreeBSD.ORG Tue Nov 22 18:26:26 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FE8F1065674 for ; Tue, 22 Nov 2011 18:26:26 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0438FC0C for ; Tue, 22 Nov 2011 18:26:25 +0000 (UTC) Received: by vcbfl10 with SMTP id fl10so794777vcb.13 for ; Tue, 22 Nov 2011 10:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dyA1h8WldVtcNwy9l0PtMjoOSezJOlOVabFv+kHh7I8=; b=LODM2cfVC5FtPxyHFBgBgC6hOqUvwV7byC3tN+ZzYfqFLq27fULkLq8qskudWq/mPp Z9MHcE8/nujLuCQ7dhlKvSXuUi3qqVcoP0PMm5FbsSDpv/9LCiQU9LU3T4dnVERSroMY egZuWlRclrNoyI3rrRKkFNiWY7b4DLqyYWCOA= MIME-Version: 1.0 Received: by 10.52.29.207 with SMTP id m15mr21462824vdh.100.1321986384757; Tue, 22 Nov 2011 10:26:24 -0800 (PST) Received: by 10.52.187.102 with HTTP; Tue, 22 Nov 2011 10:26:24 -0800 (PST) In-Reply-To: <20111122093357.GJ50300@deviant.kiev.zoral.com.ua> References: <20111122093357.GJ50300@deviant.kiev.zoral.com.ua> Date: Tue, 22 Nov 2011 18:26:24 +0000 Message-ID: From: "Paul B. Mahol" To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: net Subject: Re: [PATCH] ndis: safe fpu on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 18:26:26 -0000 On 11/22/11, Kostik Belousov wrote: > On Mon, Nov 21, 2011 at 03:49:16PM +0000, Paul B. Mahol wrote: >> Hi, >> >> This patch should fix panic on amd64 when using ndis with drivers >> which make use of fpu registers. > Do not allocate fpu_kern_ctx on stack. Its size is 528 bytes on amd64 right > now, and potentially can grow after AVX support is finished. So I need to introduce locks and allocate fpu_kern_ctx per CPU because otherwise memory leaks are possible. From owner-freebsd-net@FreeBSD.ORG Tue Nov 22 19:48:35 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 925681065670 for ; Tue, 22 Nov 2011 19:48:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B86D08FC08 for ; Tue, 22 Nov 2011 19:48:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pAMJmX0B011209; Tue, 22 Nov 2011 23:48:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pAMJmXQ6011208; Tue, 22 Nov 2011 23:48:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 22 Nov 2011 23:48:33 +0400 From: Gleb Smirnoff To: Nikos Vassiliadis Message-ID: <20111122194833.GN96616@FreeBSD.org> References: <4EC63D37.4050105@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EC63D37.4050105@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 19:48:35 -0000 Nikos, On Fri, Nov 18, 2011 at 01:10:47PM +0200, Nikos Vassiliadis wrote: N> I was playing with lagg and found out a kernel panic. Here is N> the backtrace: N> > #5 0xc0a65613 in kdb_trap (type=12, code=0, tf=0xc3f1bb1c) at /usr/src/sys/kern/subr_kdb.c:625 N> > #6 0xc0dbbc1f in trap_fatal (frame=0xc3f1bb1c, eva=24) at /usr/src/sys/i386/i386/trap.c:966 N> > #7 0xc0dbbd1c in trap_pfault (frame=0xc3f1bb1c, usermode=0, eva=24) at /usr/src/sys/i386/i386/trap.c:839 N> > #8 0xc0dbc9b5 in trap (frame=0xc3f1bb1c) at /usr/src/sys/i386/i386/trap.c:558 N> > #9 0xc0da54fc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 N> > #10 0xc0b496eb in arprequest (ifp=0xc42c5400, sip=0xc46625ac, tip=0xc46625ac, enaddr=0xc41d3d9b "\b") at /usr/src/sys/netinet/if_ether.c:264 N> > #11 0xc0b4acef in arp_ifinit (ifp=0xc42c5400, ifa=0xc4662500) at /usr/src/sys/netinet/if_ether.c:880 N> > #12 0xc0aea7ae in if_setlladdr (ifp=0xc42c5400, lladdr=0xc49ac204 "\b", len=6) at /usr/src/sys/net/if.c:3317 N> > #13 0xc4bb7bd3 in lagg_port_setlladdr (arg=0xc4a47b00, pending=1) at /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:476 N> > #14 0xc0a730fb in taskqueue_run_locked (queue=0xc42f3400) at /usr/src/sys/kern/subr_taskqueue.c:308 N> > #15 0xc0a7321f in taskqueue_run (queue=0xc42f3400) at /usr/src/sys/kern/subr_taskqueue.c:322 N> > #16 0xc0a732d3 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:418 N> N> It's triggered with these commands: N> ifconfig em2 10.0.156.1/24 N> ifconfig em3 10.0.156.2/24 N> i=`ifconfig lagg create` N> ifconfig $i laggport em2 laggport em3 N> ifconfig $i 10.0.156.3/24 N> N> Just reporting, should I fill a PR? Can't reproduce this on head. May be some additional measures are needed? Traffic? Or LACP capable switch? My log: behemoth# ifconfig igb0: flags=8843 metric 0 mtu 1500 options=401bb ether 00:25:90:03:0e:fa inet6 fe80::225:90ff:fe03:efa%igb0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active igb1: flags=8802 metric 0 mtu 1500 options=401bb ether 00:25:90:03:0e:fb nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 behemoth# ifconfig igb0 10.0.156.1/24 behemoth# ifconfig igb1 10.0.156.2/24 behemoth# behemoth# ifconfig lagg0 create behemoth# ifconfig lagg0 laggport igb0 laggport igb1 behemoth# ifconfig lagg0 10.0.156.3/24 behemoth# ifconfig igb0: flags=8843 metric 0 mtu 1500 options=401bb ether 00:25:90:03:0e:fa inet6 fe80::225:90ff:fe03:efa%igb0 prefixlen 64 scopeid 0x1 inet 10.0.156.1 netmask 0xffffff00 broadcast 10.0.156.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active igb1: flags=8843 metric 0 mtu 1500 options=401bb ether 00:25:90:03:0e:fa inet 10.0.156.2 netmask 0xffffff00 broadcast 10.0.156.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 lagg0: flags=8843 metric 0 mtu 1500 options=401bb ether 00:25:90:03:0e:fa inet 10.0.156.3 netmask 0xffffff00 broadcast 10.0.156.255 nd6 options=29 media: Ethernet autoselect status: active laggproto failover laggport: igb1 flags=0<> laggport: igb0 flags=5 behemoth# -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Nov 22 21:38:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23BFC106566B for ; Tue, 22 Nov 2011 21:38:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF38A8FC13 for ; Tue, 22 Nov 2011 21:38:45 +0000 (UTC) Received: by iakl21 with SMTP id l21so1138397iak.13 for ; Tue, 22 Nov 2011 13:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yDKwrfrmUzJj6uDb0vp81cZScRDQnjIPli0iYqjvWIc=; b=S8KBoWTYgaT7QLJQEwxquyrL+/3MyLyH43XKAPKle0n95tyJTm7lkVOLoZUIlLQu0S TUy/ypdDHrndlWg3zxzxLJwP8wQLhRMvopCXFADLt2bBlfX6OQJPUlCkwSnYdMlb+sj+ XLmgJ9p7oUdpiKn094Qj2WftaCVdOn6bYcb3s= Received: by 10.231.62.144 with SMTP id x16mr5651926ibh.2.1321997924922; Tue, 22 Nov 2011 13:38:44 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id wo4sm36278304igc.5.2011.11.22.13.38.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:38:43 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 22 Nov 2011 13:38:18 -0800 From: YongHyeon PYUN Date: Tue, 22 Nov 2011 13:38:18 -0800 To: Andrey Smagin Message-ID: <20111122213818.GA7714@michelle.cdnetworks.com> References: <20111101180135.GD6914@michelle.cdnetworks.com> <20111102020532.GF6914@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 21:38:46 -0000 On Tue, Nov 22, 2011 at 10:59:14AM +0400, Andrey Smagin wrote: > Hi! Some days back I put card in Win7 machine. > Win7 hang own network subsystem if connected to gigabit switch. > I tried last night your patches. Now when put in gigabit switch no hangs or errors, > but link (autodetect) 100mbit/s and work good. > I think I bought buggy network cards :((. > Thanks. Committed to HEAD(r227828, r227835 and r227837). From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 10:11:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD75D1065674 for ; Wed, 23 Nov 2011 10:11:21 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA108FC13 for ; Wed, 23 Nov 2011 10:11:03 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id CEEBA9DC415; Wed, 23 Nov 2011 11:11:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> Date: Wed, 23 Nov 2011 11:10:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D60470E-CB00-4804-80BA-2866DE455F5B@sarenet.es> References: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> To: Nikolay Denev X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 10:11:21 -0000 On Nov 23, 2011, at 9:30 AM, Nikolay Denev wrote: > the RFC states : >=20 > Upon receiving a signed segment, the receiver must validate it by > calculating its own digest from the same data (using its own key) = and > comparing the two digest. A failing comparison must result in the > segment being dropped and must not produce any response back to the > sender. Logging the failure is probably advisable. >=20 >=20 > Anyways, this is clearly a problem that started manifesting itself = with recent FreeBSD versions, and I've > put "sysctl net.inet.tcp.signature_verify_input=3D0" in my sysctl.conf = which seems to help restore the old behavior. But this is not the behavior I'm seeing with other BGP implementations = for FreeBSD: Quagga or Bird. If I enable the TCP MD5 support in the kernel, I can't make OpenBGPD = work *unless* I enable TCP MD5 for OpenBGP. This is the difference. I have TCP MD5 enabled in the kernel, but I have = *not* set TCP MD5 for the BGP configuration. Telnet to bird: As you can see, I send a SYN, replies with SYN+ACK, etc. = The connection goes on. 10:58:24.772799 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [S], seq = 2862267556, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 299847 ecr 0], length 0 10:58:24.773165 IP 10.0.0.2.179 > 10.0.0.1.39653: Flags [S.], seq = 3040081633, ack 2862267557, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 2720641681 ecr 299847], length 0 10:58:24.773217 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [.], ack 1, win = 1040, options [nop,nop,TS val 299847 ecr 2720641681], length 0 10:58:24.773826 IP 10.0.0.2.179 > 10.0.0.1.39653: Flags [P.], seq 1:46, = ack 1, win 1040, options [nop,nop,TS val 2720641682 ecr 299847], length = 45: BGP, length: 45 10:58:24.873634 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [.], ack 46, win = 1040, options [nop,nop,TS val 299858 ecr 2720641682], length 0 10:58:26.869066 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [P.], seq 1:6, = ack 46, win 1040, options [nop,nop,TS val 300057 ecr 2720641682], length = 5: BGP, length: 5 Telnet to OpenBGPD: Note that tcp md5 has not been enabled in the = bgpd.conf file. As you can see, I start a normal telnet to port 179, and = its SYN+ACK has an md5 signature. 11:06:09.171925 IP 10.0.0.1.43701 > 10.0.0.2.179: Flags [S], seq = 3593070548, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 346287 ecr 0], length 0 11:06:09.172292 IP 10.0.0.2.179 > 10.0.0.1.43701: Flags [S.], seq = 4229135593, ack 3593070549, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 98634819 ecr 346287,nop,nop,md5shared secret not = supplied with -M, can't check - 00000000000000000000000000000000], = length 0 11:06:12.163527 IP 10.0.0.2.179 > 10.0.0.1.43701: Flags [S.], seq = 4229135593, ack 3593070549, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 98634819 ecr 346287,nop,nop,md5shared secret not = supplied with -M, can't check - 00000000000000000000000000000000], = length 0 11:06:12.163672 IP 10.0.0.1.43701 > 10.0.0.2.179: Flags [S], seq = 3593070548, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 346587 ecr 0], length 0 11:06:12.163848 IP 10.0.0.2.179 > 10.0.0.1.43701: Flags [S.], seq = 4229135593, ack 3593070549, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 98634819 ecr 346587,nop,nop,md5shared secret not = supplied with -M, can't check - 00000000000000000000000000000000], = length 0 Telnet to Quagga: As it can be expected, it replies to a SYN without MD5 = signature with a SYN+ACK without a MD5 signature. 11:08:51.439839 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [S], seq = 1550805830, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 235210 ecr 0], length 0 11:08:51.439944 IP 10.0.0.1.179 > 10.0.0.2.61150: Flags [S.], seq = 1912625633, ack 1550805831, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 2065055119 ecr 235210], length 0 11:08:51.440943 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [.], ack 1, win = 1040, options [nop,nop,TS val 235210 ecr 2065055119], length 0 11:08:53.550765 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [P.], seq 1:6, = ack 1, win 1040, options [nop,nop,TS val 235421 ecr 2065055119], length = 5: BGP, length: 5 11:08:53.551056 IP 10.0.0.1.179 > 10.0.0.2.61150: Flags [F.], seq 1, ack = 6, win 1040, options [nop,nop,TS val 2065055330 ecr 235421], length 0 11:08:53.552381 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [.], ack 2, win = 1040, options [nop,nop,TS val 235421 ecr 2065055330], length 0 11:08:53.552408 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [F.], seq 6, ack = 2, win 1040, options [nop,nop,TS val 235421 ecr 2065055330], length 0 11:08:53.552484 IP 10.0.0.1.179 > 10.0.0.2.61150: Flags [.], ack 7, win = 1040, options [nop,nop,TS val 2065055330 ecr 235421], length 0 Interestingly, OpenBGPD only fails in this scenario in the passive role. = In active role it has no problem. Borja. From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 11:09:56 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF8B51065670 for ; Wed, 23 Nov 2011 11:09:56 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.43]) by mx1.freebsd.org (Postfix) with SMTP id 2AF7A8FC15 for ; Wed, 23 Nov 2011 11:09:56 +0000 (UTC) Received: (qmail invoked by alias); 23 Nov 2011 11:09:52 -0000 Received: from adsl-9.109.242.133.tellas.gr (EHLO [192.168.73.193]) [109.242.133.9] by mail.gmx.com (mp-eu003) with SMTP; 23 Nov 2011 12:09:52 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX19k0FoPX2ZkjOBLzxQIpKbjbZ3p6ui8Ps3+Bu/21b azUxAs0dHzdShE Message-ID: <4ECCD46E.2060908@gmx.com> Date: Wed, 23 Nov 2011 13:09:34 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EC63D37.4050105@gmx.com> <20111122194833.GN96616@FreeBSD.org> In-Reply-To: <20111122194833.GN96616@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@FreeBSD.org Subject: Re: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 11:09:56 -0000 On 11/22/2011 9:48 PM, Gleb Smirnoff wrote: > Can't reproduce this on head. May be some additional measures are needed? Traffic? Just noticed that the panic does not happen using GENERIC. Here is my kernel configuration, if you want to dig deeper. include GENERIC ident LAB options VIMAGE options IPSEC device crypto options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options DUMMYNET options ALTQ option ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 11:22:06 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8529D106566C for ; Wed, 23 Nov 2011 11:22:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 09B258FC1C for ; Wed, 23 Nov 2011 11:22:05 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pANBM4OT019351; Wed, 23 Nov 2011 15:22:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pANBM4Gh019350; Wed, 23 Nov 2011 15:22:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Nov 2011 15:22:04 +0400 From: Gleb Smirnoff To: Nikos Vassiliadis Message-ID: <20111123112204.GY96616@glebius.int.ru> References: <4EC63D37.4050105@gmx.com> <20111122194833.GN96616@FreeBSD.org> <4ECCD46E.2060908@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4ECCD46E.2060908@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 11:22:06 -0000 On Wed, Nov 23, 2011 at 01:09:34PM +0200, Nikos Vassiliadis wrote: N> On 11/22/2011 9:48 PM, Gleb Smirnoff wrote: N> > Can't reproduce this on head. May be some additional measures are needed? Traffic? N> N> Just noticed that the panic does not happen using GENERIC. N> Here is my kernel configuration, if you want to dig deeper. N> N> include GENERIC N> ident LAB N> N> options VIMAGE N> options IPSEC N> device crypto N> N> options IPFIREWALL N> options IPFIREWALL_DEFAULT_TO_ACCEPT N> options IPFIREWALL_FORWARD N> options DUMMYNET N> N> options ALTQ N> option ALTQ_CBQ N> options ALTQ_RED N> options ALTQ_RIO N> options ALTQ_HFSC N> options ALTQ_CDNR N> options ALTQ_PRIQ I'd suspect VIMAGE. Can you please try w/o it and if it appears to be VIMAGE-related, then please file a PR. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 08:30:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9971065670 for ; Wed, 23 Nov 2011 08:30:19 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE7668FC0C for ; Wed, 23 Nov 2011 08:30:18 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1699308bkb.13 for ; Wed, 23 Nov 2011 00:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cRR9VOoTReHRaRi++FmIxX47AP2DQNVqmy8L6H1iHLI=; b=qFTtH0Dg0ydLj4oKkQLxz5BUQHcKSNGx1giTmrB4N+H83ZLslrRdvWq3Xr7v/gMcZv cVQLKZa5xniVdOanQveQFHQchXaRf7OPOTiSefPBg2d8tEGAUIzoQTfMnzN/ZU9wWA+/ g5rOddpgqPDpPwImchfKM1B8W40lDXyFf24hU= Received: by 10.204.156.219 with SMTP id y27mr22950568bkw.125.1322037016946; Wed, 23 Nov 2011 00:30:16 -0800 (PST) Received: from [192.168.254.99] ([94.185.236.184]) by mx.google.com with ESMTPS id x19sm21435938fag.5.2011.11.23.00.30.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 00:30:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Wed, 23 Nov 2011 10:30:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> References: To: Borja Marcos X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 23 Nov 2011 12:06:36 +0000 Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 08:30:19 -0000 On Nov 21, 2011, at 3:29 PM, Borja Marcos wrote: >=20 > (Sent to freebsd-bugs as well, copied here for discussion, if needed) >=20 >=20 >=20 >=20 > =09 > Sorry for the brief report and the scarce details. The f****ing form = insists on rejecting the captcha after one hour writing a report.=20 >=20 > So, in short: >=20 > If TCP_MD5 is available on the system, > options IPSEC > options TCP_SIGNATURE #include support for RFC 2385 > device crypto >=20 > Turns out openbgpd can't receive BGP connections.=20 >=20 > The error is in the session.c file, line 148, function = setup_listeners(u_int *la_cnt). >=20 > Code snippet: >=20 > opt =3D 1; > if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG, > &opt, sizeof(opt)) =3D=3D -1) { > if (errno =3D=3D ENOPROTOOPT) { /* system = w/o md5sig */ > log_warnx("md5sig not available, = disabling"); > sysdep.no_md5sig =3D 1; > } else > fatal("setsockopt TCP_MD5SIG"); > } >=20 >=20 > This is wrong. Regardless of the configuration, this code activates = TCP_MD5 for the socket and leaves it enabled. This is what happens: >=20 > 14:04:33.009212 IP 10.0.0.2.36610 > 10.0.0.1.179: Flags [S], seq = 1941690122, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 115224 ecr 0], length 0 > 14:04:33.009267 IP 10.0.0.1.179 > 10.0.0.2.36610: Flags [S.], seq = 2935503211, ack 1941690123, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 4192648161 ecr 115224,nop,nop,md5shared secret not = supplied with -M, can't check - a360f2c9a9f96a582ccbabe79418105c], = length 0 >=20 > The daemon receiving the connection is replying with TCP_MD5, even = though there's no TCP_MD5 option set in the bgpd.conf file. >=20 > Removing this code (or placing it outside of the loop, creating a = temporary socket just to enable TCP_MD5 on it and using it to detect the = availability of TCP_MD5) works: >=20 > 14:04:35.395447 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [S], seq = 366635408, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 220116 ecr 0], length 0 > 14:04:35.395490 IP 10.0.0.2.179 > 10.0.0.1.45119: Flags [S.], seq = 1226417253, ack 366635409, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 511187362 ecr 220116], length 0 > 14:04:35.395584 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [.], ack 1, = win 1040, options [nop,nop,TS val 220116 ecr 511187362], length 0 > 14:04:35.396072 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [P.], seq = 1:46, ack 1, win 1040, options [nop,nop,TS val 220116 ecr 511187362], = length 45: BGP, length: 45 > 14:04:35.397031 IP 10.0.0.2.179 > 10.0.0.1.45119: Flags [P.], seq = 1:50, ack 46, win 1040, options [nop,nop,TS val 511187362 ecr 220116], = length 49: BGP, length: 49 > 14:04:35.397381 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [P.], seq = 46:65, ack 50, win 1040, options [nop,nop,TS val 220116 ecr 511187362], = length 19: BGP, length: 19 >=20 >=20 >=20 >=20 > Sorry for the terse report. It was very detailed, but lost. >=20 >=20 > Borja. Hello, I'm seeing exactly the same problem with Quagga. Quagga's bgpd also seem to always set the TCP_MD5 socket option, and = newer freebsd 8.2 machines don't seem to be able to establish bgp sessions, probably due to the = recent TCP_MD5 fixes that enabled the TCP_MD5 checksum verification of incoming packets. Since both daemons do this, and I guess this works fine with Quagga = under Linux, I'm not sure that this is incorrect. The tcp(4) man page states : "The current default behavior for the system is to respond to a = system advertising this option with TCP-MD5; this may change." the RFC states : Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digest. A failing comparison must result in the segment being dropped and must not produce any response back to the sender. Logging the failure is probably advisable. Anyways, this is clearly a problem that started manifesting itself with = recent FreeBSD versions, and I've put "sysctl net.inet.tcp.signature_verify_input=3D0" in my sysctl.conf = which seems to help restore the old behavior. Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 12:43:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B365C106566B for ; Wed, 23 Nov 2011 12:43:07 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id 70F388FC14 for ; Wed, 23 Nov 2011 12:43:07 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id DAF5F9DC47C; Wed, 23 Nov 2011 13:43:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> Date: Wed, 23 Nov 2011 13:43:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> To: Nikolay Denev X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 12:43:07 -0000 On Nov 23, 2011, at 9:30 AM, Nikolay Denev wrote: > I'm seeing exactly the same problem with Quagga. > Quagga's bgpd also seem to always set the TCP_MD5 socket option, and = newer freebsd 8.2 machines > don't seem to be able to establish bgp sessions, probably due to the = recent TCP_MD5 fixes that enabled > the TCP_MD5 checksum verification of incoming packets. Hmm. A confusion? ;) The traces I've just sent show Quagga and Bird working well, OpenBGPD = failing. Borja. From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 13:17:22 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25A15106566B for ; Wed, 23 Nov 2011 13:17:22 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.43]) by mx1.freebsd.org (Postfix) with SMTP id 7475E8FC12 for ; Wed, 23 Nov 2011 13:17:21 +0000 (UTC) Received: (qmail invoked by alias); 23 Nov 2011 13:17:20 -0000 Received: from adsl-9.109.242.133.tellas.gr (EHLO [192.168.73.193]) [109.242.133.9] by mail.gmx.com (mp-eu002) with SMTP; 23 Nov 2011 14:17:20 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1/K5MFVvwXKODXgS/LZQ1cYnKSRJUcee/y2tIe2qe mO5kglFkNjkGfB Message-ID: <4ECCF257.9090801@gmx.com> Date: Wed, 23 Nov 2011 15:17:11 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EC63D37.4050105@gmx.com> <20111122194833.GN96616@FreeBSD.org> <4ECCD46E.2060908@gmx.com> <20111123112204.GY96616@glebius.int.ru> In-Reply-To: <20111123112204.GY96616@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@FreeBSD.org Subject: Re: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 13:17:22 -0000 On 11/23/2011 1:22 PM, Gleb Smirnoff wrote: > I'd suspect VIMAGE. Can you please try w/o it and if it appears to be VIMAGE-related, > then please file a PR. It seems VIMAGE related. I'll ask at virtualization@. Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 14:06:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DE5F1065674; Wed, 23 Nov 2011 14:06:36 +0000 (UTC) (envelope-from zec@fer.hr) Received: from munja.zvne.fer.hr (munja.zvne.fer.hr [161.53.66.248]) by mx1.freebsd.org (Postfix) with ESMTP id E99B38FC0A; Wed, 23 Nov 2011 14:06:35 +0000 (UTC) Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Nov 2011 14:54:29 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Nov 2011 14:54:29 +0100 From: Marko Zec To: freebsd-net@freebsd.org Date: Wed, 23 Nov 2011 14:53:37 +0100 User-Agent: KMail/1.9.10 References: <4EC63D37.4050105@gmx.com> <20111123112204.GY96616@glebius.int.ru> <4ECCF257.9090801@gmx.com> In-Reply-To: <4ECCF257.9090801@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201111231453.37900.zec@fer.hr> X-OriginalArrivalTime: 23 Nov 2011 13:54:29.0516 (UTC) FILETIME=[6BA114C0:01CCA9E7] Cc: Nikos Vassiliadis Subject: Re: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 14:06:36 -0000 On Wednesday 23 November 2011 14:17:11 Nikos Vassiliadis wrote: > On 11/23/2011 1:22 PM, Gleb Smirnoff wrote: > > I'd suspect VIMAGE. Can you please try w/o it and if it appears to be > > VIMAGE-related, then please file a PR. > > It seems VIMAGE related. I'll ask at virtualization@. =46rom the backtrace it looks like the curvnet context is not properly set = in a=20 timer-driven call graph originating at lagg_port_setlladdr(). Perhaps this (untested) patch could help: =2D-- //depot/user/zec/vimage_8/src/sys/net/if_lagg.c 2011-09-06=20 05:45:07.000000000 0000 +++ /u/marko/p4/zec/vimage_8/src/sys/net/if_lagg.c 2011-09-06=20 05:45:07.000000000 0000 @@ -468,7 +468,9 @@ ifp =3D llq->llq_ifp; =20 /* Set the link layer address */ + CURVNET_SET(ifp->if_vnet); error =3D if_setlladdr(ifp, llq->llq_lladdr, ETHER_ADDR_LEN= ); + CURVNET_RESTORE(); if (error) printf("%s: setlladdr failed on %s\n", __func__, ifp->if_xname); From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 14:46:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D064D106564A; Wed, 23 Nov 2011 14:46:36 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out7.libero.it (cp-out7.libero.it [212.52.84.107]) by mx1.freebsd.org (Postfix) with ESMTP id 535F28FC1B; Wed, 23 Nov 2011 14:46:36 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0205.4ECD04AE.0195,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.193.58) by cp-out7.libero.it (8.5.133) id 4E9539DD061C3FDC; Wed, 23 Nov 2011 15:35:26 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.5/8.14.4) with ESMTP id pANEZQTb005373; Wed, 23 Nov 2011 15:35:26 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4ECD04AE.8070309@netfence.it> Date: Wed, 23 Nov 2011 15:35:26 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.24) Gecko/20111110 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: if_xl on 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 14:46:36 -0000 Hello. Just to say today I upgraded from 8.1 to 8.2 and xl0 stopped working. It is detected: > xl0: <3Com 3c900B-COMBO Etherlink XL> port 0xd800-0xd87f mem 0xfdefe000-0xfdefe07f irq 17 at device 7.0 on pci1 > xl0: selecting 10baseT transceiver, half duplex > xl0: Ethernet address: 00:50:04:22:a9:c0 > xl0: [ITHREAD] I can "ifconfigure" it, but no packet will get in or out. This is not a problem for me, since I had another card available. However, if anyone is interested, I'm available for details or testing. bye av. From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 15:07:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60DEE1065673 for ; Wed, 23 Nov 2011 15:07:34 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.43]) by mx1.freebsd.org (Postfix) with SMTP id AF0D88FC0C for ; Wed, 23 Nov 2011 15:07:33 +0000 (UTC) Received: (qmail invoked by alias); 23 Nov 2011 15:07:32 -0000 Received: from adsl-9.109.242.133.tellas.gr (EHLO [192.168.73.193]) [109.242.133.9] by mail.gmx.com (mp-eu001) with SMTP; 23 Nov 2011 16:07:32 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX19X1OAzo/hX6FSd7uIZPCEBhNETSDqmZ42J9Bo1l/ eYoQPYwskqHno9 Message-ID: <4ECD0C28.4060606@gmx.com> Date: Wed, 23 Nov 2011 17:07:20 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marko Zec References: <4EC63D37.4050105@gmx.com> <20111123112204.GY96616@glebius.int.ru> <4ECCF257.9090801@gmx.com> <201111231453.37900.zec@fer.hr> In-Reply-To: <201111231453.37900.zec@fer.hr> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org Subject: Re: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 15:07:34 -0000 On 11/23/2011 3:53 PM, Marko Zec wrote: > On Wednesday 23 November 2011 14:17:11 Nikos Vassiliadis wrote: >> On 11/23/2011 1:22 PM, Gleb Smirnoff wrote: >>> I'd suspect VIMAGE. Can you please try w/o it and if it appears to be >>> VIMAGE-related, then please file a PR. >> >> It seems VIMAGE related. I'll ask at virtualization@. > > From the backtrace it looks like the curvnet context is not properly set in a > timer-driven call graph originating at lagg_port_setlladdr(). > > Perhaps this (untested) patch could help: > > --- //depot/user/zec/vimage_8/src/sys/net/if_lagg.c 2011-09-06 > 05:45:07.000000000 0000 > +++ /u/marko/p4/zec/vimage_8/src/sys/net/if_lagg.c 2011-09-06 > 05:45:07.000000000 0000 > @@ -468,7 +468,9 @@ > ifp = llq->llq_ifp; > > /* Set the link layer address */ > + CURVNET_SET(ifp->if_vnet); > error = if_setlladdr(ifp, llq->llq_lladdr, ETHER_ADDR_LEN); > + CURVNET_RESTORE(); > if (error) > printf("%s: setlladdr failed on %s\n", __func__, > ifp->if_xname); Yes, that fixes the panic. Thanks Marko, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 18:31:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 416A0106564A for ; Wed, 23 Nov 2011 18:31:57 +0000 (UTC) (envelope-from lavalamp@probikesllc.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id DAF9C8FC15 for ; Wed, 23 Nov 2011 18:31:56 +0000 (UTC) Received: (qmail 64780 invoked from network); 23 Nov 2011 18:05:16 -0000 Received: from 216.151.95.152 (HELO vger.digitalfreaks.org) (216.151.95.152) by relay00.pair.com with SMTP; 23 Nov 2011 18:05:16 -0000 X-pair-Authenticated: 216.151.95.152 Date: Wed, 23 Nov 2011 13:05:16 -0500 (EST) From: "Brian Seklecki (Mobile)" X-X-Sender: lavalamp@vger.digitalfreaks.org To: Andrea Venturoli In-Reply-To: <4ECD04AE.8070309@netfence.it> Message-ID: References: <4ECD04AE.8070309@netfence.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: if_xl on 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:31:57 -0000 Send us: grep ifconfig /etc/rc.conf ifconfig -a ifconfig -m netstat -i netstat -rn netstat -i arp -an For both the working and non-working cards to compare. Thx, ~BAS On Wed, 23 Nov 2011, Andrea Venturoli wrote: > Hello. > > Just to say today I upgraded from 8.1 to 8.2 and xl0 stopped working. > It is detected: >> xl0: <3Com 3c900B-COMBO Etherlink XL> port 0xd800-0xd87f mem >> 0xfdefe000-0xfdefe07f irq 17 at device 7.0 on pci1 >> xl0: selecting 10baseT transceiver, half duplex >> xl0: Ethernet address: 00:50:04:22:a9:c0 >> xl0: [ITHREAD] > > I can "ifconfigure" it, but no packet will get in or out. > > This is not a problem for me, since I had another card available. > However, if anyone is interested, I'm available for details or testing. > > bye > av. > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 19:09:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A207B106564A; Wed, 23 Nov 2011 19:09:14 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out8.libero.it (cp-out8.libero.it [212.52.84.108]) by mx1.freebsd.org (Postfix) with ESMTP id 249088FC0C; Wed, 23 Nov 2011 19:09:14 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020D.4ECD44D8.00EC,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.202.255) by cp-out8.libero.it (8.5.133) id 4EBC059F01DB0CF5; Wed, 23 Nov 2011 20:09:12 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.4) with ESMTP id pANJ975i094705; Wed, 23 Nov 2011 20:09:07 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4ECD44D3.2050607@netfence.it> Date: Wed, 23 Nov 2011 20:09:07 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.24) Gecko/20111110 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Brian Seklecki (Mobile)" References: <4ECD04AE.8070309@netfence.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.1.2.13 Cc: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: if_xl on 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:09:14 -0000 On 11/23/11 19:05, Brian Seklecki (Mobile) wrote: > > Send us: > > grep ifconfig /etc/rc.conf > ifconfig -a > ifconfig -m > netstat -i > netstat -rn > netstat -i > arp -an From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 19:12:03 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31E61065674; Wed, 23 Nov 2011 19:12:03 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out8.libero.it (cp-out8.libero.it [212.52.84.108]) by mx1.freebsd.org (Postfix) with ESMTP id 2E79B8FC12; Wed, 23 Nov 2011 19:12:02 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0208.4ECD4582.001B,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.202.255) by cp-out8.libero.it (8.5.133) id 4EBC059F01DB343D; Wed, 23 Nov 2011 20:12:01 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.4) with ESMTP id pANJBx8F095256; Wed, 23 Nov 2011 20:11:59 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4ECD457F.1080003@netfence.it> Date: Wed, 23 Nov 2011 20:11:59 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.24) Gecko/20111110 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Brian Seklecki (Mobile)" References: <4ECD04AE.8070309@netfence.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.1.2.13 Cc: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: if_xl on 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:12:03 -0000 On 11/23/11 19:05, Brian Seklecki (Mobile) wrote: > > Send us: > > grep ifconfig /etc/rc.conf > ifconfig -a > ifconfig -m > netstat -i > netstat -rn > netstat -i > arp -an > > For both the working and non-working cards to compare. Sorry for the noise... I accidentally removed the "media" option from rc.conf and the card is not able to decide between UTP and BNC by itself. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Nov 24 12:41:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C93B106566B for ; Thu, 24 Nov 2011 12:41:34 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEE828FC14 for ; Thu, 24 Nov 2011 12:41:33 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3755309bkb.13 for ; Thu, 24 Nov 2011 04:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=bh5Y0niWaLCC6DwfLGCaObbuNE+GHy7lDTX85E9GFFY=; b=DcIK+UorcnUHR1Zwsk0Y8JmKWyQDje+0su4tYhY0PzYLOk54BmlQhsqQy3ZUiFLdA6 Xh9rqVLFKt608uNfP3MuK+P1krmF+VFO1dhtLXG8jP33oQop1FMjWXyqNRkCsp3/X9/B cuUlGU+YehKlXfL0NzZMz4Yry413tuLUq0lx0= Received: by 10.205.121.1 with SMTP id ga1mr26520282bkc.60.1322138492535; Thu, 24 Nov 2011 04:41:32 -0800 (PST) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id i3sm25276112faf.0.2011.11.24.04.41.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 04:41:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Thu, 24 Nov 2011 14:41:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5229579D-A711-4804-9E26-7089D89D81DD@gmail.com> References: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> To: Borja Marcos X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 12:41:34 -0000 On Nov 23, 2011, at 2:43 PM, Borja Marcos wrote: >=20 > On Nov 23, 2011, at 9:30 AM, Nikolay Denev wrote: >=20 >> I'm seeing exactly the same problem with Quagga. >> Quagga's bgpd also seem to always set the TCP_MD5 socket option, and = newer freebsd 8.2 machines >> don't seem to be able to establish bgp sessions, probably due to the = recent TCP_MD5 fixes that enabled >> the TCP_MD5 checksum verification of incoming packets. >=20 > Hmm. A confusion? ;) >=20 > The traces I've just sent show Quagga and Bird working well, OpenBGPD = failing. >=20 >=20 > Borja. >=20 Nope, no confusion :) My pair of FreeBSD 8.2 routers fail to establish a BGP session unless I = define MD5 password in /etc/ipsec.conf or disable the validation of the digests with the sysctl I mentioned in my previous email. I'm seeing exactly the same tcpdumps, with invalid digest options and = empty digest (all zeroes). Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Fri Nov 25 00:53:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA16A1065670; Fri, 25 Nov 2011 00:53:12 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECCB8FC14; Fri, 25 Nov 2011 00:53:12 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RTk2R-000IkP-7P; Thu, 24 Nov 2011 16:53:11 -0800 Message-ID: <4ECEE6F0.4010301@FreeBSD.org> Date: Thu, 24 Nov 2011 16:53:04 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Robert Watson References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 00:53:12 -0000 On 11/7/2011 6:41 PM, Robert Watson wrote: > > On Mon, 7 Nov 2011, Maxim Sobolev wrote: > >> On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote: >>> Now if you are clever you'd also log the inp there as the above will >>> only prove the case that something is wrong but still not help us in >>> anything to figure out what. >> >> Good point, thank you Sir. >> >> Would that be good enough? >> >> printf("BZZT! Something is terribly wrong, up == NULL! inp = %p\n", inp); >> >> Do you think of any other useful piece of information that I can log >> at this point? > > Hi Maxim: > > There was recently a commit to fix a race condition in 10-CURRENT which > I think is not slated to be merged for 9.0. You might check the commit > logs there and see if that fixes the problems you have -- if so, we > might want to reconsider the plan not to merge for 9.0. > > (It relates to a race condition on closing sockets..) Hi Robert, Thank you for the tip. I will give it a try and see what happens. So far, after installing that trap we have not seen any panics yet. I have not checked logs yet if my trap actually has catch anything or not. -Maxim From owner-freebsd-net@FreeBSD.ORG Fri Nov 25 01:52:48 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C3FB1065672 for ; Fri, 25 Nov 2011 01:52:48 +0000 (UTC) (envelope-from csalgau-br@bitdefender.com) Received: from mail.bitdefender.com (mail.bitdefender.com [91.199.104.2]) by mx1.freebsd.org (Postfix) with ESMTP id A00FC8FC0A for ; Fri, 25 Nov 2011 01:52:47 +0000 (UTC) Received: (qmail 32321 invoked from network); 25 Nov 2011 03:26:05 +0200 Received: from 79-112-50-100.iasi.fiberlink.ro (HELO ?192.168.32.128?) (csalgau@bitdefender.com@79.112.50.100) by mail.bitdefender.com with AES256-SHA encrypted SMTP; 25 Nov 2011 03:26:05 +0200 Message-ID: <4ECEEEAB.9070907@bitdefender.com> Date: Fri, 25 Nov 2011 03:26:03 +0200 From: Mihai-Catalin Salgau User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <07255796.20101207031807@bitdefender.com> In-Reply-To: <07255796.20101207031807@bitdefender.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.11.3.13847, SQMD Hits: none, rbl score: 0(0), apm score: 500, ApmFlags: [NN_LEGIT_BITDEFENDER; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD], SQMD: 648d2226795b6400acb8d73f05593483.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on elfie.dsd.hq, sigver: 7.39938 Subject: Re: vlan limits on e1000? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 01:52:48 -0000 On 12/7/2010 3:18 AM, Mihai-Catalin Salgau wrote: > Hello Freebsd-net, > > I have two dual port NICs, one Broadcom(bce0,bce1) and one Intel(em0,em1), on FreeBSD 8-stable > (about two weeks old) with a DHCP server running. > I've been successfully using a large number of vlans over bce1,em0 and em1 with iSCSI, > but wanted to switch to AoE(ata over ethernet). I've set vlandevs by round-robin, and got > vlan1 on bce0, vlan2 on em0, vlan3 on em1, vlan4 on bce0....vlan12 on em1. I've binded > net/vblade instances to each interface, but the problem I'm facing now is that while > vlans 1-10 are working properly, vlans 11 and 12 won't see any traffic unless the interface is > in promiscuous mode. I noticed that while trying to attach tcpdump and saw the thing instantly work. > I've had no problems with iSCSI over the same setup, and dhcp packets are getting trough properly. > I've moved those last two vlans to bce0 and they work ok, but I'm a bit locked on why this is happening. > Are there any known limitations on vlans on e1000? > Hi I left this dead for over a year now due to lack of time and the need to have the box up. Sorry about that. As a workaround I moved most of the vlans on the Broadcom interface and left only four on the Intel, as that worked. Now I'm really trying to debug this, so here's what I've done up until now. I've exchanged the Intel cards three times - two other Intels and a Broadcom card and the same thing happened(or didn't. depending on the point of view) So I moved to tcpdumps. All of the following was done on the server, not the clients. While running tcpdump -p -i vlan12 I see 1 AoE request frame received by the server and 1 reply being sent out to the client but that's it. Running without -p(switching to promiscuous mode) sees subsequent requests and replies and everything works right. Doing this on em0 has the same effect, but frames are tagged(duh). So I started with the hacks. I modified vblade(the AoE target I'm using) to read and write 802.1q tagged frames for the vlan I'm testing with and set it on em0. This turned out to work just fine (without promiscuous mode, that is), so I'm currently suspecting BPF as the culprit, as vblade uses BPF to read and write network packets. I'll have a mirror port set on the switch later today so I can see if any packets actually go out when tcpdump says they do, but I'm currently seeing two problems. -tcpdump not showing the actual frames being sent -BPF on VLANs not working properly I'm thinking they might get truncated after pcap and are invalid when they reach the client Any feedback or at least confirmation is welcome. I'm currently running 8-STABLE from about a week ago. Unfortunatelly I can't test CURRENT or 9-STABLE right now. From owner-freebsd-net@FreeBSD.ORG Fri Nov 25 07:24:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77701106564A; Fri, 25 Nov 2011 07:24:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA278FC08; Fri, 25 Nov 2011 07:24:02 +0000 (UTC) Received: from [192.168.2.115] (host86-148-124-36.range86-148.btcentralplus.com [86.148.124.36]) by cyrus.watson.org (Postfix) with ESMTPSA id 6258046B06; Fri, 25 Nov 2011 02:24:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4ECEE6F0.4010301@FreeBSD.org> Date: Fri, 25 Nov 2011 07:24:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> <4ECEE6F0.4010301@FreeBSD.org> To: Maxim Sobolev X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 07:24:02 -0000 On 25 Nov 2011, at 00:53, Maxim Sobolev wrote: >> There was recently a commit to fix a race condition in 10-CURRENT = which >> I think is not slated to be merged for 9.0. You might check the = commit >> logs there and see if that fixes the problems you have -- if so, we >> might want to reconsider the plan not to merge for 9.0. >>=20 >> (It relates to a race condition on closing sockets..) >=20 > Thank you for the tip. I will give it a try and see what happens. So = far, after installing that trap we have not seen any panics yet. I have = not checked logs yet if my trap actually has catch anything or not. Do we know if this fix has been merged to stable/9 and releng/9.0? Given = multiple reports of instability without it, I think we would be = well-served to merge it at this point. Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 25 23:35:19 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 609AD106566C; Fri, 25 Nov 2011 23:35:19 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEB5A8FC13; Fri, 25 Nov 2011 23:35:18 +0000 (UTC) Received: by faap15 with SMTP id p15so5349323faa.13 for ; Fri, 25 Nov 2011 15:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gDfP+5/+b2tAKC9o3qvWTZ9Wp9dO/k5f9Itq51qzvFg=; b=RraxTumN1U0DCMVtOFjis93+sGJw6ADV3IE0Az4+Hv8G8QsM+OG/XMj1JMo6pQgzzT XHAFcKd95nTy+irtvMgkKB5elJHterSCTzI40nOClAZd6nKq8Ef307SZr3kbHyjx+Wty Lc/qIL2DYQfrBQMcwaml2cpywMUJz2+9wh2c0= MIME-Version: 1.0 Received: by 10.152.132.39 with SMTP id or7mr21556792lab.14.1322262605185; Fri, 25 Nov 2011 15:10:05 -0800 (PST) Received: by 10.152.20.164 with HTTP; Fri, 25 Nov 2011 15:10:05 -0800 (PST) In-Reply-To: <20110701174112.GA78060@onelab2.iet.unipi.it> References: <20110701174112.GA78060@onelab2.iet.unipi.it> Date: Fri, 25 Nov 2011 18:10:05 -0500 Message-ID: From: Outback Dingo To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, Luigi Rizzo Subject: Re: ports/net/click anyone ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 23:35:19 -0000 On Fri, Jul 1, 2011 at 1:41 PM, Luigi Rizzo wrote: > [Cc to ports@freebsd,org, but please followup at net@freebsd.org] > > anyone interested in taking over maintainership of ports/net/click ? > We have 1.5.0 in the tree, which is old and partly broken. Luigi, coming back to an earlier email post you had on click has someone taken maintainership, Id be willing since I am using it in development areas, and belive it should be part of the ports tree still From owner-freebsd-net@FreeBSD.ORG Sat Nov 26 05:24:16 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D2691065670; Sat, 26 Nov 2011 05:24:16 +0000 (UTC) (envelope-from alexander@wittig.name) Received: from hotzenplotz.wittig.name (hotzenplotz.wittig.name [IPv6:2a02:180:1:1::5b8f:51e8]) by mx1.freebsd.org (Postfix) with ESMTP id D29098FC1E; Sat, 26 Nov 2011 05:24:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wittig.name; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=Kr7ncebKl2bDLQ3PE7hHGYhCqLuHOK83QHcnx0M1Mp4=; b=MGS97tvVF1M9+FfBo7ujoZmNQi1sCZzHPJwII39XsPmh9ZQAj849JiBrriX8nnY9H5znIcoeJmNm+OyXOtlsj+Mnh/cSyYNQBMGVFx0fLqaCqOzDZPjTxvStGe4WiAiIW0SwQxpHjPOxNHrQwRpr929hxM74wPgTXgij5lm1UHM=; Received: from [99.18.86.240] (helo=[192.168.1.64]) by hotzenplotz.wittig.name with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RUAkG-000CVg-R7; Sat, 26 Nov 2011 06:24:14 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alexander Wittig In-Reply-To: <20111121120123.GC81136@FreeBSD.org> Date: Sat, 26 Nov 2011 00:24:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> <20111110065135.GS71907@FreeBSD.org> <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> <20111121120123.GC81136@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD 9 and ARP multicast source address error messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 05:24:16 -0000 Gleb, > A> I'm not an expert on networking, but is this condition of ignoring = such an ARP packet really a noteworthy event? I.e. is this something = that should not occur in "normal" operation according to the ARP = specifications? If this is mostly for kernel developers, maybe it should = only be enabled in debug kernel builds? >=20 > Nope, this isn't for kernel developers only but for sysadmins. Some = bad traffic is present in your > network, and it should be noticed by sysadmin, that's why LOG_NOTICE = severity left. >=20 > However, I understand how annoying it is when you are in a bad = network, you don't admin it, you > can't fix it and your logging system is too chatty. I am thinking of = some generic way of supperssing > or ratelimiting all logged events that can be triggered by host on LAN = or even by remote host. That would be great. As you say, I don't administer the network or these = Windows cluster machines, so I can't make the offending ARP packages go = away. For me, filtering them out via ipfw (as described in my first = email) works just fine for now. An easier solution than some sort of = rate limiting may be a simple sysctl knob to disable the messages = manually at runtime? Something akin to the already existing = net.link.ether.inet.log_arp_permanent_modify, = net.link.ether.inet.log_arp_movements, = net.link.ether.inet.log_arp_wrong_iface, maybe. Alexander= From owner-freebsd-net@FreeBSD.ORG Sat Nov 26 14:39:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C7121065679 for ; Sat, 26 Nov 2011 14:39:09 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BCE028FC1D for ; Sat, 26 Nov 2011 14:39:08 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so7324648bkb.13 for ; Sat, 26 Nov 2011 06:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=t/UqtLJlKNVs9vf0XdWO+B18IgQj5TVXGxik0LMGVRA=; b=UiqvTF03NgRWM13BrHdO1y8OM/71DkCEyNZ4w7Uui9CtjF3zswwnJLRCbF0GKxUBFS FVSfaGkHZFGmNb0So9jeZ/X0B7Ne3KHug0GBewkS81xrrF16JIV0ubOxkr0ZMOrrUBem +x49mWXrQVY98cCrnUaIs8H653cait3/CH11Y= Received: by 10.204.154.130 with SMTP id o2mr8382313bkw.138.1322318347470; Sat, 26 Nov 2011 06:39:07 -0800 (PST) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id b2sm2411048fao.1.2011.11.26.06.39.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Nov 2011 06:39:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <0DF73F37-3E46-4F7D-AA6B-B7EB2F2276AB@gmail.com> Date: Sat, 26 Nov 2011 16:39:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111024175252.GB4663@michelle.cdnetworks.com> <0DF73F37-3E46-4F7D-AA6B-B7EB2F2276AB@gmail.com> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: Possible sge(4)/atphy(4) regression on RELENG_9? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 14:39:09 -0000 On Oct 24, 2011, at 9:18 PM, Nikolay Denev wrote: >=20 > On Oct 24, 2011, at 8:52 PM, YongHyeon PYUN wrote: >=20 >> On Mon, Oct 24, 2011 at 04:43:57PM +0300, Nikolay Denev wrote: >>> Hello, >>>=20 >>> I've recently upgraded a box running RELENG_8 to RELENG_9 and = immediately I noticed much slower network connection. >>> Running iperf shows about 20-30Mbits which was almost full GigE = (~900Mbits) speed before. >>>=20 >>> I'm noticing interface errors : >>>=20 >>> [16:37]ndenev@nas:~% netstat -I sge0 >>> Name Mtu Network Address Ipkts Ierrs Idrop = Opkts Oerrs Coll >>> sge0 1500 00:0a:e4:86:62:fa 76114295 42197 0 = 103559806 10324 0 >>> sge0 1500 10.0.0.0 nas 76109575 - - = 119109557 - - >>>=20 >>> Both the switch and the card show 1000 full-duplex. >>> I've tried playing with rxcsum,txcsum,vlanhwtag,tso but disabling = even all of them do not change anything. >>> I've tried different switch port and changed the cable. >>>=20 >>> Here is devinfo for my hardware : >>>=20 >>> sge0 pnpinfo vendor=3D0x1039 device=3D0x0191 subvendor=3D0x103c = subdevice=3D0x2a70 class=3D0x020000 >>> atphy0 pnpinfo oui=3D0xc82e model=3D0x1 rev=3D0x6 at phyno=3D0 >>>=20 >>> Of course all of this can mean hardware problem, I just want to ask = if somebody is seeing something similar, since >>> there are quite a lot minibus related changes as far as I can see. >>>=20 >>> I'll boot RELENG_8 again tomorrow and do a quick test again to = verify that this is not a hardware issue. >>>=20 >>=20 >> I don't have sge(4) controller so it would be better to let us know >> which revision introduced the regression. Just looking over the >> code change didn't reveal the possible cause. >> BTW, I thought sge(4) shall use rgephy(4). Can you also verify >> whether sge(4) in stable/8 also use atphy(4)? >=20 > I've just checked my logs and I can confirm that it was atphy(4) even = in stable/8. >=20 > Sep 26 15:55:19 nas kernel: atphy0: PHY 0 = on miibus0 > Sep 26 15:55:19 nas kernel: atphy0: none, 10baseT, 10baseT-FDX, = 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >=20 > I'll post more info when I try again stable/8 on this hardware. >=20 > Thanks! >=20 Just for the sake of completeness I'm reporting that the problem turned = out to be not hardware related. The thread "TCP Reassembly Issues" in freebsd-stable list describes the = issue. Thanks.= From owner-freebsd-net@FreeBSD.ORG Sat Nov 26 20:54:15 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B73106566B for ; Sat, 26 Nov 2011 20:54:15 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 68FD88FC08 for ; Sat, 26 Nov 2011 20:54:14 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id pAQKsBUG014934 for ; Sun, 27 Nov 2011 03:54:11 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4ED151EE.5080603@rdtc.ru> Date: Sun, 27 Nov 2011 03:54:06 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: quagga does not add interface route to the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 20:54:15 -0000 Hi! I need quagga to add default route to ng1 interface (without specifying next-hop address) when there is no default route yet. So, I use command 'ip route 0.0.0.0/0 ng1' and it tries to add it to the kernel and fails. Its debug shows: 2011/11/27 02:44:05 ZEBRA: rib_process: 0.0.0.0/0: Adding route, select 0x2125f220 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: 0.0.0.0/0: attention! gate not found for rib 0x2125f220 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: dumping RIB entry 0x2125f220 for 0.0.0.0/0 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: refcnt == 0, uptime == 0, type == 3, table == 0 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: metric == 0, distance == 10, flags == 0, status == 0 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: nexthop_num == 1, nexthop_active_num == 1, nexthop_fib_num == 0 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: NH 0.0.0.0 (0.0.0.0) with flags ACTIVE 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: dump complete 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: 0.0.0.0/0: rtm_write() unexpectedly returned -2 for command RTM_ADD 2011/11/27 02:44:05 ZEBRA: kernel_rtm_ipv4: No useful nexthops were found in RIB entry 0x2125f220 Meantime, 'route -n monitor' shows: got message of size 116 on Sun Nov 27 02:57:03 2011 RTM_ADD: Add Route: len 116, pid: 566, seq 87, errno 51, flags: locks: inits: sockaddrs: default default default If I use command 'route add default -iface ng1', it succeedes and I see differing picture: got message of size 168 on Sun Nov 27 02:53:47 2011 RTM_ADD: Add Route: len 168, pid: 2817, seq 1, errno 0, flags: locks: inits: sockaddrs: default ng1 default It seems, quagga does not pass interface name ng1 to the kernel. Does someone know how to fix it quick? I use 8.2-STABLE/amd64 and quagga-0.99.20 from ports. Eugene Grosbein