From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 13:28:46 2009 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 5B0931065670 for ; Sun, 7 Jun 2009 13:28:46 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id 1B70F8FC21 for ; Sun, 7 Jun 2009 13:28:45 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by k7.mavetju.org (Postfix, from userid 1001) id A95064509C; Sun, 7 Jun 2009 23:28:44 +1000 (EST) Date: Sun, 7 Jun 2009 23:28:44 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20090607132844.GA19694@mavetju.org> References: <200906051424.n55EOIrM012619@post.behrens.de> <4A297BB4.80002@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A297BB4.80002@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Subject: Re: NTP - default /etc/ntp.conf 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, 07 Jun 2009 13:28:46 -0000 Please note that it just has been committed. Everybody thanks a lot for your input! Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 09:27:56 2009 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 DE9B910656C3 for ; Mon, 8 Jun 2009 09:27:56 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 76D1C8FC20 for ; Mon, 8 Jun 2009 09:27:56 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 1B2AE3BBCF for ; Mon, 8 Jun 2009 11:27:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E5neiNWOkez for ; Mon, 8 Jun 2009 11:27:32 +0200 (CEST) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 31D1239CC9 for ; Mon, 8 Jun 2009 11:27:32 +0200 (CEST) Date: Mon, 8 Jun 2009 11:27:30 +0200 From: Ollivier Robert To: freebsd-net@FreeBSD.org Message-ID: <20090608092730.GA1059@roberto-al.eurocontrol.fr> References: <200906051424.n55EOIrM012619@post.behrens.de> <4A297BB4.80002@FreeBSD.org> <20090606174642.I16690@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090606174642.I16690@delplex.bde.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: NTP - default /etc/ntp.conf 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, 08 Jun 2009 09:27:57 -0000 According to Bruce Evans: > /var/db/ntpd.drift is not documented anywhere in $(find /usr/share/man) > of course. Keep in mind that most of our manpages are reverse-engineered from the HTML files Dave Mills only wanted to support... I'll try to update to the latest version and see if the now bshipped in manpages are any better. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 10:00:19 2009 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 A786E106566C for ; Mon, 8 Jun 2009 10:00:19 +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 7B2A98FC08 for ; Mon, 8 Jun 2009 10:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58A0Jcx064683 for ; Mon, 8 Jun 2009 10:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58A0JPX064682; Mon, 8 Jun 2009 10:00:19 GMT (envelope-from gnats) Date: Mon, 8 Jun 2009 10:00:19 GMT Message-Id: <200906081000.n58A0JPX064682@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bohdan Tymkiv Cc: Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bohdan Tymkiv List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:00:19 -0000 The following reply was made to PR kern/133572; it has been noted by GNATS. From: Bohdan Tymkiv To: bug-followup@FreeBSD.org, dennis.melentyev@gmail.com Cc: Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Date: Mon, 08 Jun 2009 12:51:15 +0300 Dennis, maybe this issue is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=134557 can you confirm this? -- Bohdan Tymkiv From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 10:10:07 2009 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 AD1C1106566B for ; Mon, 8 Jun 2009 10:10:07 +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 810808FC14 for ; Mon, 8 Jun 2009 10:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58AA7Bg071604 for ; Mon, 8 Jun 2009 10:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58AA7iK071603; Mon, 8 Jun 2009 10:10:07 GMT (envelope-from gnats) Date: Mon, 8 Jun 2009 10:10:07 GMT Message-Id: <200906081010.n58AA7iK071603@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eugene M. Zheganin" Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd3.5 hanging up - ng_pptp problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Eugene M. Zheganin" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:10:07 -0000 The following reply was made to PR kern/134557; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org, sergei.cherveni@gmail.com Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd3.5 hanging up - ng_pptp problem Date: Mon, 08 Jun 2009 15:37:54 +0600 Exactly same here. mpd 5.3 on 7.2-RELEASE, PPPoE client to WAN, PPTP over it. When mpd is configured as PPPoE-only client, all works just fine. When I add a pptp server fuctionality (config is proven to work on previous versions), the system starts to hang after pptp session connects and then disconnects. -- Eugene M. Zheganin From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 11:06:58 2009 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 C6DB31065673 for ; Mon, 8 Jun 2009 11:06:58 +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 B2E198FC1B for ; Mon, 8 Jun 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58B6w1m020741 for ; Mon, 8 Jun 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58B6wJ5020737 for freebsd-net@FreeBSD.org; Mon, 8 Jun 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jun 2009 11:06:58 GMT Message-Id: <200906081106.n58B6wJ5020737@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, 08 Jun 2009 11:06:59 -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/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface 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/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 306 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 17:14:20 2009 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 C7BEE106566B; Mon, 8 Jun 2009 17:14:20 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D0A78FC08; Mon, 8 Jun 2009 17:14:20 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58HEKeB006185; Mon, 8 Jun 2009 17:14:20 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58HEKfY006181; Mon, 8 Jun 2009 17:14:20 GMT (envelope-from bz) Date: Mon, 8 Jun 2009 17:14:20 GMT Message-Id: <200906081714.n58HEKfY006181@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-jail@FreeBSD.org, freebsd-net@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/134583: [hang] Machine with jail freezes after random amount of time 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, 08 Jun 2009 17:14:21 -0000 Old Synopsis: [jail] [hang] Machine with jail freezes after random amount of time New Synopsis: [hang] Machine with jail freezes after random amount of time Responsible-Changed-From-To: freebsd-jail->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Mon Jun 8 17:12:41 UTC 2009 Responsible-Changed-Why: This does not sounds like a jail but more a networking/tcp problem with 7.2-R hanging the machine. Re-assign so that the right people will look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=134583 From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 20:22:42 2009 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 94C99106566C; Mon, 8 Jun 2009 20:22:42 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [IPv6:2001:470:1f09:16f:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2C98FC1D; Mon, 8 Jun 2009 20:22:42 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 46C2A45405; Mon, 8 Jun 2009 21:22:41 +0100 (BST) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id VW+pASfTSk14; Mon, 8 Jun 2009 20:22:40 +0000 (UTC) Received: from [10.0.2.50] (daffy.tector.org.uk [82.71.32.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id C06D1453EA; Mon, 8 Jun 2009 21:22:37 +0100 (BST) Message-ID: <4A2D7307.30701@thekeelecentre.com> Date: Mon, 08 Jun 2009 21:22:31 +0100 From: Richard Tector User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Edwin Groothuis References: <20090605124428.GA85576@mavetju.org> <200906051424.n55EOIrM012619@post.behrens.de> <20090605235117.GB3235@mavetju.org> In-Reply-To: <20090605235117.GB3235@mavetju.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Frank Behrens , freebsd-net@freebsd.org, roberto@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 08 Jun 2009 20:22:42 -0000 The fact that everyone has different ideas and suggestions with regards to the contents of this file, and also that it's generally better to use time servers from your local area (http://www.pool.ntp.org/en/use.html) rather than the global pool, indicates to me that having a default configuration is not a good idea. Regards, Richard From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 23:49:50 2009 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 A0F661065670; Mon, 8 Jun 2009 23:49:50 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id 5090A8FC2A; Mon, 8 Jun 2009 23:49:49 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by k7.mavetju.org (Postfix, from userid 1001) id B46F3450BB; Tue, 9 Jun 2009 09:49:48 +1000 (EST) Date: Tue, 9 Jun 2009 09:49:48 +1000 From: Edwin Groothuis To: Richard Tector Message-ID: <20090608234948.GD98804@mavetju.org> References: <20090605124428.GA85576@mavetju.org> <200906051424.n55EOIrM012619@post.behrens.de> <20090605235117.GB3235@mavetju.org> <4A2D7307.30701@thekeelecentre.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2D7307.30701@thekeelecentre.com> User-Agent: Mutt/1.4.2.3i Cc: Frank Behrens , freebsd-net@freebsd.org, roberto@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 08 Jun 2009 23:49:51 -0000 Hello Richard, On Mon, Jun 08, 2009 at 09:22:31PM +0100, Richard Tector wrote: > The fact that everyone has different ideas and suggestions with regards > to the contents of this file, and also that it's generally better to use > time servers from your local area (http://www.pool.ntp.org/en/use.html) > rather than the global pool, indicates to me that having a default > configuration is not a good idea. The DNS servers for pool.ntp.org area already geographical distance aware: ;; ANSWER SECTION: 0.pool.ntp.org. 1089 IN A 119.148.81.6 0.pool.ntp.org. 1089 IN A 202.60.94.11 0.pool.ntp.org. 1089 IN A 202.89.184.139 0.pool.ntp.org. 1089 IN A 203.161.129.2 0.pool.ntp.org. 1089 IN A 203.82.209.217 ;; ANSWER SECTION: au.pool.ntp.org. 1200 IN A 119.148.81.6 au.pool.ntp.org. 1200 IN A 202.125.43.135 au.pool.ntp.org. 1200 IN A 202.60.94.11 au.pool.ntp.org. 1200 IN A 203.161.129.2 au.pool.ntp.org. 1200 IN A 203.82.209.217 I've only sorted them for easier comparing, I haven't changed them. But as you can see, they both give the same. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 23:50:52 2009 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 6CE7C1065672; Mon, 8 Jun 2009 23:50:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA0E8FC13; Mon, 8 Jun 2009 23:50:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 477065C025; Tue, 9 Jun 2009 07:50:51 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1367155CDB90; Tue, 9 Jun 2009 07:50:51 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id IlW5ZSVGKTeH; Tue, 9 Jun 2009 07:50:00 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 5DAE255CDB8E; Tue, 9 Jun 2009 07:49:53 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=wYR4CY0oDBAF5uPxuiFKuSTrFJYCuc09TmjZclfNLXmHYA8qyr7ERgAtL0rlUbp9M je0XjRVfcJ1l9i4yCNLSw== Message-ID: <4A2DA390.3090704@delphij.net> Date: Mon, 08 Jun 2009 16:49:36 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: FreeBSD Tinderbox References: <20090608224516.547F17302F@freebsd-current.sentex.ca> In-Reply-To: <20090608224516.547F17302F@freebsd-current.sentex.ca> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------080305080905050101040406" Cc: net@freebsd.org, current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 23:50:53 -0000 This is a multi-part message in MIME format. --------------080305080905050101040406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FreeBSD Tinderbox wrote: > cc1: warnings being treated as errors > /src/sys/net/if_gif.c: In function 'gif_ioctl': > /src/sys/net/if_gif.c:918: warning: cast to pointer from integer of different size > *** Error code 1 > > Stop in /obj/sparc64/src/sys/LINT. > *** Error code 1 The attached patch should fix this, any objections? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoto48ACgkQi+vbBBjt66C98ACgvgafjQZ/MU01V8ftN6ZI9/1U xB0AoKZipqyI0JYmBkMGNsEEYp8A0VVl =3o5u -----END PGP SIGNATURE----- --------------080305080905050101040406 Content-Type: text/plain; name="if_gif.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_gif.c.diff" Index: if_gif.c =================================================================== --- if_gif.c (revision 193731) +++ if_gif.c (working copy) @@ -912,10 +912,10 @@ case GIFSOPTS: if ((error = priv_check(curthread, PRIV_NET_GIF)) != 0) break; - if ((error = copyin(&options, &sc->gif_options, - sizeof(sc->gif_options)))) { + if ((error = copyin(ifr->ifr_data, &options, + sizeof(options)))) { if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) - ifr->ifr_data = (caddr_t)options; + sc->gif_options = options; else error = EINVAL; } --------------080305080905050101040406-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 05:09:47 2009 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 2BE4B106566C for ; Tue, 9 Jun 2009 05:09:47 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B02CD8FC12 for ; Tue, 9 Jun 2009 05:09:46 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=RZ36D/zf0MqMeIK7hGrC0jPBJaX5vGBHNEmJpK+yjYGlufLvvc6WYAdSQkLDRZueYqoM41j0+bYJJFOsHXdIigsLkflNwsuL0zrLCySG7gGhd6jZ8TpIkxTBTHUDcmmS7ml43AOVG6/T7fqN/EKldPUFhP5mgi8GnDRWJNlPtTg=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MDtGs-000H5n-NS; Tue, 09 Jun 2009 08:49:14 +0400 Date: Tue, 9 Jun 2009 08:49:12 +0400 From: Eygene Ryabinkin To: d@delphij.net Message-ID: References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2DA390.3090704@delphij.net> Sender: rea-fbsd@codelabs.ru Cc: current@freebsd.org, net@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 05:09:47 -0000 Xin, good day. Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: > The attached patch should fix this, any objections? Yes, you missed negation operator in the copyin check. The issue was already fixed by hrs@ two hours ago: http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 06:20:06 2009 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 BDDBF106566C for ; Tue, 9 Jun 2009 06:20:06 +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 ABF2E8FC14 for ; Tue, 9 Jun 2009 06:20:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n596K6oj039354 for ; Tue, 9 Jun 2009 06:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n596K6Uu039348; Tue, 9 Jun 2009 06:20:06 GMT (envelope-from gnats) Date: Tue, 9 Jun 2009 06:20:06 GMT Message-Id: <200906090620.n596K6Uu039348@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dennis Melentyev Cc: Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dennis Melentyev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:20:07 -0000 The following reply was made to PR kern/133572; it has been noted by GNATS. From: Dennis Melentyev To: bohdan200@gmail.com Cc: bug-followup@freebsd.org Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Date: Tue, 9 Jun 2009 08:51:39 +0300 Not sure. I had no PPPoE. Only PPTP connections. One is outgoing VPN to ISP and 10 incoming VPNs for employees. Also, my configuration used to have two uplinks with extensive use of policy based routing and forwarding. daemons: mpd4, pf. It is possible that I have some kind of loops in routing, it was not very professional set-up :) BTW, I have no possibility to reproduce the problem since I've downgraded system to 7.1. /dennis 2009/6/8 Bohdan Tymkiv : > Dennis, > maybe this issue is related to > http://www.freebsd.org/cgi/query-pr.cgi?pr=134557 > can you confirm this? > > -- > Bohdan Tymkiv > > -- Dennis Melentyev From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 07:21:05 2009 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 D4B2F106567B; Tue, 9 Jun 2009 07:21:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 75FA28FC0A; Tue, 9 Jun 2009 07:21:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 7EF935C025; Tue, 9 Jun 2009 15:21:04 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 0300555CDB97; Tue, 9 Jun 2009 15:21:04 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id er3Xzu7Du-pZ; Tue, 9 Jun 2009 15:20:12 +0800 (CST) Received: from charlie.delphij.net (c-67-188-2-183.hsd1.ca.comcast.net [67.188.2.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 37E9355CDB93; Tue, 9 Jun 2009 15:20:04 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=T7uN/N1yueOOJuD3CcGAwtzbzlxltMU9T8l0p3Nl6iWcvGV5tbr2OE12ILFvQRlfe PgL3plWJDJhrS6y+cuHIw== Message-ID: <4A2E0D12.40101@delphij.net> Date: Tue, 09 Jun 2009 00:19:46 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Danny Braniss References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: d@delphij.net, Hiroki Sato , rea-fbsd@codelabs.ru, FreeBSD Current , net@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 07:21:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Braniss wrote: >> Xin, good day. >> >> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: >>> The attached patch should fix this, any objections? >> Yes, you missed negation operator in the copyin check. The issue >> was already fixed by hrs@ two hours ago: >> http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 > sorry to barge in, but: > if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) > is not clear, > if ((options & ~GIF_FULLOPTS) == 0) > seems to be less offuscated or I'm missing something? Yes this looks like the usually used idiom (perhaps more efficient anyway)... I just kept the style consistent with the old code. Hiroki-san, could you have a look at this and consider if we should use this idiom? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkouDRIACgkQi+vbBBjt66A1vACggjZwN3xCIHhfsEj141tAqqqX gdcAn0XM9BDHIhpWGct861T43SlmtQyv =ozhg -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 07:45:07 2009 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 6A4CD1065673; Tue, 9 Jun 2009 07:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1CF1D8FC14; Tue, 9 Jun 2009 07:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C7BFD41C729; Tue, 9 Jun 2009 09:45:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ZPmTa2SEGpxX; Tue, 9 Jun 2009 09:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 696B041C71D; Tue, 9 Jun 2009 09:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 89B1C4448E6; Tue, 9 Jun 2009 07:42:25 +0000 (UTC) Date: Tue, 9 Jun 2009 07:42:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: d@delphij.net In-Reply-To: <4A2E0D12.40101@delphij.net> Message-ID: <20090609074144.O22887@maildrop.int.zabbadoz.net> References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> <4A2E0D12.40101@delphij.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Danny Braniss , Hiroki Sato , rea-fbsd@codelabs.ru, FreeBSD Current , net@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 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, 09 Jun 2009 07:45:07 -0000 On Tue, 9 Jun 2009, Xin LI wrote: > Danny Braniss wrote: >>> Xin, good day. >>> >>> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: >>>> The attached patch should fix this, any objections? >>> Yes, you missed negation operator in the copyin check. The issue >>> was already fixed by hrs@ two hours ago: >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 >> sorry to barge in, but: >> if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) >> is not clear, >> if ((options & ~GIF_FULLOPTS) == 0) >> seems to be less offuscated or I'm missing something? > > Yes this looks like the usually used idiom (perhaps more efficient > anyway)... I just kept the style consistent with the old code. > Hiroki-san, could you have a look at this and consider if we should use > this idiom? Also see the mail I had sent in reply to the commit message yesterday. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 07:45:58 2009 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 E9183106566B; Tue, 9 Jun 2009 07:45:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A25F48FC29; Tue, 9 Jun 2009 07:45:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MDvQt-000CEr-B0; Tue, 09 Jun 2009 10:07:43 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: rea-fbsd@codelabs.ru In-reply-to: References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> Comments: In-reply-to Eygene Ryabinkin message dated "Tue, 09 Jun 2009 08:49:12 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jun 2009 10:07:43 +0300 From: Danny Braniss Message-ID: Cc: d@delphij.net, current@freebsd.org, net@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 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, 09 Jun 2009 07:45:59 -0000 > Xin, good day. > > Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: > > The attached patch should fix this, any objections? > > Yes, you missed negation operator in the copyin check. The issue > was already fixed by hrs@ two hours ago: > http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 sorry to barge in, but: if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) is not clear, if ((options & ~GIF_FULLOPTS) == 0) seems to be less offuscated or I'm missing something? danny > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 08:05:37 2009 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 E54A5106564A; Tue, 9 Jun 2009 08:05:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (unknown [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 62BC68FC13; Tue, 9 Jun 2009 08:05:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p3185-ipbf514funabasi.chiba.ocn.ne.jp [123.225.96.185]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n5984Pfr041789; Tue, 9 Jun 2009 17:04:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n5983pbt072769; Tue, 9 Jun 2009 17:03:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 09 Jun 2009 17:03:28 +0900 (JST) Message-Id: <20090609.170328.129820575.hrs@allbsd.org> To: bzeeb-lists@lists.zabbadoz.net From: Hiroki Sato In-Reply-To: <20090609074144.O22887@maildrop.int.zabbadoz.net> References: <4A2E0D12.40101@delphij.net> <20090609074144.O22887@maildrop.int.zabbadoz.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Jun__9_17_03_28_2009_143)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.allbsd.org [133.31.130.32]); Tue, 09 Jun 2009 17:04:36 +0900 (JST) Cc: d@delphij.net, current@FreeBSD.org, hrs@FreeBSD.org, net@FreeBSD.org, danny@cs.huji.ac.il, rea-fbsd@codelabs.ru Subject: Re: [head tinderbox] failure on sparc64/sparc64 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, 09 Jun 2009 08:05:38 -0000 ----Security_Multipart(Tue_Jun__9_17_03_28_2009_143)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bjoern A. Zeeb" wrote in <20090609074144.O22887@maildrop.int.zabbadoz.net>: bz> On Tue, 9 Jun 2009, Xin LI wrote: bz> bz> > Danny Braniss wrote: bz> >>> Xin, good day. bz> >>> bz> >>> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: bz> >>>> The attached patch should fix this, any objections? bz> >>> Yes, you missed negation operator in the copyin check. The issue bz> >>> was already fixed by hrs@ two hours ago: bz> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 bz> >> sorry to barge in, but: bz> >> if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) bz> >> is not clear, bz> >> if ((options & ~GIF_FULLOPTS) == 0) bz> >> seems to be less offuscated or I'm missing something? bz> > bz> > Yes this looks like the usually used idiom (perhaps more efficient bz> > anyway)... I just kept the style consistent with the old code. bz> > Hiroki-san, could you have a look at this and consider if we should bz> > use bz> > this idiom? bz> bz> Also see the mail I had sent in reply to the commit message yesterday. Sorry, I overlooked some of the messages I received. Yes, the logic was reversed and fixed now, but your patch including style fix looks better to me. I will commit it. Thank you for your review! -- Hiroki ----Security_Multipart(Tue_Jun__9_17_03_28_2009_143)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkouF1AACgkQTyzT2CeTzy1lcACfc5RgQgb7oLMdGSwbMjob4W5M pLkAnRLDVDaLMfpf5e8I2WHV/SeM02Yh =BQGc -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jun__9_17_03_28_2009_143)---- From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 08:23:09 2009 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 DDBA8106566C for ; Tue, 9 Jun 2009 08:23:09 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [85.115.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 600DD8FC16 for ; Tue, 9 Jun 2009 08:23:08 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 10:05:54 +0200 Received: from GIBSVWIN004X.partygaming.local ([10.3.10.228]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:05:55 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by GIBSVWIN004X.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:05:55 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Jun 2009 11:05:53 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unable to clone wlan device thread-index: Acno2RxlU/iQEFpIQKOIhJLSxQfzFA== From: "Vladimir Terziev" To: X-OriginalArrivalTime: 09 Jun 2009 08:05:55.0308 (UTC) FILETIME=[1D4072C0:01C9E8D9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unable to clone wlan device 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, 09 Jun 2009 08:23:10 -0000 Hi, on FreeBSD 7.1-RELEASE (i386) driven machine, with iwi(4) (Intel = PRO/Wireless 2915ABG), i try to create a clone of the iwi0 device. Here is the device info: $ ifconfig iwi0 iwi0: flags=3D8802 metric 0 mtu 1500 ether 00:16:6f:8a:ee:4b media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 (2412 Mhz 11b) authmode OPEN privacy OFF bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 = bintval 0 $ ifconfig iwi0 list caps iwi0=3D25818300 When i try to create the clone device i get the following: # ifconfig wlan create wlandev iwi0 ifconfig: SIOCIFCREATE2: Invalid argument I searched for a similar problem in the net, but haven't found anything = meaningful. What am i missing ? Regards, Vladimir This email and any attachments are confidential, and may be legally = privileged and protected by copyright. If you are not the intended = recipient dissemination or copying of this email is prohibited. If you = have received this in error, please notify the sender by replying by = email and then delete the email completely from your system.=20 Any views or opinions are solely those of the sender. This = communication is not intended to form a binding contract unless = expressly indicated to the contrary and properly authorised. Any actions = taken on the basis of this email are at the recipient's own risk. From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 08:34:49 2009 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 B6FE31065674 for ; Tue, 9 Jun 2009 08:34:49 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7C88FC2A for ; Tue, 9 Jun 2009 08:34:49 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz4 with SMTP id 4so115175bwz.43 for ; Tue, 09 Jun 2009 01:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k0TRGd8em0NA04XUIEhV0AnccW78U2yA57tVQeIDg/Y=; b=nYYYjKry3uZvnCImi9JuPfEJfNAyFiM1SsoKCrAXs5mToO2XmIwN2LfQKYKVukdPZr aXLd4V8f0SxZBlitaBvXYNKGL4O0KIVw3VkNKYbxEzGhu+Cklmlu4eDl3UMwmKpnNzen bILD4aCfW4OUPyjM1NRHXJ8+zijf1HtbDlDJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mF/mY8N7eB9zQ8TtjZpHAJOvfMx/EJdRxGfQo63XjyjDxKznHFCjmzeOYR6D6rRsVQ EkXPwlhzHzjVGPv11wt/J9beCrJ3GM2d/py6Mdnpq/XTGh9Y/0UmPvCl9NT2aP56pSkl 1W9BtH5F0J9p7O+XxiBq5ZsSEce3FkYhzvXbk= MIME-Version: 1.0 Received: by 10.204.31.74 with SMTP id x10mr7625312bkc.7.1244536485788; Tue, 09 Jun 2009 01:34:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jun 2009 08:34:45 +0000 Message-ID: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> From: "Paul B. Mahol" To: Vladimir Terziev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 08:34:50 -0000 wlan cloning is only available on 8.0, and iwi supports only one virtual interface at any time. -- Paul From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 08:40:59 2009 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 CF20B106567B for ; Tue, 9 Jun 2009 08:40:59 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [85.115.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBEC8FC51 for ; Tue, 9 Jun 2009 08:40:58 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 10:40:52 +0200 Received: from GIBSVWIN004.partygaming.local ([10.3.10.26]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:40:53 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by GIBSVWIN004.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:40:52 +0200 Received: from 10.4.71.11 ([10.4.71.11]) by SOFSVWIN004X.partygaming.local ([10.4.10.230]) via Exchange Front-End Server corp.mail.partygaming.com ([10.3.10.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Jun 2009 08:40:51 +0000 Received: from daemon2.partygaming.local by corp.mail.partygaming.com; 09 Jun 2009 11:40:50 +0300 From: Vladimir Terziev To: "Paul B. Mahol" In-Reply-To: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> References: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Organization: GB Servicves Ltd. Date: Tue, 09 Jun 2009 11:40:49 +0300 Message-ID: <1244536849.41240.6.camel@daemon2.partygaming.local> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-OriginalArrivalTime: 09 Jun 2009 08:40:52.0607 (UTC) FILETIME=[FF56E0F0:01C9E8DD] Cc: freebsd-net@freebsd.org Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 08:41:00 -0000 Thanks Paul, i have tried the same with ral(4) device and got a similar result. What about ral(4), does it support virtual interfaces ? Regards, Vladimir On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: > wlan cloning is only available on 8.0, and iwi supports only one > virtual > interface at any time. >=20 > -- > Paul >=20 >=20 This email and any attachments are confidential, and may be legally = privileged and protected by copyright. If you are not the intended = recipient dissemination or copying of this email is prohibited. If you = have received this in error, please notify the sender by replying by = email and then delete the email completely from your system.=20 Any views or opinions are solely those of the sender. This = communication is not intended to form a binding contract unless = expressly indicated to the contrary and properly authorised. Any actions = taken on the basis of this email are at the recipient's own risk. From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 10:08:16 2009 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 8E9321065673 for ; Tue, 9 Jun 2009 10:08:16 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 174878FC0C for ; Tue, 9 Jun 2009 10:08:15 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz4 with SMTP id 4so173696bwz.43 for ; Tue, 09 Jun 2009 03:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/7OLwNDYT8mnk7TrkYJLdpvxw7PDtlCiujDTJA5uax8=; b=o9WVFmJOhJCbaDOt/8PkwwSqILkN1JzFpPFZU9VLREaBNw7OgSbo1bLecbo11APnEB hEqKmgytor13RU1JDsDkKYiZqQ4oMwBsXmqf5yvLaEFlW/suO+29Ft11ad6IyUOt+daR oYTMBzB7+mNU35/irOunOL53mtuiSFFNNJKSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a+hzPGHo+SazcHx4Mvi1PbwMv/UbNRU4wc63ilLq2nctTywPdFFvwMezhRw/GBXtFx 4zCsPEfBY7kDyxYaJZbeADG2byKzcGVtKh3WYdXXXEsnSZuih2AsMfU1jCIiE3bTfYVC LNmn5q6iha/DIIu/OunXfAhrSDf8PVF+gJ+ko= MIME-Version: 1.0 Received: by 10.204.117.17 with SMTP id o17mr7756111bkq.145.1244542094825; Tue, 09 Jun 2009 03:08:14 -0700 (PDT) In-Reply-To: <1244536849.41240.6.camel@daemon2.partygaming.local> References: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> <1244536849.41240.6.camel@daemon2.partygaming.local> Date: Tue, 9 Jun 2009 10:08:14 +0000 Message-ID: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> From: "Paul B. Mahol" To: Vladimir Terziev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 10:08:16 -0000 On 6/9/09, Vladimir Terziev wrote: > Thanks Paul, > > i have tried the same with ral(4) device and got a similar result. > > What about ral(4), does it support virtual interfaces ? No it doesn't. The only chips capable of multi bssid I'm aware of are atheros ones and only on >= 8.0. > On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: >> wlan cloning is only available on 8.0, and iwi supports only one >> virtual >> interface at any time. -- Paul From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 10:44:15 2009 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 BB3FF1065670 for ; Tue, 9 Jun 2009 10:44:15 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [85.115.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3440E8FC0C for ; Tue, 9 Jun 2009 10:44:14 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 12:44:09 +0200 Received: from GIBSVWIN004X.partygaming.local ([10.3.10.228]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 12:44:09 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by GIBSVWIN004X.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 12:44:09 +0200 Received: from 10.4.71.11 ([10.4.71.11]) by SOFSVWIN004X.partygaming.local ([10.4.10.230]) via Exchange Front-End Server corp.mail.partygaming.com ([10.3.10.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Jun 2009 10:44:08 +0000 Received: from daemon2.partygaming.local by corp.mail.partygaming.com; 09 Jun 2009 13:44:08 +0300 From: Vladimir Terziev To: "Paul B. Mahol" In-Reply-To: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> References: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Organization: GB Servicves Ltd. Date: Tue, 09 Jun 2009 13:44:07 +0300 Message-ID: <1244544247.41240.16.camel@daemon2.partygaming.local> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-OriginalArrivalTime: 09 Jun 2009 10:44:09.0673 (UTC) FILETIME=[38559390:01C9E8EF] Cc: freebsd-net@freebsd.org Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 10:44:16 -0000 The actual problem, i play with wlan cloning because of, is, i try to set up a FreeBSD based wireless access point either based on ral(4) or iwi(4) interface. The ral(4) (which is "Edimax EW-7128g") seems more suitable for that, since it has HOSTAP capability, but when i tried to run a hostapd(8) on it, i got an error about inability TKIP to be configured by hostpad(8). Since TKIP is not present as a capability of the wireless adapter, i decided to clone it and use the wlan_tkip(4) module to do the work. Thanks for your time! Regards, Vladimir On Tue, 2009-06-09 at 13:08 +0300, Paul B. Mahol wrote: > On 6/9/09, Vladimir Terziev wrote: > > Thanks Paul, > > > > i have tried the same with ral(4) device and got a similar result. > > > > What about ral(4), does it support virtual interfaces ? >=20 > No it doesn't. The only chips capable of multi bssid I'm aware of > are atheros ones and only on >=3D 8.0. >=20 > > On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: > >> wlan cloning is only available on 8.0, and iwi supports only one > >> virtual > >> interface at any time. >=20 > -- > Paul >=20 >=20 This email and any attachments are confidential, and may be legally = privileged and protected by copyright. If you are not the intended = recipient dissemination or copying of this email is prohibited. If you = have received this in error, please notify the sender by replying by = email and then delete the email completely from your system.=20 Any views or opinions are solely those of the sender. This = communication is not intended to form a binding contract unless = expressly indicated to the contrary and properly authorised. Any actions = taken on the basis of this email are at the recipient's own risk. From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 12:18:12 2009 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 E32C81065670 for ; Tue, 9 Jun 2009 12:18:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 68B6F8FC13 for ; Tue, 9 Jun 2009 12:18:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz4 with SMTP id 4so257577bwz.43 for ; Tue, 09 Jun 2009 05:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DmhIMuADtpKFehLAkXF473+csXf1dfYRbd9QfCLWxEc=; b=hnIFwvLZawY77pp6QgAIB6qzsiyJ4iICsjfISx/KkXhTcNyU8ctK7p5H4ZiwF8ycwP jT1Hsn9CMbkxvLEItXzaMykfVxkPLhNKeO3TKN0w8EGV+yl1QQ5RS8P7JfZgqoMYPtGy 9guz7Yn4yQz+heoKLrs5bc15WpZzJNNTX+Vj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IojXlVjI8GRJQjE6ktbChwcyIPzeycfCIKKbq2YVih3AJcR/n0MplxyDS5/Mn6SP8X xtfv3RVV/KXlwWozkwA2HioFad20TRKigbQgkms49MPL2ZM4n2vE9LoNeE6IEtVrJqDc iqePg8pQkIbVZE5vejudhYo8QqY/mdoL6ftTw= MIME-Version: 1.0 Received: by 10.204.54.4 with SMTP id o4mr70704bkg.10.1244549891176; Tue, 09 Jun 2009 05:18:11 -0700 (PDT) In-Reply-To: <1244544247.41240.16.camel@daemon2.partygaming.local> References: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> <1244544247.41240.16.camel@daemon2.partygaming.local> Date: Tue, 9 Jun 2009 12:18:11 +0000 Message-ID: <3a142e750906090518u6951c28clbe6e97c1f4ff1601@mail.gmail.com> From: "Paul B. Mahol" To: Vladimir Terziev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 12:18:13 -0000 On 6/9/09, Vladimir Terziev wrote: > The actual problem, i play with wlan cloning because of, is, i try to > set up a FreeBSD based wireless access point either based on ral(4) or > iwi(4) interface. > > The ral(4) (which is "Edimax EW-7128g") seems more suitable for that, > since it has HOSTAP capability, but when i tried to run a hostapd(8) on > it, i got an error about inability TKIP to be configured by hostpad(8). > Since TKIP is not present as a capability of the wireless adapter, i > decided to clone it and use the wlan_tkip(4) module to do the work. That is not important. You don't need to clone device to use TKIP. If device or device driver doesn't support encryption in hardware, software encryption will do the work via wlan_tkip(4). There is only one exception to this and that are ndis(4) drivers. NDIS do not allow such workaround. -- Paul From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 12:34:25 2009 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 AF0721065676 for ; Tue, 9 Jun 2009 12:34:25 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [85.115.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3161C8FC1E for ; Tue, 9 Jun 2009 12:34:24 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 14:34:20 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 14:34:20 +0200 Received: from 10.4.71.11 ([10.4.71.11]) by SOFSVWIN004X.partygaming.local ([10.4.10.230]) via Exchange Front-End Server corp.mail.partygaming.com ([10.3.10.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Jun 2009 12:34:19 +0000 Received: from daemon2.partygaming.local by corp.mail.partygaming.com; 09 Jun 2009 15:34:18 +0300 From: Vladimir Terziev To: "Paul B. Mahol" In-Reply-To: <3a142e750906090518u6951c28clbe6e97c1f4ff1601@mail.gmail.com> References: <3a142e750906090518u6951c28clbe6e97c1f4ff1601@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Organization: GB Servicves Ltd. Date: Tue, 09 Jun 2009 15:34:18 +0300 Message-ID: <1244550858.41240.19.camel@daemon2.partygaming.local> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-OriginalArrivalTime: 09 Jun 2009 12:34:20.0632 (UTC) FILETIME=[9CC5DD80:01C9E8FE] Cc: freebsd-net@freebsd.org Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 12:34:26 -0000 Hi Paul, this is very very important info. It means i should be able to do it once i find the actual problem. Thanks, Vladimir On Tue, 2009-06-09 at 15:18 +0300, Paul B. Mahol wrote: > On 6/9/09, Vladimir Terziev wrote: > > The actual problem, i play with wlan cloning because of, is, i try > to > > set up a FreeBSD based wireless access point either based on ral(4) > or > > iwi(4) interface. > > > > The ral(4) (which is "Edimax EW-7128g") seems more suitable for > that, > > since it has HOSTAP capability, but when i tried to run a hostapd(8) > on > > it, i got an error about inability TKIP to be configured by > hostpad(8). > > Since TKIP is not present as a capability of the wireless adapter, i > > decided to clone it and use the wlan_tkip(4) module to do the work. >=20 > That is not important. > You don't need to clone device to use TKIP. > If device or device driver doesn't support encryption in hardware, > software > encryption will do the work via wlan_tkip(4). > There is only one exception to this and that are ndis(4) drivers. NDIS > do not allow such workaround. >=20 > -- > Paul >=20 >=20 This email and any attachments are confidential, and may be legally = privileged and protected by copyright. If you are not the intended = recipient dissemination or copying of this email is prohibited. If you = have received this in error, please notify the sender by replying by = email and then delete the email completely from your system.=20 Any views or opinions are solely those of the sender. This = communication is not intended to form a binding contract unless = expressly indicated to the contrary and properly authorised. Any actions = taken on the basis of this email are at the recipient's own risk. From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 15:47:22 2009 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 4AA47106566B for ; Tue, 9 Jun 2009 15:47:22 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AEA968FC17 for ; Tue, 9 Jun 2009 15:47:21 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n59FMxRo016538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 08:22:59 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A2E7E53.2010306@freebsd.org> Date: Tue, 09 Jun 2009 08:22:59 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Vladimir Terziev References: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> <1244544247.41240.16.camel@daemon2.partygaming.local> In-Reply-To: <1244544247.41240.16.camel@daemon2.partygaming.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, "Paul B. Mahol" Subject: Re: Unable to clone wlan device 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, 09 Jun 2009 15:47:22 -0000 As Paul mentioned iwi supports only 1 vap at a time. ral supports multiple vaps but only 1 ap vap + N wds vaps. It may be possible to support more complex configurations with some ralink parts (e.g. 2860 and later) but noone has made the effort. Not sure about the tkip comment. The output of ifconfig wlanX list caps shows support for h/w crypto acceleration. When a device/driver does not support h/w acceleration the work is done in s/w. This is unrelated to cloning/vaps. Sam Vladimir Terziev wrote: > The actual problem, i play with wlan cloning because of, is, i try to > set up a FreeBSD based wireless access point either based on ral(4) or > iwi(4) interface. > > The ral(4) (which is "Edimax EW-7128g") seems more suitable for that, > since it has HOSTAP capability, but when i tried to run a hostapd(8) on > it, i got an error about inability TKIP to be configured by hostpad(8). > Since TKIP is not present as a capability of the wireless adapter, i > decided to clone it and use the wlan_tkip(4) module to do the work. > > Thanks for your time! > > Regards, > > Vladimir > > > On Tue, 2009-06-09 at 13:08 +0300, Paul B. Mahol wrote: > >> On 6/9/09, Vladimir Terziev wrote: >> >>> Thanks Paul, >>> >>> i have tried the same with ral(4) device and got a similar result. >>> >>> What about ral(4), does it support virtual interfaces ? >>> >> No it doesn't. The only chips capable of multi bssid I'm aware of >> are atheros ones and only on >= 8.0. >> >> >>> On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: >>> >>>> wlan cloning is only available on 8.0, and iwi supports only one >>>> virtual >>>> interface at any time. >>>> >> -- >> Paul >> >> >> > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. > > > _______________________________________________ > 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 Tue Jun 9 16:20:03 2009 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 8EBA3106566B for ; Tue, 9 Jun 2009 16:20:03 +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 618BC8FC1C for ; Tue, 9 Jun 2009 16:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n59GK3dj035903 for ; Tue, 9 Jun 2009 16:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n59GK3ia035902; Tue, 9 Jun 2009 16:20:03 GMT (envelope-from gnats) Date: Tue, 9 Jun 2009 16:20:03 GMT Message-Id: <200906091620.n59GK3ia035902@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bohdan Tymkiv Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bohdan Tymkiv List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 16:20:04 -0000 The following reply was made to PR kern/134557; it has been noted by GNATS. From: Bohdan Tymkiv To: bug-followup@FreeBSD.org, sergei.cherveni@gmail.com Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Tue, 09 Jun 2009 19:12:28 +0300 I confirm that downgrading to 7.1-RELEASE-p5 from svn sources on the same machine fixes the issue. -- Bohdan Tymkiv Home From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 05:40:03 2009 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 95C071065686 for ; Wed, 10 Jun 2009 05:40:03 +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 840ED8FC25 for ; Wed, 10 Jun 2009 05:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5A5e3h0052246 for ; Wed, 10 Jun 2009 05:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5A5e31R052245; Wed, 10 Jun 2009 05:40:03 GMT (envelope-from gnats) Date: Wed, 10 Jun 2009 05:40:03 GMT Message-Id: <200906100540.n5A5e31R052245@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Takefu Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Takefu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 05:40:03 -0000 The following reply was made to PR kern/121257; it has been noted by GNATS. From: Takefu To: bug-followup@FreeBSD.org, vnovy@vnovy.net Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Date: Wed, 10 Jun 2009 14:14:42 +0900 > Dropped Receive Packets on Half-duplex 10/100 Networks > ------------------------------------------------------ > If you have an Intel PCI Express adapter installed, running at 10 or > 100 Mbps, half-duplex, with TCP Segment Offload (TSO) enabled, you may > observe occasional dropped receive packets. To work around this > problem, disable TSO, or update the network to operate in full-duplex > and/or 1 Gbps. http://downloadmirror.intel.com/14614/eng/rel_notes_v14_0.txt :-) From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 12:56:09 2009 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 8399B1065673 for ; Wed, 10 Jun 2009 12:56:09 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 14FBF8FC14 for ; Wed, 10 Jun 2009 12:56:08 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 926E8130C95; Wed, 10 Jun 2009 16:37:44 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 2739A130EF7; Wed, 10 Jun 2009 16:37:44 +0400 (MSD) Date: Wed, 10 Jun 2009 16:33:01 +0400 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20090610123301.GE40250@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 10062009 #2334115, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 8698 [Jun 09 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Method: white ip list X-SpamTest-Rate: 0 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: Subject: bge interrupt coalescing sysctls 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, 10 Jun 2009 12:56:09 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken the patch. I'm not sure how to fix the collision, and since I do not use dynamic tuning I has left only static coalescing parameters in the patch and has added a loader tunable to set number of receive descriptors and read only sysctl to read the tunable. I usually use these parameters: /boot/loader.conf: hw.bge.rxd=512 /etc/sysctl.conf: dev.bge.0.rx_coal_ticks=500 dev.bge.0.tx_coal_ticks=10000 dev.bge.0.rx_max_coal_bds=64 dev.bge.0.tx_max_coal_bds=128 # apply the above parameters dev.bge.0.program_coal=1 Could anyone commit it ? -- Igor Sysoev http://sysoev.ru/en/ --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="patch.bge" --- sys/dev/bge/if_bge.c 2009-05-21 01:17:10.000000000 +0400 +++ sys/dev/bge/if_bge.c 2009-06-05 13:45:49.000000000 +0400 @@ -447,12 +447,16 @@ DRIVER_MODULE(miibus, bge, miibus_driver, miibus_devclass, 0, 0); static int bge_allow_asf = 0; +static int bge_rxd = BGE_SSLOTS; TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf); +TUNABLE_INT("hw.bge.rxd", &bge_rxd); SYSCTL_NODE(_hw, OID_AUTO, bge, CTLFLAG_RD, 0, "BGE driver parameters"); SYSCTL_INT(_hw_bge, OID_AUTO, allow_asf, CTLFLAG_RD, &bge_allow_asf, 0, "Allow ASF mode if available"); +SYSCTL_INT(_hw_bge, OID_AUTO, bge_rxd, CTLFLAG_RD, &bge_rxd, 0, + "Number of receive descriptors"); #define SPARC64_BLADE_1500_MODEL "SUNW,Sun-Blade-1500" #define SPARC64_BLADE_1500_PATH_BGE "/pci@1f,700000/network@2" @@ -1008,21 +1012,15 @@ return (0); } -/* - * The standard receive ring has 512 entries in it. At 2K per mbuf cluster, - * that's 1MB or memory, which is a lot. For now, we fill only the first - * 256 ring entries and hope that our CPU is fast enough to keep up with - * the NIC. - */ static int bge_init_rx_ring_std(struct bge_softc *sc) { int i; - for (i = 0; i < BGE_SSLOTS; i++) { + for (i = 0; i < bge_rxd; i++) { if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) return (ENOBUFS); - }; + } bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, sc->bge_cdata.bge_rx_std_ring_map, @@ -2383,6 +2381,52 @@ #endif static int +bge_sysctl_program_coal(SYSCTL_HANDLER_ARGS) +{ + struct bge_softc *sc; + int error, i, val; + + val = 0; + error = sysctl_handle_int(oidp, &val, 0, req); + if (error != 0 || req->newptr == NULL) + return (error); + sc = arg1; + BGE_LOCK(sc); + + /* XXX cut from bge_blockinit(): */ + + /* Disable host coalescing until we get it set up */ + CSR_WRITE_4(sc, BGE_HCC_MODE, 0x00000000); + + /* Poll to make sure it's shut down. */ + for (i = 0; i < BGE_TIMEOUT; i++) { + if (!(CSR_READ_4(sc, BGE_HCC_MODE) & BGE_HCCMODE_ENABLE)) + break; + DELAY(10); + } + + if (i == BGE_TIMEOUT) { + device_printf(sc->bge_dev, + "host coalescing engine failed to idle\n"); + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); + BGE_UNLOCK(sc); + return (ENXIO); + } + + /* Set up host coalescing defaults */ + CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); + CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, sc->bge_rx_max_coal_bds); + CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS, sc->bge_tx_max_coal_bds); + + /* Turn on host coalescing state machine */ + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); + + BGE_UNLOCK(sc); + return (0); +} + +static int bge_attach(device_t dev) { struct ifnet *ifp; @@ -4495,6 +4539,19 @@ ctx = device_get_sysctl_ctx(sc->bge_dev); children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "program_coal", + CTLTYPE_INT | CTLFLAG_RW, + sc, 0, bge_sysctl_program_coal, "I", + "program bge coalescence values"); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_coal_ticks", CTLFLAG_RW, + &sc->bge_rx_coal_ticks, 0, ""); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_coal_ticks", CTLFLAG_RW, + &sc->bge_tx_coal_ticks, 0, ""); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_max_coal_bds", CTLFLAG_RW, + &sc->bge_rx_max_coal_bds, 0, ""); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_max_coal_bds", CTLFLAG_RW, + &sc->bge_tx_max_coal_bds, 0, ""); + #ifdef BGE_REGISTER_DEBUG SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "debug_info", CTLTYPE_INT | CTLFLAG_RW, sc, 0, bge_sysctl_debug_info, "I", --fdj2RfSjLxBAspz7-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 13:33:31 2009 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 268201065675 for ; Wed, 10 Jun 2009 13:33:31 +0000 (UTC) (envelope-from excalibur@accesswave.ca) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.freebsd.org (Postfix) with ESMTP id E39CC8FC08 for ; Wed, 10 Jun 2009 13:33:30 +0000 (UTC) (envelope-from excalibur@accesswave.ca) Received: from ip03.eastlink.ca ([24.222.39.36]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0KL000J55XLTDA81@mta01.eastlink.ca> for freebsd-net@freebsd.org; Wed, 10 Jun 2009 10:03:29 -0300 (ADT) Received: from blk-11-8-77.eastlink.ca (HELO mail.dreadnet.org) ([76.11.8.77]) by ip03.eastlink.ca with ESMTP; Wed, 10 Jun 2009 10:03:28 -0300 Received: from localhost (mail.dreadnet.org [192.168.200.15]) by mail.dreadnet.org (Postfix) with ESMTP id AEE6B6D73C38 for ; Wed, 10 Jun 2009 10:03:28 -0300 (ADT) Received: from mail.dreadnet.org ([192.168.200.15]) by localhost (mail.dreadnet.org [192.168.200.15]) (amavisd-new, port 10024) with ESMTP id f8cgrLNIE+8J for ; Wed, 10 Jun 2009 10:03:26 -0300 (ADT) Received: from [192.168.200.103] (unknown [192.168.200.103]) by mail.dreadnet.org (Postfix) with ESMTP id 9CAD36D73C2C for ; Wed, 10 Jun 2009 10:03:26 -0300 (ADT) Date: Wed, 10 Jun 2009 10:03:31 -0300 From: Chris Bowlby To: freebsd-net@freebsd.org Message-id: <4A2FAF23.6090906@accesswave.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroEAOlLL0pMCwhN/2dsb2JhbACBT8wphA0F X-IronPort-AV: E=Sophos;i="4.41,341,1241406000"; d="scan'208";a="363550637" X-Virus-Scanned: amavisd-new at dreadnet.org User-Agent: Thunderbird 2.0.0.19 (X11/20081227) Subject: IPSec VPN issues 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, 10 Jun 2009 13:33:31 -0000 Hi Everyone, I let this question sit in freebsd-questions overnight before posting this here, as I did not get any responses. Any help would be appreciated. -------------------------------- I'm in the process of configuring a VPN tunnel via IPSec to another network to provide an easy means to manage both networks. I can get the VPN established from my FreeBSD box to the server on the other side, but I can't seem to route any traffic through the interface so that it goes to the other side of the VPN. I know I am missing a step, but I can't seem to find any information in the documentation about what that step might be. Here is what I have so far: I have compiled my kernel with the following options: # IP Sec Options options IPSEC # IP Security options IPSEC_DEBUG # debug for IP security options IPSEC_FILTERTUNNEL # To properly filter on the inner packets (this was done in case I needed to expand some fire-walling to this box) And added the crypto device: # IPSec device crypto the kernel is installed and running with no issues as far as I can tell. I have also installed security/ipsec-tools, though I did noticed that a kernel patch was required for something related to NAT. As I am running FreeBSD 7.2, I was not sure if that patch was still required, and I am honestly not sure if NATing is what I need/require to get this running. My interfaces are as follows: amaethon# ifconfig em0: flags=8843 metric 0 mtu 1500 options=19b inet 1xx.1xx.2xx.2xx netmask 0xffffff00 broadcast 1xx.1xx.2xx.255 media: Ethernet autoselect (100baseTX ) status: active gif0: flags=8051 metric 0 mtu 1280 tunnel inet 1xx.1xx.2xx.2 --> xxx.2xx.1xx.1xx inet 1xx.1xx.2xx.2 --> 1xx.1xx.xxx.1 netmask 0xfffffc00 The routing tables are as follows: default 1xx.1xx.2xx.1 UGS 0 1807 em0 127.0.0.1 127.0.0.1 UH 0 4 lo0 1xx.1xx.xxx.0/22 1xx.1xx.xxx.1 UGS 0 0 gif0 1xx.1xx.xxx.1 1xx.1xx.2xx.2 UH 1 327 gif0 1xx.1xx.2xx.0/24 link#1 UC 0 0 em0 1xx.1xx.2xx.1 00:13:10:09:5b:1f UHLW 2 0 em0 1114 1xx.1xx.2xx.2 00:1c:c0:94:2c:0c UHLW 1 924 lo0 Right now I am simply looking to have any local (to the host) pinging a system on the other side. As I don't have immediate access to the routing details of the other end, and it's configured exactly the same as it has been for other VPN's, I am inclined to believe the issue is on my side of the VPN. The system I have, only has one NIC in it at this time, but can easily be configured to have a second. The system is also behind another system that is handling the local routing and fire-walling, and is NATing all appropriate traffic to the various box's. I have used the examples in the freebsd handbook to guide me as far as I have gotten thus far (btw there is a step missing in there, forgetting to tell you to run setkey -f /path/to/racoon/setkey.conf). I have googled everything I can find, looked over freebsd.org and freebsddiary.org (those articles are a bit out dated I think), and have found no information to indicate what I am missing.. I suspect it might be that this system is not doing traffic NATing, or a packet filter configuration is required, but I have tried every example with no luck. At this point I am stuck, and looking for some guidance. From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 14:54:54 2009 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 592D9106566B for ; Wed, 10 Jun 2009 14:54:54 +0000 (UTC) (envelope-from allceus@host.datatriangle.com) Received: from host.datatriangle.com (host.datatriangle.com [69.16.229.230]) by mx1.freebsd.org (Postfix) with ESMTP id 077708FC1B for ; Wed, 10 Jun 2009 14:54:53 +0000 (UTC) (envelope-from allceus@host.datatriangle.com) Received: from allceus by host.datatriangle.com with local (Exim 4.69) (envelope-from ) id 1MEN7b-00077O-DU for freebsd-net@freebsd.org; Wed, 10 Jun 2009 08:41:39 -0400 To: freebsd-net@freebsd.org Recieved: Date: Wed, 10 Jun 2009 08:41:39 -0400 From: dr.dawn-elise_snipes@allceus.com Message-ID: <70a28c7f14717473cc9ee2bd62a8abe0@localhost.localdomain> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: phplist v2.10.9 X-MessageID: 10 X-ListMember: freebsd-net@freebsd.org Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/related; type="text/html"; boundary="b1_70a28c7f14717473cc9ee2bd62a8abe0" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.datatriangle.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [32006 32007] / [47 12] X-AntiAbuse: Sender Address Domain - host.datatriangle.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [AllCEUs.com] View Counseling Education Videos Online at Blip.tv 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: Wed, 10 Jun 2009 14:54:54 -0000 --b1_70a28c7f14717473cc9ee2bd62a8abe0 Content-Type: text/plain; charset = "UTF-8" Content-Transfer-Encoding: 8bit -View AllCEUs counseling education videos -20% savings code for CEUs, from the already lowest industry cost (code: 4989) Don't want any more message from us, just let us know: http://allceus.com/mail_list/?p=unsubscribe&uid=37ba0c6dd4da598f351d23e5d8ff4d87 Having trouble viewing this email? View it in your browser. To update your preferences visit http://allceus.com/mail_list/?p=preferences&uid=37ba0c6dd4da598f351d23e5d8ff4d87 Dr. Dawn-Elise Snipes dr.dawn-elise_snipes@allceus.com PO BOX 1688 Alachua, FL 32616 -- Powered by PHPlist, www.phplist.com -- --b1_70a28c7f14717473cc9ee2bd62a8abe0-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 14:13:57 2009 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 C3FA5106564A for ; Wed, 10 Jun 2009 14:13:57 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8313.mail.in.yahoo.com (web8313.mail.in.yahoo.com [202.43.219.5]) by mx1.freebsd.org (Postfix) with SMTP id D58B88FC14 for ; Wed, 10 Jun 2009 14:13:56 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 64448 invoked by uid 60001); 10 Jun 2009 13:47:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1244641634; bh=CXs+12XUAP9W2q6D2GmaoW5w7tfhvQDuMn8JELZe1q8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=ilpHtHpbsZoMtoc/Fa7NfmlNFuYvLd/ovx0sSezDdUKWlSQLLi50xSNsL8fKRDBi0nfXWkmXFatkJuNblsroEjHYjIa3pmVuJyRf9YhOD63fCv6smU/j6F3r/BDeEn3hV92MsovUUJJ1goz49/mcFofPjbVUL6d6nFwOc4Y4pK8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=IkXjTqjiwZTDui312BsPenkkWGR8M3Opi2yXX0ZdZbdCNtGofB9CTtCkZ2+x2uyXp6N8EgLSB20w09vV3jq+OeNR25q0YsnRJ0Zc06bVWig766XCrc/1vXmoFYoaXLdW6wERLBmzRTE8Wtm+0e8d3o4U6+hJ3bgTLwnFoI+wJtQ=; Message-ID: <28959.63465.qm@web8313.mail.in.yahoo.com> X-YMail-OSG: 4I_BJ8oVM1mcm5d7EZCvgIQwAFUYNnPKEvPIVbh3TAt8Ls62Xs_aA6SbEEEPicDDCbvRYEeKHO7qJ3SP2zvLi9n0qTl8DGW5bhJUwVRoVP5s9e5Rc7wlWBSR6gvO5g1KPjrP7JFaWCt0OxLBTZesObl38ZBByYnswuu486NzDlcTsfNKTlp6MYg8zbzMuT1HV8mw4f6hckw6DQ-- Received: from [125.22.253.101] by web8313.mail.in.yahoo.com via HTTP; Wed, 10 Jun 2009 19:17:13 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Wed, 10 Jun 2009 19:17:13 +0530 (IST) From: saravana perumal To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Jun 2009 15:56:30 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: sarbalas@gmail.com Subject: TCP Free-BSD setup behaviour. 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, 10 Jun 2009 14:13:58 -0000 =A0Hi , =A0 =A0 Have some behaviour change=A0 with FREEBSD=A0 compared to=A0 LINUX . 1. When sending the Same=A0 TCP packet once again [ Retranmission of TCP pa= cket ] Whether the Same Identification field [ IP packet]used or not . but when seeing that thru packet capture, Free BSD sending the differnt one= [ increases sequentially IP Identification] 2.Retranmission Time is not increasing Linearly with Respect to BSD. not ke= eping more time interval . AS per RFC=20 expecting Retransmission timeout should=A0 increase Linearly. Issue is not = seen with Linux Setup 3. Active SYN open state in FREE BSD setup=A0, Does not reach Syn-received = State. When Sending syn packet to DUT but=A0 for that FreeBSD is not sendin= g back=20 SYN/ACK .=A0 Issue is with Free BSD Setup.Linux works fine, =A0 4.When checking the State - TIME-WAIT=20 =A0 Sending FIN and expecting the ACK ;Getting the ACK properly. =A0 Sending Data Segment and Expecting the RST signal not getting the RST ;= Instead DUT is sending the Last TCP packet. =A0 Issue seen only in Free BSD. =A0 Same issue in FIN-WAIT2=A0 & FIN-WAIT1 State also . =A0 Sending FIN and Expect the ACK : Getting the ACK =A0 Sending Data segment with Data : Expecting the RST signal from DUT ; bu= t got Last transmitted TCP packet[ FIN -ACK] =A0 Any idea about the above scenario would be helpful =A0 Thanks, Saravanan.=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 17:20:04 2009 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 3A7D6106564A for ; Wed, 10 Jun 2009 17:20:04 +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 27AE58FC0C for ; Wed, 10 Jun 2009 17:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5AHK3EH036976 for ; Wed, 10 Jun 2009 17:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5AHK3pr036971; Wed, 10 Jun 2009 17:20:03 GMT (envelope-from gnats) Date: Wed, 10 Jun 2009 17:20:03 GMT Message-Id: <200906101720.n5AHK3pr036971@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Roar Pettersen Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roar Pettersen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 17:20:04 -0000 The following reply was made to PR kern/134557; it has been noted by GNATS. From: Roar Pettersen To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Wed, 10 Jun 2009 19:09:00 +0200 (CEST) Hi ! We also see a similar problem with FreeBSD 7.2-Stable and MPD 5.3, after 4-5 days then the mpd process goes into a deadlock. Not able to kill the process or reload the server, have to press the Power Off button. System load is normaly 2-3%, but when the problem occur it raise to 30-35%. No error messages, nothing in the log files. The problem is releated to FreeBSD 7.2, no problem with 7.1. -- Roar Pettersen Universitetet i Bergen - The University of Bergen BERGEN - Norway From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 20:51:06 2009 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 305321065672; Wed, 10 Jun 2009 20:51: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 059248FC19; Wed, 10 Jun 2009 20:51:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5AKp5tY005129; Wed, 10 Jun 2009 20:51:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5AKp5Db005125; Wed, 10 Jun 2009 20:51:05 GMT (envelope-from linimon) Date: Wed, 10 Jun 2009 20:51:05 GMT Message-Id: <200906102051.n5AKp5Db005125@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/135451: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] 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, 10 Jun 2009 20:51:06 -0000 Old Synopsis: no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 New Synopsis: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 10 20:50:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135451 From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 21:05:12 2009 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 B574F106566B for ; Wed, 10 Jun 2009 21:05:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 70B388FC3B for ; Wed, 10 Jun 2009 21:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0985E41C712 for ; Wed, 10 Jun 2009 23:05:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id rnoamArNblfu for ; Wed, 10 Jun 2009 23:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9164141C6FC; Wed, 10 Jun 2009 23:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 729454448E6 for ; Wed, 10 Jun 2009 21:03:31 +0000 (UTC) Date: Wed, 10 Jun 2009 21:03:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@FreeBSD.org Message-ID: <20090610210021.N22887@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: fxp hack in sys/net/if.c? 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, 10 Jun 2009 21:05:13 -0000 Hi, could anyone having a clue why that is there look at it and either remove it or remove it and properly handle it elsewhere? I have continuesly noticed it for a while so I think the "temporary" as given in the comment rather means "forgotten"? sys/net/if.c: DELAY(100);/* XXX: temporary workaround for fxp issue*/ /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 21:31:50 2009 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 B0273106566C for ; Wed, 10 Jun 2009 21:31:50 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 6605B8FC13 for ; Wed, 10 Jun 2009 21:31:50 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so573555ana.13 for ; Wed, 10 Jun 2009 14:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/KiTGkuV+HQymWreoVpuOGFQvxmlXx55uJLclENh2Ys=; b=eci40pwA+0hUwcuU/5D1OGcE4W+/t6cE02n0SynOmXLqSN1OIT5y4byduYLEI7aeVs Xyfp3W9jy30toq1B2dPYjUyGkvGM/xt9imbkejacZPy+FA8YqXX8CqcxvbkiNPV7jMfX D5mmneQaByNvC/3IMIdoAtZ+2k7/Bgue5EA0A= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=q3VD7V17j1JUh1fRRwv6UUgkVIFJ8fePeYYsIHFJAUPH4R9ZCkFpTFm9ctNQFFuwzO RTOFe6vT8oSLoBxZLIpItc2SV1/uc1Z7ds2W3mGC3dc7Idl40UqUo9BHlioz1rrB92vT VZagfjLhsKFLDupgAQtL1HhSjfmOfS7UtAz4w= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.58.1 with SMTP id g1mr1897925ana.181.1244669509485; Wed, 10 Jun 2009 14:31:49 -0700 (PDT) In-Reply-To: <3c1674c90906101417j39a01f85k8e98c0ee19a011a7@mail.gmail.com> References: <20090610210021.N22887@maildrop.int.zabbadoz.net> <3c1674c90906101417j39a01f85k8e98c0ee19a011a7@mail.gmail.com> Date: Wed, 10 Jun 2009 14:31:49 -0700 X-Google-Sender-Auth: e3642c7a9e255e75 Message-ID: <3c1674c90906101431x7b556855pd3103d9e7a9f26dc@mail.gmail.com> From: Kip Macy To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: fxp hack in sys/net/if.c? 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, 10 Jun 2009 21:31:51 -0000 The reasoning behind moving the delay in to shared code is not very compell= ing. -Kip On Wed, Jun 10, 2009 at 2:17 PM, Kip Macy wrote: > From "cvs blame": > > Add workaround for fxp issue at interface initialization with IPv6. > > =A0Some LAN card chip for fxp is known to cause problem at > =A0interface initialization with IPv6 enabled. It happens at > =A0some delicate timing. > =A0And also, just adding some DELAY before IPv6 address > =A0autoconfiguration is known to avoid the problem. > > =A0Complete fix is changing the driver not to use interrupt at > =A0multicast filter initialization, but trying such change in > =A0this stage will be dangerous. > > =A0So I add some DELAY() only inside #ifdef INET6 part, > =A0as temporal workaround only for 4.0. > > Approbed by: jkh > > Noticed by: Mattias Pantzare > > Obtained from: openbsd-tech mailing list > > > > On Wed, Jun 10, 2009 at 2:03 PM, Bjoern A. > Zeeb wrote: >> Hi, >> >> could anyone having a clue why that is there look at it and either >> remove it or remove it and properly handle it elsewhere? >> >> I have continuesly noticed it for a while so I think the "temporary" >> as given in the comment rather means "forgotten"? >> >> sys/net/if.c: =A0 =A0 =A0 =A0 =A0 DELAY(100);/* XXX: temporary workaroun= d for fxp >> issue*/ >> >> /bz >> >> -- >> Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The greatest r= isk is not taking one. >> _______________________________________________ >> 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" >> > > > > -- > When bad men combine, the good must associate; else they will fall one > by one, an unpitied sacrifice in a contemptible struggle. > > =A0 =A0Edmund Burke > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 21:50:36 2009 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 35B2210656C4 for ; Wed, 10 Jun 2009 21:50:36 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id DFF798FC26 for ; Wed, 10 Jun 2009 21:50:35 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so583890ywe.13 for ; Wed, 10 Jun 2009 14:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uF6txaobfhrCfV3LAzHhNlWpaP93MpxYSoo2d9e9nrY=; b=AgvW0wO2l1j8klbALCzBWPPzNe8NU2vQIh/vK/c+kgSBjrcAyUdzYCCBX3dBuYu5AK 3wxcD9KSel9ajYfdXkBsaL5P7Mc51/45bL11yZtd3E8H7lFQ0mVJ/cAZ/+wjh9K3uy2+ hlg61yc1/xsvgfr4LRwf4jgP/FrYwbXa1Ait8= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Vsoyegfyns5U1V229Z4GEC3G/FFZn18dvCsa5i6Bb9ZjtKdQQZqS9WM/vDFUr1r5MC H8UIrBBGQh0yj5q9kX7Qm1Hk5RQw0Y8XcwZ/o2mAtzrRQMQvKpHEfQ58DTiRUQdwf9t/ 9qQWwdLg2ztaz8U5X3Gw+/0DetYwp1fZcZxYk= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.14.2 with SMTP id 2mr1933980ann.68.1244668670266; Wed, 10 Jun 2009 14:17:50 -0700 (PDT) In-Reply-To: <20090610210021.N22887@maildrop.int.zabbadoz.net> References: <20090610210021.N22887@maildrop.int.zabbadoz.net> Date: Wed, 10 Jun 2009 14:17:50 -0700 X-Google-Sender-Auth: e2f97abd5e8474b6 Message-ID: <3c1674c90906101417j39a01f85k8e98c0ee19a011a7@mail.gmail.com> From: Kip Macy To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: fxp hack in sys/net/if.c? 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, 10 Jun 2009 21:50:36 -0000 >From "cvs blame": Add workaround for fxp issue at interface initialization with IPv6. Some LAN card chip for fxp is known to cause problem at interface initialization with IPv6 enabled. It happens at some delicate timing. And also, just adding some DELAY before IPv6 address autoconfiguration is known to avoid the problem. Complete fix is changing the driver not to use interrupt at multicast filter initialization, but trying such change in this stage will be dangerous. So I add some DELAY() only inside #ifdef INET6 part, as temporal workaround only for 4.0. Approbed by: jkh Noticed by: Mattias Pantzare Obtained from: openbsd-tech mailing list On Wed, Jun 10, 2009 at 2:03 PM, Bjoern A. Zeeb wrote: > Hi, > > could anyone having a clue why that is there look at it and either > remove it or remove it and properly handle it elsewhere? > > I have continuesly noticed it for a while so I think the "temporary" > as given in the comment rather means "forgotten"? > > sys/net/if.c: =A0 =A0 =A0 =A0 =A0 DELAY(100);/* XXX: temporary workaround= for fxp > issue*/ > > /bz > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The greatest ri= sk is not taking one. > _______________________________________________ > 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 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 01:54:38 2009 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 44BA5106566B for ; Thu, 11 Jun 2009 01:54:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id D751F8FC17 for ; Thu, 11 Jun 2009 01:54:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-159-184.carlnfd1.nsw.optusnet.com.au (c122-106-159-184.carlnfd1.nsw.optusnet.com.au [122.106.159.184]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n5B1sTJ5000590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 11:54:35 +1000 Date: Thu, 11 Jun 2009 11:54:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Igor Sysoev In-Reply-To: <20090610123301.GE40250@rambler-co.ru> Message-ID: <20090611114120.I21056@delplex.bde.org> References: <20090610123301.GE40250@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: bge interrupt coalescing sysctls 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, 11 Jun 2009 01:54:38 -0000 On Wed, 10 Jun 2009, Igor Sysoev wrote: > For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: > http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html > However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken > the patch. I'm not sure how to fix the collision, and since I do not > use dynamic tuning That commit looked ugly (lots of internal API changes and bloat in interrupt handlers in many network drivers to support polling which mostly shouldn't be supported at all and mostly doesn't use the interrupt handlers). > I has left only static coalescing parameters in the patch > and has added a loader tunable to set number of receive descriptors and > read only sysctl to read the tunable. I usually use these parameters: > > /boot/loader.conf: > hw.bge.rxd=512 > > /etc/sysctl.conf: > dev.bge.0.rx_coal_ticks=500 > dev.bge.0.tx_coal_ticks=10000 > dev.bge.0.rx_max_coal_bds=64 These rx settings give to high a latency for me. > dev.bge.0.tx_max_coal_bds=128 > # apply the above parameters > dev.bge.0.program_coal=1 > > Could anyone commit it ? Not me, sorry. The patch is quite clean. If I committed then I would commit the dynamic coalescing configuration separately anyway. You can probably make hw.bge.rxd a sysctl too (it would take a down/up to get it changed, but that is already needed for too many parameters in network drivers anyway). I should use a sysctl for the ifq length too. This could be done at a high level for each driver. Limiting queue lengths may be a good way to reduce cache misses, while increasing them is sometimes good for reducing packet loss. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 06:02:53 2009 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 D3384106564A for ; Thu, 11 Jun 2009 06:02:53 +0000 (UTC) (envelope-from cbuechler@gmail.com) Received: from mail.pfsense.org (mail.pfsense.org [69.64.6.29]) by mx1.freebsd.org (Postfix) with ESMTP id AC8A38FC14 for ; Thu, 11 Jun 2009 06:02:53 +0000 (UTC) (envelope-from cbuechler@gmail.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.pfsense.org (Postfix) with ESMTP id BA3B324786 for ; Thu, 11 Jun 2009 00:45:03 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.pfsense.org Received: from mail.pfsense.org ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbE5XkipMWB4 for ; Thu, 11 Jun 2009 00:45:00 -0500 (EST) Received: from [10.0.64.15] (96-28-38-25.dhcp.insightbb.com [96.28.38.25]) by mail.pfsense.org (Postfix) with ESMTP id ADE002477E for ; Thu, 11 Jun 2009 00:45:00 -0500 (EST) Message-ID: <4A3099DC.5050909@gmail.com> Date: Thu, 11 Jun 2009 01:45:00 -0400 From: Chris Buechler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4A249A57.1070900@pfsense.org> In-Reply-To: <4A249A57.1070900@pfsense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ath(4) randomly changes MTU to 2290 after explicitly set to 1500 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, 11 Jun 2009 06:02:54 -0000 Chris Buechler wrote: > > somehow it ends up switching MTU to 2290 when we never configure it as > such. This breaks bridging to an Ethernet interface because if_bridge > requires the MTU to be the same on both interfaces. For the sake of the archives and anyone who finds this thread in the future, the problem was resolved by Jim Thompson and Sam Leffler. This is the change: http://svn.freebsd.org/changeset/base/193524 Thanks Jim and Sam! From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 10:32:10 2009 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 2D45A106566B for ; Thu, 11 Jun 2009 10:32:10 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A094F8FC0A for ; Thu, 11 Jun 2009 10:32:09 +0000 (UTC) (envelope-from bra@fsn.hu) Message-ID: <4A30D90B.3020007@fsn.hu> Date: Thu, 11 Jun 2009 12:14:35 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Stationery: 0.4.8.14 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Thu, 11 Jun 2009 12:14:36 +0200 (CEST) Cc: Subject: Redirecting traffic with IPSec and pf doesn't work 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, 11 Jun 2009 10:32:10 -0000 Hello, What I'm trying to accomplish is the following: - there are two machines, connected over the internet (let's call them A and B) - when A tries to connect to B:port, or B to A:port (via TCP, port is just a TCP port, in this case, 3306) the connection should be redirected to a local listener, instead of the remote - the above should only be done if I want to (I can do this with pf anchors or tables) - the connection between the two machines should be secured in kernel space (for efficiency and performance) I can redirect the connections in the unsecured (no IPSec) case with the following pf.conf (this is for machine A): rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is an alias on A's lo0) So when I do a telnet from A to B, the connection establishes and I can reach A's listener, instead of B's. Now with IPSec. ipsec.conf contains this (along with the PSK definitions): spdadd A_IP B_IP any -P out ipsec esp/transport/A_IP-B_IP/default ah/transport/A_IP-B_IP/default; and the same on B, with swapped orders. IPSec between the two machines works, but the redirection doesn't. pf.conf now has: rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is lo0's alias address in this case, but I've also tried with A's public IP and also with a gif tunnel) What I see in pflog's output seems to be OK: 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 000038 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 and the traffic shows up on enc0 as well, but is not that nice: 11:57:36.482910 (confidential): SPI 0x00003d55: IP A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 11:57:36.483009 (confidential): SPI 0x00003d55: IP A_IP.59940 > B_IP.3306: R 3107058077:3107058077(0) win 0 The command, which produced the above output is: MACHINE_A $ telnet B_IP 3306 telnet: connect to address B_IP: Interrupted system call telnet: Unable to connect to remote host I've tried to set net.enc.out.ipsec_filter_mask to different values without success, only 0x0 gave a connection refused answer, instead of "Interrupted system call". This is on 7-STABLE. Is redirecting TCP flows on IPSec secured connections impossible because some layering differences? (maybe the above redirects the packet with IPSec headers, so this causes the problem) Thanks, From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 14:12:15 2009 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 1C3E41065670 for ; Thu, 11 Jun 2009 14:12:15 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by mx1.freebsd.org (Postfix) with ESMTP id CF4998FC13 for ; Thu, 11 Jun 2009 14:12:14 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ETShEe0PtA9JOXg5EodkzZ8deT8pp3MWTn+QUd1UXBL7eLE5s9W1HQUDYQqq4Hpc; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.249] (helo=joker.seclark.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MEkn8-0002R7-3d; Thu, 11 Jun 2009 09:58:06 -0400 Message-ID: <4A310D6C.3070602@earthlink.net> Date: Thu, 11 Jun 2009 09:58:04 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Attila Nagy References: <4A30D90B.3020007@fsn.hu> In-Reply-To: <4A30D90B.3020007@fsn.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79faaa1d6c97256dd71a7ec66627551b5e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.249 Cc: freebsd-net@freebsd.org Subject: Re: Redirecting traffic with IPSec and pf doesn't work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 14:12:15 -0000 Attila Nagy wrote: > Hello, > > What I'm trying to accomplish is the following: > - there are two machines, connected over the internet (let's call them A > and B) > - when A tries to connect to B:port, or B to A:port (via TCP, port is > just a TCP port, in this case, 3306) the connection should be redirected > to a local listener, instead of the remote > - the above should only be done if I want to (I can do this with pf > anchors or tables) > - the connection between the two machines should be secured in kernel > space (for efficiency and performance) > > I can redirect the connections in the unsecured (no IPSec) case with the > following pf.conf (this is for machine A): > rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 > pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to > B_IP port 3306 > (192.168.254.1 is an alias on A's lo0) > > So when I do a telnet from A to B, the connection establishes and I can > reach A's listener, instead of B's. > > Now with IPSec. > > ipsec.conf contains this (along with the PSK definitions): > spdadd A_IP B_IP any -P out ipsec > esp/transport/A_IP-B_IP/default > ah/transport/A_IP-B_IP/default; > and the same on B, with swapped orders. > > IPSec between the two machines works, but the redirection doesn't. > > pf.conf now has: > rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port > 3306 > pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to > B_IP port 3306 > > (192.168.254.1 is lo0's alias address in this case, but I've also tried > with A's public IP and also with a gif tunnel) > > What I see in pflog's output seems to be OK: > 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S > 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> > 000038 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: > S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> > > and the traffic shows up on enc0 as well, but is not that nice: > 11:57:36.482910 (confidential): SPI 0x00003d55: IP A_IP.59940 > > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> > 11:57:36.483009 (confidential): SPI 0x00003d55: IP A_IP.59940 > > B_IP.3306: R 3107058077:3107058077(0) win 0 > > The command, which produced the above output is: > MACHINE_A $ telnet B_IP 3306 > telnet: connect to address B_IP: Interrupted system call > telnet: Unable to connect to remote host > > I've tried to set net.enc.out.ipsec_filter_mask to different values > without success, only 0x0 gave a connection refused answer, instead of > "Interrupted system call". > > This is on 7-STABLE. > > Is redirecting TCP flows on IPSec secured connections impossible because > some layering differences? (maybe the above redirects the packet with > IPSec headers, so this causes the problem) > > Thanks, > _______________________________________________ > 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" > I don't know on 7.x but on 6.x you have to turn on options IPSEC_FILTERGIF #filter ipsec packets from a tunnel to get packets to go thru ipfilter - I assume it is the same for pf. I had the same problem not being able to redirect packets coming from a ipsec tunnel until I turned this option on. HTH, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 14:48:13 2009 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 1DA97106564A for ; Thu, 11 Jun 2009 14:48:13 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A18EC8FC1A for ; Thu, 11 Jun 2009 14:48:12 +0000 (UTC) (envelope-from bra@fsn.hu) Message-ID: <4A311926.4010607@fsn.hu> Date: Thu, 11 Jun 2009 16:48:06 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: sclark46@earthlink.net References: <4A30D90B.3020007@fsn.hu> <4A310D6C.3070602@earthlink.net> In-Reply-To: <4A310D6C.3070602@earthlink.net> X-Stationery: 0.4.9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Thu, 11 Jun 2009 16:48:10 +0200 (CEST) Cc: freebsd-net@freebsd.org Subject: Re: Redirecting traffic with IPSec and pf doesn't work 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, 11 Jun 2009 14:48:13 -0000 Stephen Clark wrote: > Attila Nagy wrote: >> Hello, >> >> What I'm trying to accomplish is the following: >> - there are two machines, connected over the internet (let's call >> them A and B) >> - when A tries to connect to B:port, or B to A:port (via TCP, port is >> just a TCP port, in this case, 3306) the connection should be >> redirected to a local listener, instead of the remote >> - the above should only be done if I want to (I can do this with pf >> anchors or tables) >> - the connection between the two machines should be secured in kernel >> space (for efficiency and performance) >> >> I can redirect the connections in the unsecured (no IPSec) case with >> the following pf.conf (this is for machine A): >> rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 >> pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any >> to B_IP port 3306 >> (192.168.254.1 is an alias on A's lo0) >> >> So when I do a telnet from A to B, the connection establishes and I >> can reach A's listener, instead of B's. >> >> Now with IPSec. >> >> ipsec.conf contains this (along with the PSK definitions): >> spdadd A_IP B_IP any -P out ipsec >> esp/transport/A_IP-B_IP/default >> ah/transport/A_IP-B_IP/default; >> and the same on B, with swapped orders. >> >> IPSec between the two machines works, but the redirection doesn't. >> >> pf.conf now has: >> rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 >> port 3306 >> pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to >> B_IP port 3306 >> >> (192.168.254.1 is lo0's alias address in this case, but I've also >> tried with A's public IP and also with a gif tunnel) >> >> What I see in pflog's output seems to be OK: >> 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > >> B_IP.3306: S 3107058076:3107058076(0) win 65535 > 3,sackOK,timestamp 69415267 0> >> 000038 rule 0/0(match): rdr in on lo0: A_IP.59940 > >> 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 > 1460,nop,wscale 3,sackOK,timestamp 69415267 0> >> >> and the traffic shows up on enc0 as well, but is not that nice: >> 11:57:36.482910 (confidential): SPI 0x00003d55: IP A_IP.59940 > >> B_IP.3306: S 3107058076:3107058076(0) win 65535 > 3,sackOK,timestamp 69415267 0> >> 11:57:36.483009 (confidential): SPI 0x00003d55: IP A_IP.59940 > >> B_IP.3306: R 3107058077:3107058077(0) win 0 >> >> The command, which produced the above output is: >> MACHINE_A $ telnet B_IP 3306 >> telnet: connect to address B_IP: Interrupted system call >> telnet: Unable to connect to remote host >> >> I've tried to set net.enc.out.ipsec_filter_mask to different values >> without success, only 0x0 gave a connection refused answer, instead >> of "Interrupted system call". >> >> This is on 7-STABLE. >> >> Is redirecting TCP flows on IPSec secured connections impossible >> because some layering differences? (maybe the above redirects the >> packet with IPSec headers, so this causes the problem) >> >> Thanks, >> _______________________________________________ >> 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" >> > > I don't know on 7.x but on 6.x you have to turn on > options IPSEC_FILTERGIF #filter ipsec packets from a > tunnel > > to get packets to go thru ipfilter - I assume it is the same for pf. I > had the > same problem not being able to redirect packets coming from a ipsec > tunnel until > I turned this option on. Yes, but I'm sending, not receiving. So I want to redirect on the sender side.... From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 20:52:10 2009 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 511A8106566B for ; Thu, 11 Jun 2009 20:52:10 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D4DB98FC15 for ; Thu, 11 Jun 2009 20:52:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4D40F41C75B; Thu, 11 Jun 2009 22:33:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Q+q9wzJmBHaN; Thu, 11 Jun 2009 22:33:18 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BED8A41C75A; Thu, 11 Jun 2009 22:33:18 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id F3BCF4448E6; Thu, 11 Jun 2009 20:33:10 +0000 (UTC) Date: Thu, 11 Jun 2009 20:33:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090611180438.G22887@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD net mailing list , src-committers@freebsd.org Subject: HEADS UP: INET dependencies in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:52:10 -0000 Hi, over the last days I fixed a few places missing #ifdef INET as well changed the kernel build file in sys/conf/files and added depencies for those parts that really require INET to compile / work at the moment. WARNING: -------------------------------- This means for example if you build a kernel without INET you will no longer get gre, ipfw, libablias, ipsec, if_enc, if_bridge, nfsserver, .. Those will _silently_ be disabled whether or not they are in your kernel configuration. WARNING: -------------------------------- You will also not get any of the 12 interfaces I found that had a compile time dependency on INET (if you remove INET from your kernel config): if_age, if_alc, if_ale, if_em, if_igb, if_fxp, if_ixgbe, if_jme, if_msk, if_mxge, if_sk, if_txp. I will send out an extra mail with more information on each interface and how to fix later in a second. (The same may apply to some other code). See r193824, r193949-193950, 193954, 193956-193957, 193960, 193983, 193986-193988, 193990-193991, 193993-193994, 193996-193997 of sys/conf/files for what was changed and if you are looking for a network project to cleanup a bit of our stack. For now I didn't see much of a problem here, as virtually noone so far would have built a kernel without INET support and still wanted networking as it just hadn't (easily) been possible. Obviously people may be concerned that those things will rot and warn others with #error anymore and that other people will one day trip over this. Unless hit by a bus I do not intend to drop this ball but will work (together with you!) to clean things up, resolve them, etc. For now the goal was to actually see how much of impure code we have and clean things basically up before 8.0. Now do not expect that I caught all and everything. We are far away from that. The long term goal is to separate INET6 off INET. So in addition to a kernel config like: ---------------------------------------- include LINT ident LINT-NOINET6 nooptions INET6 ---------------------------------------- FreeBSD 8 LINT currently also builds a kernel with: ---------------------------------------- include LINT ident LINT-NOINET makeoptions NO_MODULES=yes nooptions INET nooptions INET6 ---------------------------------------- Note: LINT will not boot! In case of arm I include AVILA, in case of mips I used ADM5120 instead of LINT (as arm and mips do not have LINT). HINT FOR DEVELOPERS: -------------------------------- For developers this means that if you add new code you really should make sure that INET in addition to INET6 will be properly #ifdefed. KIND OF HEADS UP FOR DEVLEOPERS: -------------------------------- This is kind of a heads up that from the time 8 will be branched off and HEAD will be 9 all new code should 1) have feature parity for INET and INET6 where applicable 2) new/changed code that only has #ifdef INET6 but no #ifdef INET (where applicable) should no longer be done. 3) No it's not April 1st today;-) Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 20:52:10 2009 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 B2A24106566C; Thu, 11 Jun 2009 20:52:10 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 147A88FC16; Thu, 11 Jun 2009 20:52:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C0D5C41C49C; Thu, 11 Jun 2009 22:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id sNSX2JseoUBr; Thu, 11 Jun 2009 22:35:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3ED9F41C71D; Thu, 11 Jun 2009 22:35:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 382E34448E6; Thu, 11 Jun 2009 20:33:28 +0000 (UTC) Date: Thu, 11 Jun 2009 20:33:28 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Gallatin , Pyun YongHyeon , Jack F Vogel , Andrew Thompson , Michael Tuexen Message-ID: <20090611184555.J22887@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD net mailing list Subject: Ethernet NIC drivers depending unconditionally on INET 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, 11 Jun 2009 20:52:10 -0000 Hi, as announced in my other mail to current@ and net@ I added the mandatory "INET" dependency to 12 Ethernet NIC drivers. Additionally I am adding if_bridge here as well. Those drivers should be fixed and once done the (mandatory) inet dependency should be removed again from sys/conf/files for that driver. If you have questions, need help, compile testing, ... feel free to mail me. I won't be able to test things as I do not own all of the different cases but I can review patches, .. Generally speaking upfront: if one of the drivers mentioned here or not, supportes offload capabilities for rx or tx of v4 or v6, for tcp, udp, sctp, .. they need to be properly hidden under the apropriate #ifdefs. Everything that needs v4 belongs under #ifdef INET. Everything that needs v6 belongs under #ifdef INET6. Upper layer protocols like TCP, UDP, SCTP should be at least #if defined (INET) || defined(INET6). In case of SCTP probebly #ifdef (SCTP) as well. You will need to include opt_inet.h, opt_inet6.h, opt_sctp.h in those cases and at least the buildkernel (not building the module alone) part should properly check them. For single module builds we are kind of lost here and I think we usually enabled things by default as they are in GENERIC. Another general note that scared me while looking at CSUM_TSO and IFCAP_TSO4|IFCAP_TSO6. Almost none of the drivers actually checks that it is an IPv4 packet before grabiing the IP header, TCP header, ... How do we actually know that it is an IPv4 packet in all those drivers? Should we do a IP Version fiel check? I think em(4) is one of those that does. I hope this will improve with tuexen's work on the CSUM flags. In case you are maintaining another driver but cannot find it on the list - be sure we'll find you during the 9.x lifecycle in case you do not properly handle things;-) if_age: ---------------------------------------- I identifed two in_pseudo() calls that are INET specific. The problem is that thi is part of the (IPv4) TSO code and it seems to be mandatory for that case. The proper fix seems to be to but that block under #ifdef INET and in case INET is not defined to also disable announcing or permitting to set these features entirely as we won't be able to handle them or use them anyway. if_alc: ---------------------------------------- There is one in_pseudo(); Apart from that things seem identical to if_age. if_ale: ---------------------------------------- There is one in_pseudo(); Apart from that things seem identical to if_age. if_em: ---------------------------------------- There is one in_pseudo() in em_tso_setup() that prevented the driver from being linked into the kernel; the entire code unfortunately has at least one more place of IP/IPV6 distinction for cksum offloading em_transmit_checksum_setup() that is not properly handled either. In either case the feature should be disbaled and not be announced if the address family is not there to handle the code. Note: tuexen is working on a proper set of v4/v6 definitions for the csum offloading, so we will be able to do this more fine grained in the future. For now not having INET6 would penalize INET as well. if_igb: ---------------------------------------- igb_tso_setup() has one in_pseudo() call. See if_age for that. It also has dependencies on the entire LRO framework like tcp_lro_free(), tcp_lro_rx(), tcp_lro_flush(), tcp_lro_init(). The LRO framework is on the IPv6TODO list. For the moment if there is no INET LRO should be completely compiled out and not advertised removing the TUNABLE and SYSCTL and changing the default to 0. Be prepared in case LRO will arrive for IPv6. Side note: calling tcp_lro_free() on something that hadn't been initialized for example because lro was enabled by the sysctl after itniialization, can that be a problem? Maybe tcp_lro_free() should just return in case cntl is NULL? if_fxp: ---------------------------------------- There is one in_pseudo(); Apart from that things seem identical to if_age. ixgbe: ---------------------------------------- There is one in_pseudo() in ixgbe_tso_setup(). See if_igb for that. There is an arp_ifinit() call in ixgbe_ioctl() that already seems to check for the proper address family and only needs the #ifdefs around like the ioctl in if_em has. The same that applies for if_igb about LRO applies here as well. if_jme: ---------------------------------------- Two in_pseudo() calls; see if_age. if_msk: ---------------------------------------- An in_cksum_skip() call. Almost like if_age but this seems to be further conditional on driver flags and CSUM_TCP that seem to be set independently of TSO. I am not entirely sure if there is a proper solution or if we might be forced to return an error in that case in case there is not INET support. if_mxge: ---------------------------------------- mxge_rx_csum() has one in_pseudo(). The function and callers already seem to know how do deal with results in case the csum can't be validated. So this should be a simple #ifdef INET wrapping here; side note: the tcpudp_csum variables in the callers are not needed. side note: huge inlining going on there;) mxge_lro_flush() has another call to in_pseudo(). As with if_igb/ixgbe if there is no INET there should be no LRO for now, the capabilities not advertised, etc. Be prepared in case LRO will arrive for IPv6. if_sk: ---------------------------------------- sk_rxcksum() has an in_addword() call. It seems that sk_rxcksum is only used if IFCAP_RXCSUM is on. So similar things like to TSO should be done; hiding it under #ifdef INET and not advertising the feature etc. if_txp.c: ---------------------------------------- Now this is an interesting case as txp_download_fw_section() is using in_cksum() to validate the firmware csum before downloading it to the card it seems. I am not sure how to bes work around that one. if_bridge: ---------------------------------------- if_bridge is porobably mostly INET6 clean but doesn't have any INEt checks. It's just a matter of going through the code and adding proper #ifdef INET handling the simple cases and see what's left. This is just work; in case you are bored, read this mail to the end and would like to do something, know the difference between IPv4 and IPv6 is 2 and thinking of C doesn't make you think of scale of C major in first place, you are welcome to send patches:-) Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 21:48:58 2009 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 417B31065673; Thu, 11 Jun 2009 21:48:58 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id EBD218FC0C; Thu, 11 Jun 2009 21:48:57 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n5BLmRt9016846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 17:48:28 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n5BLmRt9016846 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1244756908; bh=I+vbzJvLcU3v6NhEQvikzLiwNoBEhfqRRpejtOcUsak=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vHagwxQTBTTIFppB4F3Ihe+YB6ehbNz0rPiq+bRkjdvXJexHNwFIt3Exa5VmZpVEg cExWV4VncHPMabuPchNDLTVz2B4rvDKQQ73SggzlXH+z7MAuQmw0RAwU17Lv++9tm9 WSFm+yVjndDQI5SrSrZGKzTqF8hrhm8Df4WrBY54= Message-ID: <4A317BA6.3050300@cs.duke.edu> Date: Thu, 11 Jun 2009 17:48:22 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090611180438.G22887@maildrop.int.zabbadoz.net> In-Reply-To: <20090611180438.G22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list , FreeBSD current mailing list , src-committers@FreeBSD.org Subject: Re: HEADS UP: INET dependencies in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:48:59 -0000 Bjoern A. Zeeb wrote: > This is kind of a heads up that from the time 8 will be branched off > and HEAD will be 9 all new code should > 1) have feature parity for INET and INET6 where applicable As a sort of side-note, what about feature parity for INET6 for existing IPV4 features like TSO? Who is working on that? Thanks, Drew From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 01:53:54 2009 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 A570B106566B; Fri, 12 Jun 2009 01:53:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8588FC13; Fri, 12 Jun 2009 01:53:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so625306rvb.43 for ; Thu, 11 Jun 2009 18:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=UfbFq2Q7DYKBWmRAkizOUlgorX9vGsPzgG2X8KaoVlY=; b=HTbMJQIaCBKspdDMTanRf1mZoO17eL+Z1mYyQ80KAUAg7K+FYCO520fg71sqVVPusG NvmusuoRbiakqs/scFvyrN6HKa5Hlh67RJ++TxuQ2+BDxNnReVCQ8zPGTZaGUrD4A2Ot GT5vrwOfhmjGDT99hcjVew+WuClJX/4FRVcIE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Nkidu7IIf8J4kjxA8Bworssq0lShzen8S47NJbr8MIkb2VWE94qPyM9H42HBeXR/Vx jPeOSOcZgq1M3KKMi7tcxMxexfCawYWxzcgBvIMQnrcMjumnjqAZ3uq2S6R3PW8kpXe/ 3v9/0lhrdm4u0qc5OBH/mrK3Frg3b6x2OfSmY= Received: by 10.140.193.15 with SMTP id q15mr2419473rvf.257.1244770285223; Thu, 11 Jun 2009 18:31:25 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id f42sm2131591rvb.31.2009.06.11.18.31.23 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 18:31:24 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 12 Jun 2009 10:34:06 +0900 From: Pyun YongHyeon Date: Fri, 12 Jun 2009 10:34:06 +0900 To: "Bjoern A. Zeeb" Message-ID: <20090612013406.GB72855@michelle.cdnetworks.co.kr> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090611184555.J22887@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD net mailing list , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 01:53:54 -0000 On Thu, Jun 11, 2009 at 08:33:28PM +0000, Bjoern A. Zeeb wrote: > Hi, > > as announced in my other mail to current@ and net@ I added the > mandatory "INET" dependency to 12 Ethernet NIC drivers. Additionally > I am adding if_bridge here as well. > > Those drivers should be fixed and once done the (mandatory) inet > dependency should be removed again from sys/conf/files for that > driver. > > If you have questions, need help, compile testing, ... feel free to > mail me. I won't be able to test things as I do not own all of the > different cases but I can review patches, .. > > > Generally speaking upfront: if one of the drivers mentioned here or > not, supportes offload capabilities for rx or tx of v4 or v6, for tcp, > udp, sctp, .. they need to be properly hidden under the apropriate > #ifdefs. > > Everything that needs v4 belongs under #ifdef INET. > Everything that needs v6 belongs under #ifdef INET6. > Upper layer protocols like TCP, UDP, SCTP should be at least > #if defined (INET) || defined(INET6). > In case of SCTP probebly #ifdef (SCTP) as well. > > You will need to include opt_inet.h, opt_inet6.h, opt_sctp.h > in those cases and at least the buildkernel (not building the module > alone) part should properly check them. For single module builds > we are kind of lost here and I think we usually enabled things by > default as they are in GENERIC. > > Another general note that scared me while looking at CSUM_TSO and > IFCAP_TSO4|IFCAP_TSO6. Almost none of the drivers actually checks > that it is an IPv4 packet before grabiing the IP header, TCP header, > ... How do we actually know that it is an IPv4 packet in all those Yeah, there are no checksum offloading support for IPv6 under FreeBSD so there are no cases the frames are IPv6 when CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > drivers? Should we do a IP Version fiel check? I think em(4) is one I believe this should be done in upper stack. Upper stack already know IP version as well as other useful fields(e.g. IP header length, TCP header length, etc). You wouldn't want to parse mbuf chains which takes a lot of CPU cycles. > of those that does. I hope this will improve with tuexen's work on > the CSUM flags. > > In case you are maintaining another driver but cannot find it on the > list - be sure we'll find you during the 9.x lifecycle in case you do > not properly handle things;-) > [ list of drivers part removed ] I guess you missed hme(4) and gem(4) in the list and most old hardwares that supports checksum offloading have no capability to handle IPv6 checksum offloading. If we do not define appropriate capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be hard to change code, I guess. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 05:20:34 2009 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 9F3581065672; Fri, 12 Jun 2009 05:20:34 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 00F918FC13; Fri, 12 Jun 2009 05:20:33 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by ewy8 with SMTP id 8so2202749ewy.43 for ; Thu, 11 Jun 2009 22:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=NcINc+Q7gCcilqifKQbmOSpcVWzGnptZ0NjVjiT2/Q4=; b=xPQMS+ue8kIh+Y2407pFQJB1ngjMO6Wkpf+/VC+jt0tXDjUsw7iPAu3u872INxBCyJ WAX1cOkhMR1XrfgP9033qR2TuVtRkZPVyN0qSgi1WU8TyQauh9lsZzAH61zK4UE5Kp45 Vd3RytyHjWaluaJdEiBmLUmQ0kSFNsRj6/GK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=kx+GtsOj1zScpAGU7yYyzf0FaBsAq3kskokwMJ9oJsycsS/K0+5dvEUWEfR0J+ebxc So/0kq1b/AJ+m/HcE2ti6i8TyoOkr0LwL6lAUIldGL5cb5lgzLRtQbivNgiv3ntd4XLs 6/DhXzba3RGXQrqHCK3X8okWN4jgFJ8knbPA4= Received: by 10.210.39.2 with SMTP id m2mr348575ebm.13.1244784032947; Thu, 11 Jun 2009 22:20:32 -0700 (PDT) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 28sm1024117eye.36.2009.06.11.22.20.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 22:20:31 -0700 (PDT) To: Oleg Bulyzhin , freebsd-net@FreeBSD.org References: <864ov9htgq.fsf@kopusha.onet> <81bpp8l6de.fsf@zhuzha.ua1> <20090603170311.GA18104@lath.rinet.ru> <20090604204720.GA49677@lath.rinet.ru> <81hbyuvl3z.fsf@zhuzha.ua1> <20090605185647.GA76962@lath.rinet.ru> Organization: TOA Ukraine From: Mikolaj Golub Date: Fri, 12 Jun 2009 08:20:29 +0300 In-Reply-To: <20090605185647.GA76962@lath.rinet.ru> (Oleg Bulyzhin's message of "Fri\, 5 Jun 2009 22\:56\:47 +0400") Message-ID: <814oumni3m.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 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, 12 Jun 2009 05:20:34 -0000 On Fri, 5 Jun 2009 22:56:47 +0400 Oleg Bulyzhin wrote: > On Fri, Jun 05, 2009 at 04:57:52PM +0300, Mikolaj Golub wrote: > >> It works for me. With the patch I has not managed to crash the system using my >> test. Some notes: >> >> - only ng_ipfw/ng_car subsystem has been tested (not dummynet). >> - my -current box is under qemu (I don't have real server running -current to >> test this). >> >> If you are interesting in some testing of dummynet before commiting this to >> current, let me know. I could try some tests but only the next week. > > I did some testing of dummynet though extra testing would not hurt. I see the patch has been commited to 8-CURRENT :-). Thanks. I did some dummy tests on "fixed" current (simple dummynet configuration + traffic + ipfw reloaded every second) and did not have any issues. At present I don't have old -current without fix to reproduce the crash, but on 7-STABLE running this test I saw in dmesg many ipfw: ouch!, skip past end of rules, denying packet messages and one time crashed the system. So it looks like my testbase rather good and would have found problems with fixed current if they still had had. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 05:46:51 2009 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 E3B42106564A; Fri, 12 Jun 2009 05:46:51 +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 B9BF28FC08; Fri, 12 Jun 2009 05:46:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5C5kpVG059914; Fri, 12 Jun 2009 05:46:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5C5kp0O059910; Fri, 12 Jun 2009 05:46:51 GMT (envelope-from linimon) Date: Fri, 12 Jun 2009 05:46:51 GMT Message-Id: <200906120546.n5C5kp0O059910@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces 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, 12 Jun 2009 05:46:52 -0000 Synopsis: [igb] low speed routing between two igb interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 12 05:46:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135222 From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 06:15:21 2009 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 87A5B106566C for ; Fri, 12 Jun 2009 06:15:21 +0000 (UTC) (envelope-from Anatoliy.Poloz@onetelecom.od.ua) Received: from main.merlin.com.ua (mail.onetelecom.od.ua [91.194.72.4]) by mx1.freebsd.org (Postfix) with ESMTP id 439398FC0A for ; Fri, 12 Jun 2009 06:15:21 +0000 (UTC) (envelope-from Anatoliy.Poloz@onetelecom.od.ua) Received: from [192.168.67.95] (t0ly [192.168.67.95]) by main.merlin.com.ua (Postmaster) with ESMTP id EF9675DCE1F; Fri, 12 Jun 2009 09:04:04 +0300 (EEST) Message-ID: <4A31EE3C.80600@onetelecom.od.ua> Date: Thu, 11 Jun 2009 22:57:16 -0700 From: "Anatoliy.Poloz" User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: nuno.antunes@gmail.com, mav@FreeBSD.org, freebsd-net@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: [ng_car] issue/whish/todo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anatoliy.Poloz@onetelecom.od.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 06:15:21 -0000 Good day I would like ещ introduce You several issue. I would like to be able to when you call "_getstat_" to see the bytes, not only packets. This is for drawing graphs of node load. I would also like to be able to configure some "_car_nods_" after exit on output, without checking in ipfw, not depending on ip.fw.one_pass. Like per ng_car node one_pass. is it real? From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 06:42:25 2009 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 A70391065670 for ; Fri, 12 Jun 2009 06:42:25 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 60A798FC18 for ; Fri, 12 Jun 2009 06:42:24 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MF0T0-0005zk-Bt for freebsd-net@freebsd.org; Fri, 12 Jun 2009 06:42:22 +0000 Received: from c-82-209-158-128.cust.bredband2.com ([82.209.158.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jun 2009 06:42:22 +0000 Received: from mc by c-82-209-158-128.cust.bredband2.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jun 2009 06:42:22 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Michael Widerkrantz Date: Fri, 12 Jun 2009 08:42:09 +0200 Organization: Temple of the Moby Hack Lines: 50 Message-ID: <86hbym7y2m.fsf@brain.hack.org> References: <49F1128A.3080501@comcast.net> <49F1E2E7.5010703@lancaster.ac.uk> <49F2077D.2060701@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-82-209-158-128.cust.bredband2.com User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.3 (berkeley-unix) Cancel-Lock: sha1:sG4LcVaURLq0QIwIxUxLNoA5+Xs= Sender: news Subject: Re: IPv6 Ideas 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, 12 Jun 2009 06:42:25 -0000 Nathan Lay (2009-04-24 20:39 +0200): >> What are your problems with using radvd? I have used it quite a bit >> on FreeBSD (6.1) without any hassle. It's even written quite nicely >> in my experience so working on patches for it should be quite >> do-able if there are features missing. >> > radvd actually does support DNS advertisement (but rtsol doesn't, so > it doesn't matter). I'm sorry for the late response. I had over 500 unread messages in this mailing list. It's true that radvd supports the RDNSS option (RFC 5006). Just add something like this to your radvd.conf: interface whatever { # *snipp* RDNSS 2001:16d8:ffff:1::1 { }; }; I have written a client side implementation of RDNSS. It was developed under FreeBSD, but seems to work under Linux as well. Some early testing has been done under MacOS X as well. You can find it here: http://hack.org/mc/hacks/radns/ It doesn't support aging of the RDNSS data yet and you need some way to make it play well with a DHCP client if you're running dual stack, otherwise they will compete for /etc/resolv.conf. I'm hoping to be able to find the time to clean up radns, add aging and a script to work with dhclient. Shouldn't be too hard. I'm willing to patch FreeBSD's rtadvd to support RFC 5006 as well, if I can find the time. Cheers, MC. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 07:34:24 2009 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 C3947106566B; Fri, 12 Jun 2009 07:34:24 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B158A8FC0C; Fri, 12 Jun 2009 07:34:24 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5C7YOfd071413; Fri, 12 Jun 2009 07:34:24 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5C7YO9O071409; Fri, 12 Jun 2009 07:34:24 GMT (envelope-from yongari) Date: Fri, 12 Jun 2009 07:34:24 GMT Message-Id: <200906120734.n5C7YO9O071409@freefall.freebsd.org> To: tim.schwitalla@gmx.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/135451: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] 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, 12 Jun 2009 07:34:25 -0000 Synopsis: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Jun 12 07:32:18 UTC 2009 State-Changed-Why: Would you try the following patch and let me know how it goes? http://people.freebsd.org/~yongari/fxp/fxp.ich.patch Also show me the output of "ifconfig fxp0", I'd like to know whether the patch also adds Rx checksum offloading support to ICH based controllers. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Jun 12 07:32:18 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=135451 From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 09:50:03 2009 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 9E3AB1065675 for ; Fri, 12 Jun 2009 09:50:03 +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 81DC08FC46 for ; Fri, 12 Jun 2009 09:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5C9o3dO065749 for ; Fri, 12 Jun 2009 09:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5C9o3Y9065748; Fri, 12 Jun 2009 09:50:03 GMT (envelope-from gnats) Date: Fri, 12 Jun 2009 09:50:03 GMT Message-Id: <200906120950.n5C9o3Y9065748@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Michael Cc: Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 09:50:03 -0000 The following reply was made to PR kern/135222; it has been noted by GNATS. From: Michael To: Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces Date: Fri, 12 Jun 2009 11:45:47 +0200 The original poster reported that the suggested fix works for him: --- Hello Michael, Thank you. It's working. I consider it necessary to put this into the release errata. Mishustin Andrew wrote: >> Number: 135222 >> Category: kern >> Synopsis: [igb] low speed routing between two igb interfaces >> Confidential: no >> Severity: serious >> Priority: medium >> Responsible: freebsd-bugs >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Wed Jun 03 18:30:01 UTC 2009 >> Closed-Date: >> Last-Modified: >> Originator: Mishustin Andrew >> Release: FreeBSD 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 >> Organization: > HNT >> Environment: > FreeBSD test.hnt 7.2-RELEASE FreeBSD 7.2-RELEASE #12: Thu Apr 30 18:28:15 MSD 20 > 09 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC amd64 >> Description: > I made a FreeBSD multiprocesor server to act as simple gateway. > It use onboard Intel 82575EB Dual-Port Gigabit Ethernet Controller. > I observe traffic speed near 400 Kbit/s. > I test both interfaces separately - > ftp client work at speed near 1 Gbit/s in both directions. > Then I change NIC to old Intel "em" NIC - gateway work at speed near 1 Gbit/s. > > Looks like a bug in igb driver have an effect upon forwarded traffic. > > If you try > hw.igb.enable_aim=0 > The speed is near 1 Mbit/s > > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" has no effect. > > Nothing in messages.log > > netstat -m > 516/1674/2190 mbufs in use (current/cache/total) > 515/927/1442/66560 mbuf clusters in use (current/cache/total/max) > 515/893 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/44/44/33280 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/16640 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/8320 16k jumbo clusters in use (current/cache/total/max) > 1159K/2448K/3607K 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/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > I use only IPv4 traffic. > >> How-To-Repeat: > On machine with two igb interfaces > use rc.conf like this: > > hostname="test.test" > gateway_enable="YES" > ifconfig_igb0="inet 10.10.10.1/24" > ifconfig_igb1="inet 10.10.11.1/24" > > And try create heavy traffic between two networks. >> Fix: > > >> Release-Note: >> Audit-Trail: >> Unformatted: > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 11:00:07 2009 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 D30F1106564A; Fri, 12 Jun 2009 11:00:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 747DE8FC15; Fri, 12 Jun 2009 11:00:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5F85A41C750; Fri, 12 Jun 2009 13:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id gA20EHWhBm2p; Fri, 12 Jun 2009 13:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id C77D041C732; Fri, 12 Jun 2009 13:00:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 62E3B4448E6; Fri, 12 Jun 2009 10:56:31 +0000 (UTC) Date: Fri, 12 Jun 2009 10:56:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Pyun YongHyeon In-Reply-To: <20090612013406.GB72855@michelle.cdnetworks.co.kr> Message-ID: <20090612100900.M22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Navdeep Parhar , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 11:00:08 -0000 On Fri, 12 Jun 2009, Pyun YongHyeon wrote: Hi, > Yeah, there are no checksum offloading support for IPv6 under > FreeBSD so there are no cases the frames are IPv6 when > CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). What I had missed was the CSUM_TSO6 (the 6 at the end) part. grepping through the tree I am even wondering a lot more now when I see what cxgb(4) is doing with that;) >> In case you are maintaining another driver but cannot find it on the >> list - be sure we'll find you during the 9.x lifecycle in case you do >> not properly handle things;-) >> > > [ list of drivers part removed ] > > I guess you missed hme(4) and gem(4) in the list and most old Nope, both have a hand crafted way of computing the cksums; not sure if that is good or bad; I guess the latter but with that they were not running into the INET dependency problematic I cared about in this pass. > hardwares that supports checksum offloading have no capability to > handle IPv6 checksum offloading. If we do not define appropriate > capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, > IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be > hard to change code, I guess. There is no such things as an IPv6 cksum. For IPv6 you only care about ULPs. I am not entirely sure (as in I forgot; it's been a month;) but Michael Tuexen (new comitter) is working on the proper flags im along with one for SCTP; The part I am usure about was if he only cared about CSUM first and not IFCAP but really both have to come along. What was the plan here? Michael, can you fill this gap (perhaps below)? To also address Drew's question: > As a sort of side-note, what about feature parity for INET6 for > existing IPV4 features like TSO? Who is working on that? Ok, maybe we should write down the big list now. What all can we have? What do we already have? What do we need? What needs to be changed? IPv4 CSUM offloading ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a different CSUM_* subset for each card, right? We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. What will that be? TSO v4/v6 We do have IFCAP_TSO4|IFCAP_TSO6 We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll need to add CSUM_TSO6? LRO v4/v6 (is anyone doing or planning to and can talk about it, LRO v6?) We do have IFCAP_LRO. TOE -- how much is that tied into IPv4/v6 and how much general infrastructure, rather than per-card, could a world need? We do have IFCAP_TOE = (IFCAP_TOE4|IFCAP_TOE6) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 14:23:33 2009 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 092C41065679; Fri, 12 Jun 2009 14:23:33 +0000 (UTC) (envelope-from gallatin@myri.com) Received: from myri.com (mailbox2.myri.com [64.172.73.26]) by mx1.freebsd.org (Postfix) with ESMTP id D38FE8FC21; Fri, 12 Jun 2009 14:23:32 +0000 (UTC) (envelope-from gallatin@myri.com) Received: from [172.31.134.217] (drew2-ovpn.sw.myri.com [172.31.134.217]) by myri.com (8.13.7+Sun/8.13.7) with ESMTP id n5CE5pl7011400; Fri, 12 Jun 2009 07:05:51 -0700 (PDT) Message-ID: <4A3260BD.4040307@myri.com> Date: Fri, 12 Jun 2009 10:05:49 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 14:23:33 -0000 Bjoern A. Zeeb wrote: >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I'm not sure what you mean by this. Right now, at least on the receive side, tcp_input() for IPv6 is completely ignoring ULP csum values sent up by drivers. > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? Cool! I had no idea that IFCAP_TSO6 was used, but apparently it is. When I get a chance to work on FreeBSD, I guess I'll flip that bit on in mxge and see if I actually get any packets with CSUM_TSO set. It would be helpful to have a CSUM_TSO{4,6} to reduce packet parsing. But as yongari pointed out, its fairly silly to make drivers parse the packets that the stack is sending them, and it would be ideal if we could easily pull the information from somewhere. > LRO v4/v6 (is anyone doing or planning to and can talk about it, LRO v6?) > We do have IFCAP_LRO. I can do it for mxge, and then Jack can port it to his version. I really need to look at finally making mxge use Jack's port of the mxge LRO. Drew From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 14:30:05 2009 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 4BD83106566C; Fri, 12 Jun 2009 14:30:05 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 06B218FC1B; Fri, 12 Jun 2009 14:30:04 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n5CDUnCW004021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 09:31:41 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n5CDUnCW004021 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1244813502; bh=UizV9K0br7D4KVaB/Sr78m2lDuu6Ue5krfIKkJru49A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VEJ+VCFk7RQEI0cNCTiF3W4twg2HL+MxEk4MNkfXHo1sRd8c6zyv+CuLmzRTVDct9 sN8Fl2OS0pLFsQ3aQsmmkamXd86BDGmR3RTXm029C5GBwWbasPR5Ya9gxxNt+zTM+f XIt7pB5ner8Z8ByVTsSlFjHQU4RvCMijfz40eWjI= Message-ID: <4A325883.3050206@cs.duke.edu> Date: Fri, 12 Jun 2009 09:30:43 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> In-Reply-To: <20090611184555.J22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 14:30:05 -0000 Bjoern A. Zeeb wrote: > if_mxge: > ---------------------------------------- > mxge_rx_csum() has one in_pseudo(). The function and callers > already seem to know how do deal with results in case the csum can't > be validated. So this should be a simple #ifdef INET wrapping here; > side note: the tcpudp_csum variables in the callers are not needed. > side note: huge inlining going on there;) > mxge_lro_flush() has another call to in_pseudo(). As with if_igb/ixgbe Thanks for pointing those out. It will be a few days before I've got time to deal with it properly. If you don't see me commit a fix within a week, please remind me. > if there is no INET there should be no LRO for now, the capabilities > not advertised, etc. Be prepared in case LRO will arrive for IPv6. As to LRO & IPV6... I was going to port our LRO for IPv6, but discovered the state of IPv6 in FreeBSD is so disgraceful that there was no point. Eg, there is no checksum offload, no TSO, etc, for INET6. Once those things are there, I'll be happy to provide LRO for IPv6. Drew From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 14:35:13 2009 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 0AB73106564A; Fri, 12 Jun 2009 14:35:13 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id B94388FC23; Fri, 12 Jun 2009 14:35:12 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n5CEZBQd007675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 10:35:12 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n5CEZBQd007675 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1244817312; bh=0TRL4ZAynW0/vr3URFWS+yZYIusi00MGJEo4uyW6l3s=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=N9Et5dznHaH5eY0cM0cZrb0PPiq/RZzLM6ytJFsKPDv+v3aV3jBWV94WgsNaJokea QN790ioxOMOPeTOlWWnTbYJEcnQo2Gt0vwNZtHHCsDGXD12VJ4/lccG8LxCkuMWZp9 xmLvmbeEQbeNVZP3aMD23CWRF6RrmEcqO1PW/7oY= Message-ID: <4A326797.10503@cs.duke.edu> Date: Fri, 12 Jun 2009 10:35:03 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 14:35:13 -0000 (apologies if this is the second copy you get, I've been having email issues) Bjoern A. Zeeb wrote: >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I'm not sure what you mean by this. Right now, at least on the receive side, tcp_input() for IPv6 is completely ignoring ULP csum values sent up by drivers. > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? Cool! I had no idea that IFCAP_TSO6 was used, but apparently it is. When I get a chance to work on FreeBSD, I guess I'll flip that bit on in mxge and see if I actually get any packets with CSUM_TSO set. It would be helpful to have a CSUM_TSO{4,6} to reduce packet parsing. But as yongari pointed out, its fairly silly to make drivers parse the packets that the stack is sending them, and it would be ideal if we could easily pull the information from somewhere. > LRO v4/v6 (is anyone doing or planning to and can talk about it, LRO v6?) > We do have IFCAP_LRO. I can do it for mxge, and then Jack can port it to his version. I really need to look at finally making mxge use Jack's port of the mxge LRO. Drew From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:07:03 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id 43A921065674; Fri, 12 Jun 2009 17:07:03 +0000 (UTC) Date: Fri, 12 Jun 2009 17:07:03 +0000 From: Navdeep Parhar To: "Bjoern A. Zeeb" Message-ID: <20090612170703.GA994@hub.freebsd.org> Mail-Followup-To: "Bjoern A. Zeeb" , Pyun YongHyeon , FreeBSD net mailing list , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon , "George V. Neville-Neil" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.1i Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 17:07:03 -0000 On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > > Hi, > > >Yeah, there are no checksum offloading support for IPv6 under > >FreeBSD so there are no cases the frames are IPv6 when > >CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > > The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > > What I had missed was the CSUM_TSO6 (the 6 at the end) part. > grepping through the tree I am even wondering a lot more now when I > see what cxgb(4) is doing with that;) I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? cxgb(4) will not let you enable IFCAP_TSO6 on the interface. It has always been disallowed as far as I can tell. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:26:59 2009 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 51AF0106566B for ; Fri, 12 Jun 2009 17:26:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 243B38FC12 for ; Fri, 12 Jun 2009 17:26:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by pzk35 with SMTP id 35so1439601pzk.3 for ; Fri, 12 Jun 2009 10:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=v62ImNvzWEnAsqcxjTMIDivQeNw5F32uf6hynx8DVR4=; b=YneKAbqBh5lBZBxxkIUA32hUg14IExeH/ElCLqXcTOLoAZsTO4kHXEqsUN1kA67XfJ /zXnp8mslDkUqbJBNUohLxq6cpXN9NXV27RWfhyIXqkDNxKUqwk54USXPjJpvE+gQyJo Nt6X0+Wa2HF+1vc+z2WGKZPTotWUrpAsfYJpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sY+Gr9U8RC1HTsVHk6RbzhkM1+4ICy15+3jT73M2NCmIYsUvdT0lNgPPyNL9NQwOyF +Aifi3IWEJVL+e9IJGYRSeJVB1lj9fVZIfwnWWykNcjfcKlhp7j5+Q6b6UftfmA9A/Ug ND3tClJ8jSXVgQVA5Hd9qpBQKpZ4f0YY2tN+E= MIME-Version: 1.0 Received: by 10.142.225.20 with SMTP id x20mr1522352wfg.127.1244826218220; Fri, 12 Jun 2009 10:03:38 -0700 (PDT) Date: Fri, 12 Jun 2009 10:03:38 -0700 Message-ID: <2a41acea0906121003n4e2c8a54k6ac41cc934c6d7d0@mail.gmail.com> From: Jack Vogel To: FreeBSD Net , FreeBSD Current , FreeBSD stable Content-Type: multipart/mixed; boundary=000e0cd28cf08b4e89046c29b00f X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Intel ESB2 problems and their solution 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, 12 Jun 2009 17:26:59 -0000 --000e0cd28cf08b4e89046c29b00f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I wanted to circulate a document from our technical marketing group that details a problem with the family of adapters called ES2LAN. These are most commonly seen as LOMs (on motherboard) in SuperMicro and other servers, the most common device ID is 0x1096 but also may be 0x1098, 0x10BA, or 0x10BB. They are a device driven by the 'em' driver. This document has some Windows symptoms that will be of no value here, but the problem does occur on FreeBSD, most often it is seen as a failure to load, due to a "Shared Code Initialization" failure. There is driver changes in 7.2 that address this problem, however the driver alone is only part of the complete solution, you MUST have firmware updates to resolve the problem, and this document provides pointers for particular systems. If you have a system that has seen this issue please obtain and apply the relevant firmware. I hope this helps resolve any of these issues customers are still seeing. Cheers everyone, Jack Vogel Intel Lan Access Division freebsd@intel.com --000e0cd28cf08b4e89046c29b00f Content-Type: application/pdf; name="ESB2_problems.pdf" Content-Disposition: attachment; filename="ESB2_problems.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fvv5ah0y0 JVBERi0xLjQNJeLjz9MNCjMwIDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDI5NTQwL08gMzIvRSA2 MzQ5L04gNC9UIDI4ODkzL0ggWyA1OTYgMjYxXT4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg DQp4cmVmDQozMCAxNQ0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwODU3IDAwMDAwIG4NCjAw MDAwMDA5MzggMDAwMDAgbg0KMDAwMDAwMTA2OCAwMDAwMCBuDQowMDAwMDAxMTg2IDAwMDAwIG4N CjAwMDAwMDE3NjQgMDAwMDAgbg0KMDAwMDAwMjE2NSAwMDAwMCBuDQowMDAwMDAyNDA4IDAwMDAw IG4NCjAwMDAwMDI0ODUgMDAwMDAgbg0KMDAwMDAwMjcxMyAwMDAwMCBuDQowMDAwMDA0OTc3IDAw MDAwIG4NCjAwMDAwMDUzNTggMDAwMDAgbg0KMDAwMDAwNTU5NyAwMDAwMCBuDQowMDAwMDA2MTI3 IDAwMDAwIG4NCjAwMDAwMDA1OTYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0NS9QcmV2IDI4 ODgyL1Jvb3QgMzEgMCBSL0luZm8gMjkgMCBSL0lEWzwyRkQ2NDBBMkU0MEI1RDkzRjlDQTQxQzE2 QThBODMzQT48MDQ2MUE2QTZBMjdDQjE0MjhGRUJEMjE3NzI2OUQ0RjQ+XT4+DQpzdGFydHhyZWYN CjANCiUlRU9GDQogICAgICAgICAgICAgDQo0NCAwIG9iag08PC9MZW5ndGggMTczL0ZpbHRlci9G bGF0ZURlY29kZS9JIDE4Ny9MIDE3MS9TIDExMT4+c3RyZWFtDQp42mJgYGBmYGBaysDCwMBxnIGX AQF4gWKsQMwxlSHpyQs+MQaG2f/BEowsU0TfRc24xHG4+NQUrw1L0hwlMl20Ii55hxwAmmbiAFSi pAwkmFRC0xpAGgSNLaAmAAE/A4PPCSDNA8QQEWUGHtYPwYof83gZtHgktoouOCP3YTfrgyrexGm8 Fx4xcCUJOGZAnCTJwBD/HWQyENsCsSwDQ959kIuA+B1AgAEAnecotg0KZW5kc3RyZWFtDWVuZG9i ag0zMSAwIG9iag08PC9NZXRhZGF0YSAyOCAwIFIvUGFnZXMgMjcgMCBSL1R5cGUvQ2F0YWxvZy9Q YWdlTGFiZWxzIDI1IDAgUj4+DWVuZG9iag0zMiAwIG9iag08PC9Dcm9wQm94WzAgMCA2MTIgNzky XS9QYXJlbnQgMjcgMCBSL0NvbnRlbnRzIDM5IDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEy IDc5Ml0vUmVzb3VyY2VzIDMzIDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMzMgMCBvYmoNPDwvRm9u dDw8L1RUMiAzNCAwIFIvVFQ0IDM1IDAgUi9UVDYgNDAgMCBSL1RUOCA0MiAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM3IDAgUj4+Pj4NZW5kb2JqDTM0IDAgb2JqDTw8 L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMzYgMCBSL0xhc3RDaGFyIDE3NC9XaWR0 aHNbMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDAgMjUwIDI3OCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDAgMCA1NjQgMCAwIDAgNzIyIDY2NyA2 NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMCA3MjIgNjExIDg4OSA3MjIgNzIyIDU1NiAwIDY2 NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiAwIDAgMCAwIDAgMCAwIDAgNDQ0IDUwMCA0NDQgNTAw IDQ0NCAzMzMgNTAwIDUwMCAyNzggMCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4 OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAzMzMgNDQ0IDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDc2MF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmly c3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMzUg MCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAzOCAwIFIvTGFzdENoYXIg MTIxL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDcyMiA3MjIgNzIyIDY2NyA2MTEgMCAwIDI3OCAw IDAgMCA4MzMgMCA3NzggNjY3IDAgNzIyIDY2NyA2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NTU2IDAgNTU2IDYxMSA1NTYgMzMzIDYxMSAwIDI3OCAwIDAgMjc4IDg4OSA2MTEgNjExIDYxMSAw IDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTZdL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9G aXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0z NiAwIG9iag08PC9TdGVtViA4Mi9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFNNVC9Gb250U3RyZXRj aC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzQvRGVzY2VudCAtMjE2L0ZvbnRCQm94Wy01 NjggLTMwNyAyMDAwIDEwMDddL0FzY2VudCA4OTEvRm9udEZhbWlseShUaW1lcyBOZXcgUm9tYW4p L0NhcEhlaWdodCA2NTYvWEhlaWdodCAtNTQ2L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5n bGUgMD4+DWVuZG9iag0zNyAwIG9iag08PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4 dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTM4IDAgb2JqDTw8L1N0ZW1WIDEzOC9G b250TmFtZS9BcmlhbC1Cb2xkTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0Zs YWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250QkJveFstNjI4IC0zNzYgMjAwMCAxMDEwXS9Bc2NlbnQg OTA1L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250 RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTM5IDAgb2JqDTw8L0xlbmd0aCAyMTkz L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpo3qxYy27jyBXd+ytqSQYjmm9SS3e3M+lgeiaw BSRAdxY0VZKYlkmFpCTrO5LvyDfm3EdRasVxsjAEUKyqW/f95O3Pj5FZDzcfFje3i0VsIrNY3URh EMYmxE/e5qEp8FbGZvF8E5r1zSwIw6g0i/oGL0liFsebr97944fYn6VB6d3+3GzX8lptzYOfB5nX yVr/Rj/IPfOx2sty8GdRMPes8XPvkx3qvtkpXNO18mYqfVma3g6KZrv/DzD/r4s/gkfgi9J5YRaf hNnMMSu8fmbwzBvt1vxy96u5W8q62rn9nnlpDrJufLA3KJXMo7Nv3i93n775PxBMJoJxTgSZ9FxI fql6ujz3ahF2488yUkIcyks41w1GCGOkaox8MkauxsizMsjyMCJzEImwIGIh0fHuX2y9H5uDNY/7 5+eqPxl/8be3bZuncTB3uKLcaSoSvhdHVjYYa4ZhbweSfSM7lZ8FkXeQhfVnkIpOn3TDtmbV7WXR +lGQekvFBKDebqvRuo2xM6MiZSdYsRKiIkjSIgGvzoyJMheXwhxjT7xW/qBZIHDOkIA/Wm+b8WQ6 2Vn5MdggCkIuAbn76RXipF7f2tF8uftomtacgXDjs2KFz/gF5P6XP4vVWjPH6YUXTF4XCqt54pPr RPx8IR/IKGT8hAIGz7mX85GAxQLwwot7KC/3FNZ8vvXngP7NfOR1xyDtyCh6iBBTkNHlLW/J00Lw 2GOn/sOebzyJE98/IjxLT3DH3/wAu8YsICGbmfDYwZqGsQxsxQGHKaleDs2zH8GBPAFZb4QTU1d7 ARTSplZGW1sLRMNiHASNXJaDEwMi4JciaSdSvRLa5PuRukSUip53tl91PXgitJUPqdraml3fPW2t 7g7m2IwbWJeNb8XXQLPMy7OvITYUcSGI2TEavwQr8IQEf8gSq6q2A9grPNOtgLHRxdIemtoGzj0U +QXr4TlkOULDK985k9eUtdhIZDT9MFIowmwRGSGGhHzSDEaDyozgMic3oENTAxRa9InldrQtBQjH qR2Pls8spTdyd1kK13EYJFGRXmgkdSxpSiN1kooRgNWaribeM9CT5cyuOm19eGe1RCA5RRFVVhMp HqcbS0r1XdqeOZLX2fs6JyE8A7PQhAG5aykOklk0XdX1nt2dTH0+1HQ0+BLWYMZO58j55yTUKMZR 3WMehAXkDl1oly6/u5JCTpqRZ0RQc7UFAbjsB/yRimLyOvvkpxqwpe71S16YL/grdK+tYL3MW5O3 ksksORtHOKP8yCgFie4J6U5IC2V5WiEikc5AwpCQE0woYZ0gMEJYRXCuq4Jf1bcrX/DsC2zcotp/ +ALTmEuXft3fF7+btFc7hTo3Hyy5bAqJYrAJZyJ3p9q4J1WQ3WBz2dnpTt2smpr9nnTDe+bB1haF kFGZx2bp3upq27Rr8817eHxEwjOvlPD/Ep0XLlk4l4wd3+QvBXmjn0tBKsQVC1QkMFe5ulRQJUUi yUk2BbDtUt4oeDujuGD5yNvuTL0fRkX1jIyIgx4I3I12InJS/8WmGU6XF3YKQz4STrvcdpXeT0aP ex+14zAhJuqm75wQPnFeS8uGu/YnErRS6kuzVLh6/wOnhKS9xMDKdtafkneuQYTWDmkD1mNTR1zM ObPy5sanQsP1iHsRuEDpOQO+2TKlZRHEP/ZL9KKJ7POSsiL093h63o3d88Ap7KHrRvSoPjVte9B0 VHKlglpVChV+IypozPJ0IhNflH/G7M9yKc8kGqg4jK43U6aF4xRFXxpuYBE3fKV5S+N5kOdT93bd IC2mDmY4IZ+EoLvTNkZbIt2FLxQUNL3V8w61Hi6hPRpORu56FF81cm61vT0Xne7cL6mFpI6g5IYX mdPZPNSCbSl/AzfSmVQlfvZTroy87zoetLwyyykDRt6RjqgB5BPqIjSBSTORKRhSClM42B6peU7J blUJ9Jafe7nTC5i0NLi8tEPAeca4CiXCvJHYoLV5nl51KWyWr14UAH2GlOsMX6rhg7BMtPe4MPfZ M4IiwkRxrsTXcfMAf+24u4GhkN2+m203SLl1ZR0ycK0FxJEaA0jXfz/X5qlVmdgv0ji7ZF8dOX4v GQpXQZPyPJQlnA17dkok03G0bpPd0SCCPFhuu5dduN/SvSKnyxtPdAT4p7/cm6dONjuHpsDzNWHL 14RN3knY6/nz8TSgsZhR5/3MPa6k/IxHFgTCWlZsQatDZ93tp6m1t8vzJHrUu83WGvui72PjkBio ISC4O+NamSLJswvm4skSyt5A7LENYlF5b3moizkr6BQfs00UgJvPv+9lv1H2cIZWHAd1d5A1DYlo SE7BRTgl8fwNC6TvYIHX2ulf0fxyAHCr3EqrrLFgNhX3we2aDQC1s95AMpvP35gQuMPQfmtjq8OJ uiEuXdSjccxVK7QCk/uBZpYnbwRb9j7Si/t9hQfIbCUj2eV8qCPjkSd684+nSuccgl7/08hyt7OV E4a+2hgZ4Vq5S1L/mXy68Nw+3V7KqUx/R/5IIHOh+WQZ2UGgoXZqS1PugmPpgmN0wf3/DlYM1++k J9fVhjpoiMJkho1YVaU+WWE5KcypK2KBU6euyKkrYnXNJZg7BmnlMlxjDlQbWdlJgSUrsFR8SzmW m1TvWH9ckBMdJLD1/WlSHgiaS4aWXBcdOvPJz1Seg+yr5hO93MrdtVXeySMCSAC/uCNpB1HJIOQt l8qSGocn9EvyiULwKpuvf5EL3efD2M1PnD7onqQPRoSeYtXwt4gX2bnlTyFoExWWk5R8fAJ/rWx2 8rFDz1DwZyz4Su8oVM13pCsXRdKavhb937WweNdaSMrQaeL3VOJ6e56X6atML/MM5GhrsO2S0vmz RejyUSZYMI/Rt6/jxrbmgSv/I6yJJw0g1g0gsPvTVlbLSXIYHbJf9Tmuxblf3PxbgAEApP0zXgoN CmVuZHN0cmVhbQ1lbmRvYmoNNDAgMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3Jp cHRvciA0MSAwIFIvTGFzdENoYXIgMTIxL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDcyMiA3MjIg NjY3IDAgMCAwIDI3OCAwIDAgMCAwIDAgMCA2NjcgMCA3MjIgNjY3IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgNTU2IDAgMCAwIDU1NiAzMzMgMCAwIDAgMCAwIDI3OCA4ODkgNjExIDYxMSA2MTEg MCAzODkgNTU2IDMzMyA2MTEgMCAwIDAgNTU2XS9CYXNlRm9udC9BcmlhbC1Cb2xkSXRhbGljTVQv Rmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoN NDEgMCBvYmoNPDwvU3RlbVYgMTM1Ljg0L0ZvbnROYW1lL0FyaWFsLUJvbGRJdGFsaWNNVC9Gb250 U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDAvRmxhZ3MgOTYvRGVzY2VudCAtMjExL0ZvbnRC Qm94Wy01NjAgLTM3NiAxMTU3IDEwMDBdL0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2Fw SGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0x NT4+DWVuZG9iag00MiAwIG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDQz IDAgUi9MYXN0Q2hhciAxNzQvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDAg MzMzIDI3OCAyNzggMCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDAgMjc4IDAgMCAw IDAgMCAwIDAgNjY3IDAgMCA2NjcgMCA3NzggNzIyIDI3OCAwIDY2NyAwIDAgMCAwIDY2NyAwIDcy MiA2NjcgMCA3MjIgNjY3IDAgMCA2NjcgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2 IDI3OCA1NTYgNTU2IDIyMiAwIDAgMjIyIDgzMyA1NTYgNTU2IDU1NiAwIDMzMyA1MDAgMjc4IDAg NTAwIDcyMiAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNzM3XS9CYXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTQzIDAgb2JqDTw8L1N0ZW1WIDg4L0ZvbnROYW1l L0FyaWFsTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDMyL0Rlc2Nl bnQgLTIxMS9Gb250QkJveFstNjY1IC0zMjUgMjAwMCAxMDA2XS9Bc2NlbnQgOTA1L0ZvbnRGYW1p bHkoQXJpYWwpL0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250RGVzY3JpcHRvci9J dGFsaWNBbmdsZSAwPj4NZW5kb2JqDTEgMCBvYmoNPDwvQ3JvcEJveFswIDAgNjEyIDc5Ml0vUGFy ZW50IDI3IDAgUi9Db250ZW50cyAzIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEyIDc5Ml0v UmVzb3VyY2VzIDIgMCBSL1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqDTw8L0ZvbnQ8PC9UVDIg MzQgMCBSL1RUNiA0MCAwIFIvVFQ4IDQyIDAgUi9UVDEwIDE4IDAgUi9UVDExIDE1IDAgUi9UVDEz IDE2IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgMzcgMCBSPj4+Pg1l bmRvYmoNMyAwIG9iag08PC9MZW5ndGggMjIyNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K aN60WNtu3MgRfddX9CMZaGjeL4sggCR7gwQQbEjzECDOA8XpmWF2TM6SHEn+jf3iPXVpziWyvUAS CBiS3dXd1XWqTlXp3V8fI7MZr26XV++Wy9xEZrm+ipKgKk2IP3mrQpNXaVDFZvnlKjSbqyAMw8os G37B6MuVZx76fjJ39WG040/GX/6b9ot1v1g2i3mnogjKUnbCDqGspgVRGIQqyW8knGdBlYYRieOs KDk79J/ecmuNn3tD76dB4vWTnwSFZ5raLz0ogt/Rj4LYM2s/83p/EWF2MJNf4bmVT2vGr7z4ix/F +N7LsOykS3RK99oP9rnlLXT6wOtldsfrZEezsmMDHYaWB59In5Uh3QYs9Fhz+7qXJbUIdSKEmXpU rWkrkdmdKvUy/iS39f+1/DvMiMEorQqzfP8fhgUSUShQiFwesdyCTJqpSROx6M+1v0iDzGt3h4E1 vPcXSVDi1AijuJGJFjKSGzn6iLNsnkRvKnGmIR2ckwCpQPDS0Y/2GbfHbYd656eeafEzjgc7+gWO Jl1e7CASZsWTDX/0bpk82HqDpS1qP8bAhDfLbytD72TS3DNbfsjHi7/AjXiW/YIW8Dl8wxjumGcV HFNVd16YieLrdmAXSb2XGkoUhMpn78MHvEXeJx/7PHy8B1iVd+1ndJVb+br77F/DH0i+8xext6Jb j9DIW5OPnm8HPQtIQGxoefLZDjz22SeNna4Lp+yJtdnILnSiUpSum8aOo8EBOTbbtONkh9G0HYxQ Qu0tgZzAST883sIlY/lkh7i5C86cLvljeKuxli1sRRZufbJYtzGtgIxI9xS6erKAqjcTwruGfoUn ytIQtGOQoNsowW+d8g2L9oJZFFRFPkN2pKtc1Djs2E8aIixjW5wEQ+ccmdifOSLBMQSTNQ7ghBGh df1AvyMOpNBYxLDYWtawhLzqBElu64732rghwUqUPLEiQ1WorrGy3OoAkDy5fSHURZFv2wExot7D HAKpJ3ltd+30lVYozNP2wlYAujZTS8HO3BfShn7o7b4af5G7kVpsmQTkNuGsYOp8qRIFu84O12qW pifTNgRbQiTMqLAtEhh2GA77qRWI4AVVFkdHjCLHCKmC1Jl+zepM2x47qfZs9IEMGXtjYFhADZog SxXY5ztkuPwTn1U6fyjULXuxz6g+xLvvngXKmExOAzptnc/SB7zj1TJFjTNHMWHp89dDy1sMduUn zDLs2CLjPCuePYuI49MDVkTeR3JGYmDm+ZpXdKKIbPUOvzEZ/VZkQCg+kbdhbyuZ7061p/1Xg6jz rGNDgMhDZJs/ENOUSCLN6UFR5SkJxzFR+furP8OW5V9EqhShIM0jxde7rAmCJMmSI/azS2ky+Lkn dkOk7MEGa37tffYgpo+SjA3cD2Pb8fCGmaGUq+aOt2CTWAZ+G9kN4feTlZ07mah3RgTJhIl3B0YG KrzXK+NZj+IZv/I5B1nVMrgREzIlE9VCgZWYv9UdFWRSmkAOzDFxoqC5sOYbbtv750bNqrL8llGj mfQWakxhktxZlQI+QhH04dPje7OXr51P+aMmckm8dT9w8KOiMTsKt5UIGeBAb0QTC8KBc8VWJlu2 kUrqGQ38CgB9sZ18T9en4uuWT3vVzdXQMqgLmn7Y90N91KB1O7GUHjNvahEFd2848RuM5cHWSDO2 HgkN59mKxeL/BYZLQUl6CkYFS6KsajedfLElD/pO6b6F42aezm4Q2sa+ygd5Ml5iNwlXZreDD69l ovWxVKUtsQkY07wI6Vsh4fKc2yNnqVi5Hawkdk8BiDwBi75o3qF07YQmnaNc5W3lHdFInJZDi4/3 hgqA0Ks3OjdeK3mrKheFy2WBCi/peqlR6ViqFSgN0t6dDKtHZORmKxVtDvL8Au5jUyAYVXzyMfJW UJ45QvI/dITYmVhzz91B0BrFdrFkX+Lm0bgpqfEoPhTuGL5AHEdsE8vAb6OiEJNr6BvxG8UFAmzb yx2jIsC9opOE7rJhrEbeSolfc1H2LB9kNI3UoZ0m28kw1yS5W0E1CdUBL52yXkjVNaW2cdsfRGa3 0pUKu2rzo4K16bupbqaL+hTn7foGl/wbiH0nTL0fuJxEFsCKqX22wRFbTV8L5LwSDe1J/jpi+19l sqiY+xot3252vrAs0xXFOpkl8jbdyKYzB67jqYFEYnG5ieDe8AS1JXLjiCty3JGATwE7T3OTRl3M DRBCEUBdBPdCKdcefNZAhTSNdK5ZAMnspaeQIi+qLpxibrZjBYDCDdXDM9V69WlySDwXhi4jJKcZ Qak64YyQzhkBjVng6uAkyLK8+lHp8VYPO9f2pHLmmLWW9vW+56J7ZU2BDurhESwRe48+fj7732he i+81MycJxWXWKL/4T0Q/SfGbc/FLsbCGUWAOlIy4f+lxFERcQ3Kfb7YKQBLkVXpsWebkHeqthhX7 gTaFiB/6f4D8hyBiV0Fi5ZHGPB1kkOu/TFynogyfaCdN/Ygs45nxXNCaBy5n/qEOxuqBrNPke/7x /p7d+Ua4RpOMQm0eHh/pwu67fpLnbvYgWoQ2zKzqqXZuUQogF41kPMOt/Em3zsWziVWoX+CRrYxY s68bqFZ5v+iATJsnnwjyIINUY1b4pcM8LhEpK3BvcUPVCq14JawKSdKYeLKWv+aT1U5ZGZ52S7mz U+TULST70JbHIsecjWuzVwrR5RL2cJFMDkF9Rt5+PGQ2SqoUTqGKiI+FvimZsBmolvgFnTfIfWP5 FghaabGsXACVbxXH38FZOIDaGIfmSMHmIr+eXDOG2qAo0x+2t3Qyq0b4cGM70WWfDus1cQqcRrvR PVral63tZmfy87n1fYInUS2XIxLb0f0LIM+QY79dgWk/9KwFEprXWkspI630Sd1k1r1WZZ0fSeXv BFu3SEzA8WNHre52umqSOq4/3cOMtkE3fLl8tqC7wXkASGYM9X9P3KoW3m7Xv4zKpx+WV78LMACF CyJ3Cg0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8L0xlbmd0aCAzNjcwL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGgxIDU4ODQ+PnN0cmVhbQ0KaN7kOH90VNWZ3733vXkvP0gmIYSQAHnjI4nJ 5DcI+dVkkswkwEAImYAzgDqTyYQEA4lJiGYBm8JS6SDpWD3gaqvUUhWo+hLAnXQtRKvVc1Z3PWWb 3VXaFUHkuEU5FnFVkrfffRkiuJ52z+k/e86+O9/9ft/vu9+99/0YIAAQA4PAoHCVq6D4b/90sQcl LyGs9ff3KTmvfrUbgCQBiEJb98bNnxW+eg+AKQX5+I2dA21Hdj/3MkACtx9pD/haX3tuQwAg+VXk F7ejID6PfQ8D3Ir8gvbNfffd27isEvkVAPRaZ5ffl1KRUgGQ2I0xdm723ddNmfgM+h9Ce2WLb3OA tfluA5h5Be2f7+4JdN8f/zKOH7cUgN0DRHiLhEDEXB4TF+IIGVOYHYQ2mhjLRJFQIpmoKME3rpVd W7rAdlm5rIsPTtaRhXIMeWVwWiveAUXiCkhHmMsegTQA/WwEzk969Evi3aBObtLPZMWj8fEITF0+ yIA7IRuWwytwGU6SHGiEMf1t8IOb3gt5KP8h/D2MwR/ADq1AIZVsB0X/MTwImbALDkKpkKqfgBVw UY6HZFgAZaQLTDALNsIT5AwsAyeOUQ718APowX41yj8nJaghEA13YPRH4HE4Cf8E/wFzcMR8GCcS +Vz/B6gFF+awDUbhD2KNuBdmwkPwDByGl+EDkk8OkY/Yx/oJ/U39P9ErG4pgMayHFmw/gp+i3TPw j1RlP9NT9W36s/obMBezP4qzfhlew1hXiULWEj99mg1Mfqlv0Y9iHWIxZ8weWzXOpgH64OdoOQ5f kShsO6lCq6h/MkGfDRKkgwJWzG8NbIb7YQ/sw1k8Bk/CC3CRVJF28hb5mM6gg/SU2Cg1SA1RpyZ+ p9frVzFGLFgw29vhbrgPPX8ED8N+9PwpxnoV22WYIItJOakky0gT+SH5Pvk5+S9qpe/Sr1gci2e5 zMO8bDt7n30hixOrJg9Mvq036vdhLQnWPBpXshbn2QwboBt64V7YjqdkDwxhC2H1jmLTsJ6nsP0a fg/nsF2Ai/BH3HMizjGa5GArxFZObGQ5WUPuIhtJLzlAXiRhcpK8Rj4iV+giupiW0lW0iW6k3bSP hqhGh+kpep7+CbMsYw7Wy77LjrJX2Bvst+wdAYTlgk/oELYKjwia8DvhsnBFmBRBVLHliz7x4MRT k87J9XqmXq636Pv0ELaLWOP5OJtMyML5NOKq+qENd043tnuwDWDtduOM9sMTWDtevRchjHeAMdzD r8Fv4G14B+f3e3gfPocvsDh8frOIheSRIqzvd0g9tnW4Tv1kOxkkQ+QxrPMwOYFtjJzBWU7iDNdS D72T9tPtdB89QB+no3SMjuNK6MyEK5HC6pmT3c7WsztZH9vPHmV/x55gT7IwG2O/EahQJjQKPcIu ISQ8JbwgvC6cFs6IhWK5GMSmiSfEX4kXTImmNNMik8sUlkzygPyhPAnH4HUYhhPfPPtkDzGTYXiO fMgENkjfpG4aQ8fJTuGfSRauQAUBcQi2wKeY4TzyW7qE3M78ZB3WbydpI+vhJ2wue4othzfFLcTF GkkruIQDcE38NfjEIB1hVAyyCfIFPQrtMETvnjise0gcuMgh+jTumB1QAdlCKozTUmGUZNBsekp6 noShUjKxUlYmxyN3iJ3DNF1yPPkIfOx9PD9n8Ww10afxnnCBnJFWYXYT7AW02QGV5NBkAhwWPdRL 5tJDZMXErol/Y4/rT5I59H2AiYSJalqLO26NfoSehE/gwOQXwntwkr4La/Cu4TdOzqd49u7FO81a uEZn4Hly4X2k21ZVVfmdivKy0pIlty1aWFxUWJCfl2vNyb41KzNjgXqLRUmfP29uWuqclNnJs5Jm JiaY4+NmxMZER8mSSRQYJZDrUOu8ipbp1YRMdenSPM6rPhT4bhB4NQVFdTfbaIrXMFNutrShZds3 LG1TlrZpS2JWKqAiL1dxqIr2ll1VwmTdajfS++yqR9EuGfRKgxYyDWYGMhYLeiiOlHa7ohGv4tDq +tuDDq8dxxuOia5VawPRebkwHB2DZAxS2my1e5jMriQGQWc7yoYpyDMwKy1VtTu0Oaqdp6CxDIev VWtc7XbY0ywWT16uRmr9aosGao0WbzVMoNYIo5lqNckIo3Tw6cBeZTh3LPhg2AwtXmtsq9rq2+DW mM/DYyRYMa5dm/0351O+ZnHwxFr3Azdq01jQkdKhcDYYfEDRDq5236i18N7jwTHQl2bUeYN1GPpB rKLTpWA0utvj1shuDKnwmfBZTc0voDq4xLtJ0aLUGrU9uMmLa5Ma1KBpwDKSmmob1d+DVIcSbHar Fq0qTfX47HOHkyDYNHBsjk2Zc7MmL3fYnDBV2OG4+AgRO+NGIjCtMyjDnFPOpunKEp6Rugx3hKb4 FczEreKcSngXKIGgvwTN8PIQ9NJacUU6tKhab9BcxuXcXxMzzKoS/AxwB6iX/nizxBeRmDLMnwEn +T6Z3muov05rVquWk8O3iFSLa4o5Vhr8bXm5/WFarXabFURYPmjE2vo8ZQVYfouFL/DesA1akNEG V7uneAVa0kbAVmD1aNTLNWPXNbPWcM3gdc20u1fFnXwc+DvdLE3OnP7Fm5NnOtrLNJL8Z9SBKb3T pTpXr3MrjqA3Ultn803clL5kWhehtJm1bpZGIxRNY4YWN+WGaWPOuGM1IQN/JmNTt4YlGXelISFK nWb2Lp3qPdEWy//SKaxf5l4G+totkqZWZr2ZL7+Jvym92CDDhIVM6mxeFwxG36gDXjQ5ZhLfXeW1 k0ev5ct9RhlvvE4Kb+FTlV9f4tsqInoEzovHwScAZAitsNp0BOpNpbCU7YIy1DUj5KHuIdRloP2W CH6Iluo6ypcjXEbIRXAhKAgtCB6EFQjbEVbTUvgFwl70reD+HLN94Oa0+DokiWvhFsSJwgeQKpyD LFMaLBVOg4qyTIy/UIyFBqQzxB2QJM3jPvpF5FeYMtDmY8yhFzKFl6AEfcvF3ZCMudejrkTMhhrT Box3DpJxnGdMH5JNiJeLdpSB/okA7B0cuxnzGECoY1fAgb7LBCvUs+U4v9OQR5+CWsQO1M9CKBJ+ jHOywq1I8/yXIO1B3IE2DehrRX091rMac21kn8J6xAU47nr2r3CaPAaHEI+j/SLhKswkXxpxKwiu FvosxlqByQSjJhMpRPw5wlV5LWRLH4ATx7/jOmYLoY3XDp/wHZGaDqB/G8apZs/DpkiNOSzgsWSA C8JpWiqDvg/nrpj245rvgDyszZ3SB2Qn1qrBgP3gQ7ySA45XgrAEoTwCZeJxEo0Qg3oX8stNTeDn IKVDMfrmY6xmvjdQV4h5GhDJf0UkfwNjngVY1+rr/qblkIM+VpYIrhsApuEKvm9cwe8cA5ND6LMV /StpEX4H7aBPTwHUskT9YZZI75jCoCL9PQOjLzkEc6tnQSLNwpZJM6GLJOPpuMvoVxl9ldEX8J4W jBSkp4dp/shBjnJH5mUjWmCLOZuaXpSVmF6RxfnZtvLO7PT3jsxJP4twNKs4fU9FcfouhAKEfuS5 XdaR7PSurK7NXd/vekBYAsnJuMqJCbItTM69uCYpKilqSShMTtlKpdCvpNAxKbRRCrVKodulUJ0U WiyF8qWQVQplSKEFUpKcKJvlODlWjpZl2SQLMpVBTgrr79ms/PAnmcwcmQTeCwZtprznBx3vBJTI FL/utJnMSZ2uGq3E6gxLepO2xOrUpMb17mFChjwo1eieMIFmd5joXLQ7jT+1R4EQffe+tAj2eIhT G/ODs0XRrrrUMInGG5Wo1hAt0QnO5poUSO6vSqlKrEworbN/S+eN9NavrxTrjZezceAlSCdb+ccX 6TsmpT8scakLpSFDGuLSkCFNmaftd7rc2pF5Hq2YE/o8DzlWfcK2jb8HeFVHAMGr7e1vT9EGWxRl 2HYi8oKQ6W3xt3PsC2gn1IBds6l2Zbh627eot3F1tWofhm2OZvfwNlvAPlJtq3aoPrtnFBpIy3DO 0E3hfnA93CjkkJb/OWKYtPAhc3jEhqFviTjE1Q084hCPOMQjNtgajIiODlcNcTa6h2Wo8eDDx8DH aEw0LpU3zeKpSTZ3VxrrVm5JuT/tlwKQZyEGn8Wx+F43A4Gr8qrzqrkKNwxXxfFXvogq5f5yS9ov ybMRlRnFCWoNWLdav3H18gtSHB12DpjJqD5GB0cS04utHv6cofwRJPI/QBguWrltvknyo0wU/Ayi TaKfMZoaJQl+AnPk7JIUa4P5SsXKiYoG89WKleaJCqiqmKjgUFRoSbAkZGCHexuuKWzsmk2Er/CJ M2Y85U7Td/HeFwOWUWDkuC0uSoLUGaY5sTM+sfBhrQ3nzRegauWlokKSZFJvybxt0eKFxcn03fED j46PP3pgnFZP4XHj6Vj8/6x5/o81fkXjN//195fvTt3BgO+ieOSmaAHpoQhtQvonqAUhCrlJ+EWE JjCfHInQFOLIGxGaoXw8QgtIX4nQJphPE5sHugNtPn9AOaw0twcU/ldcH4qU2q6e7q4eX19H1xal u9Ofr9h9fb6/YFTAB1NcXZ1buaRXWbYF/YpKSwvzsCvOV6o7O5Wmjo3tfb1KU6A30NMfaK13LG20 L7O6Bja3dHWubP7zLDTDAHRDANrwm9iPWIHDCM34bc/pldCF3+Jd0BexUqAWuR6kee9DeYdhoaCk E/3zkbIbct9fOVLBdGYKfq93oWzrtE0vypYhnopXBKXYCiEvQhUb0mr06ETchD4bMYc+w6sJx+tF 6IF+7FuhHhywFBox52XGP3QDsBlajGgrMT633ohxOzG/nr9g+9dop3bnGMYSjd1IwYzztyF1SYyf +kuHSwfh37elSnfFV3wmz5MN8c+WvlTO8ciKfzmr65OV8odyjPFvd2Tn/7cAAwBSGX1vCg0KZW5k c3RyZWFtDWVuZG9iag01IDAgb2JqDTw8L1N0ZW1WIDAvRm9udE5hbWUvR0VIUERJK1N5bWJvbE1U L0ZvbnRTdHJldGNoL05vcm1hbC9Gb250RmlsZTIgNCAwIFIvRm9udFdlaWdodCA0MDAvRmxhZ3Mg NC9EZXNjZW50IC0yMTkvRm9udEJCb3hbMCAtMjIwIDExMTMgMTAwNV0vQXNjZW50IDEwMDUvRm9u dEZhbWlseShTeW1ib2wpL0NhcEhlaWdodCAwL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5n bGUgMD4+DWVuZG9iag02IDAgb2JqDTw8L1N1YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlw dG9yIDUgMCBSL0Jhc2VGb250L0dFSFBESStTeW1ib2xNVC9XWzEyMFs0NjBdXS9DSURUb0dJRE1h cC9JZGVudGl0eS9DSURTeXN0ZW1JbmZvPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5 KS9SZWdpc3RyeShBZG9iZSk+Pi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag03IDAgb2JqDTw8 L0xlbmd0aCAyMTgvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCmjeVFCxTsQwDN3zFR45MSSN kGCouhxLBw5EC3sucUsk6kRuOvTvSUp7iMG2/Oyn92x5bp9b8gnkGwfbYYLBk2Ocw8IW4YqjJ6g0 OG/T3m3ZTiaCzORunRNOLQ0B6lrI9zycE69w1/dVda9OIF/ZIXsaM/SgPz4z0i0xfuOElEBB04DD Qcjzi4kXMyHIX+Yf2q8RQW99tasHh3M0FtnQiFAr9fjUHAXJ/Z8frOtgvwyLY1srrRuRt3e88MpV NyN2Yc4et9M3I8WCJ7x9J4ZY1EqIHwEGAIAKauoKDQplbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoN PDwvU3RlbVYgNDIvRm9udE5hbWUvQ291cmllck5ld1BTTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0Zv bnRXZWlnaHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTMwMC9Gb250QkJveFstMjEgLTY4MCA2Mzgg MTAyMV0vQXNjZW50IDgzMi9Gb250RmFtaWx5KENvdXJpZXIgTmV3KS9DYXBIZWlnaHQgNTc4L1hI ZWlnaHQgLTU3OC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNOSAw IG9iag08PC9Dcm9wQm94WzAgMCA2MTIgNzkyXS9QYXJlbnQgMjcgMCBSL0NvbnRlbnRzIDExIDAg Ui9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDEwIDAgUi9UeXBlL1Bh Z2U+Pg1lbmRvYmoNMTAgMCBvYmoNPDwvQ29sb3JTcGFjZTw8L0NzNiAyMSAwIFI+Pi9Gb250PDwv VFQyIDM0IDAgUi9UVDQgMzUgMCBSL1RUNiA0MCAwIFIvVFQxMCAxOCAwIFIvVFQxNSAyNCAwIFIv VFQxNyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM3IDAgUj4+ Pj4NZW5kb2JqDTExIDAgb2JqDTw8L0xlbmd0aCAzNjgxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpo3tRa3W/bOBJ/z1/BR+lQKxI/9LHAPrRpurd3bTdIssUCxT0otpz41rF8kpy0//3NBylR tpTsAXvAHQzIooYzJIe/meGMdP7TTSLu27N3t2fnt7daJOJ2fZakUSxFDD++K2KRFiqKU3H7eBaL +7NFFMexEbdLaN0+nwXXVVtvD92m3onw9p8oSVpJcS8pdpKyLNIsCPgDYojFIokSrTJx+/4MZCcZ 0mgUiQN8Da5DHVShjHQAI4U6SoJDCDwq6KixoWsN1yzYCW7tqPVE15o7M+cTN6o2zKI0ECvbA6/P 4QIlbEOYLsgrwxxGXPny7plZlGJJRCv5MUwU9Lnjls9QjmYICkqDeh0aYBW7ikQ847NVQ882oxk2 7ZswjWQg1vy8scM8lw2zvhElj7I69zTQwCpgYZewvjy4DBO4Xl3DkoJfPgEdKCzNCivvqzYSQoT/ uP2b24mCdiIedpi26fYvuDmxcpujc96c24dKrOvttg4VzPp5s6N/0JSEyYiuvNtWIlykwZ6ew+xk wF2fuMtmVYVZ0Ia40pJ6NtUaHzV42dHEEhMpWShAkoXIAL+vwbISJe4m6LQDwQXviglQsc8PJT+j DZOOBIuX8HDPLdSbgZGoUe2YwUrcVRUxrqzMLizGI9wRM6IT5n+gxn5lB7Ws2G3NgzSipGdiz/8N d9zQdUlCDltqlI1dzXeWybIEi1nDHucBb9rCKefIilBDX4P9tuxwbEIPWlA0t9WBs94kZvOlLjJV BrvQjpNMuDEpa/4qXGgwK+gGSA8XGeCpg5lpnF/K5pERcMXt9z2iIDEp6v1XJBtUv4ZlrAZWZEJV pqhvpIl3ny64M0+7iGJlCn+p5CeyAasfNs0jWgitRkaJAncyvVQTFSZPBOi8UNpqjf0aqw9X+Ot+ BZaZ4+okTKIDSOIuXF6CSaEV/QLLTYJPuMM/P5awX4aRD4iwNmVnejRjqe04quCBbr7wgv8O8zGw ywv0Bw2MAd7mp6Yq+UGHnTJQEam8cUOoKEVzHO0/+msaIS78pRS8FM1LUQDOj5vdgQjfcBXvm81T 1bBcGCqTxp/6sU+4vD3LQQ1SpBArABWg0aIoYCLguZvqbO1RUyky8GbYJ40dOUnjSOUDd4qKH7iT FByhduw5zCMfsUsNypofXGoV6dyxwxqiWI/4VZ6O+Iky8Ks88/lVEekxv5FpVMzze2Tgt2Sfn7Vj col/dvpK4yi+dno6acej2+XP8tvl+fzSp9v5zdL5WDAfzE2WID9EczJC63Eur27en3+6uAJMyeD9 hLdB+KcuimTW0O4g3BYUH1JEJXkRcWg3ITpmAw7hfiRpsKTEOSVpnRIEoAWaZlc19q7cohuxthJH ucqVZ/Vkjso7zhCyPZd64jhAhikk21txNBGMK4m0ofHztbjmYXtDMYjiCTsxUZwzMRUZOHTukh4B gXmnrcQyOysZuHuYTI5sjcRy90YysPco6gefsBHH7mxkYO9BNslulaLBQjwAm/GyLdXB34yXNc3r Zj3wSo/qJjVNBdxPoV2lfHSlzVYOdXarfyasqR51qkfdwsSJRFQtEoigBRjFDd4rABj0OsGHNpHJ ZwEC1FQ7gJz40Z55BiHMPetH58Z2EGH2eT/qDz+FEcs/60fn+K1mlPbcXJJE+sg6HJ0XP9Dd6ub4 3ew9funT3ezm6DNwkcpzjqBwG+8V4+XyG8d7h5e8xwuc0OFBLmP0gAiaLI7B/10LQk2MYk9Ro9QL XgWJ6TxoLO8MZph5HjPTIzvIMPcLkBkGn0KMZZ9HzDS7VYpMEG/zgHH0OcDM8bu5e/yTgJmjzwAG ewwO5jisfa6tO8mkzOg8jNAwmA286E8AR6mchQZS8/mA45hnsMHc8xFnZmwHDmZ/IeR4w0+hw/LP x5wZfquZGA72w6kRDrtHi3d0XvxAd6ub43ez9/ilT3ezm6NPw0MX4D1TB4+T/OFa/Ciuq38dOE/Y NNWK76bPX1hY4TRH9SeVH9H1fK47yDPBBYEsyGYkFlokOCcQCAezAg9mss88T89ifeXGhcUbSuh/ FH/lk9gmxCLKA2cx2+9EbA/39zatabtq9UbccevAfx2yiF1tW2Jn+y6rti0bTEC/h1STOcJ9DD5V z+IeqIXQOuE+p37FcU8iR6cFAsSdOUxv2COyBpj0nXzhPTsfO8yx3xjTfQF8IE/tgRwCQc4YoTvE iIaDB0LEz2RjciBwQOmqrcDDubiimkDz2P7wesFOg1dxpb+TetBkZPtQczzbbuvnze7e5vHltq3F phWl2G7aTtRr0T0wqaLkeefCoZ2jrQ1sQwAjVTCo2TxCkgCQwcqXqxB0AMw06IVtbddl2W3s7Y6G G3dbWdqzHdixlU7slvpPCLN0quk03irehVim+ARgTIKLCbP7iqUJNgNexTM2JObjyGJJFbe89WFS zj0bZ0Q4syc7rn2IRbwPtW1QmbGf2Ug+7EF7sIQW+43HBWRUvWLrSQ23tGFH+8NC3C75q4S98vtW JfMvx+rsSM6yE9/rg5tpafn2je27B916WqCRK+FDZ8YtOWcprbNkDehgv6/5BmQq8jUw7LLe8UNs wZRswSyxhkFWoSDmST1lFV79bMKaVJpHWe/DZe8t3aEQkI9jg/8FG0UHLgPCPt40jzyRFGMfSqWb xORRnguVgbM+mk9ic9XRJJKUkv1+IrZAtMQ6VaZtvV1cNfWKas8H2JIwSTLcyc/lI9XMK9iGNHDV LS1N8lLZOAd/q45z5dg5DbdyV7U7f99saJAn3BGEt8BCgkIrwfby9/K+mtKDysCXy0k9yCk9qMwM SvCLWSoFGnhfnWPYt3/Ou1uihiOLzEdEA4eyxGPVU6xwWoMjiiVIOvbwiSOLMfoPdJ8I+p0numE9 ydqnv1bCUdr0EYM9OcRsE6I9xTH/XYVYnL35OGNcXMpBrhhxmgLfb3ATfPmM1wk/uOjfIiAP9EbR BJRUglLHhZnYHYMTewy+6cpGfCzJI/1eCb7ZITgSLLSfTLHP1e3Lgi/gMA29nFFBvcO6exaUzJe5 eEo30uCbKqWzSBKgzi/aVCxbVp9olzuvyP7Qdfsfzs+fn5+jDYbZaIk1a0WvCWJ+PwRn1OAcXVZ7 AK/TdOfYo0BKQu8TbB1XJ8oMbzkyFt89VM1dXTar9rytmqeqOW9BcWAWJoj37fbcnXzclOm1XQLn RQMoVMPhBsAwXqM2Mir8ReLrPa/QNVgE4Et7uM8K4PaRDesreoPwKjgW2D3Zr99YXE/RHKw9sfrV Ao1CXUsHZtp0GWV9Me4mo00nWMPfhwsKT5pL6b9eUwtCKFG/Lfn/ianVCwBJpI0E8wCx0PsTUEKH bwjshBaIgoU5RcsJVjKHlfVSH5pjtIBkdBkxJdJqdNY8AgukRcZb7xFWFhIOspDDkvHB+RlndYwi WJ+Zcp6WHCd4NreEJIfQMkZRT/eJDkaTRIcjT7L26dNAkgWGNQsk2TtFg9gx7BBV8PbjdGrFXtQ5 uedTf0rX395+pPez7s2rdX7jJM17x/52u6y3B1LnFArBZUJCjmj7rzsqC0FwoxaERZbpAYQ2Gky6 Kw3uqtyeb3ar6lv00PHQj2M8ygLOJ/Ancyq2vei9IJeDPNtf+wkm88jkqXkJk1hcm3dsMsvo1c5c yB7oEyF7mmgx6Us+DtlTmExhzTGvsscGJMJx5gKj0XF8Qy8rP4ibh3q93vHLygZ9mEvZJ8ED+WYu XwPPn+7E5hBkphDEq/swwo4+wU6KZkTYSV/xZXk6WvYEblKdpi/gBrcvzuedmYRzeZrOO7OBPuHM pokOOJ7kP+LMdNG/oSNfBsdoKRMHGnj6BVGTBG9xYyAE3pT7CnL3F/Bi4qj438HLKx7nqS171Bzj RRdRxnjBw7NK59HCWzqsewowhf3SYAYwsG3JC0coqQrc+nnA9PQpwEwSHWA8yX8EMCqOksHTcDxT 1lTm4tkX+ujogr6J+BjivglulCF+DIGfXkl75ScP5e4FhCkJk/m/QdjytZgGGs2lF9NeCWje6v/z gIa7LX3HNAKZjKnmPAuynj4FskmiA5kn+RhkWBMxnIKOk3ZEW2IgiPFig+S1eqTGMSTsmrQsQzJp oYqI+HRx9V7sbZET9zgJWtE9lJ04tBXcVOLy5p0Un95eiE2Y07d6C/wgDUn8wH4AA2tKjMkYCZPp 6KpqN/c7KqThN0dU5SzX62rZVZSZrjgzpQ/FvqP8lp+L5YNNXe/5QRvxmz8cdlZfOpMU4DydHZdb FqaAk0RKny5kaW4GhAxqpSNrlmU5EaWYqo+wqpM8t5lhn1KhGoxV9EfOn3cHTprOqfWhqap3lE3d vBerZgO3WZ9INT8cr7DgfD+eqh0NU4acw0913DagBdhvEPk4veP/56rt6GMs/rhyQ/c0B/woL+Ma JRYTaeOeSu6wpWtJn0zecYNqlfWOXJloa/72tFmyjDW3G/KA91Z6RF+r7Co7/pqINRO5p2DSg2Wg LzVlcBOCL3kHFB1IEvtG8CgJ94vpobtaVpgc+KIWdWzcIHay9ttA3Ex9VBCRfYqS2RQljiinMfyX 858UdRPyp3eLFJRjyHnj1Du6r+i+4c5/4ANS3PSMt9N+S2pzq891x2+XTsABuWZmPE/sXlu51AqC DM7hQIGlafjbzZR3dUcPV7ADiMUDn4KZbhv4gSlGqpb593yF+MC1gDX1rW1fwU8fuDnsGvKAM+lx RjuCzYewr+7nAXmIu6riSYnHARU59KdprOyADdXb6scBK96o3DUhKRSA4c/OzEo74uAVVpbD8tmn DBGr4zFE3JfXK7ZwsqYsaLh1d+Amt7hSsiM922+tM1oErNM5COpyYNK3yO2yte08yk2spj3AENZk zC/VpsIavgJW/Sk8TyZo9m3cacXW59U97yTR5/63AAMAoZRHQQoNCmVuZHN0cmVhbQ1lbmRvYmoN MTIgMCBvYmoNPDwvQ3JvcEJveFswIDAgNjEyIDc5Ml0vUGFyZW50IDI3IDAgUi9Db250ZW50cyAx NCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyAxMyAwIFIvVHlw ZS9QYWdlPj4NZW5kb2JqDTEzIDAgb2JqDTw8L0NvbG9yU3BhY2U8PC9DczYgMjEgMCBSPj4vRm9u dDw8L1RUMiAzNCAwIFIvVFQ0IDM1IDAgUi9UVDYgNDAgMCBSL1RUOCA0MiAwIFIvVFQxNSAyNCAw IFIvVFQxNyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM3IDAg Uj4+Pj4NZW5kb2JqDTE0IDAgb2JqDTw8L0xlbmd0aCAxODc4L0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpo3oxX227jyBF991fUYxOIKN4vfrSt2TgTZwZrZYDFbB5oqSUxkUiFTdmzP7KfkW/M qaqmrPHA2IVh9rWqTtdd858eY9q6q5vl1Xy5zCim5eYqTsO6ogh/OqsjKqMirBNaHq4i2l6FURRl tFzxJKfly5X5tHigz/tm3PTDwQXLfzO3QrmVYVxFKZgt70AMokgoyN96lRklk0zMILMo67DMWOaM BcZMa+6G9tkO7noiTzx5dCaPJvIiCytFzIRCENEsDuOsLhkMmMYpnzH7vGJUX83f2yANS9OdgixM zbe5rD4M1t4EdViYx6DA9y5gNobWQ4vd0jzzujR2uA7+tfwbw4pzxVWHSYU3vPd4jz5MchBE34Hi JyeKaRmUwLLzQigoTGdfbFAZNwo8WgvYAReMwp8A4Y7sUoOZ32z0yl6+TZCYJ50K474TVuR6GU+v jFd2E+SmH/DZ2jDIw8p0XopHIedKQLq1e4VBi0fVYKJ7fyHejeV6FOkgCJ4FtFOQyq4jUeusDvO0 qt+YMKkmE5apqisKRV+5DpUOCQF6EeZQ/azA4/MwweNTbIwytzIf9LLK886Slu8YLy7Vem+dis22 Ao5/9KOFyNr84BVJmJR59mrweDJ4pi+gW6DJRPuxGQbbjYKO1dN0srmGtqEOXIHs2ui5XwwWj4DG ndIf9dsPo1CAkO/2/i7p7k6XlhagjeHmTHOTsER2cqZA2PFyJ0eN3ne882StgqIDhnJi/aww1jR6 gXIF93V9lmhjOYn0G3nwaxXqFJ6H8HRS2vaCYxfSpN73U0leQ+UFJ4Nz6mKPKbzHLBaff/4UZOaB 7g/N1rozx/ezS17CURLPMZ6SIScpZnh/COIEzxBmjNYHS2GIM0hpviBWPoq7J3hFZsJcBmrWMuoX cccack6dUvk4d7Ki9sHuZQMhDDWMMrcyX4tRKzUERDo7wZHj406494MlpWrl9gHAKuPBbqkRIS9e iH45jYCBC2LG45l6KeCG3IBTv34SISddOBUk/iMezE+Uk71HoCrig63koY3wogdJAJxvzf2tppnL 2NSYY1MiGNUEqU+a4wBBM/ZH16zGtp8WLLYyIS13utE6EvM/sNiT7h3lgWtdsKub0VLb0arXrYNk /SfPwHNuXoWI5tpxJ1CTRNPWFO3RFO3xFO0jtCoBkUhAMA6n2XhDTUen47oZ7drHIofhqhFbdaJP uz/SStYn5eCUXw/7xBhtMOMEN/BhYrxvzyZUFymOIeXnNPcVINgstZgFSZ8TNhh8YwXm4m+1+Buz ZgGdHjR7OWFoN2LVB7HqrTovFAtnJ+KSVmgOAEIJigpBwf7+US3/LFITvRGCW65TUYMCcwpCinDt k0Nt9KwX8o5Vxag7TVQy50KFoVd+J70o37UXcfluUuR3guqemlGEXftH/uCLF80G8kfluwDJHbXk jRQa47Qxv3UFrRyFeRTXBY79xK067XdqrSK7cTxez+fBjF3uBWqr8WX3xDeDDkM9adnKGTBLOUDU yhKHKWCv+sN8tZ7btXX+3lYdtZvv2yd4BnNthNQvfuPYzowXq0fu0M/0tGvm1rv6dp5mOqtKHeNc x3A3HkQ/i+WVPDwK0WQleRUWBeEfoUqDvdpw7zkpKM3k9KwkbjYvNDpLKu4IWd15mrK637aR3hZT byC5wNz1q9MBRZTu765n31sGbpemvjmdnbuJqa39agAI/QLUXCI03haamae+wMMxVF3E0LId9zZg O10H7FqziUU1dQJlUpSv8uM3Wey+gy3/R1WSF+niZl6xaitEBeewXBdFtmCrpOaGfmq3zVM70mLc WRgSGcKO9Pmvv9Dv9M+x3bejJiSk1FeJUe5FJqWK/A2xiCB57DcjwqFgP8ulcqTqHLlEfSodXUKP zeHIzjZtfmlk1Qbc5CFvsb+hq6SPgPWrefzy8ddgykAlSinefqG92WUzlEpxNr/Tz/Y5JKSrP275 M/xiyF97/ot27YfG/23F/tBr9UIq5RL3fd3qfanDDw9fMnd63vi6Nlih+u9JC5my0mJ8ZshZ8A0/ qTxS1T5xkdFiR+1l87C2UxFJIkkTU47x2ZqxI6grjunOQW6N1hq57ri3DYrISroNpDp00SPqID20 /7FqAGitLKvs/br0iBKqpWTES8SKYIxfeKTlx7nWjU23ktKoNkXc1lV1WVRm54bYF2nmvBosPANN BvxUqlTCNeG9bPpnfy9mMZJHcv69eP5p5y1883BLH9rhIF3jSzPY6z/R5mVR6nleBOeUHG5PblRT ZuIaLxLo6K5M742YsR2mG0hAeG87EGqT0bsdbbh4odXzlxgX6pO20Rm35ztuiKe2J0Hcp9Vl9E6/ FWP/+1WCkp/qdv1pL6635iKQGvEFQFM/GOVop0cMCqaVZMO+zPeOg3X8w6OSbh8bI1qPKXQ9jDd2 Pocut9oMhn2l7TbSNcXyxgjSuFHSnU4HiNxzh+NXo7S7/bTa6aSVfnTTftNlyO1M4dWCCvN/AQYA 5SrYdwoNCmVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5k YW50Rm9udHNbNiAwIFJdL0Jhc2VGb250L0dFSFBESStTeW1ib2xNVC9Ub1VuaWNvZGUgNyAwIFIv RW5jb2RpbmcvSWRlbnRpdHktSC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTYgMCBvYmoNPDwvU3VidHlw ZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA4IDAgUi9MYXN0Q2hhciAxMTEvV2lkdGhzWzYwMF0v QmFzZUZvbnQvQ291cmllck5ld1BTTVQvRmlyc3RDaGFyIDExMS9FbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTE3IDAgb2JqDTw8L1N0ZW1WIDEzNi9Gb250TmFtZS9U aW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9G bGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vQXNjZW50 IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01 NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTE4IDAgb2JqDTw8 L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTcgMCBSL0xhc3RDaGFyIDEyMS9XaWR0 aHNbMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAzMzMgMjUwIDI3OCAwIDUwMCA1MDAg MCAwIDUwMCA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDcyMiA3MjIgNjY3IDYxMSA3 NzggMCAzODkgMCA3NzggNjY3IDk0NCA3MjIgNzc4IDYxMSAwIDcyMiA1NTYgNjY3IDcyMiA3MjIg MCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCA0NDQgNTU2IDQ0NCAzMzMgNTAwIDAgMjc4IDAgNTU2 IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiA1MDAgNTAwXS9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5B bnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTE5IDAgb2JqDTw8L1N0ZW1WIDcxLjc0Mi9G b250TmFtZS9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRX ZWlnaHQgNDAwL0ZsYWdzIDk4L0Rlc2NlbnQgLTIxNi9Gb250QkJveFstNDk4IC0zMDcgMTEyMCAx MDIzXS9Bc2NlbnQgODkxL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2 L1hIZWlnaHQgLTU0Ni9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNT4+DWVuZG9i ag0yMCAwIG9iag08PC9TdGVtViAxMTYuODY3L0ZvbnROYW1lL1RpbWVzTmV3Um9tYW5QUy1Cb2xk SXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDk4L0Rlc2Nl bnQgLTIxNi9Gb250QkJveFstNTQ3IC0zMDcgMTIwNiAxMDMyXS9Bc2NlbnQgODkxL0ZvbnRGYW1p bHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTUzMS9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNT4+DWVuZG9iag0yMSAwIG9iag1bL0lDQ0Jhc2VkIDIy IDAgUl0NZW5kb2JqDTIyIDAgb2JqDTw8L0xlbmd0aCAyNTk4L0ZpbHRlci9GbGF0ZURlY29kZS9O IDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFtDQpo3pyWd1RU1xaHz713eqHNMNIZepMuMID0 LiAdBFEYZgYYygDDDE1siKhARBERAUWQoIABo6FIrIhiISioYA9IEFBiMIqoqGRG1kp8eXnv5eX3 x73f2mfvc/fZe5+1LgAkTx8uLwWWAiCZJ+AHejjTV4VH0LH9AAZ4gAGmADBZ6am+Qe7BQCQvNxd6 usgJ/IveDAFI/L5l6OlPp4P/T9KsVL4AAMhfxOZsTjpLxPkiTsoUpIrtMyKmxiSKGUaJmS9KUMRy Yo5b5KWffRbZUczsZB5bxOKcU9nJbDH3iHh7hpAjYsRHxAUZXE6miG+LWDNJmMwV8VtxbDKHmQ4A iiS2CziseBGbiJjEDw50EfFyAHCkuC845gsWcLIE4kO5pKRm87lx8QK6LkuPbmptzaB7cjKTOAKB oT+Tlcjks+kuKcmpTF42AItn/iwZcW3poiJbmlpbWhqaGZl+Uaj/uvg3Je7tIr0K+NwziNb3h+2v /FLqAGDMimqz6w9bzH4AOrYCIHf/D5vmIQAkRX1rv/HFeWjieYkXCFJtjI0zMzONuByWkbigv+t/ OvwNffE9I/F2v5eH7sqJZQqTBHRx3VgpSSlCPj09lcni0A3/PMT/OPCv81gayInl8Dk8UUSoaMq4 vDhRu3lsroCbwqNzef+pif8w7E9anGuRKPWfADXKCEjdoALk5z6AohABEnlQ3PXf++aDDwXimxem OrE4958F/fuucIn4kc6N+xznEhhMZwn5GYtr4msJ0IAAJAEVyAMVoAF0gSEwA1bAFjgCN7AC+IFg EA7WAhaIB8mADzJBLtgMCkAR2AX2gkpQA+pBI2gBJ0AHOA0ugMvgOrgJ7oAHYASMg+dgBrwB8xAE YSEyRIHkIVVICzKAzCAGZA+5QT5QIBQORUNxEA8SQrnQFqgIKoUqoVqoEfoWOgVdgK5CA9A9aBSa gn6F3sMITIKpsDKsDRvDDNgJ9oaD4TVwHJwG58D58E64Aq6Dj8Ht8AX4OnwHHoGfw7MIQIgIDVFD DBEG4oL4IRFILMJHNiCFSDlSh7QgXUgvcgsZQaaRdygMioKiowxRtihPVAiKhUpDbUAVoypRR1Ht qB7ULdQoagb1CU1GK6EN0DZoL/QqdBw6E12ALkc3oNvQl9B30OPoNxgMhobRwVhhPDHhmATMOkwx 5gCmFXMeM4AZw8xisVh5rAHWDuuHZWIF2ALsfuwx7DnsIHYc+xZHxKnizHDuuAgcD5eHK8c14c7i BnETuHm8FF4Lb4P3w7Px2fgSfD2+C38DP46fJ0gTdAh2hGBCAmEzoYLQQrhEeEh4RSQS1YnWxAAi l7iJWEE8TrxCHCW+I8mQ9EkupEiSkLSTdIR0nnSP9IpMJmuTHckRZAF5J7mRfJH8mPxWgiJhJOEl wZbYKFEl0S4xKPFCEi+pJekkuVYyR7Jc8qTkDclpKbyUtpSLFFNqg1SV1CmpYalZaYq0qbSfdLJ0 sXST9FXpSRmsjLaMmwxbJl/msMxFmTEKQtGguFBYlC2UesolyjgVQ9WhelETqEXUb6j91BlZGdll sqGyWbJVsmdkR2gITZvmRUuildBO0IZo75coL3FawlmyY0nLksElc3KKco5yHLlCuVa5O3Lv5eny bvKJ8rvlO+QfKaAU9BUCFDIVDipcUphWpCraKrIUCxVPKN5XgpX0lQKV1ikdVupTmlVWUfZQTlXe r3xReVqFpuKokqBSpnJWZUqVomqvylUtUz2n+owuS3eiJ9Er6D30GTUlNU81oVqtWr/avLqOeoh6 nnqr+iMNggZDI1ajTKNbY0ZTVdNXM1ezWfO+Fl6LoRWvtU+rV2tOW0c7THubdof2pI6cjpdOjk6z zkNdsq6Dbppune5tPYweQy9R74DeTX1Y30I/Xr9K/4YBbGBpwDU4YDCwFL3Ueilvad3SYUOSoZNh hmGz4agRzcjHKM+ow+iFsaZxhPFu417jTyYWJkkm9SYPTGVMV5jmmXaZ/mqmb8YyqzK7bU42dzff aN5p/nKZwTLOsoPL7lpQLHwttll0W3y0tLLkW7ZYTllpWkVbVVsNM6gMf0Yx44o12trZeqP1aet3 NpY2ApsTNr/YGtom2jbZTi7XWc5ZXr98zE7djmlXazdiT7ePtj9kP+Kg5sB0qHN44qjhyHZscJxw 0nNKcDrm9MLZxJnv3OY852Ljst7lvCvi6uFa6NrvJuMW4lbp9thd3T3Ovdl9xsPCY53HeU+0p7fn bs9hL2Uvllej18wKqxXrV/R4k7yDvCu9n/jo+/B9unxh3xW+e3wfrtRayVvZ4Qf8vPz2+D3y1/FP 8/8+ABPgH1AV8DTQNDA3sDeIEhQV1BT0Jtg5uCT4QYhuiDCkO1QyNDK0MXQuzDWsNGxklfGq9auu hyuEc8M7I7ARoRENEbOr3VbvXT0eaRFZEDm0RmdN1pqraxXWJq09EyUZxYw6GY2ODotuiv7A9GPW MWdjvGKqY2ZYLqx9rOdsR3YZe4pjxynlTMTaxZbGTsbZxe2Jm4p3iC+Pn+a6cCu5LxM8E2oS5hL9 Eo8kLiSFJbUm45Kjk0/xZHiJvJ4UlZSslIFUg9SC1JE0m7S9aTN8b35DOpS+Jr1TQBX9TPUJdYVb haMZ9hlVGW8zQzNPZkln8bL6svWzd2RP5LjnfL0OtY61rjtXLXdz7uh6p/W1G6ANMRu6N2pszN84 vslj09HNhM2Jm3/IM8krzXu9JWxLV75y/qb8sa0eW5sLJAr4BcPbbLfVbEdt527v32G+Y/+OT4Xs wmtFJkXlRR+KWcXXvjL9quKrhZ2xO/tLLEsO7sLs4u0a2u2w+2ipdGlO6dge3z3tZfSywrLXe6P2 Xi1fVl6zj7BPuG+kwqeic7/m/l37P1TGV96pcq5qrVaq3lE9d4B9YPCg48GWGuWaopr3h7iH7tZ6 1LbXadeVH8Yczjj8tD60vvdrxteNDQoNRQ0fj/COjBwNPNrTaNXY2KTUVNIMNwubp45FHrv5jes3 nS2GLbWttNai4+C48Pizb6O/HTrhfaL7JONky3da31W3UdoK26H27PaZjviOkc7wzoFTK051d9l2 tX1v9P2R02qnq87Inik5Szibf3bhXM652fOp56cvxF0Y647qfnBx1cXbPQE9/Ze8L1257H75Yq9T 77krdldOX7W5euoa41rHdcvr7X0WfW0/WPzQ1m/Z337D6kbnTeubXQPLB84OOgxeuOV66/Jtr9vX 76y8MzAUMnR3OHJ45C777uS9pHsv72fcn3+w6SH6YeEjqUflj5Ue1/2o92PriOXImVHX0b4nQU8e jLHGnv+U/tOH8fyn5KflE6oTjZNmk6en3KduPlv9bPx56vP56YKfpX+ufqH74rtfHH/pm1k1M/6S /3Lh1+JX8q+OvF72unvWf/bxm+Q383OFb+XfHn3HeNf7Puz9xHzmB+yHio96H7s+eX96uJC8sPCb AAMA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9G b250RGVzY3JpcHRvciAyMCAwIFIvTGFzdENoYXIgMTE2L1dpZHRoc1szMzMgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA0NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgMCAwIDAgMjc4XS9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZEl0YWxpY01UL0ZpcnN0Q2hhciA1OC9FbmNvZGlu Zy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTI0IDAgb2JqDTw8L1N1YnR5cGUv VHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTkgMCBSL0xhc3RDaGFyIDEyMC9XaWR0aHNbMjUwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjUwIDAgNTAwIDUwMCA1MDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgNjExIDY2NyAwIDYxMSAwIDAgMCAwIDAgMCA1NTYgMCAwIDAgMCAwIDAg NTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDUwMCAwIDUwMCA0NDQgMjc4IDAgNTAw IDI3OCAwIDAgMCA3MjIgNTAwIDUwMCA1MDAgMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDAgNDQ0XS9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjUgMCBvYmoNPDwvTnVtc1swIDI2IDAg Ul0+Pg1lbmRvYmoNMjYgMCBvYmoNPDwvUy9EPj4NZW5kb2JqDTI3IDAgb2JqDTw8L0NvdW50IDQv VHlwZS9QYWdlcy9LaWRzWzMyIDAgUiAxIDAgUiA5IDAgUiAxMiAwIFJdPj4NZW5kb2JqDTI4IDAg b2JqDTw8L1N1YnR5cGUvWE1ML0xlbmd0aCAzNjA1L1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNC4w LWMzMTYgNDQuMjUzOTIxLCBTdW4gT2N0IDAxIDIwMDYgMTc6MTQ6MzkiPgogICA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAgICAgICA8eGFwOkNyZWF0b3JUb29s PlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4 YXA6TW9kaWZ5RGF0ZT4yMDA5LTA2LTA5VDEyOjUwOjE5LTA3OjAwPC94YXA6TW9kaWZ5RGF0ZT4K ICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDktMDYtMDlUMTI6NTA6MTktMDc6MDA8L3hhcDpD cmVhdGVEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZv cm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAg ICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5NaWNyb3NvZnQgV29yZCAtIEVTQjJf QlNEX1N0YXRlbWVudC5kb2M8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAg ICA8L2RjOnRpdGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+ CiAgICAgICAgICAgICAgIDxyZGY6bGk+bWZzdHJhdHQ8L3JkZjpsaT4KICAgICAgICAgICAgPC9y ZGY6U2VxPgogICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFj cm9iYXQgRGlzdGlsbGVyIDguMC4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3Jk ZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAg ICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAg ICAgICA8eGFwTU06RG9jdW1lbnRJRD51dWlkOjJmMzM1OTY5LWViZDEtNDMyYy1iY2JmLTFjZjk0 YjZhZDY5YTwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVp ZDpiMzc4MmY5My03Y2MxLTQxZmEtOTk0OS03MTJjMmZhNDA3MzQ8L3hhcE1NOkluc3RhbmNlSUQ+ CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tl dCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmoNPDwvQ3JlYXRpb25EYXRlKEQ6 MjAwOTA2MDkxMjUwMTktMDcnMDAnKS9BdXRob3IobWZzdHJhdHQpL0NyZWF0b3IoUFNjcmlwdDUu ZGxsIFZlcnNpb24gNS4yLjIpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDguMC4wIFwoV2lu ZG93c1wpKS9Nb2REYXRlKEQ6MjAwOTA2MDkxMjUwMTktMDcnMDAnKS9UaXRsZShNaWNyb3NvZnQg V29yZCAtIEVTQjJfQlNEX1N0YXRlbWVudC5kb2MpPj4NZW5kb2JqDXhyZWYNCjAgMzANCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwNjM0OSAwMDAwMCBuDQowMDAwMDA2NDc2IDAwMDAwIG4NCjAw MDAwMDY2MTggMDAwMDAgbg0KMDAwMDAwODkxNSAwMDAwMCBuDQowMDAwMDEyNjY4IDAwMDAwIG4N CjAwMDAwMTI4OTYgMDAwMDAgbg0KMDAwMDAxMzEwMCAwMDAwMCBuDQowMDAwMDEzMzg3IDAwMDAw IG4NCjAwMDAwMTM2MjAgMDAwMDAgbg0KMDAwMDAxMzc0OSAwMDAwMCBuDQowMDAwMDEzOTE4IDAw MDAwIG4NCjAwMDAwMTc2NzAgMDAwMDAgbg0KMDAwMDAxNzgwMCAwMDAwMCBuDQowMDAwMDE3OTY4 IDAwMDAwIG4NCjAwMDAwMTk5MTcgMDAwMDAgbg0KMDAwMDAyMDA0NiAwMDAwMCBuDQowMDAwMDIw MjAzIDAwMDAwIG4NCjAwMDAwMjA0NTIgMDAwMDAgbg0KMDAwMDAyMDg5MyAwMDAwMCBuDQowMDAw MDIxMTQ5IDAwMDAwIG4NCjAwMDAwMjE0MTAgMDAwMDAgbg0KMDAwMDAyMTQ0NSAwMDAwMCBuDQow MDAwMDI0MTM4IDAwMDAwIG4NCjAwMDAwMjQ0MzMgMDAwMDAgbg0KMDAwMDAyNDgyOCAwMDAwMCBu DQowMDAwMDI0ODY0IDAwMDAwIG4NCjAwMDAwMjQ4ODkgMDAwMDAgbg0KMDAwMDAyNDk2MSAwMDAw MCBuDQowMDAwMDI4NjQ0IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMzA+Pg0Kc3RhcnR4cmVm DQoxMTYNCiUlRU9GDQo= --000e0cd28cf08b4e89046c29b00f-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:40:07 2009 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 CB7051065694; Fri, 12 Jun 2009 17:40:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 75E4A8FC1F; Fri, 12 Jun 2009 17:40:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0971D41C70A; Fri, 12 Jun 2009 19:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id bOG0OlR42a1t; Fri, 12 Jun 2009 19:40:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9A88441C730; Fri, 12 Jun 2009 19:40:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 6660E4448E6; Fri, 12 Jun 2009 17:38:46 +0000 (UTC) Date: Fri, 12 Jun 2009 17:38:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Navdeep Parhar In-Reply-To: <20090612170703.GA994@hub.freebsd.org> Message-ID: <20090612173728.B22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 17:40:08 -0000 On Fri, 12 Jun 2009, Navdeep Parhar wrote: > On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: >> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: >> >> Hi, >> >>> Yeah, there are no checksum offloading support for IPv6 under >>> FreeBSD so there are no cases the frames are IPv6 when >>> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. >> >> The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). >> >> What I had missed was the CSUM_TSO6 (the 6 at the end) part. >> grepping through the tree I am even wondering a lot more now when I >> see what cxgb(4) is doing with that;) > > I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? yes I did. > cxgb(4) > will not let you enable IFCAP_TSO6 on the interface. It has always > been disallowed as far as I can tell. Yes, you have it in the logic bu you define it to 0;) #define IFCAP_TSO6 0x0 /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:45:07 2009 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 2671C106566B for ; Fri, 12 Jun 2009 17:45:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D37058FC14 for ; Fri, 12 Jun 2009 17:45:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2AFE941C759; Fri, 12 Jun 2009 19:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id uuswp9nVMFJ0; Fri, 12 Jun 2009 19:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BBA0841C758; Fri, 12 Jun 2009 19:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2363E4448E6; Fri, 12 Jun 2009 17:42:40 +0000 (UTC) Date: Fri, 12 Jun 2009 17:42:40 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Gallatin In-Reply-To: <4A3260BD.4040307@myri.com> Message-ID: <20090612173855.T22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <4A3260BD.4040307@myri.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 17:45:07 -0000 On Fri, 12 Jun 2009, Andrew Gallatin wrote: > Bjoern A. Zeeb wrote: > >>> As a sort of side-note, what about feature parity for INET6 for >>> existing IPV4 features like TSO? Who is working on that? >> >> Ok, maybe we should write down the big list now. What all can we have? >> What do we already have? What do we need? What needs to be changed? >> >> IPv4 CSUM offloading >> ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 >> We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a >> different CSUM_* subset for each card, right? >> >> We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. >> What will that be? insert "need to" before "be" > I'm not sure what you mean by this. > > Right now, at least on the receive side, tcp_input() for IPv6 > is completely ignoring ULP csum values sent up by drivers. > > > >> TSO v4/v6 >> We do have IFCAP_TSO4|IFCAP_TSO6 >> >> We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll >> need to add CSUM_TSO6? > > Cool! I had no idea that IFCAP_TSO6 was used, but apparently it is. > When I get a chance to work on FreeBSD, I guess I'll flip that > bit on in mxge and see if I actually get any packets with CSUM_TSO > set. > > It would be helpful to have a CSUM_TSO{4,6} to reduce packet parsing. > But as yongari pointed out, its fairly silly to make drivers parse the > packets that the stack is sending them, and it would be ideal if > we could easily pull the information from somewhere. Yes, all for that; that's why we are talking about thing. Not sure what will make sense; perhaps we'll need to see what you all actually need for all the drivers and combinations? -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:50:07 2009 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 473211065672 for ; Fri, 12 Jun 2009 17:50:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0176B8FC1F for ; Fri, 12 Jun 2009 17:50:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4BECF41C795; Fri, 12 Jun 2009 19:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 17Yt36L9yzNO; Fri, 12 Jun 2009 19:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id CB98A41C75A; Fri, 12 Jun 2009 19:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id F3AEF4448E6; Fri, 12 Jun 2009 17:45:57 +0000 (UTC) Date: Fri, 12 Jun 2009 17:45:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Gallatin In-Reply-To: <4A325883.3050206@cs.duke.edu> Message-ID: <20090612174248.X22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <4A325883.3050206@cs.duke.edu> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 17:50:07 -0000 On Fri, 12 Jun 2009, Andrew Gallatin wrote: Hi, > Bjoern A. Zeeb wrote: > >> if_mxge: >> ---------------------------------------- >> mxge_rx_csum() has one in_pseudo(). The function and callers >> already seem to know how do deal with results in case the csum can't >> be validated. So this should be a simple #ifdef INET wrapping here; >> side note: the tcpudp_csum variables in the callers are not needed. >> side note: huge inlining going on there;) >> mxge_lro_flush() has another call to in_pseudo(). As with if_igb/ixgbe > > Thanks for pointing those out. It will be a few days before > I've got time to deal with it properly. If you don't see > me commit a fix within a week, please remind me. Well do not rush it; it's been like that for ages; we may first want to get infrastructure etc. in place to better fix all those maybe? It's just that it won't be forgotten in 3 months;-) >> if there is no INET there should be no LRO for now, the capabilities >> not advertised, etc. Be prepared in case LRO will arrive for IPv6. > > As to LRO & IPV6... I was going to port our LRO for IPv6, > but discovered the state of IPv6 in FreeBSD is so disgraceful > that there was no point. Eg, there is no checksum offload, > no TSO, etc, for INET6. Once those things are there, I'll > be happy to provide LRO for IPv6. With "port our LRO" you mean the driver parts? So how much does the FreeBSD infrastructure for LRO/v4 help and work for you (and the others)? Would adding v6 support there help? I will have to have a look but I can work on those things (propably post-RC1 or so). Till then a few other things still need my attention. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:43:50 2009 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 BD2CC106567E; Fri, 12 Jun 2009 17:43:50 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4E55A8FC14; Fri, 12 Jun 2009 17:43:50 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n5CHhnpP018829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 13:43:49 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n5CHhnpP018829 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1244828629; bh=TdoTaqvJVmPZd25zZAlOZW+v7NBCOH+NgiPp8XE708U=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QLLvm1etWUr0b8COm2fRtdoWt97b8YJ3j9RE8q/xIMkpA9UUmmKywHqRbZnwkiHLO tD6RV5Sxrw1TUGuO+NLf0l4L1Fg7+BPDwfA5873Dh8ZcWGlRXKJ1RvSZKygCfr//HD pQVwBeBE0klKjPj8x8kiLpNCWPO8tTB3BVmOiErA= Message-ID: <4A3293C8.5070101@cs.duke.edu> Date: Fri, 12 Jun 2009 13:43:36 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> In-Reply-To: <20090612173728.B22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 12 Jun 2009 18:02:39 +0000 Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Navdeep Parhar , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 17:43:53 -0000 Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Navdeep Parhar wrote: > >> On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: >>> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: >>> >>> Hi, >>> >>>> Yeah, there are no checksum offloading support for IPv6 under >>>> FreeBSD so there are no cases the frames are IPv6 when >>>> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. >>> >>> The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). >>> >>> What I had missed was the CSUM_TSO6 (the 6 at the end) part. >>> grepping through the tree I am even wondering a lot more now when I >>> see what cxgb(4) is doing with that;) >> >> I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? > > yes I did. > >> cxgb(4) >> will not let you enable IFCAP_TSO6 on the interface. It has always >> been disallowed as far as I can tell. > > Yes, you have it in the logic bu you define it to 0;) > #define IFCAP_TSO6 0x0 So I guess TSO6 has never been tested at all on any interface on Freebsd. Is this true? Drew From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 18:19:43 2009 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 7EBD8106564A; Fri, 12 Jun 2009 18:19:43 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 35A218FC2C; Fri, 12 Jun 2009 18:19:43 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n5CIJgb4020743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 14:19:42 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n5CIJgb4020743 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1244830782; bh=fcQFWi4cnhnrLHUpBIpgrdaWX2Bhm4UG/QLHVJRmz1s=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ElGyYvNoDRmDjV/VwjRzd8pJp2Btql8mGGaJLUp5xIP2DIcL3R5Jn7L4Db55EsbHR RhzdYTBtyVNsZrab9/OguWqcTaAZRlM3CYxtzWDOJzlfvdZqR5b4MKjY7Y/vkJ/XNA CMYAarAQUoAx1U8cBerdtW5y9g1jKFcBXz68Y4y8= Message-ID: <4A329C38.2040808@cs.duke.edu> Date: Fri, 12 Jun 2009 14:19:36 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <4A325883.3050206@cs.duke.edu> <20090612174248.X22887@maildrop.int.zabbadoz.net> In-Reply-To: <20090612174248.X22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 18:19:43 -0000 Bjoern A. Zeeb wrote: >>> if there is no INET there should be no LRO for now, the capabilities >>> not advertised, etc. Be prepared in case LRO will arrive for IPv6. >> >> As to LRO & IPV6... I was going to port our LRO for IPv6, >> but discovered the state of IPv6 in FreeBSD is so disgraceful >> that there was no point. Eg, there is no checksum offload, >> no TSO, etc, for INET6. Once those things are there, I'll >> be happy to provide LRO for IPv6. > > With "port our LRO" you mean the driver parts? So how much does the > FreeBSD infrastructure for LRO/v4 help and work for you (and the > others)? Would adding v6 support there help? For "port our LRO", I actually meant the LRO code itself, the IPv4 version of which was originally contributed by my employer (Myricom). Notice sys/netinet/tcp_lro.c is sys/dev/mxge/mxge_lro.c ported to be a bit more generic by Jack when he wanted LRO for ixgbe. The mxge LRO is shared among a few of our drivers for other OSes, and at least one has grown support for LRO for IPv6, so that should be trivial to port to FreeBSD. The thing I really need to do is convert mxge to use tcp_lro.c and remove mxge_lro.c. I've just been too busy. As to how much it helps.. I've seen some machines go from 3Gb/s to line rate (9.4Gb/s) for 1500b recieves. Drew From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 18:24:04 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id DF61A106566B; Fri, 12 Jun 2009 18:24:04 +0000 (UTC) Date: Fri, 12 Jun 2009 18:24:04 +0000 From: Navdeep Parhar To: "Bjoern A. Zeeb" Message-ID: <20090612182404.GA20035@hub.freebsd.org> Mail-Followup-To: "Bjoern A. Zeeb" , Pyun YongHyeon , FreeBSD net mailing list , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon , "George V. Neville-Neil" References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090612173728.B22887@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.1i Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 18:24:05 -0000 On Fri, Jun 12, 2009 at 05:38:46PM +0000, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Navdeep Parhar wrote: > > >On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: > >>On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > >> > >>Hi, > >> > >>>Yeah, there are no checksum offloading support for IPv6 under > >>>FreeBSD so there are no cases the frames are IPv6 when > >>>CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > >> > >>The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > >> > >>What I had missed was the CSUM_TSO6 (the 6 at the end) part. > >>grepping through the tree I am even wondering a lot more now when I > >>see what cxgb(4) is doing with that;) > > > >I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? > > yes I did. > > >cxgb(4) > >will not let you enable IFCAP_TSO6 on the interface. It has always > >been disallowed as far as I can tell. > > Yes, you have it in the logic bu you define it to 0;) > #define IFCAP_TSO6 0x0 Not quite. TSO_SUPPORTED is defined and so cxgb(4) picks up the right values of IFCAP_TSO4 and IFCAP_TSO6. It's just that IFCAP_TSO6 is not in the enabled-by-default capabilities (CXGB_CAP_ENABLE), and cxgb_ioctl will not let you enable IFCAP_TSO6. cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the way they are. If the stack's tso6 works, then this is a bug in cxgb. Regards, Navdeep > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:50:07 2009 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 E2F96106564A; Fri, 12 Jun 2009 17:50:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED828FC23; Fri, 12 Jun 2009 17:50:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C9D6F41C750; Fri, 12 Jun 2009 19:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id mQZnggT-L8DY; Fri, 12 Jun 2009 19:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D2E2F41C76D; Fri, 12 Jun 2009 19:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 04D804448E6; Fri, 12 Jun 2009 17:49:12 +0000 (UTC) Date: Fri, 12 Jun 2009 17:49:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Gallatin In-Reply-To: <4A3293C8.5070101@cs.duke.edu> Message-ID: <20090612174706.N22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> <4A3293C8.5070101@cs.duke.edu> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 12 Jun 2009 18:26:23 +0000 Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Navdeep Parhar , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 17:50:08 -0000 On Fri, 12 Jun 2009, Andrew Gallatin wrote: > Bjoern A. Zeeb wrote: >> On Fri, 12 Jun 2009, Navdeep Parhar wrote: >> >>> On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: >>>> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: >>>> >>>> Hi, >>>> >>>>> Yeah, there are no checksum offloading support for IPv6 under >>>>> FreeBSD so there are no cases the frames are IPv6 when >>>>> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. >>>> >>>> The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). >>>> >>>> What I had missed was the CSUM_TSO6 (the 6 at the end) part. >>>> grepping through the tree I am even wondering a lot more now when I >>>> see what cxgb(4) is doing with that;) >>> >>> I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? >> >> yes I did. >> >>> cxgb(4) >>> will not let you enable IFCAP_TSO6 on the interface. It has always >>> been disallowed as far as I can tell. >> >> Yes, you have it in the logic bu you define it to 0;) >> #define IFCAP_TSO6 0x0 > > So I guess TSO6 has never been tested at all on any interface on > Freebsd. Is this true? I wan't not sure; looking at em_tso_setup() in sys/dev/e1000/if_em.c, there was v6 code as well; the I spotted the return FALSE; So I guess, you are right; noone ever did TSO6 on FreeBSD probably. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 18:40:07 2009 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 B72AC1065672; Fri, 12 Jun 2009 18:40:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 62A208FC23; Fri, 12 Jun 2009 18:40:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 28A9A41C729; Fri, 12 Jun 2009 20:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id vqE63vBqGLFp; Fri, 12 Jun 2009 20:40:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id A779241C712; Fri, 12 Jun 2009 20:40:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id F3BB84448E6; Fri, 12 Jun 2009 18:35:37 +0000 (UTC) Date: Fri, 12 Jun 2009 18:35:37 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Navdeep Parhar In-Reply-To: <20090612182404.GA20035@hub.freebsd.org> Message-ID: <20090612183349.B22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> <20090612182404.GA20035@hub.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 18:40:08 -0000 On Fri, 12 Jun 2009, Navdeep Parhar wrote: Hi, >>> cxgb(4) >>> will not let you enable IFCAP_TSO6 on the interface. It has always >>> been disallowed as far as I can tell. >> >> Yes, you have it in the logic bu you define it to 0;) >> #define IFCAP_TSO6 0x0 > > Not quite. TSO_SUPPORTED is defined and so cxgb(4) picks up the > right values of IFCAP_TSO4 and IFCAP_TSO6. It's just that IFCAP_TSO6 > is not in the enabled-by-default capabilities (CXGB_CAP_ENABLE), and > cxgb_ioctl will not let you enable IFCAP_TSO6. > > cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the > way they are. If the stack's tso6 works, then this is a bug in > cxgb. Oki, I think once this all has settled we'll be able to text it on cxgb as well; let us get the infrastructure shaken out first. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 20:10:03 2009 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 56F85106564A for ; Fri, 12 Jun 2009 20:10:03 +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 447658FC0C for ; Fri, 12 Jun 2009 20:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5CKA3lT049630 for ; Fri, 12 Jun 2009 20:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5CKA37i049629; Fri, 12 Jun 2009 20:10:03 GMT (envelope-from gnats) Date: Fri, 12 Jun 2009 20:10:03 GMT Message-Id: <200906122010.n5CKA37i049629@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Ted Mittelstaedt Cc: Subject: Re: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ted Mittelstaedt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 20:10:03 -0000 The following reply was made to PR kern/125195; it has been noted by GNATS. From: Ted Mittelstaedt To: bug-followup@FreeBSD.org, francisgendreau@videotron.ca Cc: Subject: Re: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Date: Fri, 12 Jun 2009 13:07:50 -0700 Some more followup - I moved my own problem fxp0 card to a FreeBSD 4.11-RELEASE system and it is detected fine, no "MII without any PHY" error message. The system that I was getting the "MII without any PHY" error message on was a FreeBSD 6.4 system. The problem fxp0 card is an Intel Etherexpress Pro/100, with a S82557 chip on it. Since it is a standalone PCI card and not embedded on the motherboard I can exchange it easily, - if anyone would like it for debugging I'd be happy to send them my card in the mail. To Francis, if possible could you download an older version of FreeBSD and check it on your hardware? You can find older versions here: ftp://ftp.cse.buffalo.edu/pub/FreeBSD-Archive/old-releases/i386/ISO-IMAGES/ The really old versions, ie: 4.11 and such, only have full-blown install ISO's and may also lack PCI IDs for your chip in which case the card wouldn't even be detected at all. But, the newer versions like 5.5 and so on do have boot-only ISO CD images which shouldn't be that bad. If an older driver version detects your card and attaches without the error message, we can assume this is a bug introduced by one of the patches to the driver, and it should be easy to zero in to the patch that is responsible. From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 21:16:01 2009 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 EBD0D106564A; Fri, 12 Jun 2009 21:16:01 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from dvz-002.fh-muenster.de (dvz-002.FH-Muenster.DE [193.174.88.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C10E8FC0A; Fri, 12 Jun 2009 21:16:01 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by dvz-002.fh-muenster.de (Postfix) with ESMTP id 195781CC4EA; Fri, 12 Jun 2009 22:55:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at dvz-002.fh-muenster.de X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.665, BAYES_00=-2.312] Received: from dvz-002.fh-muenster.de ([127.0.0.1]) by localhost (dvz-002.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDfzrqFCTcv9; Fri, 12 Jun 2009 22:55:56 +0200 (CEST) Received: from [192.168.1.100] (p508FEA6E.dip.t-dialin.net [80.143.234.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by dvz-002.fh-muenster.de (Postfix) with ESMTP id A33431CC4C9; Fri, 12 Jun 2009 22:55:55 +0200 (CEST) Message-Id: <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> From: Michael Tuexen To: Bjoern A. Zeeb In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 22:57:56 +0200 References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.935.3) Cc: Pyun YongHyeon , FreeBSD net mailing list , "George V. Neville-Neil" , Navdeep Parhar , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 12 Jun 2009 21:16:02 -0000 On Jun 12, 2009, at 12:56 PM, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > > Hi, > >> Yeah, there are no checksum offloading support for IPv6 under >> FreeBSD so there are no cases the frames are IPv6 when >> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > > The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > > What I had missed was the CSUM_TSO6 (the 6 at the end) part. > grepping through the tree I am even wondering a lot more now when I > see what cxgb(4) is doing with that;) > > >>> In case you are maintaining another driver but cannot find it on the >>> list - be sure we'll find you during the 9.x lifecycle in case you >>> do >>> not properly handle things;-) >>> >> >> [ list of drivers part removed ] >> >> I guess you missed hme(4) and gem(4) in the list and most old > > Nope, both have a hand crafted way of computing the cksums; not sure > if that is good or bad; I guess the latter but with that they were not > running into the INET dependency problematic I cared about in this > pass. > > >> hardwares that supports checksum offloading have no capability to >> handle IPv6 checksum offloading. If we do not define appropriate >> capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, >> IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be >> hard to change code, I guess. > > There is no such things as an IPv6 cksum. For IPv6 you only care about > ULPs. > > > I am not entirely sure (as in I forgot; it's been a month;) but > Michael Tuexen (new comitter) is working on the proper flags im along > with one for SCTP; The part I am usure about was if he only cared > about CSUM first and not IFCAP but really both have to come along. > > What was the plan here? Michael, can you fill this gap (perhaps > below)? Sure. See my comments below. > > > To also address Drew's question: > >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? Yes. Currently some driver would do CSUM_IP|CSUM_TCP|CSUM_UDP. The igb driver currently does CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP. > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I think we should keep CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP which are for IPv4. In addition we need new flags CSUM_TCP6, CSUM_UDP6, CSUM_SCTP6 which are only for IPv6. After the change the igb driver would announce CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP|CSUM_TCP6|CSUM_UDP6|CSUM_SCTP6. The network layer and transport layer has to be changed accordingly. My plan is to provide the infrastructure and test it with the igb driver. After that is in the repository, other drivers have to be changed to announce their appropriate capabilities. I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 capabilities... Why would we want to enable IPv4 offloading and not IPv6 or vice versa? > > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? > > LRO v4/v6 (is anyone doing or planning to and can talk about it, > LRO v6?) > We do have IFCAP_LRO. > > TOE -- how much is that tied into IPv4/v6 and how much general > infrastructure, rather than per-card, could a world need? > We do have IFCAP_TOE = (IFCAP_TOE4|IFCAP_TOE6) > > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking > one. > _______________________________________________ > 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 Sat Jun 13 00:48:47 2009 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 17EC7106564A; Sat, 13 Jun 2009 00:48:47 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id C93738FC13; Sat, 13 Jun 2009 00:48:46 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n5D0mN4P009407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 20:48:24 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n5D0mN4P009407 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1244854104; bh=IUXgSerfb1o9zwqXw09pzvq2QmO4rLg3X7H+l/2feVU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RwlR8OtkY6vrwUi8VwGZF/HoBJwmJEE7x4oxxoL+e+y7FqU/eSzprGsPOKn+MoRKD HxX31FPBlNIXJ3MHeeBNB3WKpfoV3R38PMW8pp3Owgim2Od6L4TyrBoUTjrh7v5+dW ej6FfoKrk6iRgv/AwMAppE/udpFzcpgYfCMpqF+s= Message-ID: <4A32F752.90003@cs.duke.edu> Date: Fri, 12 Jun 2009 20:48:18 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Michael Tuexen References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> In-Reply-To: <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 00:48:47 -0000 Michael Tuexen wrote: > I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > capabilities... Why would we want to enable IPv4 offloading and > not IPv6 or vice versa? I'd assume that some older hardware supports IPv4 offloads, but might not have support for IPv6 offloads. Drew From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 01:11:59 2009 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 6AFF11065673; Sat, 13 Jun 2009 01:11:59 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 42D2C8FC12; Sat, 13 Jun 2009 01:11:59 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5D1Bv6G089986; Sat, 13 Jun 2009 01:11:57 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5D1BvOc089982; Sat, 13 Jun 2009 01:11:57 GMT (envelope-from yongari) Date: Sat, 13 Jun 2009 01:11:57 GMT Message-Id: <200906130111.n5D1BvOc089982@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB 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, 13 Jun 2009 01:11:59 -0000 Synopsis: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Jun 13 01:11:35 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=125195 From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 05:48:41 2009 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 79F63106564A; Sat, 13 Jun 2009 05:48:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id B98598FC18; Sat, 13 Jun 2009 05:48:40 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1463193ana.13 for ; Fri, 12 Jun 2009 22:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=gfYN4QPHsHjQgNd1VwcGajzct1iA7cMlweyGXobQCww=; b=YpNW10hVR2TuRW1dKfr+X2Fx5EiEX2gtQMrlcQCp4e1XHYkupmZstbx6thZSgfmpHx C2uIAofdSWwXK/P3Q4M9uSodmY47bPxaCKidFsORGMunQRu1P5c+wiCDuQckBsNb48Ka Rkm5hGel+NvIMOkuEBUyBAqMOQFZ4Ek5GbnV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=BRUrrutJm4YNIVTzDTYOjRp+LaF9GW+4Y3zetgXq7dF5oAXYnQV7/St/tABu7xyLZ/ 6ahUkhFknkzYWuQLY8EOj9YXGaOnIl6ntcLk64/YPKw6PDiVgefd19FKqCHwuA1HOneX T/8eINCzO3yiIBW6gnQ6r+ZHVZD6x9sHwE7mM= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.152.1 with SMTP id z1mr5942490and.69.1244872120052; Fri, 12 Jun 2009 22:48:40 -0700 (PDT) In-Reply-To: <20090612182404.GA20035@hub.freebsd.org> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> <20090612182404.GA20035@hub.freebsd.org> Date: Fri, 12 Jun 2009 22:48:40 -0700 X-Google-Sender-Auth: 25f36e3cf7f7c9c9 Message-ID: <3c1674c90906122248i253fd70t8330dd050279baa2@mail.gmail.com> From: Kip Macy To: "Bjoern A. Zeeb" , Pyun YongHyeon , FreeBSD net mailing list , Michael Tuexen , Andrew Thompson , Jack F Vogel , Andrew Gallatin , Pyun YongHyeon , "George V. Neville-Neil" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 05:48:41 -0000 > cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the > way they are. =A0If the stack's tso6 works, then this is a bug in > cxgb. > It may not have supported it when the driver was ported - I know it didn't do v6 RSS. -Kip From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 07:15:09 2009 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 73DFE106564A for ; Sat, 13 Jun 2009 07:15:09 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from dvz-002.fh-muenster.de (mail.FH-Muenster.DE [193.174.88.2]) by mx1.freebsd.org (Postfix) with ESMTP id 283758FC1F for ; Sat, 13 Jun 2009 07:15:08 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by dvz-002.fh-muenster.de (Postfix) with ESMTP id 8341E1CC5CD; Sat, 13 Jun 2009 09:13:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at dvz-002.fh-muenster.de X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.665, AWL=-0.000, BAYES_00=-2.312] Received: from dvz-002.fh-muenster.de ([127.0.0.1]) by localhost (dvz-002.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLkDnjifmuiD; Sat, 13 Jun 2009 09:13:05 +0200 (CEST) Received: from [192.168.1.100] (p508FEA6E.dip.t-dialin.net [80.143.234.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by dvz-002.fh-muenster.de (Postfix) with ESMTP id CF9D81CC5C7; Sat, 13 Jun 2009 09:13:04 +0200 (CEST) Message-Id: From: Michael Tuexen To: Andrew Gallatin In-Reply-To: <4A32F752.90003@cs.duke.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 09:15:06 +0200 References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD net mailing list Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 07:15:09 -0000 On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: > Michael Tuexen wrote: > > > I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > > capabilities... Why would we want to enable IPv4 offloading and > > not IPv6 or vice versa? > > I'd assume that some older hardware supports IPv4 offloads, but > might not have support for IPv6 offloads. Sure. But then the driver only provides the CSUM_ flags which are appropriate. For example, a similar thing is already in the igb driver: 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); 1169 #if __FreeBSD_version >= 800000 1170 if (adapter->hw.mac.type == e1000_82576) 1171 ifp->if_hwassist |= CSUM_SCTP; 1172 #endif 1173 } For FreeBSD 8 and a particular chip, SCTP checksum offloading is supported. No need for a special IFCAP_TXCSUM. Best regards Michael > > Drew From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 07:58:42 2009 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 76FB91065674; Sat, 13 Jun 2009 07:58:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 3B57D8FC39; Sat, 13 Jun 2009 07:58:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pzk35 with SMTP id 35so1721288pzk.3 for ; Sat, 13 Jun 2009 00:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=2Dsax8gZtQcVXXRFVop7NLtJqNRkBwSlc2op1BxPVq4=; b=fTObudEuulNY2B+9hrGh1aHCIpnrFjTP446UGGH/NPxDrTsbiSF1AZgCInXhKiCnOI u9u/s+TNtStDcWYji+DCk3e8p44Yy+AhD6rSGZ0oLm/VdC5C7+g99eHcl34pDS/DqRU2 /S9/IqRcgFNylptnuh78NZHMugqRehLuqmmzE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=REgqW1bLB1RHv/uwca/9BaG1Jr/+SMmbjKi89tH1ItJu8fVlJ4rgXmLLJJKR6AiKep o7L2KR0yvEpLBRPySY7bCzcP/YAgQMUVIp8C3SPnEWC1RlTAuzoQBkSuenFbD9un7/bs pvy1XdhOzFqFznqU0DCMIo39/Ge0Sw3s+YyYs= Received: by 10.115.106.14 with SMTP id i14mr7631180wam.77.1244879921624; Sat, 13 Jun 2009 00:58:41 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id m28sm2181937waf.37.2009.06.13.00.58.37 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Jun 2009 00:58:38 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 13 Jun 2009 17:01:36 +0900 From: Pyun YongHyeon Date: Sat, 13 Jun 2009 17:01:36 +0900 To: Michael Tuexen Message-ID: <20090613080136.GB76872@michelle.cdnetworks.co.kr> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD net mailing list , Andrew Gallatin Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 07:58:42 -0000 On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: > On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: > > >Michael Tuexen wrote: > > > >> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > >> capabilities... Why would we want to enable IPv4 offloading and > >> not IPv6 or vice versa? > > > >I'd assume that some older hardware supports IPv4 offloads, but > >might not have support for IPv6 offloads. > Sure. But then the driver only provides the CSUM_ flags which > are appropriate. For example, a similar thing is already in the > igb driver: > > 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { > 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); > 1169 #if __FreeBSD_version >= 800000 > 1170 if (adapter->hw.mac.type == e1000_82576) > 1171 ifp->if_hwassist |= CSUM_SCTP; > 1172 #endif > 1173 } That would disable all IPv4/IPv6 checksum offloading if administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ IFCAP_RXCSUM6 users could choose best working one even if some part of driver/controller had checksum offload bugs. > > For FreeBSD 8 and a particular chip, SCTP checksum offloading > is supported. No need for a special IFCAP_TXCSUM. > > Best regards > Michael > > > > >Drew > From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 08:25:22 2009 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 13AEF106566C for ; Sat, 13 Jun 2009 08:25:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id CE9828FC1E for ; Sat, 13 Jun 2009 08:25:21 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by pzk35 with SMTP id 35so1729172pzk.3 for ; Sat, 13 Jun 2009 01:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7KLG1L2Dr6ryuykZZD77hPziPxxKO1HB93mijrcWI48=; b=fWPYdJ6zU/FtPzCXFHw5dzky8d0JjCfZaNmesHBCqT/5yJPTg7jcrj92kZ5OePjAnr Ne2V61C42m2kOcNpn9TZIdcMspSX3BZN8ZnXBADAVFlE6GFE+BPdYEYuOJs61ctd3tzk Vf7034UfY4YHsPBIrirsh/TKY9mz1x7CotOz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cw10yTD4jPrten0SXpZ5Vxoky5BtNnK0OIkYKisYk4Rg+V858U4WQawqjSIjSNM78A VfnrIpyw/QMt0xbTul9BiGPINiol3HWLBljVsf9JRpoXuKnw9ohFMAGb9/XngiFq8LSI ClXDPMadb+qhIjkdhkRHtcpV1rM4K9MbXX03Q= MIME-Version: 1.0 Received: by 10.142.44.14 with SMTP id r14mr2014515wfr.221.1244881521537; Sat, 13 Jun 2009 01:25:21 -0700 (PDT) In-Reply-To: <20090613080136.GB76872@michelle.cdnetworks.co.kr> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> Date: Sat, 13 Jun 2009 01:25:21 -0700 Message-ID: <2a41acea0906130125u4f6f6124l77e6115264ffb305@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD net mailing list , Michael Tuexen , Andrew Gallatin Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 08:25:22 -0000 I agree with Michael, I don't want to see this proliferation of capabilities, if you want checksum offload you get it whatever the IP type. Jack On Sat, Jun 13, 2009 at 1:01 AM, Pyun YongHyeon wrote: > On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: > > On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: > > > > >Michael Tuexen wrote: > > > > > >> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > > >> capabilities... Why would we want to enable IPv4 offloading and > > >> not IPv6 or vice versa? > > > > > >I'd assume that some older hardware supports IPv4 offloads, but > > >might not have support for IPv6 offloads. > > Sure. But then the driver only provides the CSUM_ flags which > > are appropriate. For example, a similar thing is already in the > > igb driver: > > > > 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { > > 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); > > 1169 #if __FreeBSD_version >= 800000 > > 1170 if (adapter->hw.mac.type == e1000_82576) > > 1171 ifp->if_hwassist |= CSUM_SCTP; > > 1172 #endif > > 1173 } > > That would disable all IPv4/IPv6 checksum offloading if > administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ > IFCAP_RXCSUM6 users could choose best working one even if some part > of driver/controller had checksum offload bugs. > > > > > For FreeBSD 8 and a particular chip, SCTP checksum offloading > > is supported. No need for a special IFCAP_TXCSUM. > > > > Best regards > > Michael > > > > > > > >Drew > > > _______________________________________________ > 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 Sat Jun 13 08:26:13 2009 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 4C30C1065678 for ; Sat, 13 Jun 2009 08:26:13 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from dvz-002.fh-muenster.de (mail.FH-Muenster.DE [193.174.88.2]) by mx1.freebsd.org (Postfix) with ESMTP id C7C718FC0C for ; Sat, 13 Jun 2009 08:26:12 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by dvz-002.fh-muenster.de (Postfix) with ESMTP id 52F051CC5C5; Sat, 13 Jun 2009 10:24:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at dvz-002.fh-muenster.de X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.665, BAYES_00=-2.312] Received: from dvz-002.fh-muenster.de ([127.0.0.1]) by localhost (dvz-002.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY7zStaIp6nZ; Sat, 13 Jun 2009 10:24:08 +0200 (CEST) Received: from [192.168.1.100] (p508FEA6E.dip.t-dialin.net [80.143.234.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by dvz-002.fh-muenster.de (Postfix) with ESMTP id 53ABE1CC5B5; Sat, 13 Jun 2009 10:24:08 +0200 (CEST) Message-Id: <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> From: Michael Tuexen To: pyunyh@gmail.com In-Reply-To: <20090613080136.GB76872@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 10:26:09 +0200 References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD net mailing list , Andrew Gallatin Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 08:26:13 -0000 On Jun 13, 2009, at 10:01 AM, Pyun YongHyeon wrote: > On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: >> On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: >> >>> Michael Tuexen wrote: >>> >>>> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 >>>> capabilities... Why would we want to enable IPv4 offloading and >>>> not IPv6 or vice versa? >>> >>> I'd assume that some older hardware supports IPv4 offloads, but >>> might not have support for IPv6 offloads. >> Sure. But then the driver only provides the CSUM_ flags which >> are appropriate. For example, a similar thing is already in the >> igb driver: >> >> 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { >> 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); >> 1169 #if __FreeBSD_version >= 800000 >> 1170 if (adapter->hw.mac.type == e1000_82576) >> 1171 ifp->if_hwassist |= CSUM_SCTP; >> 1172 #endif >> 1173 } > > That would disable all IPv4/IPv6 checksum offloading if > administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ > IFCAP_RXCSUM6 users could choose best working one even if some part > of driver/controller had checksum offload bugs. Sure. That is what I wrote in my earlier mail: Do we want to provide a ability to disable/enable checksum offload for IPv4 and IPv6 individually... Besides this "working around bugs" I see no reason to do it. Some other capabilities TSO/TOE are IPv[46] specific. I have no strong opinion on this. What do others think? Best regards Michael > >> >> For FreeBSD 8 and a particular chip, SCTP checksum offloading >> is supported. No need for a special IFCAP_TXCSUM. >> >> Best regards >> Michael >> >>> >>> Drew >> From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 08:50:08 2009 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 475B9106566B; Sat, 13 Jun 2009 08:50:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id CA6308FC19; Sat, 13 Jun 2009 08:50:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 65DE841C735; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ZgrLVfaFPcmc; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id EF8F341C71D; Sat, 13 Jun 2009 10:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B3D104448E6; Sat, 13 Jun 2009 08:48:39 +0000 (UTC) Date: Sat, 13 Jun 2009 08:48:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Michael Tuexen In-Reply-To: <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> Message-ID: <20090613084513.L22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, FreeBSD net mailing list , Andrew Gallatin Subject: Re: Ethernet NIC drivers depending unconditionally on INET 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, 13 Jun 2009 08:50:08 -0000 On Sat, 13 Jun 2009, Michael Tuexen wrote: > On Jun 13, 2009, at 10:01 AM, Pyun YongHyeon wrote: > >> On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: >>> On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: >>> >>>> Michael Tuexen wrote: >>>> >>>>> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 >>>>> capabilities... Why would we want to enable IPv4 offloading and >>>>> not IPv6 or vice versa? >>>> >>>> I'd assume that some older hardware supports IPv4 offloads, but >>>> might not have support for IPv6 offloads. >>> Sure. But then the driver only provides the CSUM_ flags which >>> are appropriate. For example, a similar thing is already in the >>> igb driver: >>> >>> 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { >>> 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); >>> 1169 #if __FreeBSD_version >= 800000 >>> 1170 if (adapter->hw.mac.type == e1000_82576) >>> 1171 ifp->if_hwassist |= CSUM_SCTP; >>> 1172 #endif >>> 1173 } >> >> That would disable all IPv4/IPv6 checksum offloading if >> administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ >> IFCAP_RXCSUM6 users could choose best working one even if some part >> of driver/controller had checksum offload bugs. > Sure. That is what I wrote in my earlier mail: Do we want to > provide a ability to disable/enable checksum offload for > IPv4 and IPv6 individually... > Besides this "working around bugs" I see no reason to do > it. Some other capabilities TSO/TOE are IPv[46] specific. > I have no strong opinion on this. What do others think? I think if there are bugs the driver would have to make sure to handle if_hwassist appropriately ; actually we are already doing this. Often it would be chip revision specific I guess so it doesn't really make sense to break it down to IPv4/v6. Either you turn it on and get what the driver thinks this chip can do or you don't get any. If there is a bug for a chip revision, enhance the driver to know to handle it correctly and be done. Actuallt that is exactly what you sample above is doing - enabling CSUM_SCTP only for a specific chip. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 17:41:22 2009 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 63E001065673 for ; Sat, 13 Jun 2009 17:41:22 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4968FC1F for ; Sat, 13 Jun 2009 17:41:21 +0000 (UTC) (envelope-from louie@transsys.com) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 53A705C04; Sat, 13 Jun 2009 13:24:26 -0400 (EDT) Message-Id: <865C7FF6-F9DD-4684-8AF3-204941032330@transsys.com> From: Louis Mamakos To: saravana perumal In-Reply-To: <28959.63465.qm@web8313.mail.in.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 13:24:25 -0400 References: <28959.63465.qm@web8313.mail.in.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Subject: Re: TCP Free-BSD setup behaviour. 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, 13 Jun 2009 17:41:22 -0000 On Jun 10, 2009, at 9:47 AM, saravana perumal wrote: > Hi , > > Have some behaviour change with FREEBSD compared to LINUX . You probably ought to verify the behavior against the protocol specifications, and not what some other TCP implementation happens to to. > > 1. When sending the Same TCP packet once again [ Retranmission of > TCP packet ] Whether the Same Identification field [ IP packet]used > or not . > but when seeing that thru packet capture, Free BSD sending the > differnt one [ increases sequentially IP Identification] The IPID header field is used for reassembly of IP fragments, and is not of consequence to TCP. If the protocol stack absolutely knows that a TCP retransmission is identical to the previous segment, then in theory, it could use the same IPID fields to increase the chance that a previously fragmented TCP segment with a lost segment could get reassembled with fragments from the retransmission. Since there's much work done to avoid fragmentation in the first place (e.g., using Path MTU discovery), this "feature" probably never gets used. This behavior makes more sense if the TCP implementation keeps around a retransmit queue of previously sent packets, rather than simply generating new TCP segments with whatever data happens to be in the TCP send window at the time of the retransmission attempt. > > 2.Retranmission Time is not increasing Linearly with Respect to BSD. > not keeping more time interval . AS per RFC > expecting Retransmission timeout should increase Linearly. Issue is > not seen with Linux Setup Retransmission time is highly dependent on many factors, like the implementation of TCP slow-start, what the TCP stack has estimated as the round-trip time, etc. In the general case, over the span of many retransmissions, the sending TCP stack should back-off the retransmit times. > > 3. Active SYN open state in FREE BSD setup , Does not reach Syn- > received State. When Sending syn packet to DUT but for that FreeBSD > is not sending back > SYN/ACK . Issue is with Free BSD Setup.Linux works fine, If the FreeBSD system is doing a TCP active open (e.g., a connect() system call), then it sends a SYN to the remote TCP, and expects a SYN/ ACK back from the remote system. At that point, since the remote has ACK'd the SYN, it should correctly respond with simply an ACK of the remote TCP's SYN, and perhaps any data that might have been piggybacked in the ACK segment. There's no need to retransmit the SYN. Or is the remote system doing the active open to the FreeBSD system? It's hard to believe that the FreeBSD TCP can't respond to an incoming TCP segment to a listening socket carrying a SYN segment? > > 4.When checking the State - TIME-WAIT > Sending FIN and expecting the ACK ;Getting the ACK properly. > Sending Data Segment and Expecting the RST signal not getting the > RST ; Instead DUT is sending the Last TCP packet. > > Issue seen only in Free BSD. I may be misunderstanding. When in TIME-WAIT state, the local TCP is waiting for a bit in case the "final" ACK of the remote TCP's FIN got lost, and the remote retransmits the FIN (and perhaps any data that might have been in the window along with the FIN). The local TCP shouldn't generate a RST assuming that the remote's retransmitted TCP segment is still within the window. I'm not sure what's in the "Last TCP packet." > > Same issue in FIN-WAIT2 & FIN-WAIT1 State also . > Sending FIN and Expect the ACK : Getting the ACK > Sending Data segment with Data : Expecting the RST signal from > DUT ; but got Last transmitted TCP packet[ FIN -ACK] > Ditto. > Any idea about the above scenario would be helpful > > Thanks, > Saravanan. The TCP in Linux is hardly the reference implementation; with the TCP stack in various 4.xBSD varients preceeding it by many years, not to mention many others implementations in other platforms. I'm not sure looking for variances between some random Linux TCP stack is really the right way to approach testing. louie