From owner-freebsd-net@FreeBSD.ORG Sun Jan 8 03:02:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C5E2106566C; Sun, 8 Jan 2012 03:02:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 736D98FC12; Sun, 8 Jan 2012 03:02:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q08326iw002065; Sun, 8 Jan 2012 03:02:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q08326ks002061; Sun, 8 Jan 2012 03:02:06 GMT (envelope-from linimon) Date: Sun, 8 Jan 2012 03:02:06 GMT Message-Id: <201201080302.q08326ks002061@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/163903: [igb] "igb0:tx(0)", "bpf interface lock" v2.2.5 9-STABLE 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, 08 Jan 2012 03:02:06 -0000 Old Synopsis: "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABLE New Synopsis: [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABLE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 8 03:01:52 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=163903 From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 10:01:48 2012 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 3BC6C106564A for ; Mon, 9 Jan 2012 10:01:48 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04b.sare.net (proxypop04b.sare.net [194.30.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id F02F88FC0C for ; Mon, 9 Jan 2012 10:01:47 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id D3BAD9DC4AD; Mon, 9 Jan 2012 11:01:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120104092824.GA24657@diehard.n-r-g.com> Date: Mon, 9 Jan 2012 11:01:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> <20120104092824.GA24657@diehard.n-r-g.com> To: Claudio Jeker X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 09 Jan 2012 10:01:48 -0000 On Jan 4, 2012, at 10:28 AM, Claudio Jeker wrote: > On Wed, Jan 04, 2012 at 09:27:28AM +0100, Borja Marcos wrote: >>=20 >> Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. >> According to my packet captures, in case there's no properly set key >> with setkey(8) it will use whatever key. Look at the captures = mentioned >> here: >>=20 >> = http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/e= a347a919dbc165d/eeaa2965fc4f64c9?show_docid=3Deeaa2965fc4f64c9&pli=3D1 >>=20 >>=20 >> Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless >> there's a valid key associated to the socket, either using setkey(8) = (I >> don't know if they use it) or via the API for setting keys. > How does FreeBSD avoid the chicken and egg problem of accepting > connections with MD5SIG? I understand, but what if you haven't configured any peer for MD5SIG? = Openbgpd is *still* enabling it. Maybe there's a simple solution in FreeBSD: ignoring the MD5SIG flags = (and not adding the option to the outgoing packets) _UNLESS_ there's a = matching SPD for the flow. I think that's the problem. It's pointless to = check MD5SIG or originate packets with MD5SIG when there's no matching = SPD. What does it use in that case, a random key? So I'm beginning to think that FreeBSD is the problem, not Openbgpd. = Although of course neither Quagga nor bird set the MD5 option when you = haven't explicitly enabled it in your BGP configuration. Borja. From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 11:07:09 2012 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 DE351106566C for ; Mon, 9 Jan 2012 11:07:09 +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 CB5578FC21 for ; Mon, 9 Jan 2012 11:07:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q09B79qx042256 for ; Mon, 9 Jan 2012 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q09B79sQ042254 for freebsd-net@FreeBSD.org; Mon, 9 Jan 2012 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Jan 2012 11:07:09 GMT Message-Id: <201201091107.q09B79sQ042254@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, 09 Jan 2012 11:07:09 -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/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163482 net IP address is not round robined if DNS name has many o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I 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/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/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/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 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 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 Jan 9 15:41:22 2012 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 BBD431065678 for ; Mon, 9 Jan 2012 15:41:22 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 85D6B8FC0C for ; Mon, 9 Jan 2012 15:41:22 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C32D321432 for ; Mon, 9 Jan 2012 10:22:49 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 09 Jan 2012 10:22:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=XkgTOneOItEEw/q64RGDgF CFANE=; b=c1a7FnifyHfZFXXwjWdFPw1LdGQt7e1tehXAQK4MIpr8W+5eapHFKg gK8BZYGBerOmeVUo4a/kUuy+lRV1G/u6cCR2Ssd0uFJoQiWJ7pAgoZ0yAWuT/Vx3 aliXxFTmUr9DiAE6m7ar8Lp6egP9PEZa8iaE4I+ALzjxRQcx52o7g= X-Sasl-enc: Oj+ISlX+MuXEDs5nS97UuiBTkSxT7zlNrD9rYOLGAAAN 1326122569 Received: from [138.251.207.122] (dyn-207-122.cs.st-andrews.ac.uk [138.251.207.122]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4463F8E0082; Mon, 9 Jan 2012 10:22:49 -0500 (EST) Message-ID: <4F0B0684.8040609@incunabulum.net> Date: Mon, 09 Jan 2012 15:23:48 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Baldwin References: <201112221115.10239.jhb@freebsd.org> In-Reply-To: <201112221115.10239.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Deferring inp_freemoptions() to an asychronous task 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, 09 Jan 2012 15:41:22 -0000 John, Sorry it's taken me so long to reply. No objections in principle to your change, but this seems to point at a more general issue with modern network controllers. You've also stumbled on the behaviour specific to how BSD has traditionally dealt with broadcast/multicast sockets. The pcbinfo structure can't really be disentangled from this. Of course, it doesn't help that we have historically required these sockets to be bound to INADDR_ANY. It might be useful to break reception out using a separate hash/tree, rather than walking all sockets as is currently done, but legacy usage needs to be supported. Interestingly enough, Microsoft has probably done something similar, judging from things which appear in MSDN. John Baldwin wrote: > I have a workload at work where a particular device driver can take a while to > update its MAC filter table when adding or removing multicast link-layer > addresses. One of the ways I've tackled fixing this is to change > inp_freemoptions() so that it does all of its actual work asychronously in a > separate task. Currently it does its work synchronously; however, it can be > invoked while the associated protocol holds a write lock on its pcbinfo lock > (e.g. from in_pcbdetach() called from udp_detach()). This stalls all packet > reception for that protocol since received packets need a read lock on the > pcbinfo to lookup the socket associated with a given (ip, port) tuple. There is often a delay between asking for the group and actually getting the hash filter entry set up in the MAC, so the operations are async. I can see many apps like to assume the operation is instantaneous rather than deferred; they are probably being naive... The same being true for taking down the hash filter entry is not surprising. thanks Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 16:30:19 2012 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 C1B94106564A for ; Mon, 9 Jan 2012 16:30:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 990DD8FC0A for ; Mon, 9 Jan 2012 16:30:19 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 4EA8A46B53; Mon, 9 Jan 2012 11:30:19 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D1952B91C; Mon, 9 Jan 2012 11:30:18 -0500 (EST) From: John Baldwin To: Bruce Simpson Date: Mon, 9 Jan 2012 11:28:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201112221115.10239.jhb@freebsd.org> <4F0B0684.8040609@incunabulum.net> In-Reply-To: <4F0B0684.8040609@incunabulum.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201091128.10193.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jan 2012 11:30:18 -0500 (EST) Cc: net@freebsd.org Subject: Re: Deferring inp_freemoptions() to an asychronous task 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, 09 Jan 2012 16:30:19 -0000 On Monday, January 09, 2012 10:23:48 am Bruce Simpson wrote: > John, > > Sorry it's taken me so long to reply. > > No objections in principle to your change, but this seems to point at a > more general issue with modern network controllers. > > You've also stumbled on the behaviour specific to how BSD has > traditionally dealt with broadcast/multicast sockets. The pcbinfo > structure can't really be disentangled from this. > > Of course, it doesn't help that we have historically required these > sockets to be bound to INADDR_ANY. It might be useful to break reception > out using a separate hash/tree, rather than walking all sockets as is > currently done, but legacy usage needs to be supported. > > Interestingly enough, Microsoft has probably done something similar, > judging from things which appear in MSDN. > > John Baldwin wrote: > > I have a workload at work where a particular device driver can take a while to > > update its MAC filter table when adding or removing multicast link-layer > > addresses. One of the ways I've tackled fixing this is to change > > inp_freemoptions() so that it does all of its actual work asychronously in a > > separate task. Currently it does its work synchronously; however, it can be > > invoked while the associated protocol holds a write lock on its pcbinfo lock > > (e.g. from in_pcbdetach() called from udp_detach()). This stalls all packet > > reception for that protocol since received packets need a read lock on the > > pcbinfo to lookup the socket associated with a given (ip, port) tuple. > > There is often a delay between asking for the group and actually getting > the hash filter entry set up in the MAC, so the operations are async. > > I can see many apps like to assume the operation is instantaneous rather > than deferred; they are probably being naive... > > The same being true for taking down the hash filter entry is not surprising. The other fun part in this case is that if it is going to take a long time, a driver should probably be enabling reception of all multicast (equivalent of IFF_ALLMULTI) while it reprograms the table to avoid dropping packets for already-joined groups. I'm not currently doing this as we are using a different hack, but I think that is something drivers should probably be doing. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 17:00:28 2012 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 0A7FB1065672 for ; Mon, 9 Jan 2012 17:00:28 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id B06818FC13 for ; Mon, 9 Jan 2012 17:00:27 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C152025D3892; Mon, 9 Jan 2012 17:00:26 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 71B9EBD8D19; Mon, 9 Jan 2012 17:00:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id WNYUI7BTyiGE; Mon, 9 Jan 2012 17:00:24 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5031CBD8D17; Mon, 9 Jan 2012 17:00:24 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120106221859.GC29646@diehard.n-r-g.com> Date: Mon, 9 Jan 2012 17:00:23 +0000 Content-Transfer-Encoding: 7bit Message-Id: <648F3DA8-EBEC-4CC1-A8C4-EC4B1E0896F7@lists.zabbadoz.net> References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> <20120106153500.GA78077@sandvine.com> <20120106221859.GC29646@diehard.n-r-g.com> To: Claudio Jeker X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 09 Jan 2012 17:00:28 -0000 On 6. Jan 2012, at 22:18 , Claudio Jeker wrote: > On Fri, Jan 06, 2012 at 10:35:01AM -0500, Ed Maste wrote: >> On Thu, Jan 05, 2012 at 08:18:39PM -0500, J David wrote: >> >>> To help understand what's going on and test some of this stuff, I >>> hacked up a TCP-MD5-aware echo server and tried various things. >> >> Hi J David, >> >> Thank you very much for this extensive testing and analysis. Would you >> care to post your basic echo server somewhere for others to use in >> debugging this, just to save time for anyone who can debug further? >> > > nc(1) has MD5 support (-S). There is no need for extra tools. > You still need to install the SA since nc will only turn on the sockopt. Not for the listen socket in FreeBSD... I patched that locally. General comment for all the others on the issue as well: There's quite a bit of things to fix in the input path validation to do still it turns out; seems we are still accepting unsigned RSTs despite a policy in place to mandate MD5 between the hosts etc... I am trying to get the SYN cache breakage fixed currently to get the status quo back to what was expected and am finding other things in the stack etc that distract me and get improved along the lines... anyway, I am hopeful to have a patch for the first issue later today. It's a bit intrusive as I indeed started to clean some things up also preparing for more. I'll keep everyone informed. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 17:40:13 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00E4D106566C for ; Mon, 9 Jan 2012 17:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E15488FC0A for ; Mon, 9 Jan 2012 17:40:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q09HeCLG009525 for ; Mon, 9 Jan 2012 17:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q09HeCsq009524; Mon, 9 Jan 2012 17:40:12 GMT (envelope-from gnats) Date: Mon, 9 Jan 2012 17:40:12 GMT Message-Id: <201201091740.q09HeCsq009524@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= Cc: Subject: Re: kern/163903: [igb] " igb0:tx(0)" ," bpf interface lock" v2.2.5 9-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:40:13 -0000 The following reply was made to PR kern/163903; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: bug-followup@FreeBSD.org, kes-kes@yandex.ru Cc: Subject: Re: kern/163903: [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABLE Date: Mon, 9 Jan 2012 19:36:31 +0200 it repeats again, but now I install release 9 traffice flow about 20-30Mbit/s, ~4000 pps # uname -a FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0 r229830: Mon Jan 9 02:53:51 EET 2012 :/usr/obj/usr/src.svn/9.0.0/sys/KES_KERN_v9 i386 # tcpdump -n -i igb0 tcpdump: WARNING: igb0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on igb0, link-type EN10MB (Ethernet), capture size 65535 bytes wait 2 mins ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel # netstat -W 1 igb0 input (Total) output packets errs idrops bytes packets errs bytes colls 10 16 0 9342 12 7 18980 0 4 19 0 3076 6 8 12668 0 8 10 0 3444 10 7 12990 0 8 16 0 9140 10 6 17168 0 6 19 0 3282 8 7 12832 0 10 9 0 3597 12 6 11631 0 14 18 0 9646 16 7 19188 0 4 14 0 3076 6 8 12668 0 12 13 0 3930 18 5 10670 0 22 11 0 10376 30 7 20396 0 22 21 0 4652 26 7 14236 0 26 15 0 5268 40 8 15336 0 12 12 0 9464 12 7 18888 0 22 18 0 4744 30 7 14556 0 # netstat -m 21622/1688/23310 mbufs in use (current/cache/total) 19389/969/20358/262144 mbuf clusters in use (current/cache/total/max) 19389/835 mbuf+clusters out of packet secondary zone in use (current/cache) 0/90/90/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 44183K/2720K/46903K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/14/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 26 requests for I/O initiated by sendfile 0 calls to protocol drain routines # sysctl -a | grep igb |less device igb "IGB Core Lock","igb0:tx(0)" "igb0:tx(0)","bpf interface lock" "igb0:tx(0)","system map" "igb0:tx(0)","UMA zone" "IGB Core Lock","igb0:tx(1)" "igb0:tx(1)","bpf interface lock" "igb0:tx(1)","UMA zone" "IGB Core Lock","igb0:tx(2)" "igb0:tx(2)","bpf interface lock" "igb0:tx(2)","UMA zone" "IGB Core Lock","igb0:tx(3)" "igb0:tx(3)","bpf interface lock" "igb0:tx(3)","UMA zone" "IGB Core Lock","igb0:rx(3)" "igb0:rx(3)","system map" "igb0:rx(3)","UMA zone" "igb0:rx(3)","UMA boot pages" "IGB Core Lock","igb1:tx(0)" "IGB Core Lock","igb1:tx(1)" "IGB Core Lock","igb1:tx(2)" "IGB Core Lock","igb1:tx(3)" "IGB Core Lock","igb1:rx(3)" device igb "IGB Core Lock","igb0:tx(0)" "igb0:tx(0)","bpf interface lock" "igb0:tx(0)","system map" "igb0:tx(0)","UMA zone" "IGB Core Lock","igb0:tx(1)" "igb0:tx(1)","bpf interface lock" "igb0:tx(1)","UMA zone" "IGB Core Lock","igb0:tx(2)" "igb0:tx(2)","bpf interface lock" "igb0:tx(2)","UMA zone" "IGB Core Lock","igb0:tx(3)" "igb0:tx(3)","bpf interface lock" "igb0:tx(3)","UMA zone" "IGB Core Lock","igb0:rx(3)" "igb0:rx(3)","system map" "igb0:rx(3)","UMA zone" "igb0:rx(3)","UMA boot pages" "IGB Core Lock","igb1:tx(0)" "IGB Core Lock","igb1:tx(1)" "IGB Core Lock","igb1:tx(2)" "IGB Core Lock","igb1:tx(3)" "IGB Core Lock","igb1:rx(3)" "igb1:rx(3)","system map" "igb1:rx(3)","UMA zone" hw.igb.rx_process_limit: 100 hw.igb.num_queues: 0 hw.igb.header_split: 0 hw.igb.max_interrupt_rate: 8000 hw.igb.enable_msix: 1 hw.igb.enable_aim: 1 hw.igb.txd: 1024 hw.igb.rxd: 1024 dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa01c class=0x020000 dev.igb.0.%parent: pci1 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 65536003 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 2 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1086325313 dev.igb.0.rx_control: 67141658 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147483664 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 58976 dev.igb.0.fc_low_water: 58960 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 22430350 dev.igb.0.queue0.rx_packets: 7508782 dev.igb.0.queue0.rx_bytes: 7447198278 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 245159 dev.igb.0.queue1.rx_packets: 6044939 dev.igb.0.queue1.rx_bytes: 6566823122 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.queue2.no_desc_avail: 0 dev.igb.0.queue2.tx_packets: 432010 dev.igb.0.queue2.rx_packets: 7475430 dev.igb.0.queue2.rx_bytes: 8608333553 dev.igb.0.queue2.lro_queued: 0 dev.igb.0.queue2.lro_flushed: 0 dev.igb.0.queue3.no_desc_avail: 0 dev.igb.0.queue3.tx_packets: 216735 dev.igb.0.queue3.rx_packets: 6903219 dev.igb.0.queue3.rx_bytes: 7346859824 dev.igb.0.queue3.lro_queued: 0 dev.igb.0.queue3.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 72857 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 28021521 dev.igb.0.mac_stats.good_pkts_recvd: 27932434 dev.igb.0.mac_stats.bcast_pkts_recvd: 13711 dev.igb.0.mac_stats.mcast_pkts_recvd: 646 dev.igb.0.mac_stats.rx_frames_64: 905750 dev.igb.0.mac_stats.rx_frames_65_127: 3991323 dev.igb.0.mac_stats.rx_frames_128_255: 1227204 dev.igb.0.mac_stats.rx_frames_256_511: 856740 dev.igb.0.mac_stats.rx_frames_512_1023: 698309 dev.igb.0.mac_stats.rx_frames_1024_1522: 20253108 dev.igb.0.mac_stats.good_octets_recvd: 30192737656 dev.igb.0.mac_stats.good_octets_txd: 8368924045 dev.igb.0.mac_stats.total_pkts_txd: 23323776 dev.igb.0.mac_stats.good_pkts_txd: 23323776 dev.igb.0.mac_stats.bcast_pkts_txd: 38 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 10399506 dev.igb.0.mac_stats.tx_frames_65_127: 6262689 dev.igb.0.mac_stats.tx_frames_128_255: 1512382 dev.igb.0.mac_stats.tx_frames_256_511: 169690 dev.igb.0.mac_stats.tx_frames_512_1023: 279266 dev.igb.0.mac_stats.tx_frames_1024_1522: 4700243 dev.igb.0.mac_stats.tso_txd: 3 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 42947451 dev.igb.0.interrupts.rx_pkt_timer: 27932158 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 27932371 dev.igb.0.interrupts.tx_queue_empty: 23321536 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 276 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 2240 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 30192739078 dev.igb.0.host.tx_good_bytes: 8368924045 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=1 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa01c class=0x020000 dev.igb.1.%parent: pci1 dev.igb.1.nvm: -1 dev.igb.1.enable_aim: 1 dev.igb.1.fc: 3 dev.igb.1.rx_processing_limit: 100 dev.igb.1.link_irq: 1 dev.igb.1.dropped: 0 dev.igb.1.tx_dma_fail: 0 dev.igb.1.rx_overruns: 0 dev.igb.1.watchdog_timeouts: 0 dev.igb.1.device_control: 1086325313 dev.igb.1.rx_control: 67141634 dev.igb.1.interrupt_mask: 4 dev.igb.1.extended_int_mask: 2147483664 dev.igb.1.tx_buf_alloc: 0 dev.igb.1.rx_buf_alloc: 0 dev.igb.1.fc_high_water: 58976 dev.igb.1.fc_low_water: 58960 dev.igb.1.queue0.no_desc_avail: 0 dev.igb.1.queue0.tx_packets: 0 dev.igb.1.queue0.rx_packets: 0 dev.igb.1.queue0.rx_bytes: 0 dev.igb.1.queue0.lro_queued: 0 dev.igb.1.queue0.lro_flushed: 0 dev.igb.1.queue1.no_desc_avail: 0 dev.igb.1.queue1.tx_packets: 0 dev.igb.1.queue1.rx_packets: 0 dev.igb.1.queue1.rx_bytes: 0 dev.igb.1.queue1.lro_queued: 0 dev.igb.1.queue1.lro_flushed: 0 dev.igb.1.queue2.no_desc_avail: 0 dev.igb.1.queue2.tx_packets: 0 dev.igb.1.queue2.rx_packets: 0 dev.igb.1.queue2.rx_bytes: 0 dev.igb.1.queue2.lro_queued: 0 dev.igb.1.queue2.lro_flushed: 0 dev.igb.1.queue3.no_desc_avail: 0 dev.igb.1.queue3.tx_packets: 0 dev.igb.1.queue3.rx_packets: 0 dev.igb.1.queue3.rx_bytes: 0 dev.igb.1.queue3.lro_queued: 0 dev.igb.1.queue3.lro_flushed: 0 dev.igb.1.mac_stats.excess_coll: 0 dev.igb.1.mac_stats.single_coll: 0 dev.igb.1.mac_stats.multiple_coll: 0 dev.igb.1.mac_stats.late_coll: 0 dev.igb.1.mac_stats.collision_count: 0 dev.igb.1.mac_stats.symbol_errors: 0 dev.igb.1.mac_stats.sequence_errors: 0 dev.igb.1.mac_stats.defer_count: 0 dev.igb.1.mac_stats.missed_packets: 0 dev.igb.1.mac_stats.recv_no_buff: 0 dev.igb.1.mac_stats.recv_undersize: 0 dev.igb.1.mac_stats.recv_fragmented: 0 dev.igb.1.mac_stats.recv_oversize: 0 dev.igb.1.mac_stats.recv_jabber: 0 dev.igb.1.mac_stats.recv_errs: 0 dev.igb.1.mac_stats.crc_errs: 0 dev.igb.1.mac_stats.alignment_errs: 0 dev.igb.1.mac_stats.coll_ext_errs: 0 dev.igb.1.mac_stats.xon_recvd: 0 dev.igb.1.mac_stats.xon_txd: 0 dev.igb.1.mac_stats.xoff_recvd: 0 dev.igb.1.mac_stats.xoff_txd: 0 dev.igb.1.mac_stats.total_pkts_recvd: 0 dev.igb.1.mac_stats.good_pkts_recvd: 0 dev.igb.1.mac_stats.bcast_pkts_recvd: 0 dev.igb.1.mac_stats.mcast_pkts_recvd: 0 dev.igb.1.mac_stats.rx_frames_64: 0 dev.igb.1.mac_stats.rx_frames_65_127: 0 dev.igb.1.mac_stats.rx_frames_128_255: 0 dev.igb.1.mac_stats.rx_frames_256_511: 0 dev.igb.1.mac_stats.rx_frames_512_1023: 0 dev.igb.1.mac_stats.rx_frames_1024_1522: 0 dev.igb.1.mac_stats.good_octets_recvd: 0 dev.igb.1.mac_stats.good_octets_txd: 0 dev.igb.1.mac_stats.total_pkts_txd: 0 dev.igb.1.mac_stats.good_pkts_txd: 0 dev.igb.1.mac_stats.bcast_pkts_txd: 0 dev.igb.1.mac_stats.mcast_pkts_txd: 0 dev.igb.1.mac_stats.tx_frames_64: 0 dev.igb.1.mac_stats.tx_frames_65_127: 0 dev.igb.1.mac_stats.tx_frames_128_255: 0 dev.igb.1.mac_stats.tx_frames_256_511: 0 dev.igb.1.mac_stats.tx_frames_512_1023: 0 dev.igb.1.mac_stats.tx_frames_1024_1522: 0 dev.igb.1.mac_stats.tso_txd: 0 dev.igb.1.mac_stats.tso_ctx_fail: 0 dev.igb.1.interrupts.asserts: 118973 dev.igb.1.interrupts.rx_pkt_timer: 0 dev.igb.1.interrupts.rx_abs_timer: 0 dev.igb.1.interrupts.tx_pkt_timer: 0 dev.igb.1.interrupts.tx_abs_timer: 0 dev.igb.1.interrupts.tx_queue_empty: 0 dev.igb.1.interrupts.tx_queue_min_thresh: 0 dev.igb.1.interrupts.rx_desc_min_thresh: 0 dev.igb.1.interrupts.rx_overrun: 0 dev.igb.1.host.breaker_tx_pkt: 0 dev.igb.1.host.host_tx_pkt_discard: 0 dev.igb.1.host.rx_pkt: 0 dev.igb.1.host.breaker_rx_pkts: 0 dev.igb.1.host.breaker_rx_pkt_drop: 0 dev.igb.1.host.tx_good_pkt: 0 dev.igb.1.host.breaker_tx_pkt_drop: 0 dev.igb.1.host.rx_good_bytes: 0 dev.igb.1.host.tx_good_bytes: 0 dev.igb.1.host.length_errors: 0 dev.igb.1.host.serdes_violation_pkt: 0 dev.igb.1.host.header_redir_missed: 0 From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 21:50:40 2012 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 EF64C1065672 for ; Mon, 9 Jan 2012 21:50:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id B36018FC08 for ; Mon, 9 Jan 2012 21:50:39 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B1A5021F88 for ; Mon, 9 Jan 2012 16:50:38 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Jan 2012 16:50:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=a418uAtsFL/FvxujFGD3UY HvBRE=; b=Lw4Et94W2g83JQe9qcu0dHZeJKsQYjnmCrWSXBtyhreHBHKy8VOVlD 024uppRL4cIN32sIc3QgCRS8+BRh6hgmhHACmR1bg7XrTsM2kwTaIWlgEsN9DHgq 5jDeS4q4638LgjZ8XmPAEwK9tN/8Kxjk2+fITQ8yPHyEwBrGkRW54= X-Sasl-enc: bB9KMaL1ECwtxf6b/9X3Q1bRv/rxwi5ZVR5Ku8XfiC11 1326145838 Received: from [192.168.1.64] (94-192-87-254.zone6.bethere.co.uk [94.192.87.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 31E5648251C; Mon, 9 Jan 2012 16:50:38 -0500 (EST) Message-ID: <4F0B6169.5030704@incunabulum.net> Date: Mon, 09 Jan 2012 21:51:37 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Baldwin References: <201112221115.10239.jhb@freebsd.org> <4F0B0684.8040609@incunabulum.net> <201201091128.10193.jhb@freebsd.org> In-Reply-To: <201201091128.10193.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Deferring inp_freemoptions() to an asychronous task 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, 09 Jan 2012 21:50:40 -0000 John, I'm glad there are people, outside of finance and broadcast, who understand the teething pains of multicast. I might be able to spare cycles to test patches, so if someone steps up to the plate in the meantime, I'm happy to look where I can. We now have a FreeBSD testbed at work, having started a FreeBSD-based project with no infrastructure. "Of course it runs ZFS." John Baldwin wrote: > On Monday, January 09, 2012 10:23:48 am Bruce Simpson wrote: >> You've also stumbled on the behaviour specific to how BSD has >> traditionally dealt with broadcast/multicast sockets. The pcbinfo >> structure can't really be disentangled from this. >> >> Of course, it doesn't help that we have historically required these >> sockets to be bound to INADDR_ANY. It might be useful to break reception >> out using a separate hash/tree, rather than walking all sockets as is >> currently done, but legacy usage needs to be supported. >> > The other fun part in this case is that if it is going to take a long time, a > driver should probably be enabling reception of all multicast (equivalent of > IFF_ALLMULTI) while it reprograms the table to avoid dropping packets for > already-joined groups. I'm not currently doing this as we are using a different > hack, but I think that is something drivers should probably be doing. I couldn't agree more re IFF_ALLMULTI. One change which I would have liked to have made, during the IGMPv3/SSM project, was to re-do the join operation so we could do things like this a little more easily. Another would have been to add a limited wrapper around IFF_PROMISC (let's call that one IFF_SOFTMULTI), in situations where cards were known to have broken IFF_ALLMULTI. This would extend their useful lifetime into the IPv6 era, as well as making it possible to use them for ISO protocols, historic (CLNP) and useful (IS-IS), which like to have working link-layer multicast. The chances are that if you're doing any of these things, you are probably using non-broken hardware, or a vendor already lugging patches around for these things (in which case, please share). Or you are using pcap directly and feeling the suck of having to write everything userland at layer 2. I don't have much free time for development outside of work at the moment, otherwise I would be rattling off more diffs. As it is, I have Git to look forward to. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 23:01:32 2012 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 CBC75106566C for ; Mon, 9 Jan 2012 23:01:32 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2E53D8FC13 for ; Mon, 9 Jan 2012 23:01:31 +0000 (UTC) Received: (qmail 22585 invoked by uid 1001); 9 Jan 2012 23:01:30 -0000 Date: Tue, 10 Jan 2012 00:01:30 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20120109230130.GA3819@diehard.n-r-g.com> Mail-Followup-To: freebsd-net@freebsd.org References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> <20120104092824.GA24657@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 09 Jan 2012 23:01:32 -0000 On Mon, Jan 09, 2012 at 11:01:44AM +0100, Borja Marcos wrote: > > On Jan 4, 2012, at 10:28 AM, Claudio Jeker wrote: > > > On Wed, Jan 04, 2012 at 09:27:28AM +0100, Borja Marcos wrote: > >> > >> Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. > >> According to my packet captures, in case there's no properly set key > >> with setkey(8) it will use whatever key. Look at the captures mentioned > >> here: > >> > >> http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1 > >> > >> > >> Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless > >> there's a valid key associated to the socket, either using setkey(8) (I > >> don't know if they use it) or via the API for setting keys. > > > How does FreeBSD avoid the chicken and egg problem of accepting > > connections with MD5SIG? > > I understand, but what if you haven't configured any peer for MD5SIG? > Openbgpd is *still* enabling it. > > Maybe there's a simple solution in FreeBSD: ignoring the MD5SIG flags > (and not adding the option to the outgoing packets) _UNLESS_ there's a > matching SPD for the flow. I think that's the problem. It's pointless to > check MD5SIG or originate packets with MD5SIG when there's no matching > SPD. What does it use in that case, a random key? > > So I'm beginning to think that FreeBSD is the problem, not Openbgpd. > Although of course neither Quagga nor bird set the MD5 option when you > haven't explicitly enabled it in your BGP configuration. Since it is possible to add MD5 for neighbors on config reload and the listening sockets are normaly not closed and reopened on config reload it was the easiest to set the MD5 option on all listening sockets no matter what (especially since at that time OpenBSD was the only BSD doing TCP MD5 and the always enable was there from the beginning (actually the MD5SUM support was done for/with OpenBGPD). -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 08:01:39 2012 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 44D12106568E for ; Tue, 10 Jan 2012 08:01:39 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04b.sare.net (proxypop04b.sare.net [194.30.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id F0DF38FC15 for ; Tue, 10 Jan 2012 08:01:38 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id C0BC29DC48A; Tue, 10 Jan 2012 09:01:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120109230130.GA3819@diehard.n-r-g.com> Date: Tue, 10 Jan 2012 09:01:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F04F4D5-35E9-4B5F-9D43-F5F8035BA462@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> <20120104092824.GA24657@diehard.n-r-g.com> <20120109230130.GA3819@diehard.n-r-g.com> To: Claudio Jeker X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 10 Jan 2012 08:01:39 -0000 On Jan 10, 2012, at 12:01 AM, Claudio Jeker wrote: > Since it is possible to add MD5 for neighbors on config reload and the > listening sockets are normaly not closed and reopened on config reload = it > was the easiest to set the MD5 option on all listening sockets no = matter > what (especially since at that time OpenBSD was the only BSD doing TCP = MD5 > and the always enable was there from the beginning (actually the = MD5SUM > support was done for/with OpenBGPD). I see, so then the TCP stack should only set and check MD5 signatures = provided there's a matching CPD entry. Otherwise, using a random key = doesn't make sense at all. Right? ;) Borja. From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 10:24:06 2012 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 E4A05106566B for ; Tue, 10 Jan 2012 10:24:06 +0000 (UTC) (envelope-from dkmail@mail.neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id B23A38FC17 for ; Tue, 10 Jan 2012 10:24:06 +0000 (UTC) Received: by mail.neveragain.de (Postfix, from userid 1029) id 3C80817024; Tue, 10 Jan 2012 11:24:05 +0100 (CET) Date: Tue, 10 Jan 2012 11:24:05 +0100 From: Dennis Koegel To: freebsd-net@freebsd.org Message-ID: <20120110102405.GA82356@neveragain.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Unnecessary sleep in network.subr: ipv6_up() 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, 10 Jan 2012 10:24:07 -0000 Cheers, problem: Having a *lot* of IPv6 interfaces (Vlan interfaces in this case) causes a huge and annoying delay time at system boot in 9.0R. ipv6_up() in network.subr does this: + # wait for DAD + sleep `${SYSCTL_N} net.inet6.ip6.dad_count` + sleep 1 This happens for each and every interface, at a minimum (and default) of two seconds per interface. It seems the behaviour was introduced with r197139. Before this merge, /etc/rc.d/network_ipv6 did the same sleeps, but only once for the whole network startup. I don't see why this should happen per interface, so I suggest the extra sleeps are limited to "once per network startup" once again (or maybe removed?). - D. From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 13:23:14 2012 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 17EC2106564A for ; Tue, 10 Jan 2012 13:23:13 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 714708FC0A for ; Tue, 10 Jan 2012 13:23:12 +0000 (UTC) Received: (qmail 23233 invoked by uid 1001); 10 Jan 2012 13:23:11 -0000 Date: Tue, 10 Jan 2012 14:23:11 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20120110132311.GA26721@diehard.n-r-g.com> Mail-Followup-To: freebsd-net@freebsd.org References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> <20120104092824.GA24657@diehard.n-r-g.com> <20120109230130.GA3819@diehard.n-r-g.com> <1F04F4D5-35E9-4B5F-9D43-F5F8035BA462@sarenet.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F04F4D5-35E9-4B5F-9D43-F5F8035BA462@sarenet.es> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 10 Jan 2012 13:23:14 -0000 On Tue, Jan 10, 2012 at 09:01:35AM +0100, Borja Marcos wrote: > > On Jan 10, 2012, at 12:01 AM, Claudio Jeker wrote: > > > Since it is possible to add MD5 for neighbors on config reload and the > > listening sockets are normaly not closed and reopened on config reload it > > was the easiest to set the MD5 option on all listening sockets no matter > > what (especially since at that time OpenBSD was the only BSD doing TCP MD5 > > and the always enable was there from the beginning (actually the MD5SUM > > support was done for/with OpenBGPD). > > I see, so then the TCP stack should only set and check MD5 signatures > provided there's a matching CPD entry. Otherwise, using a random key > doesn't make sense at all. Right? ;) > Yes. A random key never makes sense since TCP MD5 works with a shared secret. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 20:12:38 2012 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 E8829106564A for ; Tue, 10 Jan 2012 20:12:38 +0000 (UTC) (envelope-from olli@fromme.com) Received: from box.thiemo.net (box.v6.thiemo.net [IPv6:2a01:4f8:130:3101::2]) by mx1.freebsd.org (Postfix) with ESMTP id 855FA8FC0C for ; Tue, 10 Jan 2012 20:12:38 +0000 (UTC) Received: from [10.156.138.218] ([89.204.155.218]) (authenticated bits=0) by box.thiemo.net (8.14.4/8.14.4) with ESMTP id q0AKCJCe095946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 Jan 2012 21:12:28 +0100 (CET) (envelope-from olli@fromme.com) User-Agent: K-9 Mail for Android MIME-Version: 1.0 From: Oliver Fromme Date: Tue, 10 Jan 2012 21:12:17 +0100 To: freebsd-net@freebsd.org Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (box.thiemo.net [88.198.168.138]); Tue, 10 Jan 2012 21:12:37 +0100 (CET) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: fromme@secnetix.de Subject: Processes' FIBs 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, 10 Jan 2012 20:12:39 -0000 Hi, Is there a way to find out the default FIB number of a process (from a shell script)? I've checked the manpages of ps and procstat, but they don't mention FIBs. I'm using stable/8, if that matters. Best regards Oliver -- From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 20:32:05 2012 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 BBB67106564A for ; Tue, 10 Jan 2012 20:32:05 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7AFF98FC17 for ; Tue, 10 Jan 2012 20:32:05 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 10 Jan 2012 15:32:03 -0500 Date: Tue, 10 Jan 2012 14:32:24 -0600 From: "Paul A. Procacci" To: Oliver Fromme Message-ID: <20120110203224.GB27191@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, fromme@secnetix.de Subject: Re: Processes' FIBs 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, 10 Jan 2012 20:32:05 -0000 http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.html Not sure about ps/et al, but you can do it according to that post. Nearly = 2 years old now. ~Paul On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote: > Hi, > > Is there a way to find out the default FIB number of a > process (from a shell script)? I've checked the > manpages of ps and procstat, but they don't mention > FIBs. I'm using stable/8, if that matters. > > Best regards > Oliver > > -- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for= further information on confidentiality and the risks of non-secure electro= nic communication. If you cannot access these links, please notify us by re= ply message and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 22:27:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A126F1065672; Tue, 10 Jan 2012 22:27:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EE33A150FFA; Tue, 10 Jan 2012 22:26:50 +0000 (UTC) Message-ID: <4F0CBB25.4060902@FreeBSD.org> Date: Tue, 10 Jan 2012 14:26:45 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Dennis Koegel References: <20120110102405.GA82356@neveragain.de> In-Reply-To: <20120110102405.GA82356@neveragain.de> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, hrs@FreeBSD.org Subject: Re: Unnecessary sleep in network.subr: ipv6_up() 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, 10 Jan 2012 22:27:03 -0000 Looping in the author of that change ... On 01/10/2012 02:24, Dennis Koegel wrote: > Cheers, > > problem: Having a *lot* of IPv6 interfaces (Vlan interfaces in this case) > causes a huge and annoying delay time at system boot in 9.0R. > > ipv6_up() in network.subr does this: > > + # wait for DAD > + sleep `${SYSCTL_N} net.inet6.ip6.dad_count` > + sleep 1 > > This happens for each and every interface, at a minimum (and default) of > two seconds per interface. > > It seems the behaviour was introduced with r197139. Before this merge, > /etc/rc.d/network_ipv6 did the same sleeps, but only once for the whole > network startup. > > I don't see why this should happen per interface, so I suggest the extra > sleeps are limited to "once per network startup" once again (or maybe > removed?). -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 23:21:18 2012 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 325461065673; Tue, 10 Jan 2012 23:21:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id EAEA88FC0A; Tue, 10 Jan 2012 23:21:17 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D280A4AC2D; Wed, 11 Jan 2012 03:21:13 +0400 (MSK) Date: Wed, 11 Jan 2012 03:21:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <108354307.20120111032108@serebryakov.spb.ru> To: FreeBSD current In-Reply-To: <1791250845.20120111030529@serebryakov.spb.ru> References: <1791250845.20120111030529@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: mav@freebsd.org, net@freebsd.org Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 23:21:18 -0000 Hello, Lev. You wrote 11 =FF=ED=E2=E0=F0=FF 2012 =E3., 3:05:29: > OH! I have top running right now, when it "hangs". 0% idle time, LA > becomes 20 when it have only 35 processes at all, but there is no specif= ic > process consuming CPU. Ok, it seems, that here is a problem (CPU time : PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 12 root -16 - 0K 8K sleep 18:35 30.18% ng_queue And after that 5 minutes without updates, than normal numbers. It seems, that root of problem is: (a) netgraph in this version of kernel OR (b) new mpd 5.6 (previous version had 5.5). P.S. Adding net@ and mav@ to CC, original posting with all data is in current@ --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 10 23:29:30 2012 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 ED7BC106566B; Tue, 10 Jan 2012 23:29:30 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B1D9F8FC08; Tue, 10 Jan 2012 23:29:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 69BEC4AC2D; Wed, 11 Jan 2012 03:29:29 +0400 (MSK) Date: Wed, 11 Jan 2012 03:29:25 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <521415637.20120111032925@serebryakov.spb.ru> To: FreeBSD current In-Reply-To: <108354307.20120111032108@serebryakov.spb.ru> References: <1791250845.20120111030529@serebryakov.spb.ru> <108354307.20120111032108@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: mav@freebsd.org, net@freebsd.org Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under 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: Tue, 10 Jan 2012 23:29:31 -0000 Hello, Lev. You wrote 11 =FF=ED=E2=E0=F0=FF 2012 =E3., 3:21:08: >> OH! I have top running right now, when it "hangs". 0% idle time, LA >> becomes 20 when it have only 35 processes at all, but there is no speci= fic >> process consuming CPU. > Ok, it seems, that here is a problem (CPU time : > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > 12 root -16 - 0K 8K sleep 18:35 30.18% ng_queue And even more: last pid: 2450; load averages: 11.97, 5.12, 5.60 up 0+00:50:39 03:2= 5:57 75 processes: 7 running, 54 sleeping, 14 waiting CPU: 0.0% user, 0.0% nice, 89.8% system, 9.6% interrupt, 0.7% idle Mem: 46M Active, 23M Inact, 43M Wired, 8K Cache, 56M Buf, 382M Free Swap: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 12 root -16 - 0K 8K sleep 20:09 93.80% ng_queue 11 root -72 - 0K 112K WAIT 17:26 3.96% intr{swi1: netis= r 0} 11 root -92 - 0K 112K WAIT 0:21 0.20% intr{irq15: ath0= ata --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 00:01:21 2012 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 B46291065670; Wed, 11 Jan 2012 00:01:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 784AF8FC0C; Wed, 11 Jan 2012 00:01:21 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id AD48B4AC2D; Wed, 11 Jan 2012 04:01:19 +0400 (MSK) Date: Wed, 11 Jan 2012 04:01:14 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <16821107.20120111040114@serebryakov.spb.ru> To: Alexander Motin In-Reply-To: <4F0CCB50.8020109@FreeBSD.org> References: <1791250845.20120111030529@serebryakov.spb.ru> <108354307.20120111032108@serebryakov.spb.ru> <4F0CCB50.8020109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current , net@freebsd.org Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 00:01:21 -0000 Hello, Alexander. You wrote 11 =FF=ED=E2=E0=F0=FF 2012 =E3., 3:35:44: > I remember no changes in mpd-5.6 that I would expect to cause this. Any > way it should be trivial to check -- just build 5.5. I'll try tomorrow. > What do you have configured in mpd configuration and netgraph at all?=20 > AFAIR for plain PPPoE it is not very typical to use ng_queue at all as > it doesn't requires stack unwrapping and at least few years ago stack=20 > size was sufficient to run all processing in one pass. I've sent config to you directly. BTW, I've never seen ng_queue in top 10 lines before. Interrupts? For sure. Soft interurpts (netisr)? Yes. ng_queue? Never. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 00:05:31 2012 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 83DB91065670; Wed, 11 Jan 2012 00:05:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D995C8FC18; Wed, 11 Jan 2012 00:05:30 +0000 (UTC) Received: by eekd49 with SMTP id d49so59444eek.13 for ; Tue, 10 Jan 2012 16:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xmwjxX0tFjRn8O7ECuVQdr1nyRg9vUmZTlvbAQMDr6w=; b=XfRI3R5AkwSahOdcfpfM35IImAvwwdlK4q+jfD9c9KlxqSaO8lIj7c3Y0CXs0HMP4H 4YYMMWpcZDCCfhFFXwf11hgrdP0vr277vcopu/RF+pCcto9t8mg0mlZBYFBLQmrTQQeK oo6VbZbzEWEWmZiIk1eTJuBB9BpERahFKrgBA= Received: by 10.213.19.73 with SMTP id z9mr668134eba.41.1326238548606; Tue, 10 Jan 2012 15:35:48 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id a60sm310378713eeb.4.2012.01.10.15.35.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 15:35:47 -0800 (PST) Sender: Alexander Motin Message-ID: <4F0CCB50.8020109@FreeBSD.org> Date: Wed, 11 Jan 2012 01:35:44 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1791250845.20120111030529@serebryakov.spb.ru> <108354307.20120111032108@serebryakov.spb.ru> In-Reply-To: <108354307.20120111032108@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD current , net@freebsd.org Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under 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: Wed, 11 Jan 2012 00:05:31 -0000 On 01/11/12 01:21, Lev Serebryakov wrote: > Hello, Lev. > You wrote 11 ÿíâàðÿ 2012 ã., 3:05:29: > >> OH! I have top running right now, when it "hangs". 0% idle time, LA >> becomes 20 when it have only 35 processes at all, but there is no specific >> process consuming CPU. > Ok, it seems, that here is a problem (CPU time : > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > 12 root -16 - 0K 8K sleep 18:35 30.18% ng_queue > > And after that 5 minutes without updates, than normal numbers. It > seems, that root of problem is: > > (a) netgraph in this version of kernel > OR > (b) new mpd 5.6 (previous version had 5.5). I remember no changes in mpd-5.6 that I would expect to cause this. Any way it should be trivial to check -- just build 5.5. What do you have configured in mpd configuration and netgraph at all? AFAIR for plain PPPoE it is not very typical to use ng_queue at all as it doesn't requires stack unwrapping and at least few years ago stack size was sufficient to run all processing in one pass. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 01:14:18 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2D901106566B; Wed, 11 Jan 2012 01:14:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E4216152713; Wed, 11 Jan 2012 01:14:16 +0000 (UTC) Message-ID: <4F0CE268.1000903@FreeBSD.org> Date: Tue, 10 Jan 2012 17:14:16 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Hiroki Sato References: <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <20120104.060327.1335862860296491365.hrs@allbsd.org> In-Reply-To: <20120104.060327.1335862860296491365.hrs@allbsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 11 Jan 2012 01:14:18 -0000 On 01/03/2012 13:03, Hiroki Sato wrote: > Okay, thank you for your report. I will take some time to fix > TCP_MD5SIG support in openbgpd and inform you when another patch is > ready. Any news on this? Not trying to be pushy, just wondering if I need to plan a test/change window. Thanks, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 08:35:19 2012 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 9BE27106564A for ; Wed, 11 Jan 2012 08:35:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 263258FC0C for ; Wed, 11 Jan 2012 08:35:19 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 91BAB25D3892; Wed, 11 Jan 2012 08:35:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 16422BD8EF1; Wed, 11 Jan 2012 08:35:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id MfH6drlAwTvu; Wed, 11 Jan 2012 08:35:14 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DC448BD8EF0; Wed, 11 Jan 2012 08:35:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120110203224.GB27191@nat.myhome> Date: Wed, 11 Jan 2012 08:35:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120110203224.GB27191@nat.myhome> To: Paul A. Procacci X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, fromme@secnetix.de, Oliver Fromme Subject: Re: Processes' FIBs 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, 11 Jan 2012 08:35:19 -0000 On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote: > = http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.htm= l >=20 > Not sure about ps/et al, but you can do it according to that post. = Nearly 2 years old now. >=20 If you are thinking in terms of multiple forwarding information bases, = yes sysctl net.my_fibnum /bz > ~Paul >=20 > On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote: >> Hi, >>=20 >> Is there a way to find out the default FIB number of a >> process (from a shell script)? I've checked the >> manpages of ps and procstat, but they don't mention >> FIBs. I'm using stable/8, if that matters. >>=20 >> Best regards >> Oliver >>=20 >> -- >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >=20 > ________________________________ >=20 > This message may contain confidential or privileged information. If = you are not the intended recipient, please advise us immediately and = delete this message. See = http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further = information on confidentiality and the risks of non-secure electronic = communication. If you cannot access these links, please notify us by = reply message and we will send the contents to you. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 14:20:09 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1181065676 for ; Wed, 11 Jan 2012 14:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A72F58FC19 for ; Wed, 11 Jan 2012 14:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0BEK9TP053081 for ; Wed, 11 Jan 2012 14:20:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0BEK9bE053080; Wed, 11 Jan 2012 14:20:09 GMT (envelope-from gnats) Date: Wed, 11 Jan 2012 14:20:09 GMT Message-Id: <201201111420.q0BEK9bE053080@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vladimir Kutakov Cc: Subject: Re: kern/155597: [panic] Kernel panics with " sbdrop" message X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vladimir Kutakov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 14:20:09 -0000 The following reply was made to PR kern/155597; it has been noted by GNATS. From: Vladimir Kutakov To: Arnaud Lacombe Cc: bug-followup@FreeBSD.org Subject: Re: kern/155597: [panic] Kernel panics with "sbdrop" message Date: Wed, 11 Jan 2012 17:55:41 +0400 We have tried RELENG_8_2 and the panic doesn't happen anymore. Many = thanks to the FreeBSD team. On Aug 17, 2011, at 1:43 AM, Arnaud Lacombe wrote: > Hi, >=20 > Does this still happen with 9.0-BETA ? >=20 > If so, could this be a use-after-free, where an mbuf is freed (during > an m_pullup() or alike), but the old reference is still kept around, > gets added to the sockbuf, then the mbuf is re-allocated and corrupt > the sockbuf ? -- =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80 =D0=9A=D1=83=D1=82=D0=B0=D0= =BA=D0=BE=D0=B2 =D0=A2=D0=B5=D1=85=D0=BD=D0=B8=D1=87=D0=B5=D1=81=D0=BA=D0=B8=D0=B9 = =D0=B4=D0=B8=D1=80=D0=B5=D0=BA=D1=82=D0=BE=D1=80 =D0=97=D0=90=D0=9E "=D0=9F=D0=BE=D0=B8=D1=81=D0=BA=D0=BE=D0=B2=D1=8B=D0=B5= =D1=82=D0=B5=D1=85=D0=BD=D0=BE=D0=BB=D0=BE=D0=B3=D0=B8=D0=B8" vova@ashmanov.com From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 15:06:57 2012 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 49E8B106566B; Wed, 11 Jan 2012 15:06:57 +0000 (UTC) (envelope-from olli@fromme.com) Received: from haluter.fromme.com (unknown [IPv6:2a01:170:102f:0:2a0:c9ff:fe42:8524]) by mx1.freebsd.org (Postfix) with ESMTP id B6B178FC0C; Wed, 11 Jan 2012 15:06:56 +0000 (UTC) Received: from haluter.fromme.com (irc_sucks@localhost [127.0.0.1]) by haluter.fromme.com (8.14.4/8.14.4) with ESMTP id q0BF6fwl067590; Wed, 11 Jan 2012 16:06:50 +0100 (CET) (envelope-from olli@fromme.com) Received: (from olli@localhost) by haluter.fromme.com (8.14.4/8.14.4/Submit) id q0BF6eAx067588; Wed, 11 Jan 2012 16:06:40 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201201111506.q0BF6eAx067588@haluter.fromme.com> To: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed, 11 Jan 2012 16:06:40 +0100 (CET) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (haluter.fromme.com [127.0.0.1]); Wed, 11 Jan 2012 16:06:50 +0100 (CET) Cc: freebsd-net@freebsd.org, olli@secnetix.de, "Paul A. Procacci" , freebsd-hackers@freebsd.org Subject: Re: Processes' FIBs 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, 11 Jan 2012 15:06:57 -0000 Bjoern A. Zeeb wrote: > On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote: > > On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote: > > > Is there a way to find out the default FIB number of a > > > process (from a shell script)? I've checked the > > > manpages of ps and procstat, but they don't mention > > > FIBs. I'm using stable/8, if that matters. > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.html > > > > Not sure about ps/et al, but you can do it according to that post. Nearly 2 years old now. To be honest, I prefer not to fumble around in kernel memory with kgdb in a shell script. Also, it requires root privilege (setfib does not). > If you are thinking in terms of multiple forwarding information bases, yes > sysctl net.my_fibnum Thanks. Would it make sense to document that in setfib(1)? However, I need to find the default FIB number for arbitrary processes, not necessarily for the calling process. I'm currently looking at the source code of ps, but adding a field for the FIB isn't as trivial as I thought because ps only sees struct kinfo_proc (via sysctl kern.proc.*) which doesn't contain the FIB. procstat does the same. I'm currently trying to write a patch that copies p_fibnum from struct proc to struct kinfo_proc (just like p_nice, for example). Does that make sense? If so, does the patch below look reasonable? (I've made it on a stable/8 system, but it should apply to 9 and 10, too.) Best regards Oliver --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 @@ -83,7 +83,7 @@ * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and * function kvm_proclist in lib/libkvm/kvm_proc.c . */ -#define KI_NSPARE_INT 9 +#define KI_NSPARE_INT 8 #define KI_NSPARE_LONG 12 #define KI_NSPARE_PTR 6 @@ -177,6 +177,7 @@ */ char ki_sparestrings[68]; /* spare string space */ int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ + int ki_fibnum; /* Default FIB number */ u_int ki_cr_flags; /* Credential flags */ int ki_jid; /* Process jail ID */ int ki_numthreads; /* XXXKSE number of threads in total */ --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 @@ -775,6 +775,7 @@ kp->ki_swtime = (ticks - p->p_swtick) / hz; kp->ki_pid = p->p_pid; kp->ki_nice = p->p_nice; + kp->ki_fibnum = p->p_fibnum; PROC_SLOCK(p); rufetch(p, &kp->ki_rusage); kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 @@ -90,6 +90,7 @@ NULL, 0}, {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0}, {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 18:13:05 2012 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 E7860106576E for ; Wed, 11 Jan 2012 18:13:01 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (alexdupre-1-pt.tunnel.tserv23.zrh1.ipv6.he.net [IPv6:2001:470:25:450::2]) by mx1.freebsd.org (Postfix) with ESMTP id B81D78FC17 for ; Wed, 11 Jan 2012 18:13:00 +0000 (UTC) Received: (qmail 526 invoked from network); 11 Jan 2012 18:12:59 -0000 Received: from atom.alexdupre.com (HELO ?192.168.178.12?) (sysadmin@alexdupre.com@192.168.178.12) by lab.alexdupre.com with ESMTPSA; 11 Jan 2012 18:12:59 -0000 Message-ID: <4F0DD127.4040205@FreeBSD.org> Date: Wed, 11 Jan 2012 19:12:55 +0100 From: Alex Dupre User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Filtering on IPSEC 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, 11 Jan 2012 18:13:06 -0000 Hi All, I've setup my first IPSEC VPN beetween FreeBSD 8.2 and CheckPoint VPN-1. I've used a gif interface for the tunnel, setkey for security policies and racoon for ikev1. All is working fine, but I get a strange behavior: outgoing packets go via enc0, while incoming packets arrive in gif0. To be precise, setting to '3' all the net.enc.* sysctls and sending a ping via vpn, I see the echo request, the encapsulated echo request, the encapsulated echo reply on enc0 and the echo reply on gif0. Is it correct? I expected to see all 4 packets on enc0, and perhaps the 2 clear packets also on gif0. The current behavior makes impossibile to use firewall stateful filtering. I have also another question (about NAT before IPSEC), but it's partially related to this first issue, so I'll wait for a clarification before exposing it. -- Alex Dupre From owner-freebsd-net@FreeBSD.ORG Wed Jan 11 20:33:39 2012 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 77A50106564A; Wed, 11 Jan 2012 20:33:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB9A8FC0C; Wed, 11 Jan 2012 20:33:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 82E7A4AC31; Thu, 12 Jan 2012 00:33:37 +0400 (MSK) Date: Thu, 12 Jan 2012 00:33:32 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <19210156623.20120112003332@serebryakov.spb.ru> To: Chuck Burns In-Reply-To: <4F0CCDFC.9020901@gmail.com> References: <1791250845.20120111030529@serebryakov.spb.ru> <108354307.20120111032108@serebryakov.spb.ru> <4F0CCDFC.9020901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Alexander Motin , freebsd-current@freebsd.org Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:33:39 -0000 Hello, Chuck. You wrote 11 =FF=ED=E2=E0=F0=FF 2012 =E3., 3:47:08: > If it were me, I would also try with the older 44BSD scheduler, just to > see what happens. It helps both with mpd5.5 and mpd5.6. Now under network load top lines in `top' are PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 10 root 155 ki31 0K 8K RUN 2:19 60.74% idle 11 root -72 - 0K 112K WAIT 1:47 32.03% intr{swi1: netis= r 0} And system is very responsive. ng_queue is not in top 17 (one screen) lines of `top' any more, it looks usual to me. I'll try to find revision, which breaks ULE + NetGraph by binary search, but it takes some time as here is 590 revisions in "head/sys" between previous version I used (which works Ok with ULE) and current version (which doesn't). So, it should be ~9 iterations, and every iteration takes ~1 hour and I could not spend 9 hours in row on this task. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 00:59:32 2012 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 A9EB9106564A; Thu, 12 Jan 2012 00:59:32 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFF08FC16; Thu, 12 Jan 2012 00:59:32 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id DA1AA25D386E; Thu, 12 Jan 2012 00:59:30 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id ECD06BD800E; Thu, 12 Jan 2012 00:59:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id SiDitGUUgxg8; Thu, 12 Jan 2012 00:59:28 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D4380BD800D; Thu, 12 Jan 2012 00:59:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F0DD127.4040205@FreeBSD.org> Date: Thu, 12 Jan 2012 00:59:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6B1A8EF0-C5BA-4EF3-B886-8F7C490564E5@lists.zabbadoz.net> References: <4F0DD127.4040205@FreeBSD.org> To: Alex Dupre X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org Subject: Re: Filtering on IPSEC 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, 12 Jan 2012 00:59:32 -0000 On 11. Jan 2012, at 18:12 , Alex Dupre wrote: > Hi All, > I've setup my first IPSEC VPN beetween FreeBSD 8.2 and CheckPoint = VPN-1. I've used a gif interface for the tunnel, setkey for security = policies and racoon for ikev1. All is working fine, but I get a strange = behavior: outgoing packets go via enc0, while incoming packets arrive in = gif0. To be precise, setting to '3' all the net.enc.* sysctls and = sending a ping via vpn, I see the echo request, the encapsulated echo = request, the encapsulated echo reply on enc0 and the echo reply on gif0. = Is it correct? I expected to see all 4 packets on enc0, and perhaps the = 2 clear packets also on gif0. The current behavior makes impossibile to = use firewall stateful filtering. Need more input. A) why are using gif? B) are you using transport = mode? > I have also another question (about NAT before IPSEC), but it's = partially related to this first issue, so I'll wait for a clarification = before exposing it. NAT before IPSEC can be done with ipfw, not with pf, don't know about = ipfilter. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 01:00:33 2012 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 1F5541065692; Thu, 12 Jan 2012 01:00:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 46ED88FC30; Thu, 12 Jan 2012 01:00:27 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1BCD625D3899; Thu, 12 Jan 2012 01:00:25 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2928FBD800E; Thu, 12 Jan 2012 01:00:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id K5lL9u9LTk22; Thu, 12 Jan 2012 01:00:23 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 989DBBD8010; Thu, 12 Jan 2012 01:00:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201201111506.q0BF6eAx067588@haluter.fromme.com> Date: Thu, 12 Jan 2012 01:00:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201111506.q0BF6eAx067588@haluter.fromme.com> To: Oliver Fromme X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, olli@secnetix.de, "Paul A. Procacci" , freebsd-hackers@freebsd.org Subject: Re: Processes' FIBs 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, 12 Jan 2012 01:00:33 -0000 On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: >=20 > Bjoern A. Zeeb wrote: >> On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote: >>> On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote: >>>> Is there a way to find out the default FIB number of a >>>> process (from a shell script)? I've checked the >>>> manpages of ps and procstat, but they don't mention >>>> FIBs. I'm using stable/8, if that matters. >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.htm= l >>>=20 >>> Not sure about ps/et al, but you can do it according to that post. = Nearly 2 years old now. >=20 > To be honest, I prefer not to fumble around in kernel memory > with kgdb in a shell script. Also, it requires root privilege > (setfib does not). >=20 >> If you are thinking in terms of multiple forwarding information = bases, yes >> sysctl net.my_fibnum >=20 > Thanks. Would it make sense to document that in setfib(1)? >=20 > However, I need to find the default FIB number for arbitrary > processes, not necessarily for the calling process. >=20 > I'm currently looking at the source code of ps, but adding > a field for the FIB isn't as trivial as I thought because > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > which doesn't contain the FIB. procstat does the same. >=20 > I'm currently trying to write a patch that copies p_fibnum > from struct proc to struct kinfo_proc (just like p_nice, > for example). Does that make sense? If so, does the patch > below look reasonable? (I've made it on a stable/8 system, > but it should apply to 9 and 10, too.) I am not sure it makes too much sense in ps. It might make sense in sockstat maybe? > Best regards > Oliver >=20 > --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 > +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 > @@ -83,7 +83,7 @@ > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c = and > * function kvm_proclist in lib/libkvm/kvm_proc.c . > */ > -#define KI_NSPARE_INT 9 > +#define KI_NSPARE_INT 8 > #define KI_NSPARE_LONG 12 > #define KI_NSPARE_PTR 6 >=20 > @@ -177,6 +177,7 @@ > */ > char ki_sparestrings[68]; /* spare string space */ > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth = */ > + int ki_fibnum; /* Default FIB number */ > u_int ki_cr_flags; /* Credential flags */ > int ki_jid; /* Process jail ID */ > int ki_numthreads; /* XXXKSE number of threads in = total */ > --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 = +0200 > +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 > @@ -775,6 +775,7 @@ > kp->ki_swtime =3D (ticks - p->p_swtick) / hz; > kp->ki_pid =3D p->p_pid; > kp->ki_nice =3D p->p_nice; > + kp->ki_fibnum =3D p->p_fibnum; > PROC_SLOCK(p); > rufetch(p, &kp->ki_rusage); > kp->ki_runtime =3D cputick2usec(p->p_rux.rux_runtime); > --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 > +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 > @@ -90,6 +90,7 @@ > NULL, 0}, > {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, = NULL, 0}, > {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, > + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, = "d", 0}, > {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, = 0}, > {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), = LONG, >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 01:01:59 2012 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 10FB5106564A; Thu, 12 Jan 2012 01:01:59 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D53D28FC0C; Thu, 12 Jan 2012 01:01:58 +0000 (UTC) Received: by pbdt13 with SMTP id t13so8916pbd.13 for ; Wed, 11 Jan 2012 17:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mhjevjwm7Qowxafinm0IS/mjQ6AwYsbs9kVWqEQXTcc=; b=L6E6f4Rd+6x+IreyLH+lH3HmjhBpaB6e+KZpoqen+Sv+0ejPMsPC7ntQ1Zl+eUIeTv sZ/WPx3nZ/SEuDaCh3OVusBCAi0vJ6dcjs/nw1/OF6MY4Th8ptqiCwnwL+NtqrlaF+Yh ruvgU/oOa3LYd9zSJtLhl6kHJYTdcF1R5Ftfc= MIME-Version: 1.0 Received: by 10.68.197.7 with SMTP id iq7mr1603059pbc.62.1326328229331; Wed, 11 Jan 2012 16:30:29 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.68.42.73 with HTTP; Wed, 11 Jan 2012 16:30:29 -0800 (PST) In-Reply-To: <20100724121539.D57851@maildrop.int.zabbadoz.net> References: <20100724121539.D57851@maildrop.int.zabbadoz.net> Date: Thu, 12 Jan 2012 01:30:29 +0100 X-Google-Sender-Auth: tK4xB2e8ADOURTA_ohH4IzIwx2s Message-ID: From: "K. Macy" To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, alan yang , freebsd-hackers@freebsd.org Subject: Re: interface for import/export flowtable 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, 12 Jan 2012 01:01:59 -0000 On Sat, Jul 24, 2010 at 2:17 PM, Bjoern A. Zeeb wrote: > On Thu, 22 Jul 2010, alan yang wrote: > > Hey, > > >> Wonder people had implemented interface to import / export flowtable. > Yes I did, and I added an API to query it more generally. I didn't add it to net/flowtable.c because my usage seemed too niche. > > what exactly do you want to accomplish with that? I used it for redirecting flows in an application that did L7 DSR load balancing. HTH. Cheers > -- > Bjoern A. Zeeb =A0 =A0From August on I will have a life. =A0It's now up t= o you > to do the maths and count to 64. =A0 =A0 -- Bondorf, Germany, 14th June 2= 010 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 02:38:07 2012 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 98473106566C for ; Thu, 12 Jan 2012 02:38:07 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED4E8FC12 for ; Thu, 12 Jan 2012 02:38:07 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 6DC8D1FF0104 for ; Wed, 11 Jan 2012 21:14:27 -0500 (EST) Thread-Index: AczQz+jiNAOZFbLASi6Y9ZSHWsJe3g== Received: from hometx-733b1p1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 21:14:25 -0500 Received: by hometx-733b1p1.corp.verio.net (sSMTP sendmail emulation); Wed, 11 Jan 2012 20:14:25 -0600 Date: Wed, 11 Jan 2012 20:14:24 -0600 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20120112021423.GG7008@verio.net> Content-class: urn:content-classes:message Mail-Followup-To: freebsd-net@freebsd.org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Importance: normal Priority: normal References: <4F0DD127.4040205@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4F0DD127.4040205@FreeBSD.org> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 12 Jan 2012 02:14:26.0024 (UTC) FILETIME=[E8405680:01CCD0CF] Subject: Re: Filtering on IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 02:38:07 -0000 Alex Dupre wrote: > > I've setup my first IPSEC VPN beetween FreeBSD 8.2 and CheckPoint > VPN-1. I've used a gif interface for the tunnel, setkey for security > policies and racoon for ikev1. I've peered with Checkpoint VPN's using FreeBSD but I never needed to use gif interfaces to make it happen. FreeBSD's tunnel-mode IPSEC seems to interoperate quite well with Checkpoint's implementation. You should be able to match tunneled traffic using SPD's like so: spdadd 10.27.37.0/24 172.30.101.0/24 any -P in ipsec esp/tunnel/192.250.40.23-238.55.55.15/unique; spdadd 172.30.101.0/24 10.27.37.0/24 any -P out ipsec esp/tunnel/238.55.55.15-192.250.40.23/unique; With the matching 'sainfo' sections in racoon's config: sainfo address 10.27.37.0/24 any address 172.30.101.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 172.30.101.0/24 any address 10.27.37.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } > All is working fine, but I get a strange behavior: outgoing packets go > via enc0, while incoming packets arrive in gif0. Admittedly, I had set all this up back in the FreeBSD 6.x days, before the 'enc0' interface was invented, so I can't speak to how the traffic flow works exactly, but it still seems to me that using gif is needlessly complicating your setup, so you may want to simplify it. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 07:29:18 2012 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 D5C74106566B for ; Thu, 12 Jan 2012 07:29:18 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (alexdupre-1-pt.tunnel.tserv23.zrh1.ipv6.he.net [IPv6:2001:470:25:450::2]) by mx1.freebsd.org (Postfix) with ESMTP id 141FE8FC16 for ; Thu, 12 Jan 2012 07:29:17 +0000 (UTC) Received: (qmail 14027 invoked from network); 12 Jan 2012 07:29:16 -0000 Received: from atom.alexdupre.com (HELO ?192.168.178.12?) (sysadmin@alexdupre.com@192.168.178.12) by lab.alexdupre.com with ESMTPSA; 12 Jan 2012 07:29:16 -0000 Message-ID: <4F0E8BC8.2020703@FreeBSD.org> Date: Thu, 12 Jan 2012 08:29:12 +0100 From: Alex Dupre User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4F0DD127.4040205@FreeBSD.org> <6B1A8EF0-C5BA-4EF3-B886-8F7C490564E5@lists.zabbadoz.net> In-Reply-To: <6B1A8EF0-C5BA-4EF3-B886-8F7C490564E5@lists.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Filtering on IPSEC 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, 12 Jan 2012 07:29:18 -0000 Bjoern A. Zeeb ha scritto: > Need more input. A) why are using gif? B) are you using transport mode? I'm using gif, because the official FreeBSD documentation says so (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html). My configuration is very similar to what described in that page. If that's not the correct way, I'll fix the documentation after understanding the right procedure. I'm using tunnel mode for network to network vpn. > NAT before IPSEC can be done with ipfw, not with pf, don't know about ipfilter. Can you elaborate a little more about the reason ipfw can and pf cannot? Is it because with ipfw/nat the packet is reinjected with the translated src IP and so matched by SPD? Currently, with my setup and pf, I faced exactly these two problems (SPD match before translation and i/o on different interfaces). I think it's not so uncommon that the two networks may collide, so assigning a "good" ip to one endpoint gateway and making NAT on it should be well documentated in our handbook. If you give me a hint on how this could be achieved with ipfw I'll update the docs accordingly. Thanks for your support. -- Alex Dupre From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 07:55:45 2012 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 DFF4A1065672; Thu, 12 Jan 2012 07:55:45 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 91F4B8FC16; Thu, 12 Jan 2012 07:55:45 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CF55825D37C7; Thu, 12 Jan 2012 07:55:44 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 17AC4BD9009; Thu, 12 Jan 2012 07:55:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Ub0-OKV696uo; Thu, 12 Jan 2012 07:55:42 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BF681BD9008; Thu, 12 Jan 2012 07:55:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F0E8BC8.2020703@FreeBSD.org> Date: Thu, 12 Jan 2012 07:55:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F0DD127.4040205@FreeBSD.org> <6B1A8EF0-C5BA-4EF3-B886-8F7C490564E5@lists.zabbadoz.net> <4F0E8BC8.2020703@FreeBSD.org> To: Alex Dupre X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org Subject: Re: Filtering on IPSEC 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, 12 Jan 2012 07:55:46 -0000 On 12. Jan 2012, at 07:29 , Alex Dupre wrote: > Bjoern A. Zeeb ha scritto: >> Need more input. A) why are using gif? B) are you using transport = mode? >=20 > I'm using gif, because the official FreeBSD documentation says so = (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html). = My configuration is very similar to what described in that page. If = that's not the correct way, I'll fix the documentation after = understanding the right procedure. It's not and hasn't been in ... I think there was someone fixing the = documentation actually lately... I'll ping people and see where that = went. > I'm using tunnel mode for network to network vpn. If you are using tunnel mode and gif you'll have trouble; just use = tunnel mode without gif and you'll be happy. >> NAT before IPSEC can be done with ipfw, not with pf, don't know about = ipfilter. >=20 > Can you elaborate a little more about the reason ipfw can and pf = cannot? Is it because with ipfw/nat the packet is reinjected with the = translated src IP and so matched by SPD? Currently, with my setup and = pf, I faced exactly these two problems (SPD match before translation and = i/o on different interfaces). It's because (our) pf cannot NAT on incoming but only on outgoing = interfaces. And you need to NAT on packet entry into the system... > I think it's not so uncommon that the two networks may collide, so = assigning a "good" ip to one endpoint gateway and making NAT on it = should be well documentated in our handbook. If you give me a hint on = how this could be achieved with ipfw I'll update the docs accordingly. The answer is use IPv6 and ... oh wait.. not the answer you wanted to = hear;) I haven't done it in probably 5 years or so now but basically you setup = the nat on the incoming (probably your inside) interface and take care = of localhost as much as needed. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 09:10:56 2012 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 4CE35106564A; Thu, 12 Jan 2012 09:10:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D74C78FC08; Thu, 12 Jan 2012 09:10:55 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id DF1094AC2D; Thu, 12 Jan 2012 13:10:53 +0400 (MSK) Date: Thu, 12 Jan 2012 13:10:47 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <287819916.20120112131047@serebryakov.spb.ru> To: Chuck Burns , freebsd-net@freebsd.org, Alexander Motin , , Adrian Chadd In-Reply-To: <19210156623.20120112003332@serebryakov.spb.ru> References: <1791250845.20120111030529@serebryakov.spb.ru> <108354307.20120111032108@serebryakov.spb.ru> <4F0CCDFC.9020901@gmail.com> <19210156623.20120112003332@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:10:56 -0000 Hello, Lev. You wrote 12 =FF=ED=E2=E0=F0=FF 2012 =E3., 0:33:32: > I'll try to find revision, which breaks ULE + NetGraph by binary > search, but it takes some time as here is 590 revisions in "head/sys" > between previous version I used (which works Ok with ULE) and current > version (which doesn't). So, it should be ~9 iterations, and every > iteration takes ~1 hour and I could not spend 9 hours in row on this > task. Everything is much worse, that I thought. mpd built on old systems could not work on new ones and vice versa. I need to rebuild FULL system (not only kernel), update build box, rebuild ports, build image for router. It is about 5 hours per version. More than 512 revisions to search, about 10 iterations. FML. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 09:13:48 2012 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 7837F106566C for ; Thu, 12 Jan 2012 09:13:48 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id A49408FC08 for ; Thu, 12 Jan 2012 09:13:47 +0000 (UTC) Received: (qmail 24593 invoked from network); 12 Jan 2012 08:47:05 -0000 Received: from unknown (HELO alex.andxor.it) (192.168.2.30) by andxor.it with SMTP; 12 Jan 2012 08:47:05 -0000 Message-ID: <4F0E9E09.9040106@FreeBSD.org> Date: Thu, 12 Jan 2012 09:47:05 +0100 From: Alex Dupre User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0.1) Gecko/20111227 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4F0DD127.4040205@FreeBSD.org> <6B1A8EF0-C5BA-4EF3-B886-8F7C490564E5@lists.zabbadoz.net> <4F0E8BC8.2020703@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Filtering on IPSEC 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, 12 Jan 2012 09:13:48 -0000 Bjoern A. Zeeb ha scritto: > If you are using tunnel mode and gif you'll have trouble; just use tunnel mode without gif and you'll be happy. Done, it works and I see all packets on enc0 now, thanks. > It's because (our) pf cannot NAT on incoming but only on outgoing interfaces. And you need to NAT on packet entry into the system... I found a setup that seems to work in my scenario with pf, but I'm not sure it's 100% correct. Basically I added nat on enc0 and then added a new policy including my internal lan. Scenario: - virtual ip (where nat takes place): 172.22.0.5 - internal lan: 192.168.2.0/24 - other lan: 172.28.0.0/16 In pf.conf I added: nat on enc0 from 192.168.2.0/24 to any -> 172.22.0.5 In setkey.conf I added: spdadd 192.168.2.0/24 172.28.0.0/16 any -P out ipsec esp/tunnel/MYEXTIP-OTHEREXTIP/require; in addition to the "standard": pdadd 172.28.0.0/16 172.22.0.5/32 any -P in ipsec esp/tunnel/OTHEREXTIP-MYEXTIP/require; spdadd 172.22.0.5/32 172.28.0.0/16 any -P out ipsec esp/tunnel/MYEXTIP-OTHEREXTIP/require; I'm searching for trouble or is it correct? -- Alex Dupre From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 09:31:19 2012 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 EB672106566C; Thu, 12 Jan 2012 09:31:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id ACCD38FC08; Thu, 12 Jan 2012 09:31:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 5BCF44AC2D; Thu, 12 Jan 2012 13:31:18 +0400 (MSK) Date: Thu, 12 Jan 2012 13:31:12 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1379921442.20120112133112@serebryakov.spb.ru> To: freebsd-current@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: avg@FreeBSD.org, jhb@FreeBSD.org Subject: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:31:20 -0000 Hello, Freebsd-current. I have router, which connects to upstream ISP with mpd5 from ports using PPPoE. I've used SCHED_ULE for long time without nay problems. Under heavy network load (router is not the fastest one -- 500Mhz Geode CPU) main consumer of CPU was "intr{swi1: netisr 0}" thread. But it never consumes more than 75% and even when upstream channel was competently saturated router was accessible and responsive. Latest "good" I'm sure about revision is about r227874 (yes, from November 2011, I didn't update router's system for long time). But revision r229818 behaves completely different: under network load 100% CPU is consumed by "ng_queue" thread (which is never ever consume any CPU on old system). System is unresponsive, DNS based on this system returns timeouts, I could not log-in via SSH or seral console (pause between login and passwd is so huge, that it leads to timeouts), etc. LA jumps up to 20+, pre-started `top' updates screen one time per 3-4 minutes, etc. Switching to 4BSD helps. 4BSD works as usual: all CPU time is interrupts and network thread, system is responsive under heaviest load, normal operations of DNS, DHCP and hostapd. There was NO significant changes in netgraph (svn log -r 227874:229818 sys/netgraph) and three changes (r229429, r228960, r228718) in kern/sched_*.c files. But I'm not sure, that these changes are only which could affect this behavior. Now I'm trying to find "bad" revision by binary search, but it is very hard to do: old mpd5 doesn't work on new kernel and vice versa, so I need to rebuild whole world, update my build-box, rebuild ports with new world, and only after that build NanoBSD image for my router. It takes about 5 hours per iteration and here is more than 512 revisions, so it is about 10 iterations :( I could provide any debug information from old and new systems. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 10:05:33 2012 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 13CD61065673; Thu, 12 Jan 2012 10:05:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C73978FC18; Thu, 12 Jan 2012 10:05:32 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 749434AC2D; Thu, 12 Jan 2012 14:05:31 +0400 (MSK) Date: Thu, 12 Jan 2012 14:05:25 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1699441022.20120112140525@serebryakov.spb.ru> To: Andriy Gapon In-Reply-To: <4F0EADE1.9070803@FreeBSD.org> References: <1379921442.20120112133112@serebryakov.spb.ru> <4F0EADE1.9070803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:05:33 -0000 Hello, Andriy. You wrote 12 =FF=ED=E2=E0=F0=FF 2012 =E3., 13:54:41: >> Switching to 4BSD helps. 4BSD works as usual: all CPU time is >> interrupts and network thread, system is responsive under heaviest load, >> normal operations of DNS, DHCP and hostapd. > How reproducible is this result? 100% > In other words, have you definitely ruled out all other factors besides t= he > scheduler? I have two almost-identical NanoBSD images which differs in one line in = kernel config -- option about scheduler. Worlds are exactly the same, only kerne= ls were rebuilt. Alexander Motin suggests, that switching scheduler could slightly change stack consumption, which triggers switching to ng_queue instead of direct calls. Really, here is diff between "md5" of all files of one and other images: blob# diff ~lev/bsd-image.md5sums ~lev/ule-image.md5sums 74c74 < MD5 (./boot/kernel/kernel) =3D 3bb0dd757628b5065d27ee5e7fc22eb3 --- > MD5 (./boot/kernel/kernel) =3D 5ba379d2c73e1277566f4bbcb618a9f2 618c618 < MD5 (./conf/base/var/log/userlog) =3D a827af82c1f780687706b19c7d94b29e --- > MD5 (./conf/base/var/log/userlog) =3D fc289b66ae6cb23f9b24b694bf12157b 15678c15678 < MD5 (./var/log/userlog) =3D a827af82c1f780687706b19c7d94b29e --- > MD5 (./var/log/userlog) =3D fc289b66ae6cb23f9b24b694bf12157b --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 10:13:28 2012 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 A96F2106564A for ; Thu, 12 Jan 2012 10:13:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D7E0B8FC1E for ; Thu, 12 Jan 2012 10:13:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA01377; Thu, 12 Jan 2012 11:54:41 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RlHMn-000E2a-Gr; Thu, 12 Jan 2012 11:54:41 +0200 Message-ID: <4F0EADE1.9070803@FreeBSD.org> Date: Thu, 12 Jan 2012 11:54:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1379921442.20120112133112@serebryakov.spb.ru> In-Reply-To: <1379921442.20120112133112@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 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, 12 Jan 2012 10:13:28 -0000 on 12/01/2012 11:31 Lev Serebryakov said the following: > Switching to 4BSD helps. 4BSD works as usual: all CPU time is > interrupts and network thread, system is responsive under heaviest load, > normal operations of DNS, DHCP and hostapd. How reproducible is this result? In other words, have you definitely ruled out all other factors besides the scheduler? -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 10:15:13 2012 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 E436F1065678 for ; Thu, 12 Jan 2012 10:15:13 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 931708FC08 for ; Thu, 12 Jan 2012 10:15:13 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id B767A2798BF for ; Thu, 12 Jan 2012 10:55:59 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id ACBEE17034; Thu, 12 Jan 2012 10:55:59 +0100 (CET) Date: Thu, 12 Jan 2012 10:55:59 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20120112095559.GA54843@zeninc.net> References: <4F0DD127.4040205@FreeBSD.org> <20120112021423.GG7008@verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120112021423.GG7008@verio.net> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Filtering on IPSEC 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, 12 Jan 2012 10:15:14 -0000 Hi. On Wed, Jan 11, 2012 at 08:14:24PM -0600, David DeSimone wrote: > Alex Dupre wrote: > > > > I've setup my first IPSEC VPN beetween FreeBSD 8.2 and CheckPoint > > VPN-1. I've used a gif interface for the tunnel, setkey for security > > policies and racoon for ikev1. > > I've peered with Checkpoint VPN's using FreeBSD but I never needed to > use gif interfaces to make it happen. FreeBSD's tunnel-mode IPSEC seems > to interoperate quite well with Checkpoint's implementation. > > You should be able to match tunneled traffic using SPD's like so: > > spdadd 10.27.37.0/24 172.30.101.0/24 any -P in ipsec esp/tunnel/192.250.40.23-238.55.55.15/unique; > spdadd 172.30.101.0/24 10.27.37.0/24 any -P out ipsec esp/tunnel/238.55.55.15-192.250.40.23/unique; > > With the matching 'sainfo' sections in racoon's config: > > sainfo address 10.27.37.0/24 any address 172.30.101.0/24 any > { > lifetime time 1 hour; > > encryption_algorithm aes; > authentication_algorithm hmac_sha1; > compression_algorithm deflate; > } Just for information, since ipsec-tools 0.7.0, the sainfo for "incoming SA" is not needed anymore: you just need a sainfo for "local->peer" traffic. > sainfo address 172.30.101.0/24 any address 10.27.37.0/24 any > { > lifetime time 1 hour; > > encryption_algorithm aes; > authentication_algorithm hmac_sha1; > compression_algorithm deflate; > } So this one will be enough. Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 10:30:02 2012 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 41999106566B; Thu, 12 Jan 2012 10:30:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E1E8C8FC13; Thu, 12 Jan 2012 10:30:00 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA01957; Thu, 12 Jan 2012 12:29:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RlHuw-000E3v-Vi; Thu, 12 Jan 2012 12:29:59 +0200 Message-ID: <4F0EB625.3000905@FreeBSD.org> Date: Thu, 12 Jan 2012 12:29:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1379921442.20120112133112@serebryakov.spb.ru> <4F0EADE1.9070803@FreeBSD.org> <1699441022.20120112140525@serebryakov.spb.ru> In-Reply-To: <1699441022.20120112140525@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 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, 12 Jan 2012 10:30:02 -0000 on 12/01/2012 12:05 Lev Serebryakov said the following: > Hello, Andriy. > You wrote 12 ÿíâàðÿ 2012 ã., 13:54:41: > >>> Switching to 4BSD helps. 4BSD works as usual: all CPU time is >>> interrupts and network thread, system is responsive under heaviest load, >>> normal operations of DNS, DHCP and hostapd. >> How reproducible is this result? > 100% > >> In other words, have you definitely ruled out all other factors besides the >> scheduler? > > I have two almost-identical NanoBSD images which differs in one line in kernel > config -- option about scheduler. Worlds are exactly the same, only kernels were > rebuilt. > > Alexander Motin suggests, that switching scheduler could slightly > change stack consumption, which triggers switching to ng_queue > instead of direct calls. > > Really, here is diff between "md5" of all files of one and other > images: Well, I mostly meant things like uptime, load level and pattern, etc. But what mav says makes sense. Also I remember seeing some very old reports about some strange issues with SCHED_ULE and dummynet. Some links that I found: http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046332.html http://dadv.livejournal.com/139366.html#cutid1 Given the last link, I wonder if binding the ng_queue thread to a particular CPU would change anything. > blob# diff ~lev/bsd-image.md5sums ~lev/ule-image.md5sums > 74c74 > < MD5 (./boot/kernel/kernel) = 3bb0dd757628b5065d27ee5e7fc22eb3 > --- >> MD5 (./boot/kernel/kernel) = 5ba379d2c73e1277566f4bbcb618a9f2 > 618c618 > < MD5 (./conf/base/var/log/userlog) = a827af82c1f780687706b19c7d94b29e > --- >> MD5 (./conf/base/var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b > 15678c15678 > < MD5 (./var/log/userlog) = a827af82c1f780687706b19c7d94b29e > --- >> MD5 (./var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b > -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 10:37:59 2012 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 3095B106564A; Thu, 12 Jan 2012 10:37:59 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E2EDA8FC12; Thu, 12 Jan 2012 10:37:58 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 8E0294AC2D; Thu, 12 Jan 2012 14:37:57 +0400 (MSK) Date: Thu, 12 Jan 2012 14:37:51 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <524849865.20120112143751@serebryakov.spb.ru> To: Andriy Gapon In-Reply-To: <4F0EB625.3000905@FreeBSD.org> References: <1379921442.20120112133112@serebryakov.spb.ru> <4F0EADE1.9070803@FreeBSD.org> <1699441022.20120112140525@serebryakov.spb.ru> <4F0EB625.3000905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:37:59 -0000 Hello, Andriy. You wrote 12 =FF=ED=E2=E0=F0=FF 2012 =E3., 14:29:57: > Well, I mostly meant things like uptime, load level and pattern, etc. These are identical too -- freshly boot system, same load (torrent client on other box), only load -- traffic, as it is router, same upload/download speeds and peer counts in torrent client. > But what mav says makes sense. I'm rebuilding system with ULE and KSTACK_PAGES=3D6 (3 is default on i386) now. > Also I remember seeing some very old reports about some strange issues wi= th > SCHED_ULE and dummynet. > Some links that I found: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046332.html > http://dadv.livejournal.com/139366.html#cutid1 > Given the last link, I wonder if binding the ng_queue thread to a particu= lar CPU > would change anything. It is AMD Geode 500MHz. There is no ``particular CPU,'' there is only The CPU with The Core :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 11:00:33 2012 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 8CCDD106564A; Thu, 12 Jan 2012 11:00:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA368FC16; Thu, 12 Jan 2012 11:00:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 606234AC2D; Thu, 12 Jan 2012 15:00:27 +0400 (MSK) Date: Thu, 12 Jan 2012 15:00:20 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1378125765.20120112150020@serebryakov.spb.ru> To: Andriy Gapon In-Reply-To: <4F0EB625.3000905@FreeBSD.org> References: <1379921442.20120112133112@serebryakov.spb.ru> <4F0EADE1.9070803@FreeBSD.org> <1699441022.20120112140525@serebryakov.spb.ru> <4F0EB625.3000905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:00:33 -0000 Hello, Andriy. You wrote 12 =FF=ED=E2=E0=F0=FF 2012 =E3., 14:29:57: > But what mav says makes sense. It is it -- stack size. Setting KSTACK_PAGES=3D6 fixes situation. Feature request: warn user when ng_queue is used due to stack limitations :) I know from mav, that sometime it is unavoidable (with protocols like L2TP), but, IMHO, it is good idea to warn user when it COULD be avoided. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 11:07:21 2012 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 DD78F106566B; Thu, 12 Jan 2012 11:07:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2E58FC0A; Thu, 12 Jan 2012 11:07:21 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d3e:4d27:b4ee:e1e2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id A02764AC2D; Thu, 12 Jan 2012 15:07:20 +0400 (MSK) Date: Thu, 12 Jan 2012 15:07:15 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <188797811.20120112150715@serebryakov.spb.ru> To: Lev Serebryakov In-Reply-To: <1378125765.20120112150020@serebryakov.spb.ru> References: <1379921442.20120112133112@serebryakov.spb.ru> <4F0EADE1.9070803@FreeBSD.org> <1699441022.20120112140525@serebryakov.spb.ru> <4F0EB625.3000905@FreeBSD.org> <1378125765.20120112150020@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:07:22 -0000 Hello, Lev. You wrote 12 =FF=ED=E2=E0=F0=FF 2012 =E3., 15:00:20: >> But what mav says makes sense. > It is it -- stack size. Setting KSTACK_PAGES=3D6 fixes situation. OOOPS. Not. After another 5 minutes ng_queue again consumes 100% CPU :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 11:11:06 2012 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 E7FC8106564A for ; Thu, 12 Jan 2012 11:11:06 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE088FC19 for ; Thu, 12 Jan 2012 11:11:06 +0000 (UTC) Received: from [192.168.1.103] (p508FAE66.dip.t-dialin.net [80.143.174.102]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 696F21C0B4603; Thu, 12 Jan 2012 12:11:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <20111025141741.26891k8ib38ekmkg@www.nexusmail.uwaterloo.ca> Date: Thu, 12 Jan 2012 12:11:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <940650A6-785B-435B-B7C5-7C68925DEC8D@lurchi.franken.de> References: <20111025141741.26891k8ib38ekmkg@www.nexusmail.uwaterloo.ca> To: smahood@engmail.uwaterloo.ca X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Have netstat test for sctp kernel support 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, 12 Jan 2012 11:11:07 -0000 On Oct 25, 2011, at 8:17 PM, Sean Mahood wrote: > Hello, >=20 > I noticed that when doing a netstat -s (running on a kernel without = SCTP support compiled in), I get the following message output to stderr: >=20 > netstat: sysctl: net.inet.sctp.stats: No such file or directory >=20 > Wondering why it would attempt to fetch SCTP stats when it was = compiled out of the kernel, I noted that netstat could be compiled = without SCTP support as well, but that there is no good way to link the = two compilation conditions, or to have a generic binary that can run = without error regardless of compiled kernel options. >=20 > To that end, I added a method to check for environment compatibility = in netstat. For SCTP specifically, I used the FEATURE macros and added = SCTP as a FEATURE. >=20 > Other protocols could also be configured to be checked at runtime if = desired, though I haven't implemented any others at this time. Hi Sean, I agree, the error message should be avoided. There is a similar = situation for IPv6. When not compiled into the kernel, netstat should not report an error, even if it is not = recompiled. The way it is handled for INET6 is to pay attention to the errno in case = sysctlbyname() fails. we also have already one place in the sctp.c code where we do the correct check. I guess it = was missed in the code responsable for the above error message. So what do you think about the attached patch, which resolves the issue = you reported in a way already used in netstat and which is portable to other BSD based platform (like = Mac OS X)? Thank you very much for reporting the issue. Best regards Michael Index: sctp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sctp.c (revision 230008) +++ sctp.c (working copy) @@ -611,7 +611,8 @@ memset(&zerostat, 0, len); if (sysctlbyname("net.inet.sctp.stats", &sctpstat, &len, zflag ? &zerostat : NULL, zflag ? len : 0) < 0) { - warn("sysctl: net.inet.sctp.stats"); + if (errno !=3D ENOENT) + warn("sysctl: net.inet.sctp.stats"); return; } } else >=20 > -- Sean >=20 >=20 >=20 > = ____________= ___________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 14:04:45 2012 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 4E9F51065670; Thu, 12 Jan 2012 14:04:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F5FF8FC17; Thu, 12 Jan 2012 14:04:41 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id q0CE4JQ9066103; Thu, 12 Jan 2012 15:04:34 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id q0CE4ItN066102; Thu, 12 Jan 2012 15:04:18 +0100 (CET) (envelope-from olli) Date: Thu, 12 Jan 2012 15:04:18 +0100 (CET) Message-Id: <201201121404.q0CE4ItN066102@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, Oliver Fromme , freebsd-net@FreeBSD.ORG, "Paul A. Procacci" In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lurza.secnetix.de [127.0.0.1]); Thu, 12 Jan 2012 15:04:35 +0100 (CET) Cc: Subject: Re: Processes' FIBs 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, 12 Jan 2012 14:04:45 -0000 Bjoern A. Zeeb wrote: > On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: > > I'm currently looking at the source code of ps, but adding > > a field for the FIB isn't as trivial as I thought because > > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > > which doesn't contain the FIB. procstat does the same. > > > > I'm currently trying to write a patch that copies p_fibnum > > from struct proc to struct kinfo_proc (just like p_nice, > > for example). Does that make sense? If so, does the patch > > below look reasonable? (I've made it on a stable/8 system, > > but it should apply to 9 and 10, too.) > > I am not sure it makes too much sense in ps. It might make sense in > sockstat maybe? Well, every process has a default FIB number (p_fibnum in struct proc). It is a property of the process, just like the nice value for example. So I think it makes sense for ps to be able to display it if the user asks for it. This is the piece of information that I need. On the other hand, sockstat displays open sockets only. Of course, an internet socket has a FIB number associated with it, too, so sockstat could display it. But that would be a completely different piece of information, and it wouldn't solve the actual problem that I'm currently facing. Best regards Oliver --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 @@ -83,7 +83,7 @@ * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and * function kvm_proclist in lib/libkvm/kvm_proc.c . */ -#define KI_NSPARE_INT 9 +#define KI_NSPARE_INT 8 #define KI_NSPARE_LONG 12 #define KI_NSPARE_PTR 6 @@ -177,6 +177,7 @@ */ char ki_sparestrings[68]; /* spare string space */ int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ + int ki_fibnum; /* Default FIB number */ u_int ki_cr_flags; /* Credential flags */ int ki_jid; /* Process jail ID */ int ki_numthreads; /* XXXKSE number of threads in total */ --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 @@ -775,6 +775,7 @@ kp->ki_swtime = (ticks - p->p_swtick) / hz; kp->ki_pid = p->p_pid; kp->ki_nice = p->p_nice; + kp->ki_fibnum = p->p_fibnum; PROC_SLOCK(p); rufetch(p, &kp->ki_rusage); kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 @@ -90,6 +90,7 @@ NULL, 0}, {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0}, {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 14:36:18 2012 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 E20FC106564A for ; Thu, 12 Jan 2012 14:36:18 +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 1D9D28FC18 for ; Thu, 12 Jan 2012 14:36:17 +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 q0CEaGf2004357 for ; Thu, 12 Jan 2012 18:36:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0CEaGp0004356 for net@FreeBSD.org; Thu, 12 Jan 2012 18:36:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 12 Jan 2012 18:36:16 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20120112143616.GK74141@glebius.int.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: removing support for SIOCSIF{ADDR,NETMASK,BRDADDR,DSTADDR} 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, 12 Jan 2012 14:36:19 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hello, networkers! I'd like to remove from kernel support for several really outdated ioctls: SIOCSIFADDR SIOCSIFNETMASK SIOCSIFBRDADDR SIOCSIFDSTADDR Actually their support was always only declared, you can trigger panics easily if you play with them. These ioctls were outdated even in FreeBSD 1.0, since ifconfig(8) always used SIOCAIFADDR. There is no reason to have them in modern system. The ports team had performed an -exp run to determine number of ports that still use them: http://www.freebsd.org/cgi/query-pr.cgi?pr=163524&cat= We appeared to have three ports, that a kernel interface drivers, and they utilize SIOCSIFADDR. However, they utilize it in the in-kernel API, and this usage is not related to the ioctl() call from userland. We don't have any ports in the tree, that use the above commands as ioctl() argument. So, any objections on removal? -- Totus tuus, Glebius. --Kj7319i9nmIyA2yE Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="in.c.diff" Index: in.c =================================================================== --- in.c (revision 229775) +++ in.c (working copy) @@ -73,7 +73,7 @@ static void in_socktrim(struct sockaddr_in *); static int in_ifinit(struct ifnet *, struct in_ifaddr *, - struct sockaddr_in *, int, int, int); + struct sockaddr_in *, int, int); static void in_purgemaddrs(struct ifnet *); static VNET_DEFINE(int, nosameprefix); @@ -220,7 +220,6 @@ struct in_addr dst; struct in_ifinfo *ii; struct in_aliasreq *ifra = (struct in_aliasreq *)data; - struct sockaddr_in oldaddr; int error, hostIsNew, iaIsNew, maskIsNew; int iaIsFirst; u_long ocmd = cmd; @@ -278,10 +277,8 @@ case SIOCSIFBRDADDR: case SIOCSIFDSTADDR: case SIOCSIFNETMASK: - if (ifr->ifr_addr.sa_family != AF_INET || - ifr->ifr_addr.sa_len != sizeof(struct sockaddr_in)) - return (EINVAL); - break; + /* We no longer support that old commands. */ + return (EINVAL); case SIOCALIFADDR: if (td != NULL) { @@ -322,10 +319,6 @@ */ switch (cmd) { case SIOCAIFADDR: - case SIOCSIFADDR: - case SIOCSIFBRDADDR: - case SIOCSIFNETMASK: - case SIOCSIFDSTADDR: if (td != NULL) { error = priv_check(td, PRIV_NET_ADDIFADDR); if (error) @@ -413,10 +406,6 @@ error = EADDRNOTAVAIL; goto out; } - /* FALLTHROUGH */ - case SIOCSIFADDR: - case SIOCSIFNETMASK: - case SIOCSIFDSTADDR: if (ia == NULL) { ia = (struct in_ifaddr *) malloc(sizeof *ia, M_IFADDR, M_NOWAIT | @@ -452,7 +441,6 @@ } break; - case SIOCSIFBRDADDR: case SIOCGIFADDR: case SIOCGIFNETMASK: case SIOCGIFDSTADDR: @@ -493,61 +481,6 @@ *((struct sockaddr_in *)&ifr->ifr_addr) = ia->ia_sockmask; goto out; - case SIOCSIFDSTADDR: - if ((ifp->if_flags & IFF_POINTOPOINT) == 0) { - error = EINVAL; - goto out; - } - oldaddr = ia->ia_dstaddr; - ia->ia_dstaddr = *(struct sockaddr_in *)&ifr->ifr_dstaddr; - if (ifp->if_ioctl != NULL) { - error = (*ifp->if_ioctl)(ifp, SIOCSIFDSTADDR, - (caddr_t)ia); - if (error) { - ia->ia_dstaddr = oldaddr; - goto out; - } - } - if (ia->ia_flags & IFA_ROUTE) { - ia->ia_ifa.ifa_dstaddr = (struct sockaddr *)&oldaddr; - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, RTF_HOST); - ia->ia_ifa.ifa_dstaddr = - (struct sockaddr *)&ia->ia_dstaddr; - rtinit(&(ia->ia_ifa), (int)RTM_ADD, RTF_HOST|RTF_UP); - } - goto out; - - case SIOCSIFBRDADDR: - if ((ifp->if_flags & IFF_BROADCAST) == 0) { - error = EINVAL; - goto out; - } - ia->ia_broadaddr = *(struct sockaddr_in *)&ifr->ifr_broadaddr; - goto out; - - case SIOCSIFADDR: - error = in_ifinit(ifp, ia, - (struct sockaddr_in *) &ifr->ifr_addr, 1, 0, 0); - if (error != 0 && iaIsNew) - break; - if (error == 0) { - ii = ((struct in_ifinfo *)ifp->if_afdata[AF_INET]); - if (iaIsFirst && - (ifp->if_flags & IFF_MULTICAST) != 0) { - error = in_joingroup(ifp, &allhosts_addr, - NULL, &ii->ii_allhosts); - } - EVENTHANDLER_INVOKE(ifaddr_event, ifp); - } - error = 0; - goto out; - - case SIOCSIFNETMASK: - ia->ia_sockmask.sin_addr = ((struct sockaddr_in *) - &ifr->ifr_addr)->sin_addr; - ia->ia_subnetmask = ntohl(ia->ia_sockmask.sin_addr.s_addr); - goto out; - case SIOCAIFADDR: maskIsNew = 0; hostIsNew = 1; @@ -579,8 +512,8 @@ maskIsNew = 1; /* We lie; but the effect's the same */ } if (hostIsNew || maskIsNew) - error = in_ifinit(ifp, ia, &ifra->ifra_addr, 0, - maskIsNew, (ocmd == cmd ? ifra->ifra_vhid : 0)); + error = in_ifinit(ifp, ia, &ifra->ifra_addr, maskIsNew, + (ocmd == cmd ? ifra->ifra_vhid : 0)); if (error != 0 && iaIsNew) break; @@ -863,14 +796,11 @@ */ static int in_ifinit(struct ifnet *ifp, struct in_ifaddr *ia, struct sockaddr_in *sin, - int scrub, int masksupplied, int vhid) + int masksupplied, int vhid) { register u_long i = ntohl(sin->sin_addr.s_addr); int flags = RTF_UP, error = 0; - if (scrub) - in_scrubprefix(ia, LLE_STATIC); - IN_IFADDR_WLOCK(); if (ia->ia_addr.sin_family == AF_INET) LIST_REMOVE(ia, ia_hash); --Kj7319i9nmIyA2yE-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 17:55:52 2012 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 43305106566C for ; Thu, 12 Jan 2012 17:55:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0C1B8FC1D for ; Thu, 12 Jan 2012 17:55:51 +0000 (UTC) Received: by eeke53 with SMTP id e53so352671eek.13 for ; Thu, 12 Jan 2012 09:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=ceExu6PO2RiI9deJLgeXqE42q3UPnwXAqDWeibtQYKU=; b=rwEOaNN76R/wvBPyOv3MIRTbS4JWaflB7zrA1zPwkapsbLQPJU2IAayDW6jAgUTAr+ JylD6oLit+R2j1RQp/0zZNYbgXgdM0v6So+dDJ8lx1P3nva+0gksGnAgc9xetg+Uztca Hlz/sEDY8BUX/6yKbwy/duVX0rtHkfRezzYqA= Received: by 10.14.3.167 with SMTP id 39mr1775733eeh.6.1326390950704; Thu, 12 Jan 2012 09:55:50 -0800 (PST) Received: from imba-brutale.totalterror.net (93-152-152-135.ddns.onlinedirect.bg. [93.152.152.135]) by mx.google.com with ESMTPS id s16sm22258450eef.2.2012.01.12.09.55.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 09:55:49 -0800 (PST) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 19:55:47 +0200 To: freebsd-net@freebsd.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: ICMP attacks against TCP and PMTUD 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, 12 Jan 2012 17:55:52 -0000 Hello, A web server that I administer running Nginx and FreeBSD-7.3-STABLE was = recently under a ICMP attack that generated a large amount of outgoing TCP = traffic. With some tcpdump and netflow analysis it was evident that the attachers = are using ICMP host-unreach need-frag messages to make the web server retransmit multiple times, giving a amplification factor of about 1.6. Then I noticed RFC5927 ( http://www.faqs.org/rfcs/rfc5927.html ) and = specifically section 7.2 which discusses countermeasures against such attacks. The text reads : This section describes a modification to the PMTUD mechanism specified in [RFC1191] and [RFC1981] that has been incorporated in OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the blind performance-degrading attack described in Section 7.1. The described counter-measure basically disregards ICMP messages when a connection makes progress, without violating any of the requirements stated in [RFC1191] and [RFC1981]. The RFC is recent (dated from July 2010), and it mentions several times = Linux, Free,Open and NetBSD, but exactly in this paragraph it is mentioning only Net and OpenBSD's, = thus I'm asking if=20 anyone has idea if these modifications were being put into FreeBSD? I quickly glanced upon the source, but the TCP code is a bit too much = for me :) Also if anybody has observed similar attack, how are you protecting = yourself from it? Simply blocking host-unreach need-frag would break PMTUD. P.S.: I know 7.3 is pretty old, and I've planned upgrade to 8.2. I'm = also curious if 8.2 will behave differently. Regards, Nikolay From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 19:47:50 2012 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 82FB9106564A; Thu, 12 Jan 2012 19:47:50 +0000 (UTC) (envelope-from adrian.chadd@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 07AA38FC14; Thu, 12 Jan 2012 19:47:49 +0000 (UTC) Received: by vbbfp1 with SMTP id fp1so1068390vbb.13 for ; Thu, 12 Jan 2012 11:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Qgjo9JySNIvOV1xLq3gZhv/0nN7a0yDwVNuoHjEGrRU=; b=VzAhWMVHPu6lxOpAUKNt38/IOi9SPqj5yueMHo06jI0G4+0GUkdD8GxPeRFJhFl72B gLWYmp2YzOM8m1uxYth9hewG6Sv69Kg4FBTut8hvO7NaWQg8FwMbRkn7nOVAskBnPbsB NzaoX1rXaEhaU/zblRYgmDdE4qeoPQI+wkECw= MIME-Version: 1.0 Received: by 10.52.70.45 with SMTP id j13mr2131945vdu.115.1326397669285; Thu, 12 Jan 2012 11:47:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Thu, 12 Jan 2012 11:47:49 -0800 (PST) In-Reply-To: <287819916.20120112131047@serebryakov.spb.ru> References: <1791250845.20120111030529@serebryakov.spb.ru> <108354307.20120111032108@serebryakov.spb.ru> <4F0CCDFC.9020901@gmail.com> <19210156623.20120112003332@serebryakov.spb.ru> <287819916.20120112131047@serebryakov.spb.ru> Date: Thu, 12 Jan 2012 11:47:49 -0800 X-Google-Sender-Auth: b5XMVPEqxviegDGuwSFFM_R_MME Message-ID: From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Alexander Motin , freebsd-current@freebsd.org, Chuck Burns Subject: Re: Very fresh (two days ago) 10-current becomes completely unresponsive under 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: Thu, 12 Jan 2012 19:47:50 -0000 .. this is why someone needs to put together an automated testing framework to build, run, test and report on this. Then, the warehouse-sized space and cooling needed for a few hundred machines, all doing automated regression testing. That's how "a project" fixes this. :-) The alternative is people keep up to date on -HEAD, every two or so weeks, and report issues. But we know how often that happens.. Adrian 2012/1/12 Lev Serebryakov : > Hello, Lev. > You wrote 12 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2012 =D0=B3., 0:33:32: > >> =C2=A0I'll try to find revision, which breaks ULE + NetGraph by binary >> search, but it takes some time as here is 590 revisions in "head/sys" >> between previous version I used (which works Ok with ULE) and current >> version (which doesn't). So, it should be ~9 iterations, and every >> iteration takes ~1 hour and I could not spend 9 hours in row on this >> task. > =C2=A0Everything is much worse, that I thought. mpd built on old systems > =C2=A0could not work on new ones and vice versa. I need to rebuild FULL > =C2=A0system (not only kernel), update build box, rebuild ports, build > =C2=A0image for router. It is about 5 hours per version. More than 512 > =C2=A0revisions to search, about 10 iterations. FML. > > -- > // Black Lion AKA Lev Serebryakov > From owner-freebsd-net@FreeBSD.ORG Thu Jan 12 19:58:02 2012 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 A2401106566B; Thu, 12 Jan 2012 19:58:02 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id 166458FC19; Thu, 12 Jan 2012 19:58:02 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward12.mail.yandex.net (Yandex) with ESMTP id 70ADAC22EF2; Thu, 12 Jan 2012 23:58:00 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1326398280; bh=g+D1BXPv/mv5siEJMy8G13DiHAOx4BRSkVbtW8rfw5I=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=goTeoPjhR+6Y2dFo5UHbWTZ9nBASwR0JzETm8foUdwxKYTjvfQQS/Ik3WGuZSD1AJ /T6x4bc83ZyBCWKYcl6UvYeNA9RzgpU9Qy+ScYYgB+q/SYowvgxnFPFwChH/barP70 PWsjZLv7bWYgM4PXy1xTcBaq762Elo4myPmdQeOA= Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 34FDA16A0485; Thu, 12 Jan 2012 23:58:00 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1326398280; bh=g+D1BXPv/mv5siEJMy8G13DiHAOx4BRSkVbtW8rfw5I=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=goTeoPjhR+6Y2dFo5UHbWTZ9nBASwR0JzETm8foUdwxKYTjvfQQS/Ik3WGuZSD1AJ /T6x4bc83ZyBCWKYcl6UvYeNA9RzgpU9Qy+ScYYgB+q/SYowvgxnFPFwChH/barP70 PWsjZLv7bWYgM4PXy1xTcBaq762Elo4myPmdQeOA= Received: from unknown (unknown [176.8.25.138]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id vxCiMixb-vxCitglV; Thu, 12 Jan 2012 23:58:00 +0400 X-Yandex-Spam: 1 Date: Thu, 12 Jan 2012 21:57:57 +0200 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <17806711.20120112215757@yandex.ru> To: Lev Serebryakov In-Reply-To: <188797811.20120112150715@serebryakov.spb.ru> References: <1379921442.20120112133112@serebryakov.spb.ru> <4F0EADE1.9070803@FreeBSD.org> <1699441022.20120112140525@serebryakov.spb.ru> <4F0EB625.3000905@FreeBSD.org> <1378125765.20120112150020@serebryakov.spb.ru> <188797811.20120112150715@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re[2]: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:58:02 -0000 Çäðàâñòâóéòå, Lev. Âû ïèñàëè 12 ÿíâàðÿ 2012 ã., 13:07:15: LS> Hello, Lev. LS> You wrote 12 ÿíâàðÿ 2012 ã., 15:00:20: >>> But what mav says makes sense. >> It is it -- stack size. Setting KSTACK_PAGES=6 fixes situation. LS> OOOPS. Not. After another 5 minutes ng_queue again consumes 100% CPU LS> :( FreeBSD r229881 10-CURRENT IF Load http://piccy.info/view3/2474120/f4a4eb06a8af54434e9643024737ae30/orig/ CPU load http://piccy.info/view3/2474125/0d4474f8f3f4491eb49a11cdf3a301f4/orig/ if traffic goes normal: there are {irq256: re0}, ng_queue and netisr threads in top when there is fall: {irq256: re0}, ng_queue and no intr{swi1: netisr 3} in top, when intr{swi1: netisr 3} appear in 'top' then traffic starts to flow normally until next fall: 16:05; 16:28, 18:05: 18:30, 19:05: 19:30 it is like 30min interval. 19:45 is reboot Also freebsd stops to work on igb after couple of hours. There is no such problem on re -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 06:43:55 2012 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 54FEE106566B; Fri, 13 Jan 2012 06:43:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1FEEB8FC0A; Fri, 13 Jan 2012 06:43:54 +0000 (UTC) Received: from julian-mac.elischer.org ([12.42.66.130]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0D6hmCg048734 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 22:43:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F0FD2E3.1060607@freebsd.org> Date: Thu, 12 Jan 2012 22:44:51 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Oliver Fromme References: <201201121404.q0CE4ItN066102@lurza.secnetix.de> In-Reply-To: <201201121404.q0CE4ItN066102@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "Paul A. Procacci" , Oliver Fromme , freebsd-net@freebsd.org Subject: Re: Processes' FIBs 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, 13 Jan 2012 06:43:55 -0000 On 1/12/12 6:04 AM, Oliver Fromme wrote: > Bjoern A. Zeeb wrote: > > On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: > > > I'm currently looking at the source code of ps, but adding > > > a field for the FIB isn't as trivial as I thought because > > > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > > > which doesn't contain the FIB. procstat does the same. > > > > > > I'm currently trying to write a patch that copies p_fibnum > > > from struct proc to struct kinfo_proc (just like p_nice, > > > for example). Does that make sense? If so, does the patch > > > below look reasonable? (I've made it on a stable/8 system, > > > but it should apply to 9 and 10, too.) > > > > I am not sure it makes too much sense in ps. It might make sense in > > sockstat maybe? > > Well, every process has a default FIB number (p_fibnum in > struct proc). It is a property of the process, just like > the nice value for example. So I think it makes sense for > ps to be able to display it if the user asks for it. This > is the piece of information that I need. > > On the other hand, sockstat displays open sockets only. > Of course, an internet socket has a FIB number associated > with it, too, so sockstat could display it. But that > would be a completely different piece of information, > and it wouldn't solve the actual problem that I'm currently > facing. > I hadn't considered that a process would want to see the fib of another. but of course it makes sense. I see no problem the the attached patch except that it doesn't fix the man page for ps and setfib(2) or setfib(8) (or is it 1?) etc. if there are no objections, I can add this when it has been polished.. > Best regards > Oliver > > --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 > +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 > @@ -83,7 +83,7 @@ > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and > * function kvm_proclist in lib/libkvm/kvm_proc.c . > */ > -#define KI_NSPARE_INT 9 > +#define KI_NSPARE_INT 8 > #define KI_NSPARE_LONG 12 > #define KI_NSPARE_PTR 6 > > @@ -177,6 +177,7 @@ > */ > char ki_sparestrings[68]; /* spare string space */ > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ > + int ki_fibnum; /* Default FIB number */ > u_int ki_cr_flags; /* Credential flags */ > int ki_jid; /* Process jail ID */ > int ki_numthreads; /* XXXKSE number of threads in total */ > --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 > +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 > @@ -775,6 +775,7 @@ > kp->ki_swtime = (ticks - p->p_swtick) / hz; > kp->ki_pid = p->p_pid; > kp->ki_nice = p->p_nice; > + kp->ki_fibnum = p->p_fibnum; > PROC_SLOCK(p); > rufetch(p,&kp->ki_rusage); > kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); > --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 > +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 > @@ -90,6 +90,7 @@ > NULL, 0}, > {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0}, > {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, > + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, > {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 09:47:59 2012 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 107EA106566B for ; Fri, 13 Jan 2012 09:47:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6118FC15 for ; Fri, 13 Jan 2012 09:47:57 +0000 (UTC) Received: (qmail 50046 invoked from network); 13 Jan 2012 08:11:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Jan 2012 08:11:48 -0000 Message-ID: <4F0FFDC9.1090503@freebsd.org> Date: Fri, 13 Jan 2012 10:47:53 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Nikolay Denev References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ICMP attacks against TCP and PMTUD 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, 13 Jan 2012 09:47:59 -0000 On 12.01.2012 18:55, Nikolay Denev wrote: > Hello, > > A web server that I administer running Nginx and FreeBSD-7.3-STABLE was recently > under a ICMP attack that generated a large amount of outgoing TCP traffic. > With some tcpdump and netflow analysis it was evident that the attachers are using > ICMP host-unreach need-frag messages to make the web server > retransmit multiple times, giving a amplification factor of about 1.6. > Then I noticed RFC5927 ( http://www.faqs.org/rfcs/rfc5927.html ) and specifically section 7.2 > which discusses countermeasures against such attacks. The text reads : > > This section describes a modification to the PMTUD mechanism > specified in [RFC1191] and [RFC1981] that has been incorporated in > OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the > blind performance-degrading attack described in Section 7.1. The > described counter-measure basically disregards ICMP messages when a > connection makes progress, without violating any of the requirements > stated in [RFC1191] and [RFC1981]. > > The RFC is recent (dated from July 2010), and it mentions several times Linux, Free,Open and NetBSD, > but exactly in this paragraph it is mentioning only Net and OpenBSD's, thus I'm asking if > anyone has idea if these modifications were being put into FreeBSD? We haven't implemented this (yet). > I quickly glanced upon the source, but the TCP code is a bit too much for me :) > > Also if anybody has observed similar attack, how are you protecting yourself from it? > Simply blocking host-unreach need-frag would break PMTUD. We have a sysctl called "net.inet.tcp.minmss" which lower-bounds the MSS we accept in SYN and ICMP need frag messages. It defaults to 216 as 256 is the smallest allowable MTU in the Internet. The only known user of MTU 256 is packet radio which isn't exactly much used on the common Internet. You should be able to safely increase this value to 536. If you are willing to live with a little bit of fall-out then 1220 is a good value as well. > P.S.: I know 7.3 is pretty old, and I've planned upgrade to 8.2. I'm also curious if 8.2 will behave differently. No. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 12:55:32 2012 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 9A934106564A; Fri, 13 Jan 2012 12:55:32 +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 313378FC1C; Fri, 13 Jan 2012 12:55:31 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0DCRpEx098358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 14:27:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0DCRp0i091394; Fri, 13 Jan 2012 14:27:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0DCRnHi091393; Fri, 13 Jan 2012 14:27:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Jan 2012 14:27:49 +0200 From: Kostik Belousov To: Julian Elischer Message-ID: <20120113122749.GG31224@deviant.kiev.zoral.com.ua> References: <201201121404.q0CE4ItN066102@lurza.secnetix.de> <4F0FD2E3.1060607@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l7ZAGG5ZGPl0OWqn" Content-Disposition: inline In-Reply-To: <4F0FD2E3.1060607@freebsd.org> 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: freebsd-hackers@freebsd.org, "Paul A. Procacci" , Oliver Fromme , Oliver Fromme , freebsd-net@freebsd.org Subject: Re: Processes' FIBs 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, 13 Jan 2012 12:55:32 -0000 --l7ZAGG5ZGPl0OWqn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2012 at 10:44:51PM -0800, Julian Elischer wrote: > On 1/12/12 6:04 AM, Oliver Fromme wrote: > >Bjoern A. Zeeb wrote: > > > On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: > > > > I'm currently looking at the source code of ps, but adding > > > > a field for the FIB isn't as trivial as I thought because > > > > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > > > > which doesn't contain the FIB. procstat does the same. > > > > > > > > I'm currently trying to write a patch that copies p_fibnum > > > > from struct proc to struct kinfo_proc (just like p_nice, > > > > for example). Does that make sense? If so, does the patch > > > > below look reasonable? (I've made it on a stable/8 system, > > > > but it should apply to 9 and 10, too.) > > > > > > I am not sure it makes too much sense in ps. It might make sense in > > > sockstat maybe? > > > >Well, every process has a default FIB number (p_fibnum in > >struct proc). It is a property of the process, just like > >the nice value for example. So I think it makes sense for > >ps to be able to display it if the user asks for it. This > >is the piece of information that I need. > > > >On the other hand, sockstat displays open sockets only. > >Of course, an internet socket has a FIB number associated > >with it, too, so sockstat could display it. But that > >would be a completely different piece of information, > >and it wouldn't solve the actual problem that I'm currently > >facing. > > >=20 > I hadn't considered that a process would want to see the fib of another. > but of course it makes sense. > I see no problem the the attached patch except that it doesn't fix the=20 > man page for ps and setfib(2) or setfib(8) (or is it 1?) >=20 > etc. > if there are no objections, I can add this when it has been polished.. The patch misses compat32 bits and breaks compat32 ps/top. >=20 > >Best regards > > Oliver > > > >--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 > >+++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 > >@@ -83,7 +83,7 @@ > > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c = and > > * function kvm_proclist in lib/libkvm/kvm_proc.c . > > */ > >-#define KI_NSPARE_INT 9 > >+#define KI_NSPARE_INT 8 > > #define KI_NSPARE_LONG 12 > > #define KI_NSPARE_PTR 6 > > > >@@ -177,6 +177,7 @@ > > */ > > char ki_sparestrings[68]; /* spare string space */ > > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ > >+ int ki_fibnum; /* Default FIB number */ > > u_int ki_cr_flags; /* Credential flags */ > > int ki_jid; /* Process jail ID */ > > int ki_numthreads; /* XXXKSE number of threads in total=20 > > */ > >--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 > >+++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 > >@@ -775,6 +775,7 @@ > > kp->ki_swtime =3D (ticks - p->p_swtick) / hz; > > kp->ki_pid =3D p->p_pid; > > kp->ki_nice =3D p->p_nice; > >+ kp->ki_fibnum =3D p->p_fibnum; > > PROC_SLOCK(p); > > rufetch(p,&kp->ki_rusage); > > kp->ki_runtime =3D cputick2usec(p->p_rux.rux_runtime); > >--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 > >+++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 > >@@ -90,6 +90,7 @@ > > NULL, 0}, > > {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL,=20 > > 0}, > > {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, > >+ {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, > > {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > > {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > > {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" > > >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --l7ZAGG5ZGPl0OWqn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8QI0UACgkQC3+MBN1Mb4iZIQCeJMmMRc1xlEKG9AqVZ5Z3g7b2 htsAn1sIrSGYbjpROJhvpknVM7mUoiEx =uZA+ -----END PGP SIGNATURE----- --l7ZAGG5ZGPl0OWqn-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 15:29:32 2012 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 7D2C7106566B for ; Fri, 13 Jan 2012 15:29:32 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0993F8FC0C for ; Fri, 13 Jan 2012 15:29:31 +0000 (UTC) Received: by eaai12 with SMTP id i12so244294eaa.13 for ; Fri, 13 Jan 2012 07:29:30 -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=9pAc87DeUKXNGRkGsrRmiqQJxQJUxHRoCca70zT0Bbc=; b=f2kJixDyZEeB89yF682+VsUhkpHsb+d4zZbvfUt3SEl3MMwNwX9utL4zedEV8gx74v 2l44qRS17geRv+q5/wzRnUT1MeuwPnX3jq2JEX1IxNz0Hel2yNWsDLerWNN4vRGUVr+U mcoXiwowgGVDNmcgOz4O1UCFCu1ZQc19LwM5w= Received: by 10.213.19.136 with SMTP id a8mr63443ebb.76.1326468570668; Fri, 13 Jan 2012 07:29:30 -0800 (PST) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id x43sm30657060eef.8.2012.01.13.07.29.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 07:29:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: <4F0FFDC9.1090503@freebsd.org> Date: Fri, 13 Jan 2012 17:29:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <897A1A91-61DB-4783-B38A-C77DBC54DD45@gmail.com> References: <4F0FFDC9.1090503@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org Subject: Re: ICMP attacks against TCP and PMTUD 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, 13 Jan 2012 15:29:32 -0000 On Jan 13, 2012, at 11:47 AM, Andre Oppermann wrote: > On 12.01.2012 18:55, Nikolay Denev wrote: >> Hello, >>=20 >> A web server that I administer running Nginx and FreeBSD-7.3-STABLE = was recently >> under a ICMP attack that generated a large amount of outgoing TCP = traffic. >> With some tcpdump and netflow analysis it was evident that the = attachers are using >> ICMP host-unreach need-frag messages to make the web server >> retransmit multiple times, giving a amplification factor of about = 1.6. >> Then I noticed RFC5927 ( http://www.faqs.org/rfcs/rfc5927.html ) and = specifically section 7.2 >> which discusses countermeasures against such attacks. The text reads = : >>=20 >> This section describes a modification to the PMTUD mechanism >> specified in [RFC1191] and [RFC1981] that has been incorporated in >> OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the >> blind performance-degrading attack described in Section 7.1. The >> described counter-measure basically disregards ICMP messages when = a >> connection makes progress, without violating any of the = requirements >> stated in [RFC1191] and [RFC1981]. >>=20 >> The RFC is recent (dated from July 2010), and it mentions several = times Linux, Free,Open and NetBSD, >> but exactly in this paragraph it is mentioning only Net and = OpenBSD's, thus I'm asking if >> anyone has idea if these modifications were being put into FreeBSD? >=20 > We haven't implemented this (yet). >=20 >> I quickly glanced upon the source, but the TCP code is a bit too much = for me :) >>=20 >> Also if anybody has observed similar attack, how are you protecting = yourself from it? >> Simply blocking host-unreach need-frag would break PMTUD. >=20 > We have a sysctl called "net.inet.tcp.minmss" which lower-bounds the > MSS we accept in SYN and ICMP need frag messages. It defaults to 216 > as 256 is the smallest allowable MTU in the Internet. The only known > user of MTU 256 is packet radio which isn't exactly much used on the > common Internet. You should be able to safely increase this value to > 536. If you are willing to live with a little bit of fall-out then > 1220 is a good value as well. >=20 >> P.S.: I know 7.3 is pretty old, and I've planned upgrade to 8.2. I'm = also curious if 8.2 will behave differently. >=20 > No. >=20 > --=20 > Andre Thanks for the info Andre. I'm now looking again at the pcap and I'm a bit confused. First the possible attacker sends the ICMP need-frag packets with "MTU = of next hop" set to zero, which in 2012 shouldn't be very common? Then when my server sends 66 byte FIN/ACK packet, the attacker continues to send need-frag ICMPs and the FreeBSD host = sends again FIN/ACK packets. Later on he sends again ICMP need-frag packets, but with size of about = 1048 bytes, with very large part of the original packets payload, instead of the = required several bytes, this then triggers excessive retransmits from the FreeBSD host which = generates a lot of traffic. The retransmits are roughly ~300-500 byte packets. From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 21:18:04 2012 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 B39EA1065672 for ; Fri, 13 Jan 2012 21:18:04 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 238868FC15 for ; Fri, 13 Jan 2012 21:18:03 +0000 (UTC) Received: from [IPv6:2001:470:28:140:bc5b:f133:cc84:f629] ([IPv6:2001:470:28:140:bc5b:f133:cc84:f629]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id q0DLHv6f095130 for ; Fri, 13 Jan 2012 23:17:57 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4F109F79.5090406@ukr.net> Date: Fri, 13 Jan 2012 23:17:45 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Fri, 13 Jan 2012 23:17:57 +0200 (EET) X-Spam-Status: No, score=-94.3 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL, TO_NO_BRKTS_DIRECT, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Cc: Subject: Lack of performance re0 (RTL8111/8168B) 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, 13 Jan 2012 21:18:04 -0000 Tell me, what a performance in pps a network card RTL8111/8168B? Can I somehow increase it? Experimentally, since it begins to fall off 80Kpps: ( Jan 13 18:12:49 XXX kernel: re0: watchdog timeout Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN Jan 13 18:12:53 XXX kernel: re0: link state changed to UP # uname -a FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 # pciconf -lv | grep -A 4 "re0@" re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 22:35:51 2012 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 8E3A110656E6 for ; Fri, 13 Jan 2012 22:35:51 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id D5F558FC0C for ; Fri, 13 Jan 2012 22:35:50 +0000 (UTC) Received: from [IPv6:2001:470:28:140:bc5b:f133:cc84:f629] ([IPv6:2001:470:28:140:bc5b:f133:cc84:f629]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id q0DMZhe4010701; Sat, 14 Jan 2012 00:35:43 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4F10B1B3.6090908@ukr.net> Date: Sat, 14 Jan 2012 00:35:31 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F109F79.5090406@ukr.net> <20120113221548.GA18199@michelle.cdnetworks.com> In-Reply-To: <20120113221548.GA18199@michelle.cdnetworks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sat, 14 Jan 2012 00:35:43 +0200 (EET) X-Spam-Status: No, score=-97.7 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Cc: net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) 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, 13 Jan 2012 22:35:51 -0000 14.01.2012 0:15, YongHyeon PYUN wrote: > On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: >> >> Tell me, what a performance in pps a network card RTL8111/8168B? >> Can I somehow increase it? >> Experimentally, since it begins to fall off 80Kpps: ( >> > > RX performance number will show much better than that but TX is > major bottleneck of controller. I tried hard to enhance TX > performance for the controller but I'm under the impression that > that number would be the maximum(around 90Kpps) and this is also > similar number what I got on Linux. > Given that re(4) controllers are for non-server grade systems I > wouldn't be surprised to see that number. If you need higher pps, > choose controllers targeted for servers. Alternatively, low cost > controllers from JMicron/Atheros also show decent TX/RX > performance numbers. That's why I would like to get some numerical limitations of the controller re (4). While there is no way to put a network card from Intel. > >> >> Jan 13 18:12:49 XXX kernel: re0: watchdog timeout >> Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN >> Jan 13 18:12:53 XXX kernel: re0: link state changed to UP >> > > I'm more concerned on watchdog timeouts than performance numbers. > Would you show me re(4) related message from dmesg(8) output? See dmesg output below. > And if you know how to reliably trigger the watchdog timeout, would > you share with us? DDoS attack has undergone server and choked these packages: ( Trafshow showed a peak of 110K pps, but immediately operational watchdog timeout. I would appreciate help in setting up a network interface, so as long as it is not turned off by such scams. >> >> >> # uname -a >> FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 >> 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 >> >> # pciconf -lv | grep -A 4 "re0@" >> re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 >> hdr=0x00 >> vendor = 'Realtek Semiconductor Co., Ltd.' >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' >> class = network >> subclass = ethernet >> > > RealTek controllers tend to use the same PCI id for different > controllers so pciconf(8) does not help here. re(4) may have shown > more details on your controller in dmesg output. > Jan 13 18:57:03 XXX kernel: re0: port 0xe800-0xe8ff mem 0xfcfff000-0xfcffffff,0xfcffffff,0xfcff8000-0xfcffbfff irq 18 at device 0.0 on pci2 Jan 13 18:57:03 XXX kernel: re0: Using 1 MSI-X message Jan 13 18:57:03 XXX kernel: re0: Chip rev. 0x2c800000 Jan 13 18:57:03 XXX kernel: re0: MAC rev. 0x00000000 Jan 13 18:57:03 XXX kernel: miibus0: on re0 Jan 13 18:57:03 XXX kernel: rgephy0: PHY 1 on miibus0 Jan 13 18:57:03 XXX kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Jan 13 18:57:03 XXX kernel: re0: Ethernet address: 14:da:e9:75:5f:ee -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 22:43:10 2012 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 F24B3106564A for ; Fri, 13 Jan 2012 22:43:10 +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 820B38FC13 for ; Fri, 13 Jan 2012 22:43:10 +0000 (UTC) Received: by iagz16 with SMTP id z16so264996iag.13 for ; Fri, 13 Jan 2012 14:43:09 -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=0tjPU/cw4iubfOtP+dYKyow7cZr7AwYsiiD6rvjewRQ=; b=mSQtg6kDyopvrIzShLiWKIoi840PoenX22T6Mep5rWLvj5UgDHcoEdxsIKXaPKJLpg OUCAor91lAPGukcErUknM+ibBZVFx3syZ5FzaUMUfGs/cSzhs2c1F35B4L29J6sfIdL4 dgT8Wt8IHQSopsyaotFHwC9LN5+NCVhPkeR3w= Received: by 10.50.195.129 with SMTP id ie1mr2488113igc.29.1326492950607; Fri, 13 Jan 2012 14:15:50 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id g34sm33227167ibk.10.2012.01.13.14.15.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 14:15:49 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 13 Jan 2012 14:15:48 -0800 From: YongHyeon PYUN Date: Fri, 13 Jan 2012 14:15:48 -0800 To: "Vladislav V. Prodan" Message-ID: <20120113221548.GA18199@michelle.cdnetworks.com> References: <4F109F79.5090406@ukr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F109F79.5090406@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) 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: Fri, 13 Jan 2012 22:43:11 -0000 On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: > > Tell me, what a performance in pps a network card RTL8111/8168B? > Can I somehow increase it? > Experimentally, since it begins to fall off 80Kpps: ( > RX performance number will show much better than that but TX is major bottleneck of controller. I tried hard to enhance TX performance for the controller but I'm under the impression that that number would be the maximum(around 90Kpps) and this is also similar number what I got on Linux. Given that re(4) controllers are for non-server grade systems I wouldn't be surprised to see that number. If you need higher pps, choose controllers targeted for servers. Alternatively, low cost controllers from JMicron/Atheros also show decent TX/RX performance numbers. > > Jan 13 18:12:49 XXX kernel: re0: watchdog timeout > Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN > Jan 13 18:12:53 XXX kernel: re0: link state changed to UP > I'm more concerned on watchdog timeouts than performance numbers. Would you show me re(4) related message from dmesg(8) output? And if you know how to reliably trigger the watchdog timeout, would you share with us? > > > # uname -a > FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 > 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 > > # pciconf -lv | grep -A 4 "re0@" > re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class = network > subclass = ethernet > RealTek controllers tend to use the same PCI id for different controllers so pciconf(8) does not help here. re(4) may have shown more details on your controller in dmesg output. From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 23:01:54 2012 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 A6750106566B for ; Fri, 13 Jan 2012 23:01:54 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 77B448FC08 for ; Fri, 13 Jan 2012 23:01:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 68FCA446002; Fri, 13 Jan 2012 18:03:31 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4E1vctLPFbJ; Fri, 13 Jan 2012 18:03:30 -0500 (EST) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 0B896446001; Fri, 13 Jan 2012 18:03:30 -0500 (EST) From: Andrew Boyer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2012 18:01:51 -0500 Message-Id: <10A2858D-8DA8-45C4-B9A6-00CFA172404F@averesystems.com> To: Jack Vogel Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Ryan Stone Subject: Bad interaction between 82599 hardware RSC and VLANs 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, 13 Jan 2012 23:01:54 -0000 Hello Jack, I'm seeing an issue on 82599 controllers. When hardware RSC is used, = large VLAN packets arrive without the VP bit set, even though the vtag = in the descriptor is correct. It totally kills the receive performance. = Turning off hardware RSC in the driver (falling back to software LRO) = works fine, as does turning off LRO entirely. I've worked around the problem for now by overriding the VP bit if = ixgbe_rxeof() finds a valid vtag in the descriptor. Have you seen this before? It's not in the latest errata. It almost seems to be the opposite of = what Ryan reported in November 2010 ("82599 receiving packets with vlan = tag=3D0 (vlan strip problem)?"). Thanks, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 23:04:58 2012 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 7C5D7106564A for ; Fri, 13 Jan 2012 23:04:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE368FC17 for ; Fri, 13 Jan 2012 23:04:57 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so125044wgb.31 for ; Fri, 13 Jan 2012 15:04:56 -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=bbO+tyOeSPqMN8u5F88G/U/bbl55UI0fEcf11ZL4b18=; b=Qfu5alu7q3fhljltFqp7Y5RSi7OfeI4HUHxUvwdSaCXVfuzFvbVRWTASyeagfe4vD+ HQePyGwj/55YJ9tNTGEWMYunVeE23CGVimdu9teKH6tXCyN/qba3IrfxjJWPVhcp+uAU mghQkJlU1wRgTEiRwaxegXAFahOhv21uuFRtQ= MIME-Version: 1.0 Received: by 10.180.83.104 with SMTP id p8mr68410wiy.4.1326495896725; Fri, 13 Jan 2012 15:04:56 -0800 (PST) Received: by 10.180.84.66 with HTTP; Fri, 13 Jan 2012 15:04:56 -0800 (PST) In-Reply-To: <10A2858D-8DA8-45C4-B9A6-00CFA172404F@averesystems.com> References: <10A2858D-8DA8-45C4-B9A6-00CFA172404F@averesystems.com> Date: Fri, 13 Jan 2012 15:04:56 -0800 Message-ID: From: Jack Vogel To: Andrew Boyer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ryan Stone , Jack Vogel Subject: Re: Bad interaction between 82599 hardware RSC and VLANs 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, 13 Jan 2012 23:04:58 -0000 Hey Andrew, Not heard of this before, but I'll check around. Jack On Fri, Jan 13, 2012 at 3:01 PM, Andrew Boyer wrote: > Hello Jack, > I'm seeing an issue on 82599 controllers. When hardware RSC is used, > large VLAN packets arrive without the VP bit set, even though the vtag in > the descriptor is correct. It totally kills the receive performance. > Turning off hardware RSC in the driver (falling back to software LRO) > works fine, as does turning off LRO entirely. > > I've worked around the problem for now by overriding the VP bit if > ixgbe_rxeof() finds a valid vtag in the descriptor. > > Have you seen this before? > > It's not in the latest errata. It almost seems to be the opposite of what > Ryan reported in November 2010 ("82599 receiving packets with vlan tag=0 > (vlan strip problem)?"). > > Thanks, > Andrew > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 23:11:50 2012 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 972C3106564A for ; Fri, 13 Jan 2012 23:11:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 57A288FC0C for ; Fri, 13 Jan 2012 23:11:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A64D77300A; Sat, 14 Jan 2012 00:10:48 +0100 (CET) Date: Sat, 14 Jan 2012 00:10:48 +0100 From: Luigi Rizzo To: "Vladislav V. Prodan" Message-ID: <20120113231048.GA30302@onelab2.iet.unipi.it> References: <4F109F79.5090406@ukr.net> <20120113221548.GA18199@michelle.cdnetworks.com> <4F10B1B3.6090908@ukr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F10B1B3.6090908@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: pyunyh@gmail.com, net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) 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, 13 Jan 2012 23:11:50 -0000 On Sat, Jan 14, 2012 at 12:35:31AM +0200, Vladislav V. Prodan wrote: > 14.01.2012 0:15, YongHyeon PYUN wrote: > > On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: > >> > >> Tell me, what a performance in pps a network card RTL8111/8168B? > >> Can I somehow increase it? > >> Experimentally, since it begins to fall off 80Kpps: ( > >> > > > > RX performance number will show much better than that but TX is > > major bottleneck of controller. I tried hard to enhance TX > > performance for the controller but I'm under the impression that > > that number would be the maximum(around 90Kpps) and this is also > > similar number what I got on Linux. > > Given that re(4) controllers are for non-server grade systems I > > wouldn't be surprised to see that number. If you need higher pps, > > choose controllers targeted for servers. Alternatively, low cost > > controllers from JMicron/Atheros also show decent TX/RX > > performance numbers. > > That's why I would like to get some numerical limitations of the > controller re (4). my experience with netmap is that my re cards on PCIe bus can do over 1Mpps in receive (don't rember the exact number), but only about 400-450Kpps in tx. At least on the tx path i got approximately the same speed with the netsend program (in tools/tools/netrate/netsend). cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 23:27:21 2012 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 6298F1065670 for ; Fri, 13 Jan 2012 23:27:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 264748FC08 for ; Fri, 13 Jan 2012 23:27:20 +0000 (UTC) Received: by obbta17 with SMTP id ta17so4316181obb.13 for ; Fri, 13 Jan 2012 15:27:20 -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=WPvLup8XP5Xj1SZ0wWEEW1fJ/vYfG6UNtFTGVUXLH8o=; b=hh9k6xxTiG32reG3yuHbCiQ88x0DbTVUqpECrw2kNFaewDSl/CRX0hvYbvRWG69eks Lk6IS/OeyQ/zGvDEodv6w4RZeLmHn9iAYdSu7by07e7947ZMru7NxS6WAl4pnmJeii8T AaN0ZI/noqhzq9SUqoQYuPWMYMgGhZVAREusQ= Received: by 10.50.192.162 with SMTP id hh2mr323182igc.8.1326497240145; Fri, 13 Jan 2012 15:27:20 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q30sm33917617ibc.1.2012.01.13.15.27.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 15:27:19 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 13 Jan 2012 15:27:18 -0800 From: YongHyeon PYUN Date: Fri, 13 Jan 2012 15:27:18 -0800 To: "Vladislav V. Prodan" Message-ID: <20120113232718.GC18199@michelle.cdnetworks.com> References: <4F109F79.5090406@ukr.net> <20120113221548.GA18199@michelle.cdnetworks.com> <4F10B1B3.6090908@ukr.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: <4F10B1B3.6090908@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) 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: Fri, 13 Jan 2012 23:27:21 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 14, 2012 at 12:35:31AM +0200, Vladislav V. Prodan wrote: > 14.01.2012 0:15, YongHyeon PYUN wrote: > > On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: > >> > >> Tell me, what a performance in pps a network card RTL8111/8168B? > >> Can I somehow increase it? > >> Experimentally, since it begins to fall off 80Kpps: ( > >> > > > > RX performance number will show much better than that but TX is > > major bottleneck of controller. I tried hard to enhance TX > > performance for the controller but I'm under the impression that > > that number would be the maximum(around 90Kpps) and this is also > > similar number what I got on Linux. > > Given that re(4) controllers are for non-server grade systems I > > wouldn't be surprised to see that number. If you need higher pps, > > choose controllers targeted for servers. Alternatively, low cost > > controllers from JMicron/Atheros also show decent TX/RX > > performance numbers. > > That's why I would like to get some numerical limitations of the > controller re (4). > While there is no way to put a network card from Intel. > > > > >> > >> Jan 13 18:12:49 XXX kernel: re0: watchdog timeout > >> Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN > >> Jan 13 18:12:53 XXX kernel: re0: link state changed to UP > >> > > > > I'm more concerned on watchdog timeouts than performance numbers. > > Would you show me re(4) related message from dmesg(8) output? > See dmesg output below. > > > And if you know how to reliably trigger the watchdog timeout, would > > you share with us? > > DDoS attack has undergone server and choked these packages: ( Sound like hard to reproduce this on my box. > Trafshow showed a peak of 110K pps, but immediately operational watchdog > timeout. > I would appreciate help in setting up a network interface, so as long as > it is not turned off by such scams. > > >> > >> > >> # uname -a > >> FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 > >> 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 > >> > >> # pciconf -lv | grep -A 4 "re0@" > >> re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 > >> hdr=0x00 > >> vendor = 'Realtek Semiconductor Co., Ltd.' > >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > >> class = network > >> subclass = ethernet > >> > > > > RealTek controllers tend to use the same PCI id for different > > controllers so pciconf(8) does not help here. re(4) may have shown > > more details on your controller in dmesg output. > > > Jan 13 18:57:03 XXX kernel: re0: Gigabit Ethernet> port 0xe800-0xe8ff mem > 0xfcfff000-0xfcffffff,0xfcffffff,0xfcff8000-0xfcffbfff irq 18 at device > 0.0 on pci2 > Jan 13 18:57:03 XXX kernel: re0: Using 1 MSI-X message > Jan 13 18:57:03 XXX kernel: re0: Chip rev. 0x2c800000 > Jan 13 18:57:03 XXX kernel: re0: MAC rev. 0x00000000 > Jan 13 18:57:03 XXX kernel: miibus0: on re0 > Jan 13 18:57:03 XXX kernel: rgephy0: media interface> PHY 1 on miibus0 > Jan 13 18:57:03 XXX kernel: rgephy0: none, 10baseT, 10baseT-FDX, > 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > Jan 13 18:57:03 XXX kernel: re0: Ethernet address: 14:da:e9:75:5f:ee > Thanks, your controller is RTL8168E-VL. Could you try attached patch? The patch also contains unrelated one for the issue but it wouldn't hurt either. --rJwd6BRFiFCcLxzm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.txfifo.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 230063) +++ sys/dev/re/if_re.c (working copy) @@ -3147,7 +3147,13 @@ } else CSR_WRITE_4(sc, RL_TXCFG, RL_TXCFG_CONFIG); - CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16); + /* XXX */ + if ((sc->rl_flags & RL_FLAG_CMDSTOP_WAIT_TXQ) != 0) { + CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 4992 / 128); + CSR_WRITE_4(sc, RL_TXCFG, CSR_READ_4(sc, RL_TXCFG) | + RL_TXCFG_AUTO_FIFO); + } else + CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16); /* * Set the initial RX configuration. @@ -3558,7 +3564,6 @@ } /* Free the TX list buffers. */ - for (i = 0; i < sc->rl_ldata.rl_tx_desc_cnt; i++) { txd = &sc->rl_ldata.rl_tx_desc[i]; if (txd->tx_m != NULL) { @@ -3572,11 +3577,10 @@ } /* Free the RX list buffers. */ - for (i = 0; i < sc->rl_ldata.rl_rx_desc_cnt; i++) { rxd = &sc->rl_ldata.rl_rx_desc[i]; if (rxd->rx_m != NULL) { - bus_dmamap_sync(sc->rl_ldata.rl_tx_mtag, + bus_dmamap_sync(sc->rl_ldata.rl_rx_mtag, rxd->rx_dmamap, BUS_DMASYNC_POSTREAD); bus_dmamap_unload(sc->rl_ldata.rl_rx_mtag, rxd->rx_dmamap); @@ -3584,6 +3588,20 @@ rxd->rx_m = NULL; } } + + if ((sc->rl_flags & RL_FLAG_JUMBOV2) != 0) { + for (i = 0; i < sc->rl_ldata.rl_rx_desc_cnt; i++) { + rxd = &sc->rl_ldata.rl_jrx_desc[i]; + if (rxd->rx_m != NULL) { + bus_dmamap_sync(sc->rl_ldata.rl_jrx_mtag, + rxd->rx_dmamap, BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(sc->rl_ldata.rl_jrx_mtag, + rxd->rx_dmamap); + m_freem(rxd->rx_m); + rxd->rx_m = NULL; + } + } + } } /* Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 230063) +++ sys/pci/if_rlreg.h (working copy) @@ -142,6 +142,7 @@ * TX config register bits */ #define RL_TXCFG_CLRABRT 0x00000001 /* retransmit aborted pkt */ +#define RL_TXCFG_AUTO_FIFO 0x00000080 /* 8168E-VL or higher */ #define RL_TXCFG_MAXDMA 0x00000700 /* max DMA burst size */ #define RL_TXCFG_QUEUE_EMPTY 0x00000800 /* 8168E-VL or higher */ #define RL_TXCFG_CRCAPPEND 0x00010000 /* CRC append (0 = yes) */ --rJwd6BRFiFCcLxzm-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 23:42:26 2012 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 0E5591065672 for ; Fri, 13 Jan 2012 23:42:26 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 872F28FC13 for ; Fri, 13 Jan 2012 23:42:25 +0000 (UTC) Received: from [IPv6:2001:470:28:140:bc5b:f133:cc84:f629] ([IPv6:2001:470:28:140:bc5b:f133:cc84:f629]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id q0DNgK5k024085; Sat, 14 Jan 2012 01:42:20 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4F10C14F.8050408@ukr.net> Date: Sat, 14 Jan 2012 01:42:07 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F109F79.5090406@ukr.net> <20120113221548.GA18199@michelle.cdnetworks.com> <4F10B1B3.6090908@ukr.net> <20120113232718.GC18199@michelle.cdnetworks.com> In-Reply-To: <20120113232718.GC18199@michelle.cdnetworks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sat, 14 Jan 2012 01:42:20 +0200 (EET) X-Spam-Status: No, score=-97.7 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Cc: net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) 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, 13 Jan 2012 23:42:26 -0000 14.01.2012 1:27, YongHyeon PYUN wrote: > On Sat, Jan 14, 2012 at 12:35:31AM +0200, Vladislav V. Prodan wrote: >> 14.01.2012 0:15, YongHyeon PYUN wrote: >>> On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: >>>> >>>> Tell me, what a performance in pps a network card RTL8111/8168B? >>>> Can I somehow increase it? >>>> Experimentally, since it begins to fall off 80Kpps: ( >>>> >>> >>> RX performance number will show much better than that but TX is >>> major bottleneck of controller. I tried hard to enhance TX >>> performance for the controller but I'm under the impression that >>> that number would be the maximum(around 90Kpps) and this is also >>> similar number what I got on Linux. >>> Given that re(4) controllers are for non-server grade systems I >>> wouldn't be surprised to see that number. If you need higher pps, >>> choose controllers targeted for servers. Alternatively, low cost >>> controllers from JMicron/Atheros also show decent TX/RX >>> performance numbers. >> >> That's why I would like to get some numerical limitations of the >> controller re (4). >> While there is no way to put a network card from Intel. >> >>> >>>> >>>> Jan 13 18:12:49 XXX kernel: re0: watchdog timeout >>>> Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN >>>> Jan 13 18:12:53 XXX kernel: re0: link state changed to UP >>>> >>> >>> I'm more concerned on watchdog timeouts than performance numbers. >>> Would you show me re(4) related message from dmesg(8) output? >> See dmesg output below. >> >>> And if you know how to reliably trigger the watchdog timeout, would >>> you share with us? >> >> DDoS attack has undergone server and choked these packages: ( > > Sound like hard to reproduce this on my box. I agree. > >> Trafshow showed a peak of 110K pps, but immediately operational watchdog >> timeout. >> I would appreciate help in setting up a network interface, so as long as >> it is not turned off by such scams. >> >>>> >>>> >>>> # uname -a >>>> FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 >>>> 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 >>>> >>>> # pciconf -lv | grep -A 4 "re0@" >>>> re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 >>>> hdr=0x00 >>>> vendor = 'Realtek Semiconductor Co., Ltd.' >>>> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' >>>> class = network >>>> subclass = ethernet >>>> >>> >>> RealTek controllers tend to use the same PCI id for different >>> controllers so pciconf(8) does not help here. re(4) may have shown >>> more details on your controller in dmesg output. >>> >> Jan 13 18:57:03 XXX kernel: re0: > Gigabit Ethernet> port 0xe800-0xe8ff mem >> 0xfcfff000-0xfcffffff,0xfcffffff,0xfcff8000-0xfcffbfff irq 18 at device >> 0.0 on pci2 >> Jan 13 18:57:03 XXX kernel: re0: Using 1 MSI-X message >> Jan 13 18:57:03 XXX kernel: re0: Chip rev. 0x2c800000 >> Jan 13 18:57:03 XXX kernel: re0: MAC rev. 0x00000000 >> Jan 13 18:57:03 XXX kernel: miibus0: on re0 >> Jan 13 18:57:03 XXX kernel: rgephy0: > media interface> PHY 1 on miibus0 >> Jan 13 18:57:03 XXX kernel: rgephy0: none, 10baseT, 10baseT-FDX, >> 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, >> 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, >> 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >> Jan 13 18:57:03 XXX kernel: re0: Ethernet address: 14:da:e9:75:5f:ee >> > > Thanks, your controller is RTL8168E-VL. > Could you try attached patch? The patch also contains unrelated > one for the issue but it wouldn't hurt either. The patch can be applied no earlier than Tuesday, when comes the new Intel NIC. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 00:18:11 2012 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 42431106566B for ; Sat, 14 Jan 2012 00:18:11 +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 094068FC17 for ; Sat, 14 Jan 2012 00:18:10 +0000 (UTC) Received: by iagz16 with SMTP id z16so432772iag.13 for ; Fri, 13 Jan 2012 16:18:10 -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=teKvralIgHUku5leabQO/FywW39kb6l6+7ZAh0RJIvQ=; b=eb7bJBtzX62khX44sNXuJhVOD6chHAJGf//0yMpD05kp6I4iDkSJWxrdOkDyEyn3pc 7avfCtodCsmgWKBEO8Qf/Qlo7rKxer75tmyqWMIi5YHQGcTpmKz9xOKyUs+0To3+KJcu 3cm7bNV8zIZWnQrrUllWSMxxl55DSHNiPjbEo= Received: by 10.42.153.6 with SMTP id k6mr2254943icw.30.1326500290418; Fri, 13 Jan 2012 16:18:10 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id gh9sm9311256igb.3.2012.01.13.16.18.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 16:18:09 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 13 Jan 2012 16:18:08 -0800 From: YongHyeon PYUN Date: Fri, 13 Jan 2012 16:18:08 -0800 To: "Vladislav V. Prodan" Message-ID: <20120114001808.GD18199@michelle.cdnetworks.com> References: <4F109F79.5090406@ukr.net> <20120113221548.GA18199@michelle.cdnetworks.com> <4F10B1B3.6090908@ukr.net> <20120113232718.GC18199@michelle.cdnetworks.com> <4F10C14F.8050408@ukr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F10C14F.8050408@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) 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: Sat, 14 Jan 2012 00:18:11 -0000 On Sat, Jan 14, 2012 at 01:42:07AM +0200, Vladislav V. Prodan wrote: > 14.01.2012 1:27, YongHyeon PYUN wrote: > > On Sat, Jan 14, 2012 at 12:35:31AM +0200, Vladislav V. Prodan wrote: > >> 14.01.2012 0:15, YongHyeon PYUN wrote: > >>> On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: > >>>> > >>>> Tell me, what a performance in pps a network card RTL8111/8168B? > >>>> Can I somehow increase it? > >>>> Experimentally, since it begins to fall off 80Kpps: ( > >>>> > >>> > >>> RX performance number will show much better than that but TX is > >>> major bottleneck of controller. I tried hard to enhance TX > >>> performance for the controller but I'm under the impression that > >>> that number would be the maximum(around 90Kpps) and this is also > >>> similar number what I got on Linux. > >>> Given that re(4) controllers are for non-server grade systems I > >>> wouldn't be surprised to see that number. If you need higher pps, > >>> choose controllers targeted for servers. Alternatively, low cost > >>> controllers from JMicron/Atheros also show decent TX/RX > >>> performance numbers. > >> > >> That's why I would like to get some numerical limitations of the > >> controller re (4). > >> While there is no way to put a network card from Intel. > >> > >>> > >>>> > >>>> Jan 13 18:12:49 XXX kernel: re0: watchdog timeout > >>>> Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN > >>>> Jan 13 18:12:53 XXX kernel: re0: link state changed to UP > >>>> > >>> > >>> I'm more concerned on watchdog timeouts than performance numbers. > >>> Would you show me re(4) related message from dmesg(8) output? > >> See dmesg output below. > >> > >>> And if you know how to reliably trigger the watchdog timeout, would > >>> you share with us? > >> > >> DDoS attack has undergone server and choked these packages: ( > > > > Sound like hard to reproduce this on my box. > > I agree. > > > > > >> Trafshow showed a peak of 110K pps, but immediately operational watchdog > >> timeout. > >> I would appreciate help in setting up a network interface, so as long as > >> it is not turned off by such scams. > >> > >>>> > >>>> > >>>> # uname -a > >>>> FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 > >>>> 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 > >>>> > >>>> # pciconf -lv | grep -A 4 "re0@" > >>>> re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 > >>>> hdr=0x00 > >>>> vendor = 'Realtek Semiconductor Co., Ltd.' > >>>> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > >>>> class = network > >>>> subclass = ethernet > >>>> > >>> > >>> RealTek controllers tend to use the same PCI id for different > >>> controllers so pciconf(8) does not help here. re(4) may have shown > >>> more details on your controller in dmesg output. > >>> > >> Jan 13 18:57:03 XXX kernel: re0: >> Gigabit Ethernet> port 0xe800-0xe8ff mem > >> 0xfcfff000-0xfcffffff,0xfcffffff,0xfcff8000-0xfcffbfff irq 18 at device > >> 0.0 on pci2 > >> Jan 13 18:57:03 XXX kernel: re0: Using 1 MSI-X message > >> Jan 13 18:57:03 XXX kernel: re0: Chip rev. 0x2c800000 > >> Jan 13 18:57:03 XXX kernel: re0: MAC rev. 0x00000000 > >> Jan 13 18:57:03 XXX kernel: miibus0: on re0 > >> Jan 13 18:57:03 XXX kernel: rgephy0: >> media interface> PHY 1 on miibus0 > >> Jan 13 18:57:03 XXX kernel: rgephy0: none, 10baseT, 10baseT-FDX, > >> 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, > >> 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, > >> 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > >> Jan 13 18:57:03 XXX kernel: re0: Ethernet address: 14:da:e9:75:5f:ee > >> > > > > Thanks, your controller is RTL8168E-VL. > > Could you try attached patch? The patch also contains unrelated > > one for the issue but it wouldn't hurt either. > > The patch can be applied no earlier than Tuesday, when comes the new > Intel NIC. > Ok, forgot to say one more thing. The patch was generated against HEAD so you may have to use CURRENT or latest stable/9 to use the patch. Probably you can download both if_re.c and if_rlreg.h from stable/9 and apply the patch. From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 00:41:28 2012 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 40D4B1065672; Sat, 14 Jan 2012 00:41:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95C058FC17; Sat, 14 Jan 2012 00:41:27 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q0E0fD4L012609; Sat, 14 Jan 2012 09:41:23 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q0E0fCOj042644; Sat, 14 Jan 2012 09:41:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 14 Jan 2012 09:41:07 +0900 (JST) Message-Id: <20120114.094107.1766686302128995004.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F0CE268.1000903@FreeBSD.org> References: <4F036A7F.9030906@FreeBSD.org> <20120104.060327.1335862860296491365.hrs@allbsd.org> <4F0CE268.1000903@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jan_14_09_41_07_2012_838)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 14 Jan 2012 09:41:26 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade 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, 14 Jan 2012 00:41:28 -0000 ----Security_Multipart(Sat_Jan_14_09_41_07_2012_838)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F0CE268.1000903@FreeBSD.org>: do> On 01/03/2012 13:03, Hiroki Sato wrote: do> > Okay, thank you for your report. I will take some time to fix do> > TCP_MD5SIG support in openbgpd and inform you when another patch is do> > ready. do> do> Any news on this? Not trying to be pushy, just wondering if I need to do> plan a test/change window. Sorry, no news yet. I plan to work on it this weekend and in the next week. -- Hiroki ----Security_Multipart(Sat_Jan_14_09_41_07_2012_838)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8QzyMACgkQTyzT2CeTzy3stACfeFtNeZ8Db9CDnbR+iXyWnVWo TBcAn0EwtpqR/RfB7TM+BbIWhuEpHwxw =/60W -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jan_14_09_41_07_2012_838)---- From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 17:09:27 2012 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 1017610656A7 for ; Sat, 14 Jan 2012 17:09:27 +0000 (UTC) (envelope-from bnorton916@yahoo.com) Received: from nm37-vm7.bullet.mail.bf1.yahoo.com (nm37-vm7.bullet.mail.bf1.yahoo.com [72.30.238.207]) by mx1.freebsd.org (Postfix) with SMTP id A09FC8FC19 for ; Sat, 14 Jan 2012 17:09:26 +0000 (UTC) Received: from [98.139.212.152] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jan 2012 16:55:52 -0000 Received: from [98.139.212.237] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jan 2012 16:55:52 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 14 Jan 2012 16:55:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 279652.1309.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 40492 invoked by uid 60001); 14 Jan 2012 16:55:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1326560151; bh=Qa+Vti+/pSIGE+A1QtkPsye1keeKfiT9KY6LLW/KeF8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=F16nmu+IWvYQ3jKxexh9zpEdR3Ylbn+kuw1Ngv+hvGW5k28kmn+SBT4DvAzSfiaoqN1xYlPUNBkSyavpzADtv/W/mj8g8HBx9Oa1gXHLEzKYoo1N2Au5i2rpNjjljvYvKf4ED4ZXiAYcyeBSkhDR2gv/OL2xGRIa3EMKvila0BA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=bdLHv7RmFAakS5QUz77McNiOTGrlymoPICYLVhVmuo3Xrs9VegKRpmtulsKUpa9Fz+zmy5aar9PI4+vTpSTiUULJ5mcyjupA3Y9JPzBdM1XAI8RNsBbnBOEvo8RZUU6OsvHV8mnUKLZPQvFJ+VNXRQ0v+Q4/J6eWkOyCmWeKCDs=; X-YMail-OSG: qgstKYwVM1kfehjY3ufyoqBL12laIcsFQNVZzx6XJabiTT1 kXctsu1LuvWi4l5_JuQ.cNrq1sw1PJxH57rKjMB9mPxuR5.deCgAa_xhDsKu .z5BqrSzzejtR5l906n1o3u5FIzMiU0haopKEcQADPiaGguiNVYvgCwPheKh yKjcSEnEXgwgXSltk0r2dhNG7o9f6r7.NrdnsDHgA6Wj6go40KL1_CJjiV3H ZSO._8kqGE8FaysdaE_uGIqaSZjw8cTUnXiNsVMDEx0eiKurDs0DaIaMNiNu isOnanLrCEb4mqyO68IufpjROCFwK_03.5ssbRKwq.5y7n1ZgQ.30Q0Oypgm 2TIW6CNRtQwM_.T2NavVxzZGC5c4zdAsrH8kOdQnQaUV8O.3VktIapOjRXxr lCVD4H7INAHLnkrFSYoy0gtPl1l3fx50bgV57rE_tlUpsnEg635qsalZxXoX 2 Received: from [96.38.98.89] by web36505.mail.mud.yahoo.com via HTTP; Sat, 14 Jan 2012 08:55:51 PST X-Mailer: YahooMailWebService/0.8.115.331698 Message-ID: <1326560151.30035.YahooMailNeo@web36505.mail.mud.yahoo.com> Date: Sat, 14 Jan 2012 08:55:51 -0800 (PST) From: Bill Norton To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: bge0 interface seen but not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bill Norton List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 17:09:27 -0000 Greetings,=0A=0AI posted this on the pc-bsd forum and was directed here.=A0= =0A=0AI installed the latest 8.X and the interface worked fine.=A0=0A=0AYes= terday, I did a clean install of 9.0.=A0=0A=0AThe issue is that the bge0 in= terface is not working.=A0=0AIt is seen by the kernel(ifconfig shows it) bu= t just won't ping.=0AI have tried dhcp and a static address.=A0=0AI used a = backtrack live cd and this worked fine.=A0=0A=0A=0AI did find this bug belo= w but it seemed to only affect 8.2=0A=0AThe bge(4) Ethernet driver has a kn= own issue where the interface is seen but does not respond to networking re= quests. A patch is available for 8.2 (see 155442) and the driver will be fi= xed in 8.3.=0A=0AAny ideas?=A0=0A=0A=0ABill Norton From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 20:22:33 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B192C106564A; Sat, 14 Jan 2012 20:22:33 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 84D1B8FC08; Sat, 14 Jan 2012 20:22:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0EKMX8G030595; Sat, 14 Jan 2012 20:22:33 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0EKMXeZ030591; Sat, 14 Jan 2012 20:22:33 GMT (envelope-from remko) Date: Sat, 14 Jan 2012 20:22:33 GMT Message-Id: <201201142022.q0EKMXeZ030591@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: bin/164102: hostapd not configured for 802.11n 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, 14 Jan 2012 20:22:33 -0000 Synopsis: hostapd not configured for 802.11n Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Jan 14 20:22:13 UTC 2012 Responsible-Changed-Why: This is more wireless networking related then i386. http://www.freebsd.org/cgi/query-pr.cgi?pr=164102 From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 20:54:45 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D40A41065673; Sat, 14 Jan 2012 20:54:45 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A72108FC12; Sat, 14 Jan 2012 20:54:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0EKsjKj060434; Sat, 14 Jan 2012 20:54:45 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0EKsjS1060430; Sat, 14 Jan 2012 20:54:45 GMT (envelope-from adrian) Date: Sat, 14 Jan 2012 20:54:45 GMT Message-Id: <201201142054.q0EKsjS1060430@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: bin/164102: hostapd not configured for 802.11n 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, 14 Jan 2012 20:54:45 -0000 Synopsis: hostapd not configured for 802.11n Responsible-Changed-From-To: freebsd-net->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sat Jan 14 20:54:35 UTC 2012 Responsible-Changed-Why: Flip to -wireless. http://www.freebsd.org/cgi/query-pr.cgi?pr=164102 From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 22:54:01 2012 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 0BB0D1065670; Sat, 14 Jan 2012 22:54:01 +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 B767A8FC13; Sat, 14 Jan 2012 22:54:00 +0000 (UTC) Received: by iagz16 with SMTP id z16so2373674iag.13 for ; Sat, 14 Jan 2012 14:54:00 -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=H+OnoM72psYsDfcSZKeUOxVx0emfaUkRXohrnTkHUWY=; b=oQ2yy9/PQG8bivKObTCCJR2hphV9WP+Ex9LsCpJA9K0QYzyJ0Pzmt2S5yagTZy84pf IWnuCUmnwXlT3DyuB2dNHB/LxlW8HQRQyMyon/fZAdrquZkThGBhBcVahfGj9AbllIcx pQPM+NFJASZVkQPvUHKhFK8+Lc9qWKZv+WtOQ= Received: by 10.42.131.7 with SMTP id x7mr5391358ics.11.1326581640366; Sat, 14 Jan 2012 14:54:00 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r18sm45892197ibh.4.2012.01.14.14.53.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jan 2012 14:53:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 14 Jan 2012 14:53:58 -0800 From: YongHyeon PYUN Date: Sat, 14 Jan 2012 14:53:58 -0800 To: Bill Norton Message-ID: <20120114225358.GA22889@michelle.cdnetworks.com> References: <1326560151.30035.YahooMailNeo@web36505.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326560151.30035.YahooMailNeo@web36505.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , jhb@FreeBSD.org Subject: Re: bge0 interface seen but not working 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: Sat, 14 Jan 2012 22:54:01 -0000 On Sat, Jan 14, 2012 at 08:55:51AM -0800, Bill Norton wrote: > Greetings, > > I posted this on the pc-bsd forum and was directed here.? > > I installed the latest 8.X and the interface worked fine.? > > Yesterday, I did a clean install of 9.0.? > > The issue is that the bge0 interface is not working.? > It is seen by the kernel(ifconfig shows it) but just won't ping. > I have tried dhcp and a static address.? > I used a backtrack live cd and this worked fine.? > Probably disabling MSI will workaround your issue. Add hw.pci.enable_msi="0" to /boot/loader.conf. > > I did find this bug below but it seemed to only affect 8.2 > > The bge(4) Ethernet driver has a known issue where the interface is seen but does not respond to networking requests. A patch is available for 8.2 (see 155442) and the driver will be fixed in 8.3. > > Any ideas?? > I thought it was already fixed by John but it seems it is not. John, would you take a look?(NVIDIA HT MSI issue)? From owner-freebsd-net@FreeBSD.ORG Sat Jan 14 23:17:01 2012 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 25D491065670; Sat, 14 Jan 2012 23:17:01 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB6188FC1D; Sat, 14 Jan 2012 23:17:00 +0000 (UTC) Received: by ghbf14 with SMTP id f14so1556195ghb.13 for ; Sat, 14 Jan 2012 15:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=nB8MKEc7LG4P1xwOTYvadeQVl2p/Nisgc7JwQukGXPE=; b=NLLErRp5Ver0xjtJq4A4+NXCfjX59swADKLQOOUqpVs7/jzgP75kSNRct7aiqhsGk2 9B91TJoiEXZMa62QkXev6timjao2a8ahS1hVtfJFgcG+9p63bP8Mo8Rj0jR2sSe5UsJP CUZmJ1f2miLxbkfmsSN4xg7wUo3h/vMqdupso= Received: by 10.236.173.133 with SMTP id v5mr9852968yhl.73.1326581369624; Sat, 14 Jan 2012 14:49:29 -0800 (PST) Received: from [192.168.1.37] ([190.50.164.7]) by mx.google.com with ESMTPS id z3sm22173941yhd.3.2012.01.14.14.49.22 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 14:49:28 -0800 (PST) Sender: Fernando Gont Message-ID: <4F108D05.2040201@gont.com.ar> Date: Fri, 13 Jan 2012 16:59:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Nikolay Denev References: <4F0FFDC9.1090503@freebsd.org> <897A1A91-61DB-4783-B38A-C77DBC54DD45@gmail.com> In-Reply-To: <897A1A91-61DB-4783-B38A-C77DBC54DD45@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: ICMP attacks against TCP and PMTUD 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, 14 Jan 2012 23:17:01 -0000 Hello, Nikolay, On 01/13/2012 12:29 PM, Nikolay Denev wrote: > I'm now looking again at the pcap and I'm a bit confused. > First the possible attacker sends the ICMP need-frag packets with "MTU of next hop" set to zero, > which in 2012 shouldn't be very common? Not just uncommon, but actually not possible (*): the minimum IPv4 MTU is 68 bytes, so you should never see an advertised MTU smaller than that. Furthermore, as noted by Andre, the lowest *real* MTUs are >250 bytes. (*) IIRC, an archaic specification of the "frag needed" messages didn't include the "Next-Hop MTU" field, which means that in *theory* (*not* in current practice) those messages could be legitimate. > Then when my server sends 66 byte FIN/ACK packet, > the attacker continues to send need-frag ICMPs and the FreeBSD host sends again > FIN/ACK packets. > Later on he sends again ICMP need-frag packets, but with size of about 1048 bytes, > with very large part of the original packets payload, instead of the required several bytes, > this then triggers excessive retransmits from the FreeBSD host which generates a lot of traffic. > The retransmits are roughly ~300-500 byte packets. Can you post a packet trace (tcpdump's packet decode output), or send me the trace or pcap files to me off-list, so that I can take a look and comment? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1