From owner-freebsd-net@FreeBSD.ORG Sun Mar 24 19:47:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C56D5CB5 for ; Sun, 24 Mar 2013 19:47:36 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 79017141 for ; Sun, 24 Mar 2013 19:47:36 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2OJlRO9025943 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 25 Mar 2013 01:47:29 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <514F584D.6080106@norma.perm.ru> Date: Mon, 25 Mar 2013 01:47:25 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.1-RELEASE + bge0 == watchdog timeout References: <513713C2.1000007@norma.perm.ru> <20130307022446.GB3108@michelle.cdnetworks.com> <513820E2.806@norma.perm.ru> <20130307062335.GB1478@michelle.cdnetworks.com> <51383E3B.5030007@norma.perm.ru> <20130307081548.GD1478@michelle.cdnetworks.com> <20130313015753.GD3062@michelle.cdnetworks.com> <514171D1.50807@norma.perm.ru> <20130314072946.GA1519@michelle.cdnetworks.com> <51469BE4.6070502@norma.perm.ru> <20130319060327.GC1437@michelle.cdnetworks.com> <514DEED6.10001@norma.perm.ru> In-Reply-To: <514DEED6.10001@norma.perm.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 25 Mar 2013 01:47:31 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Mar 2013 19:47:36 -0000 Hi. On 24.03.2013 0:05, Eugene M. Zheganin wrote: > Hi. > > On 19.03.2013 12:03, YongHyeon PYUN wrote: >> I have no idea how this change can freeze your box. It would be >> even better to know whether the issue was triggered by bge(4) >> changes. I think you can use bge(4)/brgphy(4) of 8.3-RELEASE on >> your stable/8. Copy required files from 8.3-RELEASE to stable/8 and >> rebuild your kernel. For instance, >> >> Copy /usr/src/sys/dev/bge/if_bge.c from 8.3-RELEASE to >> /usr/src/sys/dev/bge on stable/8 >> Copy /usr/src/sys/dev/bge/if_bgereg.h from 8.3-RELEASE to >> /usr/src/sys/dev/bge on stable/8 >> Copy /usr/src/sys/dev/mii/brgphy.c from 8.3-RELEASE to >> /usr/src/sys/dev/mii on stable/8 >> Copy /usr/src/sys/dev/mii/brgphyreg.g from 8.3-RELEASE to >> /usr/src/sys/dev/mii on stable/8 >> And rebuild your kernel. > > Well, as I said, I took the if_bge* and bgrphy* sources from one of my > servers running 8.3-PRERELEASE (21 мар 2012) and applied it to the > stable/8 I'm running on this troubled server. > This is how the "last" output looks on it: > > last | grep reboot > reboot ~ Wed Mar 20 00:36 > reboot ~ Tue Mar 19 12:44 > reboot ~ Mon Mar 18 22:47 > reboot ~ Mon Mar 18 08:31 > reboot ~ Sun Mar 17 20:40 > reboot ~ Sat Mar 16 11:24 > reboot ~ Sat Mar 16 11:17 > reboot ~ Fri Mar 15 15:17 > reboot ~ Fri Mar 15 13:41 > reboot ~ Fri Mar 15 08:58 > ^^^^^^ this is the time point where the stable/8 was installed. > Please discard my last message; I just got two freezes in a row with a bunch of "bge timeout - resetting", still running the bge(4) from a 8.3-PRERELEASE. I don't know anymore what's triggering it. :( Eugene. From owner-freebsd-net@FreeBSD.ORG Mon Mar 25 11:06:47 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BF83C0 for ; Mon, 25 Mar 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2D09AC9 for ; Mon, 25 Mar 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2PB6lW3007227 for ; Mon, 25 Mar 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2PB6k5U007225 for freebsd-net@FreeBSD.org; Mon, 25 Mar 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Mar 2013 11:06:46 GMT Message-Id: <201303251106.r2PB6k5U007225@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 11:06:47 -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/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176667 net [libalias] [patch] libalias locks on uninitalized data o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 455 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 25 11:48:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECD04A9E for ; Mon, 25 Mar 2013 11:48:10 +0000 (UTC) (envelope-from OgBOmG@mercury3.interhost.it) Received: from mercury3.interhost.it (mercury3.interhost.it [194.242.61.135]) by mx1.freebsd.org (Postfix) with ESMTP id AD54C744 for ; Mon, 25 Mar 2013 11:48:10 +0000 (UTC) Received: by mercury3.interhost.it (Postfix, from userid 517) id ACA9410E353; Mon, 25 Mar 2013 12:41:55 +0100 (CET) To: net@freebsd.org Subject: bank of montreal messsage X-PHP-Script: www.assimil.it/logs/mail.php for 41.184.112.222 From: Message-Id: <20130325114334.ACA9410E353@mercury3.interhost.it> Date: Mon, 25 Mar 2013 12:41:55 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 11:48:11 -0000 Transaction ID: 072316811IKGYFESS Our records indicate that your account has been locked, click Log on: [1]BMO Bank of Montreal Sign-In. 2013 BMO Bank of Montreal. References 1. http://memoiresaboard.com/wp-includes/bmo.com/BMO/BMO/BMO/BMO/BMO/BMO/BMO/BMO/bmo/index.htm From owner-freebsd-net@FreeBSD.ORG Mon Mar 25 22:51:41 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA0F9CD9; Mon, 25 Mar 2013 22:51:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A4DA97DE; Mon, 25 Mar 2013 22:51:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2PMpfmt041783; Mon, 25 Mar 2013 22:51:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2PMpfvJ041782; Mon, 25 Mar 2013 22:51:41 GMT (envelope-from linimon) Date: Mon, 25 Mar 2013 22:51:41 GMT Message-Id: <201303252251.r2PMpfvJ041782@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177366: [ieee80211] negative malloc(9) statistics for 80211node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 22:51:41 -0000 Synopsis: [ieee80211] negative malloc(9) statistics for 80211node Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 25 22:51:29 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177366 From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 10:23:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B3F61B8 for ; Tue, 26 Mar 2013 10:23:51 +0000 (UTC) (envelope-from devel@stasyan.com) Received: from ncc.sibirtelecom.ru (mail.ncc.snt.ru [92.124.239.14]) by mx1.freebsd.org (Postfix) with ESMTP id F41FEFC8 for ; Tue, 26 Mar 2013 10:23:49 +0000 (UTC) Received: from stast.ncc.sibirtelecom.ru (unknown [92.124.239.16]) by ncc.sibirtelecom.ru (Postfix) with ESMTPS id CD10E1782C7; Tue, 26 Mar 2013 17:14:28 +0700 (NOVT) From: Stas Timokhin To: freebsd-net@freebsd.org Subject: ng_netflow patch for AS filling Date: Tue, 26 Mar 2013 17:14:46 +0700 User-Agent: KMail/1.11.1 (FreeBSD/8.3-RELEASE-p4; KDE/4.8.4; i386; ; ) MIME-Version: 1.0 Message-Id: <201303261714.49770.devel@stasyan.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 10:23:51 -0000 Hello ! Patch for injecting information network->as_number from extrernal sources (RIPE database, for example) into kernel and filling src and dst AS-number in Netflow v5 datagrams. http://www.stasyan.com/devel/ng_netflow/patch_ngnetflow_asnum.txt Example of converted RIPE-database for it: http://www.stasyan.com/devel/ng_netflow/ripe_201303.ng This patch made for FreeBSD 10.x-current for state at 26.02.2013. From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 10:26:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51B5527C for ; Tue, 26 Mar 2013 10:26:58 +0000 (UTC) (envelope-from devel@stasyan.com) Received: from mx.providersolutions.ru (mx.providersolutions.ru [89.253.252.22]) by mx1.freebsd.org (Postfix) with ESMTP id 82495FF8 for ; Tue, 26 Mar 2013 10:26:57 +0000 (UTC) Received: (qmail 30583 invoked from network); 26 Mar 2013 10:20:15 -0000 Received: from unknown (HELO mx.providersolutions.ru) ([89.253.252.14]) by 89.253.252.22 with SMTP; 26 Mar 2013 10:20:15 -0000 Received: from 92.124.239.16.ncc.sibirtelecom.ru (92.124.239.16.ncc.sibirtelecom.ru [92.124.239.16]) by rsnx.ru (Horde Framework) with HTTP; Tue, 26 Mar 2013 13:20:15 +0300 Message-ID: <20130326132015.29781oyyjmv8fdjz@webmail01.providersolutions.ru> Date: Tue, 26 Mar 2013 13:20:15 +0300 From: devel@stasyan.com To: freebsd-net@freebsd.org Subject: ng_netflow patch for AS filling MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 10:26:58 -0000 Hello ! Patch for injecting information network->as_number from extrernal sources (RIPE database, for example) into kernel and filling src and dst AS-number in Netflow v5 datagrams. http://www.stasyan.com/devel/ng_netflow/patch_ngnetflow_asnum.txt Example of converted RIPE-database for it: http://www.stasyan.com/devel/ng_netflow/ripe_201303.ng This patch made for FreeBSD 10.x-current for state at 26.02.2013. From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 10:46:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0F8C15C8 for ; Tue, 26 Mar 2013 10:46:07 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id E076C13C for ; Tue, 26 Mar 2013 10:46:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,911,1355126400"; d="scan'208";a="34090397" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 26 Mar 2013 03:46:05 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2QAk5ho021493; Tue, 26 Mar 2013 03:46:05 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 03:46:04 -0700 From: "Eggert, Lars" To: Schrodinger Subject: Re: ntpd bind() failure: Can't assign requested address Thread-Topic: ntpd bind() failure: Can't assign requested address Thread-Index: AQHOH2v5qaQ0QJ92Tka+hesYV8gLMJijHMMAgAD5wQCAAArqAIAUM0uA Date: Tue, 26 Mar 2013 10:46:04 +0000 Message-ID: <7DBA7D23-F1D6-4A40-A261-A91F8C5356EF@netapp.com> References: <76E2EE0D-B6D3-428E-9112-AF0E04E98DDE@my.gd> <20130313141716.GB18992@defiant.konundrum.org> In-Reply-To: <20130313141716.GB18992@defiant.konundrum.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 10:46:07 -0000 Hi, >> I confirm I have the same issue on 9.1 r247912 , as below: same here, on FreeBSD 10.0-CURRENT #5 r+16848a4-dirty: Mar 26 11:43:17 ntpd[2783]: bind() fd 23, family AF_INET6, port 123, scope= 1, addr fe80::92e2:baff:fe2b:3a00, mcast=3D0 flags=3D0x11 fails: Can't ass= ign requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on ix0 (3) for fe80::9= 2e2:baff:fe2b:3a00#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 23, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:200::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on ix0 (4) for fd00:ca= fe:cafe:200::7#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 24, family AF_INET6, port 123, scope= 2, addr fe80::92e2:baff:fe2b:3a01, mcast=3D0 flags=3D0x11 fails: Can't ass= ign requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on ix1 (6) for fe80::9= 2e2:baff:fe2b:3a01#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 24, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:201::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on ix1 (7) for fd00:ca= fe:cafe:201::7#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 25, family AF_INET6, port 123, scope= 3, addr fe80::21b:21ff:fea8:a534, mcast=3D0 flags=3D0x11 fails: Can't assi= gn requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em0 (9) for fe80::2= 1b:21ff:fea8:a534#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 25, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:100::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em0 (10) for fd00:c= afe:cafe:100::7#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 26, family AF_INET6, port 123, scope= 4, addr fe80::21b:21ff:fea8:a535, mcast=3D0 flags=3D0x11 fails: Can't assi= gn requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em1 (12) for fe80::= 21b:21ff:fea8:a535#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 26, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:101::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em1 (13) for fd00:c= afe:cafe:101::7#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 27, family AF_INET6, port 123, scope= 5, addr fe80::21b:21ff:fea8:a536, mcast=3D0 flags=3D0x11 fails: Can't assi= gn requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em2 (15) for fe80::= 21b:21ff:fea8:a536#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 27, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:102::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em2 (16) for fd00:c= afe:cafe:102::7#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 28, family AF_INET6, port 123, scope= 6, addr fe80::21b:21ff:fea8:a537, mcast=3D0 flags=3D0x11 fails: Can't assi= gn requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em3 (18) for fe80::= 21b:21ff:fea8:a537#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 28, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:103::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: unable to create socket on em3 (19) for fd00:c= afe:cafe:103::7#123 Mar 26 11:43:17 ntpd[2783]: bind() fd 31, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:104::7, mcast=3D0 flags=3D0x11 fails: Can't assign = requested address Mar 26 11:43:17 ntpd[2783]: bind() fd 34, family AF_INET6, port 123, scope= 0, addr fd00:cafe:cafe:1::7, mcast=3D0 flags=3D0x11 fails: Can't assign re= quested address >> However, ntpd runs fine and is bound to the following addresses: same here, running fine. My ifconfig: ix0: flags=3D8843 metric 0 mtu 1500 options=3D407bb ether 90:e2:ba:2b:3a:00 inet 10.2.0.7 netmask 0xffffff00 broadcast 10.2.0.255=20 inet6 fe80::92e2:baff:fe2b:3a00%ix0 prefixlen 64 scopeid 0x1=20 inet6 fd00:cafe:cafe:200::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (10Gbase-Twinax ) status: active ix1: flags=3D8843 metric 0 mtu 1500 options=3D407bb ether 90:e2:ba:2b:3a:01 inet 10.2.1.7 netmask 0xffffff00 broadcast 10.2.1.255=20 inet6 fe80::92e2:baff:fe2b:3a01%ix1 prefixlen 64 scopeid 0x2=20 inet6 fd00:cafe:cafe:201::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (10Gbase-Twinax ) status: active em0: flags=3D8843 metric 0 mtu 1500 options=3D4019b ether 00:1b:21:a8:a5:34 inet 10.1.0.7 netmask 0xffffff00 broadcast 10.1.0.255=20 inet6 fe80::21b:21ff:fea8:a534%em0 prefixlen 64 scopeid 0x3=20 inet6 fd00:cafe:cafe:100::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8843 metric 0 mtu 1500 options=3D4019b ether 00:1b:21:a8:a5:35 inet 10.1.1.7 netmask 0xffffff00 broadcast 10.1.1.255=20 inet6 fe80::21b:21ff:fea8:a535%em1 prefixlen 64 scopeid 0x4=20 inet6 fd00:cafe:cafe:101::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8843 metric 0 mtu 1500 options=3D4019b ether 00:1b:21:a8:a5:36 inet 10.1.2.7 netmask 0xffffff00 broadcast 10.1.2.255=20 inet6 fe80::21b:21ff:fea8:a536%em2 prefixlen 64 scopeid 0x5=20 inet6 fd00:cafe:cafe:102::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect status: no carrier em3: flags=3D8843 metric 0 mtu 1500 options=3D4019b ether 00:1b:21:a8:a5:37 inet 10.1.3.7 netmask 0xffffff00 broadcast 10.1.3.255=20 inet6 fe80::21b:21ff:fea8:a537%em3 prefixlen 64 scopeid 0x6=20 inet6 fd00:cafe:cafe:103::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect status: no carrier em4: flags=3D8843 metric 0 mtu 1500 options=3D4219b ether 00:a0:98:30:c2:28 inet6 fe80::2a0:98ff:fe30:c228%em4 prefixlen 64 scopeid 0x7=20 inet 10.11.12.7 netmask 0xffffff00 broadcast 10.11.12.255=20 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active em5: flags=3D8843 metric 0 mtu 1500 options=3D4019b ether 00:a0:98:30:c2:29 inet 10.1.4.7 netmask 0xffffff00 broadcast 10.1.4.255=20 inet6 fe80::2a0:98ff:fe30:c229%em5 prefixlen 64 scopeid 0x8=20 inet6 fd00:cafe:cafe:104::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (100baseTX ) status: active bge0: flags=3D8843 metric 0 mtu 150= 0 options=3D8009b ether 00:a0:98:30:c2:2c inet 10.0.0.7 netmask 0xffffff00 broadcast 10.0.0.255=20 inet6 fe80::2a0:98ff:fe30:c22c%bge0 prefixlen 64 scopeid 0x9=20 inet6 fd00:cafe:cafe::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (100baseTX ) status: active bge1: flags=3D8843 metric 0 mtu 150= 0 options=3D8009b ether 00:a0:98:30:c2:2d inet 10.0.1.7 netmask 0xffffff00 broadcast 10.0.1.255=20 inet6 fe80::2a0:98ff:fe30:c22d%bge1 prefixlen 64 scopeid 0xa=20 inet6 fd00:cafe:cafe:1::7 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D21 Lars From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 10:47:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6BB167D for ; Tue, 26 Mar 2013 10:47:38 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE1715A for ; Tue, 26 Mar 2013 10:47:38 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UKRT8-0000Ko-8I; Tue, 26 Mar 2013 14:51:06 +0400 Message-ID: <51517CBD.8080805@FreeBSD.org> Date: Tue, 26 Mar 2013 14:47:25 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stas Timokhin Subject: Re: ng_netflow patch for AS filling References: <201303261714.49770.devel@stasyan.com> In-Reply-To: <201303261714.49770.devel@stasyan.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 10:47:38 -0000 On 26.03.2013 14:14, Stas Timokhin wrote: > Hello ! Hello. > > > > Patch for injecting information network->as_number from extrernal > sources (RIPE database, for example) into kernel and filling src and dst > AS-number in Netflow v5 datagrams. > > > > http://www.stasyan.com/devel/ng_netflow/patch_ngnetflow_asnum.txt It is better to attach patches in ML to make it easier for others to comment :) + o1=(htonl(rec->src_addr)>>24)&0xFF; + o2=(htonl(rec->src_addr)>>16)&0xFF; + o3=(htonl(rec->src_addr)>>8)&0xFF; + o4=(htonl(rec->src_addr))&0xFF; + a1=GetAsnumber(aaa,o1,o2,o3,o4); Why do you need o* here? Why not using in_addr in GetAsnumber()? Why you are using 255 as multiplier ? MALLOC(asn[255*i1+i2].ptr_low,struct ascelllow*, sizeof(struct ascelllow),M_NETFLOW_HASH,M_NOWAIT); ^^ malloc() with M_WAITOK can be used here. + u_int8_t masklen; + u_int16_t asnum; +}; You should support at least loading 32-bit ASNs (and convert them to 23456 for v5 export). + case NGM_NETFLOW_DELETENETFROMAS: + { + break; + } You should probably support deleting prefixes :) +struct ascellhigh { + struct ascelllow* ptr_low; +}; Do we need another layer here? While v5 export supports IPv4 and 2-byte ASNs only it is probably much better to include IPv6 support at least in NGM_ messages ( like ng_ksocket do ). > > > > Example of converted RIPE-database for it: > > http://www.stasyan.com/devel/ng_netflow/ripe_201303.ng > > > > This patch made for FreeBSD 10.x-current for state at 26.02.2013. > > > > > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 11:59:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA61EC75 for ; Tue, 26 Mar 2013 11:59:38 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEB77B6 for ; Tue, 26 Mar 2013 11:59:37 +0000 (UTC) Received: from [98.139.212.147] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 11:59:31 -0000 Received: from [98.139.212.226] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 11:59:31 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 11:59:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 595129.28770.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 65002 invoked by uid 60001); 26 Mar 2013 11:59:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364299170; bh=1S3aJouYUXfBSvu3ccDf7oSkEgxNyKUCxu9uC4mnpp4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=vABZeldee6JQAj0/LxYXxZ4GXXHn1DcuvNUeohu84IkIPRt5N/i2kr2w5l+RN8recC6fF3qokvQwu+YCga3YcZSNxCIuN6zxcYcIoetbuFkarUoOcb86hy5p6rXfSm4bBZK6YA1FAVAzpUdpwUzKTHvJpHyrFXiooRd4PSbuw/M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=nOTJAn1SNXZNWX71X9m8qVgtJAYOH1j+v1Tcd9GMMo7c+wzbTbPmUmiSpaGfKxdHEGL7GbWaLONitAacEz5+oo03ncdFOnclUaCxMm83ar7iLqfWshzBUNFvugfl0DaKGFbUt7UgWBLpUhcsFn1WZI8gcYmiTT5hi/U04Rvt61o=; X-YMail-OSG: H0Bj2OIVM1mUo6JEEMESnroSoqy37d.dXPS9QC0QvlSAvp0 lrzzBM1F.xpNIicBrrYj1eMyiU8C4yj6YWY4F41Y5Q1YogRuaEpa9VOJT5OY oaEUQBrvO6wfBsHq7KqExV.KPUAnZ2ireWfvYmWXd82k36KktbSyVejk8Gtv ius84CqBY9651OD46h9WqeM2FjBdlCSver7sn_5jaP3Yh6C_obiadaQYDtAb JAeWNpLgbNUO5Cbhxes0txTzbcoPtAGduLRg5DaBbS1DJgvA.ORFHvftBA9R LgxvIFBlDtTiUisNEAhzfDLASFOWmR_5Z8ef..baoR7WwEHggVpXZOEfsNTS qNu_PIfHhH4WXqf7IThPFg7vpW6o67FCS_b6kCMEuz4jwUWrV7F9qM6F11VI owOlprjd9FRbAWf9mVDEghnlCh3yeWJ811MJ6cJqf_zQazDsEQOJhpoKlzgq dq.S57T_hH2VtwvQLqdhXi3jJJ_7rgWXpAQeMFzAlJ8kE2YE2VzOhkAO80w- - Received: from [49.125.183.152] by web31816.mail.mud.yahoo.com via HTTP; Tue, 26 Mar 2013 04:59:30 PDT X-Rocket-MIMEInfo: 002.001, SG93IGRvIHlvdSBjb25maWd1cmUgeW91ciBuZXR3b3JrIGludGVyZmFjZXM_IFVzaW5nIC9ldGMvc3RhcnRfaWYqIG9yIC9ldGMvcmMuY29uZj88YnIvPgEwAQEBAQ-- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailWebService/0.8.139.530 Message-ID: <1364299170.64928.iosMobile@web31816.mail.mud.yahoo.com> Date: Tue, 26 Mar 2013 04:59:30 -0700 (PDT) From: ktsin@acm.org Subject: Re: ntpd bind() failure: Can't assign requested address To: "lars@netapp.com" , "schrodinger@konundrum.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 11:59:38 -0000 How do you configure your network interfaces? Using /etc/start_if* or /etc/rc.conf?
From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 13:07:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 401B817D for ; Tue, 26 Mar 2013 13:07:41 +0000 (UTC) (envelope-from devel@stasyan.com) Received: from mx.providersolutions.ru (mx.providersolutions.ru [89.253.252.22]) by mx1.freebsd.org (Postfix) with ESMTP id 827C6C24 for ; Tue, 26 Mar 2013 13:07:39 +0000 (UTC) Received: (qmail 5406 invoked from network); 26 Mar 2013 13:07:27 -0000 Received: from unknown (HELO mx.providersolutions.ru) ([89.253.252.14]) by 89.253.252.22 with SMTP; 26 Mar 2013 13:07:27 -0000 Received: from b-internet.212.164.232.186.nsk.rt.ru (b-internet.212.164.232.186.nsk.rt.ru [212.164.232.186]) by rsnx.ru (Horde Framework) with HTTP; Tue, 26 Mar 2013 16:07:27 +0300 Message-ID: <20130326160727.18585l7sz9gql027@webmail01.providersolutions.ru> Date: Tue, 26 Mar 2013 16:07:27 +0300 From: devel@stasyan.com To: "Alexander V. Chernikov" Subject: Re: ng_netflow patch for AS filling References: <201303261714.49770.devel@stasyan.com> <51517CBD.8080805@FreeBSD.org> In-Reply-To: <51517CBD.8080805@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 13:07:41 -0000 >> Patch for injecting information network->as_number from extrernal >> sources (RIPE database, for example) into kernel and filling src and dst >> AS-number in Netflow v5 datagrams. > +=09o1=3D(htonl(rec->src_addr)>>24)&0xFF; > +=09o2=3D(htonl(rec->src_addr)>>16)&0xFF; > +=09o3=3D(htonl(rec->src_addr)>>8)&0xFF; > +=09o4=3D(htonl(rec->src_addr))&0xFF; > +=09a1=3DGetAsnumber(aaa,o1,o2,o3,o4); > Why do you need o* here? Per-byte presentation of IPV4-address required because scheme of =20 storing based on it. > Why not using in_addr in GetAsnumber()? > Why you are using 255 as multiplier ? 255 - width of array. It's access to two-dimensonal array. > MALLOC(asn[255*i1+i2].ptr_low,struct ascelllow*, sizeof(struct > ascelllow),M_NETFLOW_HASH,M_NOWAIT); > ^^ malloc() with M_WAITOK can be used here. Ok, will be done. > You should support at least loading 32-bit ASNs (and convert them to > 23456 for v5 export). Ok, will be done. > + case NGM_NETFLOW_DELETENETFROMAS: > + { > + break; > + } > You should probably support deleting prefixes :) "Global" delete (when destroing node) support now. But "partial" =20 deleting support need too, you're right. > +struct ascellhigh { > +=09struct ascelllow*=09ptr_low; > +}; > > Do we need another layer here? Current scheme was optimized for fast_search/small_memory_utilization =20 for IPV4-table. I suppose that for IPV6 we need something another. > While v5 export supports IPv4 and 2-byte ASNs only it is probably much > better to include IPv6 support at least in NGM_ messages ( like > ng_ksocket do ). From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 13:24:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF59A413 for ; Tue, 26 Mar 2013 13:24:58 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 5F172D42 for ; Tue, 26 Mar 2013 13:24:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,911,1355126400"; d="scan'208";a="34125457" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 26 Mar 2013 06:24:52 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2QDOq9D028954; Tue, 26 Mar 2013 06:24:52 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 06:24:52 -0700 From: "Eggert, Lars" To: " " Subject: Re: ntpd bind() failure: Can't assign requested address Thread-Topic: ntpd bind() failure: Can't assign requested address Thread-Index: AQHOKhlfqaQ0QJ92Tka+hesYV8gLMJi4a72A Date: Tue, 26 Mar 2013 13:24:51 +0000 Message-ID: <0ABC54C5-54FB-4A28-BE38-167ED30E19F5@netapp.com> References: <1364299170.64928.iosMobile@web31816.mail.mud.yahoo.com> In-Reply-To: <1364299170.64928.iosMobile@web31816.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FFB8F833A741140B484EC133FB335EB@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "schrodinger@konundrum.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 13:24:58 -0000 On Mar 26, 2013, at 12:59, wrote: > How do you configure your network interfaces? Using /etc/start_if* or /et= c/rc.conf?
The latter. (Actually, most of them are configured in rc.local with a bit of shell code= that generates the IP address from the MAC address for a set of machines.) Lars= From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 14:03:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D31639E0 for ; Tue, 26 Mar 2013 14:03:32 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by mx1.freebsd.org (Postfix) with ESMTP id 86FFAECA for ; Tue, 26 Mar 2013 14:03:32 +0000 (UTC) Received: from [98.139.212.146] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 14:03:31 -0000 Received: from [98.139.212.202] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 14:03:31 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 14:03:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 634052.14540.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 2112 invoked by uid 60001); 26 Mar 2013 14:03:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364306611; bh=Yyo3XWVt74w0lWiwuAOXhHBtTVPUsInEpTbkdCOpzmM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1u3OxdF1RRvf1on7yRwSkGNqTQcBTOAXMOuFWpeugyWlCJCsrU0Fw0qyMM9HpaDbv8MMDNJX8kuHCFEZz6qmjgmX+XEaUtEqNzwdmgFPSbggLBUthFaBctcwPHkwOwovp0Ii4H4ZQUnEFHw/CYWFE+spFSsfRhO3bMWnM5YCFs0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U9i7R/7EPQr9ZWJHjH0aVSuarLU0UMCQBcHQO1PnhIUkreEJab6BYAD9xYTlfr7XbOnCSMkSmBiuunl2E9Uf2cjnBEhRANLaFi+4AgHS2MNJ2djpemLy/F3QeNbBojhwRppxLuNkZKXvYVEXXaDyJLopcJBhgpao31mNE4sfL+M=; X-YMail-OSG: _IIxR4wVM1kfJnGKCbgOxb6iR2vN01ZJG2Zk6AeJfcVKRG1 .cXtyr6IldFfpXM.C2uPJjGEyJ252VSMuJRcx9SkTUrfH_MJVW8oZ4pWr.9T Z_trYsvTe3K8GxHF3jUo7hu.PqPvyWdvDEHoXN4sB3hMlgJbTLi8Ls2IJxxb TWpv6hWvQj5_E_HurF8dxzlYwuUlbwM6XIBcFcnLhc0tGfoZ6BIuygbtspqv 2wck5rzsXanB.DMIo20pIYByLTF6_7FPkoWKDJNLvY4m9jC9nCevhjr_2oV9 l68CHASsNSqsqeKoOsi4oFYmJ3TIAtLpLBnMcNFZ4CgtzJTrb2KnYkLWv2.W v_9XXPLF0JG_sT2QJlTFj1TZsU5pZP0iKJz4u4O4pnWaMnAes.cV8TUGL64M E1XIUPRfQ196U3cZEcVXbUpBYZa6EkMr.vhDNGAA5gzEM6T8Gf6nr1wWaqsk AgSsF9ZCIN61NdHTA8KylBtxbgi5j6yo1LIU1dQqt5ZcKPCVRvOrpBTW5bkk __2W6Hc2PPMw37KfZOJk- Received: from [49.124.229.46] by web31813.mail.mud.yahoo.com via HTTP; Tue, 26 Mar 2013 07:03:31 PDT X-Rocket-MIMEInfo: 002.001, LS0tIE9uIFR1ZSwgMy8yNi8xMywgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb20.IHdyb3RlOgo.IE9uIE1hciAyNiwgMjAxMywgYXQgMTI6NTksIDxrdHNpbkBhY20ub3JnPgo.ICB3cm90ZToKPiA.IEhvdyBkbyB5b3UgY29uZmlndXJlIHlvdXIgbmV0d29yayBpbnRlcmZhY2VzPyBVc2luZwo.IC9ldGMvc3RhcnRfaWYqIG9yIC9ldGMvcmMuY29uZj88YnIvPgo.IAo.IFRoZSBsYXR0ZXIuCj4gCj4gKEFjdHVhbGx5LCBtb3N0IG9mIHRoZW0gYXJlIGNvbmZpZ3VyZWQgaW4gcmMubG9jYWwgd2l0aCBhCj4BMAEBAQE- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364306611.67937.YahooMailClassic@web31813.mail.mud.yahoo.com> Date: Tue, 26 Mar 2013 07:03:31 -0700 (PDT) From: kit Subject: Re: ntpd bind() failure: Can't assign requested address To: LarsEggert In-Reply-To: <0ABC54C5-54FB-4A28-BE38-167ED30E19F5@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "freebsd-net@freebsd.org" , "schrodinger@konundrum.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ktsin@acm.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:03:32 -0000 --- On Tue, 3/26/13, Eggert, Lars wrote: > On Mar 26, 2013, at 12:59, > wrote: > > How do you configure your network interfaces? Using > /etc/start_if* or /etc/rc.conf?
> > The latter. > > (Actually, most of them are configured in rc.local with a > bit of shell code that generates the IP address from the MAC > address for a set of machines.) > > Lars i had seen the same error messages while trying to configure wlan0 using start_if.wlan0. i think that when an interface is first created, the flag ifdisabled is set by default. my guess is there exists a small window of time when the interface is up, ipv6 is configured but marked ifdisabled, and if ntpd happens to start during this period of time, you will see the failure messages. you may want to check your shell code again and perhaps the rc scripts too and see how they interact. kit From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 14:39:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C08A4DF6 for ; Tue, 26 Mar 2013 14:39:47 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm9-vm4.bullet.mail.ne1.yahoo.com (nm9-vm4.bullet.mail.ne1.yahoo.com [98.138.91.169]) by mx1.freebsd.org (Postfix) with ESMTP id 87BBC12E for ; Tue, 26 Mar 2013 14:39:47 +0000 (UTC) Received: from [98.138.226.178] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 26 Mar 2013 14:39:41 -0000 Received: from [98.138.226.168] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 26 Mar 2013 14:39:41 -0000 Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 26 Mar 2013 14:39:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 760786.63627.bm@omp1069.mail.ne1.yahoo.com Received: (qmail 65347 invoked by uid 60001); 26 Mar 2013 14:39:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364308780; bh=Gwo/bhyGryZS5C0hWfozD22UslwwNpiXfoLeIhHQCMI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V7tACAYvIkxeXpZdG4FNfQtbEDr2EJ6tyN97fb4UJfI+r5hnUQY1jI1vsDKJxZjzXByqz2eq7evAOooOG58iyO7tumkiERVbUxoGlbxf+BkiSEg4ITuiytSxCYRS5RGjbhpd4ZRKkc8isrfHnwpkNhOxd7SLbhAeIIw393tei/w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ul3+TmK8sli9zhGIJwo+tH5iPQU31SZVRgzIU4e80Ln166c8T01FzDskm3zVJuWV0dYv9P3wJ5RAK4WMi4xDnu/OHY0jQyvydHLEJXFblhxx7BDaj5RZV4kAkQSQTTExNGksbMTkshf3YQ1vnqXytbROnPBrxPuHwRRgtF+nRj8=; X-YMail-OSG: C9HIOmwVM1krO1J3lCF0oqhao3OAbSoWFzASc41tQ1hd.Gl 8VYH4uTN.WQ8ugRrEFUO0OE_CeRa6jtchaGswD_gaKaHM4v_1thoaQFRy3aD BRN6zFUkk_0C06GM045hrQmS1oyDF7KU3QS19hBJv4J8mquEVA3ffwJXMwBJ Cwj_aYVanV9fJn_3cA1dLQ7.gt2FdSQbE1MOqyZwV.nLiuP6nB3j86kStlWw NJNV0a4F5gCRVcHkax.Ye0bI__J2BV.Gl_qfbjcK6x6R8Kz65NEfNpgq5jOT UgEhCYFUyXdp2HbkkNK60MvDT7I0QH0Tnvn6JSq8sXSUf86eEVZKlgXDqDCt jg6oOGoKqCHdTkGdeuudtY1usveY0Tdk6A3qHjWxYm22BgxA9xCLW7.JcgTX OBiQEH8tRUg0MXxPxdHo.K90dYkyD_akSZ4MoRDdxpdLnn5LuZ6taNgfyVQ9 FFRGvyLFfXiAFJdhVGbWDnHqTAjEVB7NEPc.jSz_s44D0UM5mQnF2.P0vDdQ h8TvvI2kOWO60EDL90Azg Received: from [49.125.196.232] by web31809.mail.mud.yahoo.com via HTTP; Tue, 26 Mar 2013 07:39:40 PDT X-Rocket-MIMEInfo: 002.001, LS0tIE9uIFR1ZSwgMy8yNi8xMywga2l0IDxrdHNpbkBhY20ub3JnPiB3cm90ZToKPiAtLS0gT24gVHVlLCAzLzI2LzEzLCBFZ2dlcnQsIExhcnMKPiA8bGFyc0BuZXRhcHAuY29tPgo.IHdyb3RlOgo.ID4gT24gTWFyIDI2LCAyMDEzLCBhdCAxMjo1OSwgPGt0c2luQGFjbS5vcmc.Cj4gPsKgIHdyb3RlOgo.ID4gPiBIb3cgZG8geW91IGNvbmZpZ3VyZSB5b3VyIG5ldHdvcmsgaW50ZXJmYWNlcz8KPiBVc2luZwo.ID4gL2V0Yy9zdGFydF9pZiogb3IgL2V0Yy9yYy5jb25mPzxici8.Cj4gPiAKPiA.IFRoZSBsYXQBMAEBAQE- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> Date: Tue, 26 Mar 2013 07:39:40 -0700 (PDT) From: kit Subject: Re: ntpd bind() failure: Can't assign requested address To: LarsEggert In-Reply-To: <1364306611.67937.YahooMailClassic@web31813.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "schrodinger@konundrum.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ktsin@acm.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:39:47 -0000 --- On Tue, 3/26/13, kit wrote:=0A> --- On Tue, 3/26/13, Eg= gert, Lars=0A> =0A> wrote:=0A> > On Mar 26, 2013, at 12:59= , =0A> >=A0 wrote:=0A> > > How do you configure your network= interfaces?=0A> Using=0A> > /etc/start_if* or /etc/rc.conf?
=0A> > =0A= > > The latter.=0A> > =0A> > (Actually, most of them are configured in rc.l= ocal with=0A> a=0A> > bit of shell code that generates the IP address from= =0A> the MAC=0A> > address for a set of machines.)=0A> > =0A> > Lars=0A> = =0A> i had seen the same error messages while trying to configure=0A> wlan0= using start_if.wlan0.=0A> =0A> i think that when an interface is first cre= ated, the flag=0A> ifdisabled is set by default. my guess is there exists a= =0A> small window of time when the interface is up, ipv6 is=0A> configured = but marked ifdisabled, and if ntpd happens to=0A> start during this period = of time, you will see the failure=0A> messages.=0A> =0A> you may want to ch= eck your shell code again and perhaps the=0A> rc scripts too and see how th= ey interact.=0A> =0A> kit=0A=0Atry setting ipv6_activate_all_interfaces to = yes and configuring the corresponding $ifconfig_IF_ipv6 in your rc.conf if = you haven't done so already, and see if they help.=0A=0Afrom /etc/defaults/= rc.conf:=0A=0Aipv6_activate_all_interfaces=3D"NO" # If NO, interfaces= which have no=0A # corresponding $i= fconfig_IF_ipv6 is=0A # marked as IF= DISABLED for security=0A # reason.= =0A=0Akit From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 14:44:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CAE5AF40 for ; Tue, 26 Mar 2013 14:44:30 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id B22C3182 for ; Tue, 26 Mar 2013 14:44:30 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,911,1355126400"; d="scan'208";a="34151985" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 26 Mar 2013 07:44:30 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2QEiT54020051; Tue, 26 Mar 2013 07:44:30 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 07:44:29 -0700 From: "Eggert, Lars" To: "" Subject: Re: ntpd bind() failure: Can't assign requested address Thread-Topic: ntpd bind() failure: Can't assign requested address Thread-Index: AQHOKhlfqaQ0QJ92Tka+hesYV8gLMJi4a72AgAAKzYCAAAoaAIAAAVcA Date: Tue, 26 Mar 2013 14:44:28 +0000 Message-ID: <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> References: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> In-Reply-To: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <28BF9C77ABABB0438C6C8AE37716BA2A@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "schrodinger@konundrum.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 14:44:30 -0000 Hi, On Mar 26, 2013, at 15:39, kit wrote: >=20 > try setting ipv6_activate_all_interfaces to yes I had that set all along. > and configuring the corresponding $ifconfig_IF_ipv6 in your rc.conf if yo= u haven't done so already Can't really do this, because dhclient needs to have finished so I can gene= rate IPv6 addresses based on the IPv4 address & MAC address of the interfac= es. (Yes, this is an ugly hack, but these are lab machines.) Lars= From owner-freebsd-net@FreeBSD.ORG Tue Mar 26 22:35:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8BE90563 for ; Tue, 26 Mar 2013 22:35:59 +0000 (UTC) (envelope-from prvs=1797d483f0=admin@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) by mx1.freebsd.org (Postfix) with ESMTP id 622A08AF for ; Tue, 26 Mar 2013 22:35:59 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50001493943.msg; Tue, 26 Mar 2013 15:27:48 -0700 X-Spam-Processed: mail02.amotive.com, Tue, 26 Mar 2013 15:27:48 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=1797d483f0=admin@cadamericas.com X-Envelope-From: admin@cadamericas.com X-MDaemon-Deliver-To: freebsd-net@freebsd.org Date: Tue, 26 Mar 2013 15:27:50 -0700 To: freebsd-net From: CAD Americas Subject: CAD Americas Training Is Coming Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 6460ea67-4f5d-463d-d96b-515220a40ea7 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Info Desk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:35:59 -0000 ATTEND CAD AMERICAS TRAINING DAYS =E2=80=A6 and reach new heights! =0AMark = your calendar: A CAD Americas Training Day is coming to your area this Spri= ng! Join us for this one-day training event with an information-packed agen= da of topics important to you. Whether your focus is Mechanical Design, Con= struction, BIM, Electrical Design or Plant Design, there will be sessions t= hat will improve your productivity immediately!=0AIMPROVE YOUR PERFORMANCE = WITH NEW TOOLS AND TECHNIQUES=0A=0A=0A=0A=0ARick Ellis Civil 3D ExpertMore= =0ARobert Green CAD Mgmt ExpertMore=0ASteve Schain AutoCAD ExpertMore=0ATod= Stephens Revit ExpertMore=0ALearn from well-known industry instructors who= will share best practices and trends, product tips and tricks, new feature= s =E2=80=A6 and more.=0AImprove your productivity with new techniques that = you can put to work right away.=0AMeet your peers and exchange ideas on how= to best use the CAD tools you have to meet the demands of your job.=0ATake= a closer look at services and technologies offered by resellers in your ar= ea.=0ACHECK FOR A DATE IN YOUR LOCATION =E2=80=A6 AND REGISTER TODAY!=0A=0A= =C2=A0April 17 =E2=80=93 San Jose, CA April 18 =E2=80=93 San Bernardino, C= A =0A=0A=0A April 23 =E2=80=93 Cleveland, OH =C2=A0 April 24 =E2=80=93 Detr= oit, MI =0A=0A=0A April 25 =E2=80=93 Cincinnati, OH =C2=A0 April 30 =E2=80= =93 Atlanta, GA May 1 =E2=80=93 Dallas, TX =0A=0ACOMPLETE THIS SURVEY AND I= NFLUENCE THE SESSION CONTENT Tell us what session content you're looking fo= r. Take this survey today =E2=80=A6 and enter a drawing to win a free CAD A= mericas registration.=0AREGISTER BY MARCH 27TH AND SAVE Register for this C= AD Americas Training Day by March 27th and save.=0AEarly Bird Rate: $150 (U= ntil March 27th)=0AStandard Rate: $195 (AFTER March 27th)=0AStudent/Faculty= Rate: $95 (must present current student ID upon check-in at registration)= =0AREGISTER FOR CAD AMERICAS TRAINING TODAY! =0A=0A=0A=0A Join us at=0A=0A= =0A=0A=0A=0A=0A=0A=0A To Unsubscribe please click=C2=A0 Opt-Out=0A From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 01:44:12 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A17F591; Wed, 27 Mar 2013 01:44:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D785E3DF; Wed, 27 Mar 2013 01:44:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R1iB5S059240; Wed, 27 Mar 2013 01:44:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R1iBL9059239; Wed, 27 Mar 2013 01:44:11 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 01:44:11 GMT Message-Id: <201303270144.r2R1iBL9059239@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177402: [igb] [pf] problem with ethernet driver igb + pf / altq [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:44:12 -0000 Old Synopsis: problem with ethernet driver igb + pf / altq New Synopsis: [igb] [pf] problem with ethernet driver igb + pf / altq [regression] Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 01:43:37 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177402 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 01:46:12 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B187466A; Wed, 27 Mar 2013 01:46:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8B510402; Wed, 27 Mar 2013 01:46:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R1kCVR059327; Wed, 27 Mar 2013 01:46:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R1kCDG059326; Wed, 27 Mar 2013 01:46:12 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 01:46:12 GMT Message-Id: <201303270146.r2R1kCDG059326@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:46:12 -0000 Old Synopsis: Wrong control used to return TOS. [patch] New Synopsis: [netinet] [patch] Wrong control used to return TOS Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 01:45:58 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177362 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 01:46:40 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCC5D74D; Wed, 27 Mar 2013 01:46:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A814C5F7; Wed, 27 Mar 2013 01:46:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R1ke0P059373; Wed, 27 Mar 2013 01:46:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R1kenb059372; Wed, 27 Mar 2013 01:46:40 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 01:46:40 GMT Message-Id: <201303270146.r2R1kenb059372@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177384: [igb] [patch] Updating igb manpage/code with info about num_queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:46:40 -0000 Old Synopsis: [patch] Updating igb manpage/code with info about num_queues New Synopsis: [igb] [patch] Updating igb manpage/code with info about num_queues Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 01:46:24 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177384 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 01:47:51 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B359084E; Wed, 27 Mar 2013 01:47:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC0A619; Wed, 27 Mar 2013 01:47:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R1lp8d059446; Wed, 27 Mar 2013 01:47:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R1lpfd059445; Wed, 27 Mar 2013 01:47:51 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 01:47:51 GMT Message-Id: <201303270147.r2R1lpfd059445@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177400: [jme] JMC25x 1000baseT establishment issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:47:51 -0000 Old Synopsis: jme(4): JMC25x 1000baseT establishment issues New Synopsis: [jme] JMC25x 1000baseT establishment issues Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 01:47:27 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177400 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 01:50:27 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01ED79D8; Wed, 27 Mar 2013 01:50:27 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D2314649; Wed, 27 Mar 2013 01:50:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R1oQXq059829; Wed, 27 Mar 2013 01:50:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R1oQGn059828; Wed, 27 Mar 2013 01:50:26 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 01:50:26 GMT Message-Id: <201303270150.r2R1oQGn059828@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177194: [netgraph] Unnamed netgraph nodes for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:50:27 -0000 Old Synopsis: Unnamed netgraph nodes for vlan interfaces New Synopsis: [netgraph] Unnamed netgraph nodes for vlan interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 01:50:11 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177194 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 01:52:34 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD38BBB1; Wed, 27 Mar 2013 01:52:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 97179670; Wed, 27 Mar 2013 01:52:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R1qYho061366; Wed, 27 Mar 2013 01:52:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R1qYNM061365; Wed, 27 Mar 2013 01:52:34 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 01:52:34 GMT Message-Id: <201303270152.r2R1qYNM061365@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177032: [arge] arge1 fails to attach on UBNT Routerstation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:52:34 -0000 Old Synopsis: arge1 fails to attach on UBNT Routerstation New Synopsis: [arge] arge1 fails to attach on UBNT Routerstation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 01:51:56 UTC 2013 Responsible-Changed-Why: Over to -net, although it should possibly be on -mips. http://www.freebsd.org/cgi/query-pr.cgi?pr=177032 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 07:00:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 499D26FB; Wed, 27 Mar 2013 07:00:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 9A53B8A8; Wed, 27 Mar 2013 07:00:03 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id k13so174052wgh.5 for ; Wed, 27 Mar 2013 00:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RlwYRrHfK09NcXr65sPCfH9F/pWlvpyMLqb4N32ZElY=; b=nT4ScK6VxeEev9sciPrnXevntlzgWocAR5pwY+E5Y1qo0zAlfmRqx20/OPviFu/N5T V3nx7LVeNyN6+VRjPl08bgLPQHDP2CyAR4nb8PD5AnidXZQ8+ABjSDxqUUy7y5OmtDEl lE1daPiZjZ/AzORgxYxEbYcBe/B8bJZwSTp+oMgGPxOyILQjJEPZKZI9jC6zEkjUqppk IHzu9MDuaYSYvEwCwXe1xwzffR06IZXgN0aDBM0vyt/IHAiZg78JFvd4K5QA6Dh5A8+L /GmlPoAQBWL9CTUUnbwu1PqBcmFzxCkh22ax40H8BgAAhJWRKxrWFMsdkSy0wPiKhY+c tbug== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr7636011wic.29.1364367602812; Wed, 27 Mar 2013 00:00:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 27 Mar 2013 00:00:02 -0700 (PDT) In-Reply-To: <201303270152.r2R1qYNM061365@freefall.freebsd.org> References: <201303270152.r2R1qYNM061365@freefall.freebsd.org> Date: Wed, 27 Mar 2013 00:00:02 -0700 X-Google-Sender-Auth: 7GXr3Bx0pAY6QOYTNUnfqUmx9tw Message-ID: Subject: Re: kern/177032: [arge] arge1 fails to attach on UBNT Routerstation From: Adrian Chadd To: linimon@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 07:00:04 -0000 please reassign this to -mips, thanks! adrian On 26 March 2013 18:52, wrote: > Old Synopsis: arge1 fails to attach on UBNT Routerstation > New Synopsis: [arge] arge1 fails to attach on UBNT Routerstation > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Mar 27 01:51:56 UTC 2013 > Responsible-Changed-Why: > Over to -net, although it should possibly be on -mips. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=177032 > _______________________________________________ > 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 Wed Mar 27 09:50:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 83479C8D for ; Wed, 27 Mar 2013 09:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA29915 for ; Wed, 27 Mar 2013 09:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2R9o1xR050737 for ; Wed, 27 Mar 2013 09:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2R9o1qB050736; Wed, 27 Mar 2013 09:50:01 GMT (envelope-from gnats) Date: Wed, 27 Mar 2013 09:50:01 GMT Message-Id: <201303270950.r2R9o1qB050736@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Michael Tuexen Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Michael Tuexen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:50:01 -0000 The following reply was made to PR kern/177362; it has been noted by GNATS. From: Michael Tuexen To: bug-followup@FreeBSD.org, marka@isc.org Cc: Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS Date: Wed, 27 Mar 2013 10:45:48 +0100 It was not done by accident. The returned cmsg_type is IP_RECVTOS = instead of IP_TOS to keep it consistent with the handling of the IP_RECVTTL socket = option. I found it more important to be consistent within the same protocol = family than across different ones. I think that unfortunately IP_RECVTOS is not defined in any standard. Best regards Michael= From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 12:00:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E69BDF8D for ; Wed, 27 Mar 2013 12:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DA1FE324 for ; Wed, 27 Mar 2013 12:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2RC01Pm074478 for ; Wed, 27 Mar 2013 12:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2RC01nl074477; Wed, 27 Mar 2013 12:00:01 GMT (envelope-from gnats) Date: Wed, 27 Mar 2013 12:00:01 GMT Message-Id: <201303271200.r2RC01nl074477@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mark Andrews Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mark Andrews List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 12:00:03 -0000 The following reply was made to PR kern/177362; it has been noted by GNATS. From: Mark Andrews To: Michael Tuexen Cc: bug-followup@FreeBSD.org Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS Date: Wed, 27 Mar 2013 22:54:06 +1100 In message <25EB2335-645C-42ED-B90A-6D07A33280DB@freebsd.org>, Michael Tuexen w rites: > It was not done by accident. The returned cmsg_type is IP_RECVTOS instead > of IP_TOS to keep it consistent with the handling of the IP_RECVTTL socket > option. > I found it more important to be consistent within the same protocol family > than across different ones. > I think that unfortunately IP_RECVTOS is not defined in any standard. > > Best regards > Michael And Linux uses IP_TOS to return the value. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 12:20:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 57C409C5 for ; Wed, 27 Mar 2013 12:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 48D806EF for ; Wed, 27 Mar 2013 12:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2RCK1vm078944 for ; Wed, 27 Mar 2013 12:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2RCK1tW078943; Wed, 27 Mar 2013 12:20:01 GMT (envelope-from gnats) Date: Wed, 27 Mar 2013 12:20:01 GMT Message-Id: <201303271220.r2RCK1tW078943@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Michael Tuexen Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Michael Tuexen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 12:20:01 -0000 The following reply was made to PR kern/177362; it has been noted by GNATS. From: Michael Tuexen To: Mark Andrews Cc: bug-followup@FreeBSD.org Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS Date: Wed, 27 Mar 2013 13:16:30 +0100 On Mar 27, 2013, at 12:54 PM, Mark Andrews wrote: >=20 > In message <25EB2335-645C-42ED-B90A-6D07A33280DB@freebsd.org>, Michael = Tuexen w > rites: >> It was not done by accident. The returned cmsg_type is IP_RECVTOS = instead=20 >> of IP_TOS to keep it consistent with the handling of the IP_RECVTTL = socket=20 >> option. >> I found it more important to be consistent within the same protocol = family >> than across different ones. >> I think that unfortunately IP_RECVTOS is not defined in any standard. >>=20 >> Best regards >> Michael >=20 > And Linux uses IP_TOS to return the value. ... which is consistent with the IP_RECVTTL socket option on Linux, = where it returns a cmsg with cmsg_type IP_TTL, which is also different from how this is = handled in FreeBSD. I think Solaris uses for IPv4 socket options the same cmsg_type as the optname for the socket option to enable the reception of the = cmsg. So it looks like there is no standard here, Linux, FreeBSD and Solaris are each consistent with itself, but Linux does it differently from FreeBSD and Solaris. Best regards Michael >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 14:43:07 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C8DEFAC; Wed, 27 Mar 2013 14:43:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 770AF36F; Wed, 27 Mar 2013 14:43:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2REh7fV005812; Wed, 27 Mar 2013 14:43:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2REh7Hi005811; Wed, 27 Mar 2013 14:43:07 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 14:43:07 GMT Message-Id: <201303271443.r2REh7Hi005811@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-mips@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177032: [arge] arge1 fails to attach on UBNT Routerstation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 14:43:07 -0000 Synopsis: [arge] arge1 fails to attach on UBNT Routerstation Responsible-Changed-From-To: freebsd-net->freebsd-mips Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 14:42:08 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177032 From owner-freebsd-net@FreeBSD.ORG Wed Mar 27 23:48:26 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98A59189; Wed, 27 Mar 2013 23:48:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 72DA6A2F; Wed, 27 Mar 2013 23:48:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2RNmQxE008045; Wed, 27 Mar 2013 23:48:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2RNmQia008044; Wed, 27 Mar 2013 23:48:26 GMT (envelope-from linimon) Date: Wed, 27 Mar 2013 23:48:26 GMT Message-Id: <201303272348.r2RNmQia008044@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177417: [ip6] Invalid protocol value in ipsec6_common_input_cb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 23:48:26 -0000 Old Synopsis: Invalid protocol value in ipsec6_common_input_cb New Synopsis: [ip6] Invalid protocol value in ipsec6_common_input_cb Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 27 23:48:07 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177417 From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 02:40:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C2236ECE for ; Thu, 28 Mar 2013 02:40:41 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF6A160 for ; Thu, 28 Mar 2013 02:40:41 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id kw10so7343912vcb.0 for ; Wed, 27 Mar 2013 19:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vpoNrI6kaquYOWivo1gI/CoBBouFIIdNLzz7rsVnYZU=; b=s5Epo9UUFWbDAABJgYcc18DINvS4xUYq/DbgLYN4GVMXfcfc8lHUL440nKy20j4PGl /saZb+BHmJ4zlehuWg8ZvJRy9W8a6kmFvQtB20LC+uMKAfjUobObsRcXNLkA6/vrH9CR TV8ktcU1Uz2//y15/wgownbLNDsQgkKusx0Ijod0CKppeYMT6rISbk7ALYCe1hExWS43 Kn01kTQJp2nMXx38+Nz45w/B9FfyLzqv/x825Xi4ltdb3xaUnaWVC12dzkSH2C71jSla imA+lJ1yN3xvDb9WozYvs3WnjiXczL5EJcA/Z3V2bVEBngIxCLGC5H2slurpwvYFQkZp u7Dw== MIME-Version: 1.0 X-Received: by 10.58.188.48 with SMTP id fx16mr25870609vec.22.1364438435539; Wed, 27 Mar 2013 19:40:35 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Wed, 27 Mar 2013 19:40:35 -0700 (PDT) Date: Wed, 27 Mar 2013 19:40:35 -0700 Message-ID: Subject: ALTQ + igb(4) + 9-.1-RELEASE From: Nick Rogers To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 02:40:41 -0000 I've been using igb(4) in conjunction with ALTQ under 7.x/8.x for years on hundreds of servers. I recently began upgrading my production servers to 9.1-RELEASE, with the GENERIC kernel including ALTQ support. I recently discovered the hard way that igb(4) no longer supports ALTQ. The issue is the same as presented in this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=177402 And these threads: http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034091.html http://lists.freebsd.org/pipermail/freebsd-hackers/2013-January/041631.html Does anyone know if theres has been any resolution to this problem? Is it fixed in STABLE, or is there a patch I can try? I had researched this problem before migrating to 9.1-RELEASE as it seems to have been discovered during 9.1-RC3. I thought it had been fixed in -RELEASE, but apparently not? From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 13:50:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4122106 for ; Thu, 28 Mar 2013 13:50:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6919C8DE for ; Thu, 28 Mar 2013 13:50:02 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:cd63:a817:556f:dff2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id AABD44AC57 for ; Thu, 28 Mar 2013 17:49:54 +0400 (MSK) Date: Thu, 28 Mar 2013 17:49:52 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <394652604.20130328174952@serebryakov.spb.ru> To: "freebsd-net@freebsd.org" Subject: Win7 client, IPv6 network, multicast DNS equests and BIND name server? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 13:50:02 -0000 Hello, Freebsd-net. This question is not very FreeBSD specific, but as my router and DNS server are FreeBSD-based, I think a could ask it here and don't subscribe do BIND-related list, Ok? When DHCPv4 is not available, Win7 clients on my network pick up proper IPv6 prefix, but cannot pick up DNS server name from router advertisment. In such situation Win7 clients try to use ff01:: multicast addresses for DNS resolution. I have bind server, which listens on all addresses (udp6 *:53), but it seems, that it doesn't answer on these requests :( Is it possible to configure BIND (system one) to process such requests? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 14:58:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25353747 for ; Thu, 28 Mar 2013 14:58:37 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id B23DED53 for ; Thu, 28 Mar 2013 14:58:36 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id l10so5041177eei.31 for ; Thu, 28 Mar 2013 07:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e40D9taaT61idDGxJ/AzvtOxQ4FuGL8LhezClle04sc=; b=fFBTbZqidZmENZf5K8Xp3aCq/1LAMBCzuRDIkaE0e07MTwtPHJMzv9i/h3hhw5QnhK E+Erdrhfgu7E6onUy7Vaw018xCSsyYKAVuDgu8+4pY5CRPs4HjrVrpti0jpDxPVYfe8r RxL8Fgo2L6R8e2rfiYdj8pXEO1Tc2eSUHfSjg/EkhDt+e4+lQGrZZP14pWYNxjbKnqR8 QigKg5+g853M7tz8KbgW1cTLcW7eKrFENjF/PEirY1gTYaWuvWYjeohQBXxhMlEnTCEu Q54aWeYK8/QD8GCIzkrUSq0kz+w8pKVA9QLgLXhVQt4omKck0QmbA7vJD9FJO53KRQ2b lU1Q== X-Received: by 10.15.107.205 with SMTP id cb53mr38787279eeb.14.1364482715605; Thu, 28 Mar 2013 07:58:35 -0700 (PDT) Received: from [192.168.0.101] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id 3sm38246666eej.6.2013.03.28.07.58.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 07:58:34 -0700 (PDT) Message-ID: <51545A98.9020506@gmail.com> Date: Thu, 28 Mar 2013 15:58:32 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Win7 client, IPv6 network, multicast DNS equests and BIND name server? References: <394652604.20130328174952@serebryakov.spb.ru> In-Reply-To: <394652604.20130328174952@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 14:58:37 -0000 Am 28.03.2013 14:49, schrieb Lev Serebryakov: > Hello, Freebsd-net. > > This question is not very FreeBSD specific, but as my router and DNS > server are FreeBSD-based, I think a could ask it here and don't > subscribe do BIND-related list, Ok? > > When DHCPv4 is not available, Win7 clients on my network pick up > proper IPv6 prefix, but cannot pick up DNS server name from router > advertisment. In such situation Win7 clients try to use ff01:: > multicast addresses for DNS resolution. > > I have bind server, which listens on all addresses (udp6 *:53), but > it seems, that it doesn't answer on these requests :( > > Is it possible to configure BIND (system one) to process such > requests? > In my experience you need to run a DHCPv6 server along with the rtadvd daemon to get the DNS server to your Win7 box. In rtadvd.conf set the raflags to: :raflags="o":\ This tells the client to look for a DHCPv6 server, and to grab the information supplied there. In your dhcpd.conf (ISC DHCPD) then you need an entry like this: subnet6 2001:db8::/64 { option dhcp6.name-servers 2001:db8::1; } Where the subnet has to reflect the actual subnet configured on the interface you're sending out DHCP offers. In rc.conf add: dhcpd6_enable="YES" dhcpd6_ifaces="em0" or whatever interface DHCP should listen on. And now your Win7 should be happy. Win7 using ff01: for DNS lookups seems a bit strange to me, as I thought that Win7 is using LLMNR (http://en.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution), the counterpart to MDNS (http://en.wikipedia.org/wiki/Multicast_DNS) to look up names on the local Lan and to discover services (http://en.wikipedia.org/wiki/Zero_configuration_networking). Both use addresses from the ff02: range. I've looked into getting MDNS to update BIND like DHCP would do for DDNS, but had no luck to get that going. I don't think LLMNR could interoperate with BIND at all. Hope that helps. Cheers, Mat From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 15:00:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA49E7ED for ; Thu, 28 Mar 2013 15:00:46 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id 64CB2D6E for ; Thu, 28 Mar 2013 15:00:46 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so3395548wib.15 for ; Thu, 28 Mar 2013 08:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tVpz2LpNsLXQ98TvbvVfEgQ97dDUob+5NWB7qWQUFL0=; b=grcIlD4Lww02V049pAlQkY7g07ZIjWWPjHJ7jOa5sYeKFjmwIOlHZAVnh6yfj2dXEX 6PhD6cUd1puVMcssP5XGVrt2ARsWfreZ9O67tzqoInAHXEelZOy3E6vC9dWnWClqZVoi eWT2aEVhuq52oca6bp57XcjsMXrBqO53qDa6IETQtzHCXd0Ykt5VOKWt3RL43LYj75DP s5Z4SbQjNrljJhRqK/ULlyLDlY8Miiq6kKmGn7osDIfbLRJ3Ff7GTjAkl800vwablg47 R1veiTj8IfBk1IHTVhBOw67I7mwYf2gh+7wY4K9PoSM7EOAE+y7TTFjGPa/581Tz8sYu BHmw== X-Received: by 10.180.13.197 with SMTP id j5mr17049428wic.21.1364482845573; Thu, 28 Mar 2013 08:00:45 -0700 (PDT) Received: from [192.168.0.101] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id q13sm16201178wie.0.2013.03.28.08.00.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 08:00:44 -0700 (PDT) Message-ID: <51545B1B.2010807@gmail.com> Date: Thu, 28 Mar 2013 16:00:43 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Win7 client, IPv6 network, multicast DNS equests and BIND name server? References: <394652604.20130328174952@serebryakov.spb.ru> <51545A98.9020506@gmail.com> In-Reply-To: <51545A98.9020506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 15:00:46 -0000 Am 28.03.2013 15:58, schrieb Mattia Rossi: > Am 28.03.2013 14:49, schrieb Lev Serebryakov: >> Hello, Freebsd-net. >> >> This question is not very FreeBSD specific, but as my router and DNS >> server are FreeBSD-based, I think a could ask it here and don't >> subscribe do BIND-related list, Ok? >> >> When DHCPv4 is not available, Win7 clients on my network pick up >> proper IPv6 prefix, but cannot pick up DNS server name from router >> advertisment. In such situation Win7 clients try to use ff01:: >> multicast addresses for DNS resolution. >> >> I have bind server, which listens on all addresses (udp6 *:53), but >> it seems, that it doesn't answer on these requests :( >> >> Is it possible to configure BIND (system one) to process such >> requests? >> > In my experience you need to run a DHCPv6 server along with the rtadvd > daemon to get the DNS server to your Win7 box. > In rtadvd.conf set the raflags to: > :raflags="o":\ > > This tells the client to look for a DHCPv6 server, and to grab the > information supplied there. > In your dhcpd.conf (ISC DHCPD) then you need an entry like this: Sorry, should be dhcpd6.conf > > subnet6 2001:db8::/64 { > option dhcp6.name-servers 2001:db8::1; > } > > Where the subnet has to reflect the actual subnet configured on the > interface you're sending out DHCP offers. > > In rc.conf add: > dhcpd6_enable="YES" > dhcpd6_ifaces="em0" or whatever interface DHCP should listen on. > > And now your Win7 should be happy. > > Win7 using ff01: for DNS lookups seems a bit strange to me, as I > thought that Win7 is using LLMNR > (http://en.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution), > the counterpart to MDNS (http://en.wikipedia.org/wiki/Multicast_DNS) > to look up names on the local Lan and to discover services > (http://en.wikipedia.org/wiki/Zero_configuration_networking). Both use > addresses from the ff02: range. > > I've looked into getting MDNS to update BIND like DHCP would do for > DDNS, but had no luck to get that going. > I don't think LLMNR could interoperate with BIND at all. > > Hope that helps. > > Cheers, > > Mat > From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 15:58:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7246A4F for ; Thu, 28 Mar 2013 15:58:17 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADDA410A for ; Thu, 28 Mar 2013 15:58:17 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:cd63:a817:556f:dff2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 199454AC58; Thu, 28 Mar 2013 19:58:16 +0400 (MSK) Date: Thu, 28 Mar 2013 19:58:13 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1117653326.20130328195813@serebryakov.spb.ru> To: Mattia Rossi Subject: Re: Win7 client, IPv6 network, multicast DNS equests and BIND name server? In-Reply-To: <51545A98.9020506@gmail.com> References: <394652604.20130328174952@serebryakov.spb.ru> <51545A98.9020506@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:58:18 -0000 Hello, Mattia. You wrote 28 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2013 =D0=B3., 18:58:32: MR> And now your Win7 should be happy. I don't want to add second dhcpd (unfortunately, isc-dhcpd could not process IPv4 and IPv6 in single process), and it is not a problem to have IPv4 only DNS when dhcpd is accessible. And if dhcpd is not accessible, dhcpd6 will not be too :) MR> Win7 using ff01: for DNS lookups seems a bit strange to me, as I thought MR> that Win7 is using LLMNR=20 MR> (http://en.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution), the MR> addresses from the ff02: range. It is my typo, ff02:, of course. MR> I've looked into getting MDNS to update BIND like DHCP would do for=20 MR> DDNS, but had no luck to get that going. I've tried to get ANY DDNS updates from Win7 without AD, but it looks like there is no updates are sent :( But it is another question, and it is much more windows-related. MR> I don't think LLMNR could interoperate with BIND at all. :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 16:54:34 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65F9247C; Thu, 28 Mar 2013 16:54:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 10C8F5FC; Thu, 28 Mar 2013 16:54:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA10475; Thu, 28 Mar 2013 18:54:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <515475C7.6010404@FreeBSD.org> Date: Thu, 28 Mar 2013 18:54:31 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, FreeBSD Hackers Subject: close(2) while accept(2) is blocked X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 16:54:34 -0000 So, this started as a simple question, but the answer was quite unexpected to me. Let's say we have an opened and listen-ed socket and let's assume that we know that one thread is blocked in accept(2) and another thread is calling close(2). What is going to happen? Turns out that practically nothing. For kernel the close call would be almost a nop. My understanding is this: - when socket is created, its reference count is 1 - when accept(2) is called, fget in kernel increments the reference count (kept in an associated struct file) - when close(2) is called, the reference count is decremented The reference count is still greater than zero, so fdrop does not call fo_close. That means that in the case of a socket soclose is not called. I am sure that the reference counting in this case is absolutely correct with respect to managing kernel side structures. But I am not that it is correct with respect to hiding the explicit close(2) call from other threads that may be waiting on the socket. In other words, I am not sure if fo_close is supposed to signify that there are no uses of a file, or that userland close-d the file. Or perhaps these should be two different methods. Additional note is that shutdown(2) doesn't wake up the thread in accept(2) either. At least that's true for unix domain sockets. Not sure if this is a bug. But the summary seems to be is that currently it is not possible to break a thread out of accept(2) (at least without resorting to signals). -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 19:44:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E8C8CFB for ; Thu, 28 Mar 2013 19:44:06 +0000 (UTC) (envelope-from sathler90@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 2CFF3EF5 for ; Thu, 28 Mar 2013 19:44:06 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id d7so3012759wer.26 for ; Thu, 28 Mar 2013 12:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=82/wynNb9CAdML77tlP9r9/8eCKaGjs87t0usPtjLvU=; b=Qlkh13VOK8U97BqJmYspiHyPJHz4xkSnkvvuraPNQI055PC/U/TFIlkKRsKplGm/65 vadIQ4UR6lKxo7Jo69YMIIcPykEIKBa107BQZKY0GPmy7V7cbHj9WKEihFx88NYYjLxp kPVuZMrKkVqMPFPDNQn9KWCh59abmOVy/I4kRUEsg3+nzH/TZFuB4kYmzl3yfuSP9cCm gU9EWZ4ry9HpcSve9hrllApnQBZUx5BG8+xJxrrwpgHAJ5CbHtGaBkIDamMbUME+nCD2 LrSEL6MpkdlyTIuYSiN2SalphDQGmQMxfhYVs6qTsFsN/SWQjidWKw7+I4QOmzhzUB1j Od8Q== MIME-Version: 1.0 X-Received: by 10.194.235.196 with SMTP id uo4mr40501681wjc.30.1364499845220; Thu, 28 Mar 2013 12:44:05 -0700 (PDT) Received: by 10.180.107.8 with HTTP; Thu, 28 Mar 2013 12:44:05 -0700 (PDT) Date: Thu, 28 Mar 2013 16:44:05 -0300 Message-ID: Subject: 2 vlans - setfib - kernel: arpresolve: can't allocate llinfo for x.x.x.x From: Eduardo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 19:44:06 -0000 Hi Folks, I have a server with a 10G intel card, X520-DA2, and it is working fine, interface shows up as ix0 On this card, I have one interface connected at 10G, and it has 2 vlans on it (no "plain" IP is on the machine or on this card, only via these vlans) I have it also configured them with setfib on rc.local, so each vlan is on your own fib and sees a different default gateway etc. I removed the other net and gateway from the FIBs, so one FIB has to go to the gateway in order to reach the other vlan. I can ssh to the vlan10 fine ... and I can even do iperf UDP tests between the two vlans, but TCP does not work... and I keep getting these messages: kernel: arpresolve: can't allocate llinfo for I already removed IPFW from the kernel, (saw some reference to that being the culprit), so there is no firewall right now. This is now on FreeBSD 8 STABLE ( to be more exact: 8.4-beta-1) and it was before on 9.1, both have the same problem. I also tried something I saw on a list, hard coding ixgbe_num_queues, but made no difference either. Any ideias are appreciated. thanks -Ed From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 21:31:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33D3F2A9; Thu, 28 Mar 2013 21:31:02 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by mx1.freebsd.org (Postfix) with ESMTP id D9833400; Thu, 28 Mar 2013 21:31:01 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id pb11so5613693veb.34 for ; Thu, 28 Mar 2013 14:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uBb6lZZiwdG2q7738maVdy2/Zo090JEcR8rsv0HyVw8=; b=LWqR4Wq9rX7wU973yD88+BaH+H4NjvF/FMWvc32aZWok/OWvVng2JI8a/MYYRVoVh4 sBJtdQCcwPJjR9nYOw80zmIiXK77MnUKnJc9L9VIATG5wS+blSVuqxPvyoLUURctMZXB jeEFHtmGPRJZwi3GGWedBLltjmprwG/EZhcmighBCphlp8OZTJBnm+jQsNNRA+yydB74 Ww6MinWstW852L4/xfDmlH+ywLgR0EJxbirj56gy5cRt0RO0BZLBdcHhJDfNQJFfycyr YHrGMd2TKAWHjrxojEsN+Rm6BzcSm0oD3rCZ/kMwMrIPWX0PPc+/RVjxQ9OSYPHBPRCx 05ug== MIME-Version: 1.0 X-Received: by 10.220.108.69 with SMTP id e5mr132405vcp.47.1364506260851; Thu, 28 Mar 2013 14:31:00 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Thu, 28 Mar 2013 14:31:00 -0700 (PDT) In-Reply-To: References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> Date: Thu, 28 Mar 2013 14:31:00 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Barney Cordoba , "Clement Hermann \(nodens\)" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 21:31:02 -0000 On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff wrote: > >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >> J> UH, maybe asking the owner of the driver would help :) >> J> >> J> ... and no, I've never been aware of doing anything to stop supporting >> altq >> J> so you wouldn't see any commits. If there's something in the altq code >> or >> J> support (which I have nothing to do with) that caused this no-one >> informed >> J> me. >> >> Switching from if_start to if_transmit effectively disables ALTQ support. >> >> AFAIR, there is some magic implemented in other drivers that makes them >> modern (that means using if_transmit), but still capable to switch to >> queueing >> mode if SIOCADDALTQ was casted upon them. >> >> > Oh, hmmm, I'll look into the matter after my vacation. > > Jack Has there been any progress on resolving this issue? I recently ran into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am wondering what the latest recommendation is. I've used ALTQ and igb successfully for years and it is unfortunate it no longer works. Appreciate any advice. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 23:16:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9766CAB8; Thu, 28 Mar 2013 23:16:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id 45A239F7; Thu, 28 Mar 2013 23:16:17 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id hr11so62799vcb.3 for ; Thu, 28 Mar 2013 16:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XYivFKy4lJcbKW+37uaYqmn6BvUxFnVfEGDGmOCO2SQ=; b=EhWBkepjkXkk1lH7NtiaHZ0uP7MrLzsDVNppvc/EqziLECBfX7NceX/egIuZ/IMtxy aK5FomFuoByC2klPT+MpLkAtYPGht3cq0P9fm12/0/640TtGRMDgVa9uEYJBIHejeMpX 47p+wHS1X1RPFfS8qU/etW44AiEUHDMFotQKg/3jOmhAbh5QtVp0uz0/kf9ddBRJH2t3 JshbhTaCB8Hw3qkbvjSAXSo5NJvdsccd+HRnCi/XMQZzjkzN98MqQDqEHYDGEHvcsHPK p1BouEqGeaQ5qxDMGAHjxmUsg2jQV2o9DrCs46g/6eQEHQYvBn9N5NWpzJrXH3+bDZie 0uag== MIME-Version: 1.0 X-Received: by 10.58.161.6 with SMTP id xo6mr364606veb.50.1364512577215; Thu, 28 Mar 2013 16:16:17 -0700 (PDT) Received: by 10.220.140.14 with HTTP; Thu, 28 Mar 2013 16:16:17 -0700 (PDT) In-Reply-To: References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> Date: Thu, 28 Mar 2013 16:16:17 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Jack Vogel To: Nick Rogers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , "Clement Hermann \(nodens\)" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 23:16:18 -0000 Have been kept fairly busy with other matters, one thing I could do short term is change the defines in igb the way I did in the em driver so you could still define the older if_start entry. Right now those are based on OS version and so you will automatically get if_transmit, but I could change it to be IGB_LEGACY_TX or so, and that could be defined in the Makefile. Would this help? Jack On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: > On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: > > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff > wrote: > > > >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: > >> J> UH, maybe asking the owner of the driver would help :) > >> J> > >> J> ... and no, I've never been aware of doing anything to stop > supporting > >> altq > >> J> so you wouldn't see any commits. If there's something in the altq > code > >> or > >> J> support (which I have nothing to do with) that caused this no-one > >> informed > >> J> me. > >> > >> Switching from if_start to if_transmit effectively disables ALTQ > support. > >> > >> AFAIR, there is some magic implemented in other drivers that makes them > >> modern (that means using if_transmit), but still capable to switch to > >> queueing > >> mode if SIOCADDALTQ was casted upon them. > >> > >> > > Oh, hmmm, I'll look into the matter after my vacation. > > > > Jack > > Has there been any progress on resolving this issue? I recently ran > into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am > wondering what the latest recommendation is. I've used ALTQ and igb > successfully for years and it is unfortunate it no longer works. > Appreciate any advice. > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Mar 28 23:47:56 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 792D02AF; Thu, 28 Mar 2013 23:47:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 0B550B1F; Thu, 28 Mar 2013 23:47:56 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 751A135930F; Fri, 29 Mar 2013 00:47:53 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 5C2752848C; Fri, 29 Mar 2013 00:47:53 +0100 (CET) Date: Fri, 29 Mar 2013 00:47:53 +0100 From: Jilles Tjoelker To: Andriy Gapon Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130328234753.GA88844@stack.nl> References: <515475C7.6010404@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515475C7.6010404@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 23:47:56 -0000 On Thu, Mar 28, 2013 at 06:54:31PM +0200, Andriy Gapon wrote: > So, this started as a simple question, but the answer was quite > unexpected to me. > Let's say we have an opened and listen-ed socket and let's assume that > we know that one thread is blocked in accept(2) and another thread is > calling close(2). What is going to happen? > Turns out that practically nothing. For kernel the close call would > be almost a nop. > My understanding is this: > - when socket is created, its reference count is 1 > - when accept(2) is called, fget in kernel increments the reference > count (kept in an associated struct file) > - when close(2) is called, the reference count is decremented > The reference count is still greater than zero, so fdrop does not call > fo_close. That means that in the case of a socket soclose is not > called. > I am sure that the reference counting in this case is absolutely > correct with respect to managing kernel side structures. I agree this is expected and correct from the kernel point of view. > But I am not that it is correct with respect to hiding the explicit > close(2) call from other threads that may be waiting on the socket. In > other words, I am not sure if fo_close is supposed to signify that > there are no uses of a file, or that userland close-d the file. Or > perhaps these should be two different methods. It would be possible to keep track of the file descriptor number but I think it is not worth the large amount of extra code. Keeping track of file descriptor number would be necessary to interrupt waits after a close or dup2 on the file descriptor that was passed to the blocking call, even if the object remains open on a different file descriptor number or in a different process. Also, most people would use the new functionality incorrectly anyway. A close() on a file descriptor another thread is using is risky since it is in most cases impossible to prove that the other thread is in fact blocked on the file descriptor and not preempted right before making the system call. In the latter case, the other thread might accept a connection from a different socket created later. A dup2() of /dev/null onto the file descriptor would be safer. > Additional note is that shutdown(2) doesn't wake up the thread in > accept(2) either. At least that's true for unix domain sockets. > Not sure if this is a bug. I think it is a bug. It works properly for IPv4 TCP sockets. The resulting error is [ECONNABORTED] for a blocking socket which likely leads to infinite looping if the thread does not know about the shutdown(2) (because that error normally means the accept should be retried later). For a non-blocking socket the error is [EWOULDBLOCK] which also leads to infinite looping and is certainly wrong because select/poll do report the socket as readable. Both of these are in kern_accept() in sys/kern/uipc_syscalls.c. POSIX does not say which error code we should return here but these two are almost certainly wrong (it is usable for waking up threads stuck in accept() if those threads check a variable after every accept() failure and do not rely on the exact value of errno). Linux returns [EINVAL] for both blocking and non-blocking sockets, probably from the POSIX error condition "The socket is not accepting connections." In our man page that error condition is formulated "listen(2) has not been called on the socket descriptor." which is clearly not the case. Also, I think a non-blocking accept() should immediately fail with the head->so_error if it is set, rather than returning [EWOULDBLOCK] until another connection arrives. Likewise, filt_solisten() in sys/kern/uipc_socket.c only returns true if there is a connection, not if there was an error or shutdown() has been called. On the other hand, sopoll_generic() looks correct. Error reporting on non-blocking accept() might usefully be postponed until there is a connection or the socket has been shut down, to reduce context switches. > But the summary seems to be is that currently it is not possible to > break a thread out of accept(2) (at least without resorting to > signals). Pthread cancellation works better than raw signals for this use case. In a proper implementation such as in FreeBSD 9.0 or newer and used properly, it allows avoiding the resource leak that may happen when calling longjmp() or pthread_exit() in a signal handler just after accept() has created a new socket. -- Jilles Tjoelker From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 01:29:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 21646BCE; Fri, 29 Mar 2013 01:29:19 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id C44FE95; Fri, 29 Mar 2013 01:29:18 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id cy12so147199veb.18 for ; Thu, 28 Mar 2013 18:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DkP94A5qt1mgTxVFUkfBYU2LcYRvLa4WSuiL6frpmm8=; b=yODw8vG9iaS4VeE9Qx4TYa5gjXUn8HETBFBlEeCA8UfhZ5Q1O3GV3v3Wl7O+dC6tJR 9mHj/FUeMop1/7kNxftyosa6FOnfiyg0RDMzQn23LPfPjVtL9u/KLNg8MJp2MHURj/HF ngqVNFJB8w8oCTWmolZ8Tns5v5vAIh1fVGDJYDUlRJ3FkS6UoFV76LSTwctv+9DnSxlz 82dwa/Kxq+yGJkuGurURAUalzMrQb8gxH72uxhA1oTadILkqc9kHhoB35JOXxIU4rXKJ lfPHzcgWz8MOuKKu7LB+0hXNcWOZGmFHzZdC8E1HBKW+236IdBGEmYVby06xfaHiewOu 0XoA== MIME-Version: 1.0 X-Received: by 10.58.80.4 with SMTP id n4mr737164vex.5.1364520557674; Thu, 28 Mar 2013 18:29:17 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Thu, 28 Mar 2013 18:29:17 -0700 (PDT) In-Reply-To: References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> Date: Thu, 28 Mar 2013 18:29:17 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Barney Cordoba , "Clement Hermann \(nodens\)" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 01:29:19 -0000 On Thu, Mar 28, 2013 at 4:16 PM, Jack Vogel wrote: > Have been kept fairly busy with other matters, one thing I could do short > term is > change the defines in igb the way I did in the em driver so you could still > define > the older if_start entry. Right now those are based on OS version and so you > will > automatically get if_transmit, but I could change it to be IGB_LEGACY_TX or > so, > and that could be defined in the Makefile. > > Would this help? I'm currently using ALTQ successfully with the em driver, so if igb behaved the same with respect to using if_start instead of if_transmit when ALTQ is in play, that would be great. I do not completely understand the change you propose as I am not very familiar with the driver internals. Any kind of patch or extra Makefile/make.conf definition that would allow me to build a 9-STABLE kernel with an igb driver that works again with ALTQ, ASAP, would be much appreciated. > > Jack > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote: >> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote: >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff >> > wrote: >> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote: >> >> J> UH, maybe asking the owner of the driver would help :) >> >> J> >> >> J> ... and no, I've never been aware of doing anything to stop >> >> supporting >> >> altq >> >> J> so you wouldn't see any commits. If there's something in the altq >> >> code >> >> or >> >> J> support (which I have nothing to do with) that caused this no-one >> >> informed >> >> J> me. >> >> >> >> Switching from if_start to if_transmit effectively disables ALTQ >> >> support. >> >> >> >> AFAIR, there is some magic implemented in other drivers that makes them >> >> modern (that means using if_transmit), but still capable to switch to >> >> queueing >> >> mode if SIOCADDALTQ was casted upon them. >> >> >> >> >> > Oh, hmmm, I'll look into the matter after my vacation. >> > >> > Jack >> >> Has there been any progress on resolving this issue? I recently ran >> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am >> wondering what the latest recommendation is. I've used ALTQ and igb >> successfully for years and it is unfortunate it no longer works. >> Appreciate any advice. >> >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 04:25:45 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2554BFAA; Fri, 29 Mar 2013 04:25:45 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F317BA79; Fri, 29 Mar 2013 04:25:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2T4PiIO052390; Fri, 29 Mar 2013 04:25:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2T4Pi44052389; Fri, 29 Mar 2013 04:25:44 GMT (envelope-from linimon) Date: Fri, 29 Mar 2013 04:25:44 GMT Message-Id: <201303290425.r2T4Pi44052389@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177456: [tcp] [patch] An error of calculating TCP sequence number will resault in the machine to restart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 04:25:45 -0000 Old Synopsis: An error of calculating TCP sequence number will resault in the machine to restart New Synopsis: [tcp] [patch] An error of calculating TCP sequence number will resault in the machine to restart Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 29 04:25:17 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177456 From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 09:57:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6197D3C8 for ; Fri, 29 Mar 2013 09:57:52 +0000 (UTC) (envelope-from jean@femrice.com) Received: from mail.us4.cn4e.com (us4.cn4e.com [216.245.204.26]) by mx1.freebsd.org (Postfix) with ESMTP id DE30E7B2 for ; Fri, 29 Mar 2013 09:57:51 +0000 (UTC) Received: from mail.mail72.cn4e.com (mail.mail72.cn4e.com [218.107.207.72]) by mail.us4.cn4e.com (Postfix) with ESMTP id D831F132CE1 for ; Fri, 29 Mar 2013 04:57:44 -0500 (CDT) Received: from mail72.cn4e.com (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP id CE044600238 for ; Fri, 29 Mar 2013 17:57:34 +0800 (CST) Received: from mail72.cn4e.com (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP for ; Fri, 29 Mar 2013 17:57:34 +0800 (CST) From: =?UTF-8?B?546L5Z2kIA==?= To: Subject: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets Date: Fri, 29 Mar 2013 17:57:34 +0800 (CST) Message-Id: <1364551054742@mail72.cn4e.com> Sender: C35-RECALL: 5aeb4fc83db2a83d013db594a41c5fad MIME-Version: 1.0 X-Mailer: 35 Intelli-AntiSpam Mail System V3.0 (x64) ~ www.35.com X-Priority: 3 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 09:57:52 -0000 SGVsbG8sDQpJIGFtIGplYW4gYW5kIHZlcnkgZ2xhZCB0byBrbm93IHlvdSBmcm9tIEdvb2dsZSB3 ZWJzaXRlIC5DaGVja2VkIHlvdXIgd2Vic2l0ZSBhbmQgbWF5YmUgeW91ciBjdXN0b21lciBuZWVk IG91ciBwcm9kdWN0cyBzbyAgDQpXcml0ZSB0byB5b3UgYW5kIHRhbGsgYWJvdXQgd2hldGhlciB3 ZSBjb3VsZCBjb29wZXJhdGUgd2l0aCBlYWNoIG90aGVyIGluIHRoZSBmdXJ0aGVyIC4NCndlIGFy ZSB0aGUgbWFudWZhY3R1cmVyIG9mIFBDSSBFeHByZXNzIDFHICYxMEcgRXRoZXJuZXQgTklDIENh cmQoU2VydmVyIEFkYXB0ZXIgTklDIENhcmRzKSxJbnRlbCBjaGlwc2V0cywgT3VyIEZlbXJpY2Ug DQpicmFuZCAuQ0UsRkMsUk9IUywgU3RvY2ssIGxpZmV0aW1lIHdhcnJhbnR5LlZlcnkgZ29vZCBw cmljZSBpbiB0aGUgbWFya2V0LiANCndlIGFsc28gc3VwcGx5IFNGUCAsU0ZQKyxYRlAgYW5kIG90 aGVyIHNwZWNpYWwgbW9kdWxlcyAuDQpUaGUgRm9sbG93aW5nIG9uZSBpcyBvdXIgbWFpbmx5IE5J QyBDYXJkczoNCkZpYmVyIGNhcmRzIDoNCjEuIFBDSSBFeHByZXNzKHg0LykgRHVhbCBQb3J0IEdp Z2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICwgU0ZQIFNsb3QgLExDLCBJ bnRlbDgyNTcxRUIgQ2hpcHNldCBjb250cm9sbGVyICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBGDQoy LiBQQ0kgRXhwcmVzcyAoeDQpIER1YWwgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBG aWJlciBOSUMgQ2FyZCAsU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTc2RUIgQ2hpcHNldCBjb250cm9s bGVyICwgIFR5cGUgTnVtYmVyIDogMTAwMDJFRg0KMy5QQ0kgRXhwcmVzcyh4NCkgIER1YWwgUG9y dCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciBOSUMgQ2FyZCAsU0ZQIFNsb3QgLExD LCBJbnRlbDgyNTgwREJDaGlwc2V0IGNvbnRyb2xsZXIgLCAgVHlwZSBOdW1iZXIgOiAxRzJEQjU4 MC1TRlANCjQuIFBDSSBFeHByZXNzICh4NCkgU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBO SUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU3MkVJIENoaXBz ZXQgY29udHJvbGxlciAsICBUeXBlIE51bWJlciA6IDEwMDAxUEYNCjUuIFBDSSBFeHByZXNzICh4 MSkgU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQg LFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MyBDaGlwc2V0IGNvbnRyb2xsZXIgLCAgVHlwZSBOdW1i ZXIgOiAxR1BGNTgzLVNGUA0KNi5QQ0kgRXhwcmVzcyAoeDgpIER1YWwgUG9ydCAxMEcgRXRoZXJu ZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAsTEMsIEludGVsODI1OTlFUyBD aGlwc2V0IGNvbnRyb2xsZXIgLCAgVHlwZSBOdW1iZXIgOiAxMEcyQkYtU0ZQKw0KNy4gUENJIEV4 cHJlc3MoeDQvKSBEdWFsIFBvcnQvU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2Fy ZCwgRmliZXIgLCBTRlAgU2xvdCAsTEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xsZXIg LCBqdXN0IFRyYW5zbWlzc2l2ZSBubyByZWNlaXZlciANCmZ1bmN0aW9ucyBUeXBlIE51bWJlciA6 IDFHMkJGNTcxLVRYIChNYWlubHkgdXNlZCBpbiBVbmktZGlyZWN0aW9uYWwgR0FQICkNCjguUENJ IEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQvU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMg Q2FyZCwgRmliZXIgLCBTRlAgU2xvdCAsTEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xs ZXIgLCBqdXN0IFJlY2VpdmVyIG5vIFRyYW5zbWlzc2lvbg0KZnVuY3Rpb25zIFR5cGUgTnVtYmVy IDogMUcyQkY1NzEtUlggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0KDQpD b3BwZXIgTklDIENhcmRzOg0KMS4gUENJIEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQgR2lnYWJpdCBF dGhlcm5ldCBOSUMgQ2FyZCwgQ29wcGVyIE5JQyxSSjQ1IFNsb3QgLCBJbnRlbDgyNTcxRUIgQ2hp cHNldCBjb250cm9sbGVyICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBUDQoyLiBQQ0kgRXhwcmVzcyh4 NC8pIER1YWwgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBDb3BwZXIgTklDLFJKNDUg U2xvdCAsIEludGVsODI1NzZFQiBDaGlwc2V0IGNvbnRyb2xsZXIgLCBUeXBlIE51bWJlciA6IDEw MDAyRVQNClBseiByZXBseSB0byBtZSBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gb3VyIFByb2R1 Y3RzIC4NCkhvcGUgd2UgaGF2ZSBjaGFuY2UgdG8gY29vcGVyYXRlIHdpdGggZWFjaCBvdGhlciBp biB0aGUgZnVydGhlciAuDQpJZiB5b3UgaGF2ZSBTa3lwZSBvciBNU04gSUQgaXMgbW9yZSBiZXR0 ZXIgLE15IHNreXBlIDogRHJlYW0tZmx5OTkNCkJlc3QgUmVnYXJkcw0KSmVhbiBoZW5nDQoNCkZl bXJpY2UgKENoaW5hKSBUZWNobm9sb2d5IENvLiwgTHRkLg0KVGVsOjAwODYtMTAtNTEyNjY4MDct ODEzDQpNb2JpbGU6MDA4Ni0xMzAwMTAyMzYxNQ0KRmF4OiAwMDg2LTEwLTYyOTc5MzQzDQpFbWFp bDogSmVhbkBmZW1yaWNlLmNvbSAgIEplYW5AZmVtcmljZS5jb20uY24NCldlYnNpdGVzOiBodHRw Oi8vd3d3LmV0aGVybmV0c2VydmVyYWRhcHRlci5jb20vICAgICAgICAgIHd3dy5mZW1yaWNlLmNv bSANClNreXBlOiBEcmVhbS1mbHk5OQ0KTVNOOiBEcmVhbS1mbHk5OUBIb3RtYWlsLmNvbQ0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 11:53:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8EF1EA25 for ; Fri, 29 Mar 2013 11:53:23 +0000 (UTC) (envelope-from rlp@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 46764D92 for ; Fri, 29 Mar 2013 11:53:22 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 33872C3850 for ; Fri, 29 Mar 2013 12:53:21 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id WX5qxIhkDsIA for ; Fri, 29 Mar 2013 12:53:20 +0100 (CET) Received: from [10.0.2.212] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 9A51CC384A for ; Fri, 29 Mar 2013 12:53:20 +0100 (CET) Message-ID: <515580B0.2070205@semihalf.com> Date: Fri, 29 Mar 2013 12:53:20 +0100 From: Pablo Ribalta Lorenzo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: vlan with modified MAC fails to communicate Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 11:53:23 -0000 Hi there! Lately I've been investigating an issue that I would like to share, as I feel I may have to attack it from a different end. I have an ethernet interface from where I create a vlan. Once I set up the ip address in the vlan I can ping correctly on both sides. The issue arrives when I try to change the MAC address of the vlan, as from then on it fails to communicate unless: - I restore vlan's MAC address to its previous value - I enable promisc mode. It's also worth to mention that my current setup is FreeBSD 8.3 and the NIC driver I'm using is not fully mature. I was wondering if this behavior is due to some limitations in the NCI driver I'm using or if in fact it's the correct way to proceed, as it was possible to reproduce this same issue in FreeBSD 8.3 and FreeBSD CURRENT versions, even using more mature NIC drivers as 'em' and 're'. Could somebody please shed some light in this? Thank you. -- Pozdrawiam, Pablo Ribalta Lorenzo From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 12:10:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65A663AF for ; Fri, 29 Mar 2013 12:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 57AD3EB9 for ; Fri, 29 Mar 2013 12:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2TCA2h7038534 for ; Fri, 29 Mar 2013 12:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2TCA2d1038533; Fri, 29 Mar 2013 12:10:02 GMT (envelope-from gnats) Date: Fri, 29 Mar 2013 12:10:02 GMT Message-Id: <201303291210.r2TCA2d1038533@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Gleb Smirnoff Subject: Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 12:10:02 -0000 The following reply was made to PR kern/177456; it has been noted by GNATS. From: Gleb Smirnoff To: HouYeFei&XiBoLiu Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart Date: Fri, 29 Mar 2013 16:08:03 +0400 HouYeFei & XiBoLiu, On Thu, Mar 28, 2013 at 11:55:04PM +0000, HouYeFei&XiBoLiu wrote: H> >Number: 177456 H> >Category: misc H> >Synopsis: An error of calculating TCP sequence number will resault in the machine to restart H> >Confidential: no H> >Severity: non-critical H> >Priority: low H> >Responsible: freebsd-bugs H> >State: open H> >Quarter: H> >Keywords: H> >Date-Required: H> >Class: sw-bug H> >Submitter-Id: current-users H> >Arrival-Date: Fri Mar 29 00:00:00 UTC 2013 H> >Closed-Date: H> >Last-Modified: H> >Originator: HouYeFei&XiBoLiu H> >Release: FreeBSD-9.0 H> >Organization: H> H3C H> >Environment: H> FreeBSD www.unixnotes.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sun May 4 12:36:15 HKT 2012 root@www.unixnotes.net:/usr/src/sys/i386/compile/unixnotes i386 H> >Description: H> There is a large number of TCP links between Client and Server, each link can transmit large amounts of data. When the Client is low on memory, at the same time it wants to establish a new TCP connection to the server. The Client sends SYN message and startups retransmission timer, but retransmission of the first time H> H> sends failed because there is not enough mbuf.At this time, a sequence number is transmitted messages on the tcpcb (tp->snd_nxt) regression. Then H> H> a syn+ack message is received and processing the tp->snd_una sequence number is increased by 1, resault in tp->snd_nxt < th->snd_una. It is likely that H> H> the sending buffer has data to send, but actually is empty, call H> H> Tcp_output to send ack to the Server. But Tcp_output enter to the mbuf replication process, leading to access a null pointer. I am trying to reproduce the problem, with no success yet. Can you please clarify the sequence of failures that is required? I understand your submission in the following way: Client performs connect(2). Client TCP stack generates SYN packet, and this packet is lost in network. Client TCP stack tries to retransmit SYN packet, buf mbuf allocation fails. Client TCP stack retransmits SYN packet. Server replies with SYN+ACK. ... and according to you smth should go wrong ... But in my tests nothing goes wrong. Client successfully retransmits SYN and connection is established. This is how I instrument this. I have added special TCP option and set it before doing connect. The tcp_output() emulates failures that you described: Index: tcp_output.c =================================================================== --- tcp_output.c (revision 248873) +++ tcp_output.c (working copy) @@ -898,6 +898,13 @@ send: else TCPSTAT_INC(tcps_sndwinup); + /* Fail allocating second packet. */ + if (tp->t_flags & TF_ZHOPA && tp->t_zhopa == 1) { + tp->t_zhopa = 2; + m = NULL; + error = ENOBUFS; + goto out; + } else m = m_gethdr(M_NOWAIT, MT_DATA); if (m == NULL) { error = ENOBUFS; @@ -1273,6 +1280,13 @@ timer: if (V_path_mtu_discovery && tp->t_maxopd > V_tcp_minmss) ip->ip_off |= htons(IP_DF); + /* Lose first packet. */ + if (tp->t_flags & TF_ZHOPA && tp->t_zhopa == 0) { + tp->t_zhopa = 1; + m_freem(m); + error = 0; + } else + error = ip_output(m, tp->t_inpcb->inp_options, &ro, ((so->so_options & SO_DONTROUTE) ? IP_ROUTETOIF : 0), 0, tp->t_inpcb); Am I doing something wrong? Can you provide your way to reproduce this? Do you have backtrace of the panic? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 12:52:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07B6BF84 for ; Fri, 29 Mar 2013 12:52:58 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm35-vm6.bullet.mail.ne1.yahoo.com (nm35-vm6.bullet.mail.ne1.yahoo.com [98.138.229.102]) by mx1.freebsd.org (Postfix) with ESMTP id BCEDD142 for ; Fri, 29 Mar 2013 12:52:56 +0000 (UTC) Received: from [98.138.90.51] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 12:51:12 -0000 Received: from [98.138.88.235] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 12:51:12 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 12:51:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 205908.68888.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 48589 invoked by uid 60001); 29 Mar 2013 12:51:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364561471; bh=pK1yhNbCBIC6lP7s/vhwct29x4Lv4/f3dckXxE2KUTs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IkM/QVWdgabzS+msIKFIHMe2nGibeBYMKRa/4PU3WgnYYT+nPLDyn9FjpjfdgCa++wtdesEpFlEtCYSGExee/xMpbedcrwqoR16RfDWxZ4i+w7Pbz8TxQFpcZhYcM3GnUtZseE1qHJAtApMY13napHSxO8GXDmUOxBE8FxgCUTc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ngb1YkS7mZh2ZmH5VtZ6XTdkxXEAfraZOQDzAYEsxlb08yuW/11EAbVZ4ZgyO21tzrc2b87QlDFnG+MXRxqn0O6lx/EtlPuQ9T9MvLF5a3VqWDrQi/LAaRL+9CYSVDEX7lvZhobLRyrpk/WaDv3pSUjN+bbL1jjnw7PtPVAHgbY=; X-YMail-OSG: nX323PgVM1nYSJXZ.xZUhraWoVm79uhVloneHAnanwMwreW 8rz5oD7Mlxzv26Lj.wX6KJczy1HpTgVpkgPhSf2rpTvWt_sPymn9WOmCp7AP RlFMruFxLV01RhmzVE97JMYpFt8S_cFQaefQODJt8tqLAXqJf9yTBd1_zhc8 5Fy3Q12pxPr7A4m8H2ysV5F8U.TTIC28AcDznSmPIE41y4ertiAJlRD1emVR m0HyTVJ0_CfurO.8DG6uaFWyvyBZcd9JIo0_OwD_RE872arHoeWsHr1WWwf8 8YwJU.Wm4n9XGd6axsEs3PT1S1SeQZ4_SnbyQZ4tZjEtcuaO5Rd0bnEnSgfC EcSs5uEiq3bSiBQW1dtH1pL4mLRsDslcXuU76Dk7Jzhmh_N2nwScytNoZj0M ManOtL0RWorLgjn8Kn6KW9Ro4xBYld3ZTOQzYEdjn2DMHVLSXx8Vxzq6SkyY 9OV_6XzhPFVQGR3QHyuU.i.0Rf16rRw0.phSrE2CACPFnyrXYzyy2juXfDIx 11A7uQ1yB7n898lgGCkRzKVZVNyW.xQ-- Received: from [98.203.118.124] by web121602.mail.ne1.yahoo.com via HTTP; Fri, 29 Mar 2013 05:51:11 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gVGh1LCAzLzI4LzEzLCBOaWNrIFJvZ2VycyA8bmNyb2dlcnNAZ21haWwuY29tPiB3cm90ZToKCj4gRnJvbTogTmljayBSb2dlcnMgPG5jcm9nZXJzQGdtYWlsLmNvbT4KPiBTdWJqZWN0OiBSZTogaWdiIGFuZCBBTFRRIGluIDkuMS1yYzMKPiBUbzogIkphY2sgVm9nZWwiIDxqZnZvZ2VsQGdtYWlsLmNvbT4KPiBDYzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPiwgIkNsZW1lbnQgSGVybWFubiAobm9kZW5zKSIgPG5vZGVuczIwOTlAZ21haWwuY29tPiwgImZyZWUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364561471.47223.YahooMailClassic@web121602.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 05:51:11 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Jack Vogel , Nick Rogers In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 12:52:58 -0000 --- On Thu, 3/28/13, Nick Rogers wrote: > From: Nick Rogers > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Jack Vogel" > Cc: "Barney Cordoba" , "Clement Hermann (nodens)" , "freebsd-net@freebsd.org" > Date: Thursday, March 28, 2013, 9:29 PM > On Thu, Mar 28, 2013 at 4:16 PM, Jack > Vogel > wrote: > > Have been kept fairly busy with other matters, one > thing I could do short > > term is > > change the defines in igb the way I did in the em > driver so you could still > > define > > the older if_start entry. Right now those are based on > OS version and so you > > will > > automatically get if_transmit, but I could change it to > be IGB_LEGACY_TX or > > so, > > and that could be defined in the Makefile. > > > > Would this help? > > I'm currently using ALTQ successfully with the em driver, so > if igb > behaved the same with respect to using if_start instead of > if_transmit > when ALTQ is in play, that would be great. I do not > completely > understand the change you propose as I am not very familiar > with the > driver internals. Any kind of patch or extra > Makefile/make.conf > definition that would allow me to build a 9-STABLE kernel > with an igb > driver that works again with ALTQ, ASAP, would be much > appreciated. > > > > > Jack > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > wrote: > >> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > wrote: > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > Smirnoff > >> > wrote: > >> > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, > Jack Vogel wrote: > >> >> J> UH, maybe asking the owner of the > driver would help :) > >> >> J> > >> >> J> ... and no, I've never been aware of > doing anything to stop > >> >> supporting > >> >> altq > >> >> J> so you wouldn't see any commits. If > there's something in the altq > >> >> code > >> >> or > >> >> J> support (which I have nothing to do > with) that caused this no-one > >> >> informed > >> >> J> me. > >> >> > >> >> Switching from if_start to if_transmit > effectively disables ALTQ > >> >> support. > >> >> > >> >> AFAIR, there is some magic implemented in > other drivers that makes them > >> >> modern (that means using if_transmit), but > still capable to switch to > >> >> queueing > >> >> mode if SIOCADDALTQ was casted upon them. > >> >> > >> >> > >> > Oh, hmmm, I'll look into the matter after my > vacation. > >> > > >> > Jack > >> > >> Has there been any progress on resolving this > issue? I recently ran > >> into this problem upgrading my servers from 8.3 to > 9.1-RELEASE and am > >> wondering what the latest recommendation is. I've > used ALTQ and igb > >> successfully for years and it is unfortunate it no > longer works. > >> Appreciate any advice. > >> Do yourself a favor and either get a cheap dual port 82571 card or 2 cards and disable the IGB ports. The igb driver is defective, and until they back out the new, untested multi-queue stuff you're just neutering your system trying to use it. Frankly this project made a huge mistake by moving forward with multi queue just for the sake of saying that you support it; without having any credible plan for implementing it. That nonsense that Bill Macy did should have been tarballed up and deposited in the trash folder. The biggest mess in programming history. That being said, the solution is not to hack the igb driver; its to make ALTQ if_transmit compatible, which shouldn't be all that difficult. BC From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 12:59:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6BC34F3 for ; Fri, 29 Mar 2013 12:59:14 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm3-vm2.bullet.mail.ne1.yahoo.com (nm3-vm2.bullet.mail.ne1.yahoo.com [98.138.91.19]) by mx1.freebsd.org (Postfix) with ESMTP id 21F98178 for ; Fri, 29 Mar 2013 12:59:12 +0000 (UTC) Received: from [98.138.90.52] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 12:57:18 -0000 Received: from [98.138.86.157] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 12:57:18 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 12:57:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 674823.93461.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 76598 invoked by uid 60001); 29 Mar 2013 12:57:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364561838; bh=FhodvRiELbSm/Y4CF8nsQGtWgVoeJcXuels/3lkRAxM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=A4n07EfLHhKixwUxXvK8ljlLi3lAbVPbLXu8115PzgOsPiyzpVdBPL1mN7WTwnxPtuafAwLXhj0KBORW3zR89N4moOVUGAqxjmTOu+KN20CvHQDKQ3c4yWYKayPhkH2jsdeAYaNNf6yZhCZvnq00Qm7jVckhuYxeqzaExO5a8PQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1nRwlfXr0wOGVMPPxNQ8k3vM1HX7J0j5CrSIAJe6vMjov6sT8GyF/iE0eV9sH6Ogxypz5RvsMnOiDl6JhfJVxjoyWaX3N2N84CR/0kYjgpH8y78ljFiKpHs7M/TCHPMUBegIKX7/MZ0u1uxpuKttyQc4fFJeJaEyypC2n5VMdWU=; X-YMail-OSG: P4MoLuQVM1muUgD6C5Eny5SkQ.2NcThZiHah0mshyj9b_VL gtoRyzQVixCwacSUmKecsbs.VLvxfCZUBk7PYnom7EPDMgmJC9XxQNj.Z0Yb rnnY19Lm022_6zER7pqeoX.v8dXrkhLKU6asUBDGHPDB95PbLl5EoYANZgXu TnB22VqCmKM0YYIZbDnEV7IETNVG73Wr2qXyzNkdpgWxKNk02HNhXfuFEEv. kMOnN6oiOts9APFT.zXfV4M9kvYzqmMmTmfoxQd3gBA6uVaP5PIv8mNjc5oo 7uknyjJtxNvjy.C7bVP1E7kcda4xGpty1ZKS3EVsjuUz27KlEIygrb4qTp.0 EtsfoLGxHab4HaYCJXBiRunB97o51dKRJHg28xi5qZs4bxNq2b1HEhosSoef aExpIOkU9vxRhS1M6s0c2eVcWX9GwTYg6upUsVwNXO_j6Lj17BMjsQkczMm9 zLyar4LXTcVN9UxW3zv13jJoiWWDerOhdsHXR5zYTOait778ekwE6nWMPnSW LMLusMrYhJiyKFPvjOjMfwFh3pZsicQ-- Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Fri, 29 Mar 2013 05:57:18 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gRnJpLCAzLzI5LzEzLCBQYWJsbyBSaWJhbHRhIExvcmVuem8gPHJscEBzZW1paGFsZi5jb20.IHdyb3RlOgoKPiBGcm9tOiBQYWJsbyBSaWJhbHRhIExvcmVuem8gPHJscEBzZW1paGFsZi5jb20.Cj4gU3ViamVjdDogdmxhbiB3aXRoIG1vZGlmaWVkIE1BQyBmYWlscyB0byBjb21tdW5pY2F0ZQo.IFRvOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZwo.IERhdGU6IEZyaWRheSwgTWFyY2ggMjksIDIwMTMsIDc6NTMgQU0KPiBIaSB0aGVyZSEKPiAKPiBMYXRlbHkgSSd2ZSBiZWVuIGludmVzdGlnYXQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 05:57:18 -0700 (PDT) From: Barney Cordoba Subject: Re: vlan with modified MAC fails to communicate To: freebsd-net@freebsd.org, Pablo Ribalta Lorenzo In-Reply-To: <515580B0.2070205@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 12:59:14 -0000 --- On Fri, 3/29/13, Pablo Ribalta Lorenzo wrote: > From: Pablo Ribalta Lorenzo > Subject: vlan with modified MAC fails to communicate > To: freebsd-net@freebsd.org > Date: Friday, March 29, 2013, 7:53 AM > Hi there! > > Lately I've been investigating an issue that I would like to > share, as I feel I may have to attack it from a different > end. > > I have an ethernet interface from where I create a vlan. > Once I set up the ip address in the vlan I can ping > correctly on both > sides. The issue arrives when I try to change the MAC > address of the vlan, as from then on it fails to communicate > unless: > > - I restore vlan's MAC address to its previous value > - I enable promisc mode. > > It's also worth to mention that my current setup is FreeBSD > 8.3 and the NIC driver I'm using is not fully mature. > > I was wondering if this behavior is due to some limitations > in the NCI driver I'm using or if in fact it's the correct > way to > proceed, as it was possible to reproduce this same issue in > FreeBSD 8.3 and FreeBSD CURRENT versions, even using more > mature > NIC drivers as 'em' and 're'. > > Could somebody please shed some light in this? Thank you. > Without looking at the code, it's likely that you should be changing the MAC address BEFORE you set up the VLAN. The mac is probably being mapped into some table that being used to track the vlans. BC From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 14:05:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 123CDCA4 for ; Fri, 29 Mar 2013 14:05:19 +0000 (UTC) (envelope-from rlp@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 88BB1779 for ; Fri, 29 Mar 2013 14:05:18 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9BB19C62A5; Fri, 29 Mar 2013 15:05:16 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 87wqTbXfYs-s; Fri, 29 Mar 2013 15:05:15 +0100 (CET) Received: from [10.0.2.212] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 03E61C5842; Fri, 29 Mar 2013 15:05:15 +0100 (CET) Message-ID: <51559F9B.3060608@semihalf.com> Date: Fri, 29 Mar 2013 15:05:15 +0100 From: Pablo Ribalta Lorenzo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: vlan with modified MAC fails to communicate References: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> In-Reply-To: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 14:05:19 -0000 On 03/29/2013 01:57 PM, Barney Cordoba wrote: > > --- On Fri, 3/29/13, Pablo Ribalta Lorenzo wrote: > >> From: Pablo Ribalta Lorenzo >> Subject: vlan with modified MAC fails to communicate >> To: freebsd-net@freebsd.org >> Date: Friday, March 29, 2013, 7:53 AM >> Hi there! >> >> Lately I've been investigating an issue that I would like to >> share, as I feel I may have to attack it from a different >> end. >> >> I have an ethernet interface from where I create a vlan. >> Once I set up the ip address in the vlan I can ping >> correctly on both >> sides. The issue arrives when I try to change the MAC >> address of the vlan, as from then on it fails to communicate >> unless: >> >> - I restore vlan's MAC address to its previous value >> - I enable promisc mode. >> >> It's also worth to mention that my current setup is FreeBSD >> 8.3 and the NIC driver I'm using is not fully mature. >> >> I was wondering if this behavior is due to some limitations >> in the NCI driver I'm using or if in fact it's the correct >> way to >> proceed, as it was possible to reproduce this same issue in >> FreeBSD 8.3 and FreeBSD CURRENT versions, even using more >> mature >> NIC drivers as 'em' and 're'. >> >> Could somebody please shed some light in this? Thank you. >> > Without looking at the code, it's likely that you should be changing > the MAC address BEFORE you set up the VLAN. The mac is probably being > mapped into some table that being used to track the vlans. > > BC Thanks for your answer Barney, I'm going to extend a little bit the explanation of the issue as it may be too brief. First of all, ifconfig shows me this (mge being the NIC): mge1: flags=8843 metric 0 mtu 1500 options=8000b ether 00:01:01:58:31:30 inet 192.168.126.9 netmask 0xffffff00 broadcast 192.168.126.255 media: Ethernet autoselect (1000baseT ) status: active vlan1: flags=8843 metric 0 mtu 1500 ether 00:01:01:58:31:30 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge1 Once I set up the ip for vlan1, I'm able to ping outside: #ifconfig vlan1 inet 172.18.0.254 #ping 172.18.0.1 PING 172.18.0.1 (172.18.0.1): 56 data bytes 64 bytes from 172.18.0.1: icmp_seq=0 ttl=64 time=2.511 ms ^C --- 172.18.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss I change MAC address for vlan1 : #ifconfig vlan1 ether 00:0d:01:58:51:30 mge1: flags=8843 metric 0 mtu 1500 options=8000b ether 00:01:01:58:31:30 inet 192.168.126.9 netmask 0xffffff00 broadcast 192.168.126.255 media: Ethernet autoselect (1000baseT ) status: active vlan1: flags=8843 metric 0 mtu 1500 ether 00:0d:01:58:51:30 inet 172.18.0.254 netmask 0xffff0000 broadcast 172.18.255.255 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge1 And here is where the problems start, as I'm not able to contact with vlan1 from the outside unless: - Restore the MAC address to be 00:01:01:58:31:30 again - Set up promisc mode As I said, since I was able to see this issue in other platforms and with more mature drivers than my 'mge', I don't know if this is the expected behavior, or my NIC driver is missing something to be able to deal with this situation. However thanks for your hint, I feel I need a little bit of perspective in this issue. -- Pozdrawiam, Pablo Ribalta Lorenzo From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 14:37:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F1F1DC5 for ; Fri, 29 Mar 2013 14:37:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id F0C0F91D for ; Fri, 29 Mar 2013 14:37:22 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id ef5so448325obb.13 for ; Fri, 29 Mar 2013 07:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/sT91mjk2oNnlT3qzP1mI5WfI5y3u40SNiaqLlC3sNg=; b=ETd5LaoMJh/DPRUPf+2hiQ9wz3B7YG8wI6uhhGUPhgLxxKwDBglFr0kfgNG0jWNd7q /QSA6HS0aBwFyCgxNe/yT3LWF5NhFC3qDz5Avy9HL1SJNA11o7v5ge23Vvp4egHXKGj8 lDhZLQMD/bvmdb+e3+YOjX9qd8rLiHznimc4JEgJTDkes3pV2IHiHkeRY7u+JZva8Qhb 6JWdaN0z7rXx28Iiiyf7ip3cipJFIyeK06+JyLT3relb3yYxxLvab7bnrNwSpnnEF+Xe Uazp+1B07wTsamcZ8eI5k/q3m8TV/6p3bAgiK749CF3z7+HabyoALl1c9Umc625QUgJZ 0JGg== MIME-Version: 1.0 X-Received: by 10.60.172.84 with SMTP id ba20mr938614oec.10.1364567842569; Fri, 29 Mar 2013 07:37:22 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Fri, 29 Mar 2013 07:37:22 -0700 (PDT) In-Reply-To: <51559F9B.3060608@semihalf.com> References: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> <51559F9B.3060608@semihalf.com> Date: Fri, 29 Mar 2013 10:37:22 -0400 Message-ID: Subject: Re: vlan with modified MAC fails to communicate From: Ryan Stone To: Pablo Ribalta Lorenzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 14:37:23 -0000 On Fri, Mar 29, 2013 at 10:05 AM, Pablo Ribalta Lorenzo wrote: > Thanks for your answer Barney, > > I'm going to extend a little bit the explanation of the issue as it may be > too brief. > > First of all, ifconfig shows me this (mge being the NIC): > > mge1: flags=8843 metric 0 mtu > 1500 > options=8000b > ether 00:01:01:58:31:30 > inet 192.168.126.9 netmask 0xffffff00 broadcast 192.168.126.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan1: flags=8843 metric 0 mtu > 1500 > ether 00:01:01:58:31:30 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 100 parent interface: mge1 > > > Once I set up the ip for vlan1, I'm able to ping outside: > > #ifconfig vlan1 inet 172.18.0.254 > > #ping 172.18.0.1 > PING 172.18.0.1 (172.18.0.1): 56 data bytes > 64 bytes from 172.18.0.1: icmp_seq=0 ttl=64 time=2.511 ms > ^C > --- 172.18.0.1 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > > > I change MAC address for vlan1 : > #ifconfig vlan1 ether 00:0d:01:58:51:30 > > mge1: flags=8843 metric 0 mtu > 1500 > options=8000b > ether 00:01:01:58:31:30 > inet 192.168.126.9 netmask 0xffffff00 broadcast 192.168.126.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan1: flags=8843 metric 0 mtu > 1500 > ether 00:0d:01:58:51:30 > inet 172.18.0.254 netmask 0xffff0000 broadcast 172.18.255.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 100 parent interface: mge1 > > And here is where the problems start, as I'm not able to contact with > vlan1 from the outside unless: > > - Restore the MAC address to be 00:01:01:58:31:30 again > - Set up promisc mode > > As I said, since I was able to see this issue in other platforms and with > more mature drivers than my 'mge', > I don't know if this is the expected behavior, or my NIC driver is missing > something to be able to deal > with this situation. > > However thanks for your hint, I feel I need a little bit of perspective in > this issue. >From a quick glance at if_vlan.c, it doesn't do anything intelligent when you change its MAC address. I also don't know of any ethernet driver in FreeBSD that allows you to use multiple unicast MACs at once (I have some patches for ixgbe, but they aren't ready for prime-time). If you really want to have a different MAC on your vlan interface from its parent you will have to put the parent into promiscuous mode. From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 15:41:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0A36A5C for ; Fri, 29 Mar 2013 15:41:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id 77D25BDF for ; Fri, 29 Mar 2013 15:41:15 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so4264197wib.15 for ; Fri, 29 Mar 2013 08:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=u7nmjhgcSXy2Rx1uvG93QQQ4s1uVYMs2q5d5EYwX9o4=; b=LBlUXlN4Au4Rgh+/bU55KFPDMJ88ADdXP0v0N1IJU4+f2fJHo5prNHQOe9WFHX+qX2 WrWnZf39B7OjLGfoT7jQUKWlsLm3XwgJJcooVb9E6dng14v2BVGw+DMn5vMRIsQ/6Vzx 6qXrLCC82uzPZ5y32roMYtl/M8hEeer/RXQa8lUusQX1BJ8UFLPWsejTEBk3EHOuSFR2 qzylNz18/AYfdV2xyUgdELh4xpXivG9J0FbWlE3oUEFSzVMzRuFGVCvxjaBp0pYXXWK7 +tl+pGKdP48cqZ7CkQoMtWDJtIEkcubVVlNR4Psm2c3iWqcACmEo53OaVum0x01WTu6s zLXA== MIME-Version: 1.0 X-Received: by 10.180.79.6 with SMTP id f6mr22781313wix.26.1364571674571; Fri, 29 Mar 2013 08:41:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 29 Mar 2013 08:41:14 -0700 (PDT) In-Reply-To: References: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> <51559F9B.3060608@semihalf.com> Date: Fri, 29 Mar 2013 08:41:14 -0700 X-Google-Sender-Auth: tK4jYPCBfxrqkMf3N3wp_bwKJ7g Message-ID: Subject: Re: vlan with modified MAC fails to communicate From: Adrian Chadd To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , Pablo Ribalta Lorenzo , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 15:41:15 -0000 On 29 March 2013 07:37, Ryan Stone wrote: > From a quick glance at if_vlan.c, it doesn't do anything intelligent when > you change its MAC address. I also don't know of any ethernet driver in > FreeBSD that allows you to use multiple unicast MACs at once (I have some > patches for ixgbe, but they aren't ready for prime-time). If you really > want to have a different MAC on your vlan interface from its parent you > will have to put the parent into promiscuous mode. > > The ath(4) NICs do - for multi-VAP hostap (and soon, multi-STA) support. But the NICs have a BSS Mask register which lets the NIC pass through packets that match a filter, rather than having to put it into promiscuous mode. Adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 15:45:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C8BAB2D for ; Fri, 29 Mar 2013 15:45:36 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 53AA8C11 for ; Fri, 29 Mar 2013 15:45:36 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 29 Mar 2013 08:45:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,373,1363158000"; d="scan'208";a="310328190" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga001.fm.intel.com with ESMTP; 29 Mar 2013 08:45:29 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.213]) by ORSMSX105.amr.corp.intel.com ([169.254.4.39]) with mapi id 14.01.0355.002; Fri, 29 Mar 2013 08:45:29 -0700 From: "Pieper, Jeffrey E" To: Barney Cordoba , Jack Vogel , Nick Rogers Subject: RE: igb and ALTQ in 9.1-rc3 Thread-Topic: igb and ALTQ in 9.1-rc3 Thread-Index: AQHOLBznR6O5n9a5ZEqL7qLIP4JHeJi9FUyA//+5EdA= Date: Fri, 29 Mar 2013 15:45:28 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> References: <1364561471.47223.YahooMailClassic@web121602.mail.ne1.yahoo.com> In-Reply-To: <1364561471.47223.YahooMailClassic@web121602.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 15:45:36 -0000 -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Barney Cordoba Sent: Friday, March 29, 2013 5:51 AM To: Jack Vogel; Nick Rogers Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) Subject: Re: igb and ALTQ in 9.1-rc3 --- On Thu, 3/28/13, Nick Rogers wrote: > From: Nick Rogers > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Jack Vogel" > Cc: "Barney Cordoba" , "Clement Hermann (nodens= )" , "freebsd-net@freebsd.org" > Date: Thursday, March 28, 2013, 9:29 PM > On Thu, Mar 28, 2013 at 4:16 PM, Jack > Vogel > wrote: > > Have been kept fairly busy with other matters, one > thing I could do short > > term is > > change the defines in igb the way I did in the em > driver so you could still > > define > > the older if_start entry. Right now those are based on > OS version and so you > > will > > automatically get if_transmit, but I could change it to > be IGB_LEGACY_TX or > > so, > > and that could be defined in the Makefile. > > > > Would this help? >=20 > I'm currently using ALTQ successfully with the em driver, so > if igb > behaved the same with respect to using if_start instead of > if_transmit > when ALTQ is in play, that would be great. I do not > completely > understand the change you propose as I am not very familiar > with the > driver internals. Any kind of patch or extra > Makefile/make.conf > definition that would allow me to build a 9-STABLE kernel > with an igb > driver that works again with ALTQ, ASAP, would be much > appreciated. >=20 > > > > Jack > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > wrote: > >> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > wrote: > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > Smirnoff > >> > wrote: > >> > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, > Jack Vogel wrote: > >> >> J> UH, maybe asking the owner of the > driver would help :) > >> >> J> > >> >> J> ... and no, I've never been aware of > doing anything to stop > >> >> supporting > >> >> altq > >> >> J> so you wouldn't see any commits. If > there's something in the altq > >> >> code > >> >> or > >> >> J> support (which I have nothing to do > with) that caused this no-one > >> >> informed > >> >> J> me. > >> >> > >> >> Switching from if_start to if_transmit > effectively disables ALTQ > >> >> support. > >> >> > >> >> AFAIR, there is some magic implemented in > other drivers that makes them > >> >> modern (that means using if_transmit), but > still capable to switch to > >> >> queueing > >> >> mode if SIOCADDALTQ was casted upon them. > >> >> > >> >> > >> > Oh, hmmm, I'll look into the matter after my > vacation. > >> > > >> > Jack > >> > >> Has there been any progress on resolving this > issue? I recently ran > >> into this problem upgrading my servers from 8.3 to > 9.1-RELEASE and am > >> wondering what the latest recommendation is. I've > used ALTQ and igb > >> successfully for years and it is unfortunate it no > longer works. > >> Appreciate any advice. > >> > >Do yourself a favor and either get a cheap dual port 82571 card or >2 cards and disable the IGB ports. The igb driver is defective, and until >they back out the new, untested multi-queue stuff you're just neutering=20 >your system trying to use it. > >Frankly this project made a huge mistake by moving forward with multi >queue just for the sake of saying that you support it; without having >any credible plan for implementing it. That nonsense that Bill Macy did >should have been tarballed up and deposited in the trash folder. The >biggest mess in programming history. > >That being said, the solution is not to hack the igb driver; its to make >ALTQ if_transmit compatible, which shouldn't be all that difficult.=20 > >BC I may be misunderstanding what you are saying, but if the solution is, as y= ou say "not to hack the igb driver", then how is it defective in this case?= Or are you just directing vitriol toward Intel? Multi-queue is working fin= e in igb.=20 Jeff _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 15:57:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC4A4146 for ; Fri, 29 Mar 2013 15:57:32 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm32-vm5.bullet.mail.ne1.yahoo.com (nm32-vm5.bullet.mail.ne1.yahoo.com [98.138.229.53]) by mx1.freebsd.org (Postfix) with ESMTP id 78290D0B for ; Fri, 29 Mar 2013 15:57:32 +0000 (UTC) Received: from [98.138.90.51] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 15:54:09 -0000 Received: from [98.138.89.234] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 15:54:09 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 15:54:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 440903.45602.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 52944 invoked by uid 60001); 29 Mar 2013 15:54:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364572449; bh=ER2VkXX49TOajnjx/SObF/5r5r7we+9k4XN+G1pxp04=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Guuu58qUd6otnlzrUXoFZzrvETYmAguXnYcuNsO9OJXXHCiTWE8PGJ8598PqoqgTBocBx/+R9DUyCz3Sm6VC/+LCgqcNAjO/AyJKabozkWgzsW2RlVBlYQIIXGOlo4ghJhl/4SrFqOAKlUqV41VWjtH0koBa+VlUK+LHu/LbX4k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PvRWv/WtG8ezJvRBQzc5rHMqxqFRctS6/DWUYTfNx3v2l3E1WjGzO7lMmP2jCqwtHNCagnH57c9NaurTeAnEbU/kbGLAMQ56ceSQIMAS89r7jlDF/urEk68OWJZbfJ+d3wZB2+vnLm72J6RNo3Zyqsa7/xk/hcEnJm5SakzkTrg=; X-YMail-OSG: P4Amp8MVM1nDm5biCjEtn1U.7t43idvOC.PRSwYEhya1Pag 92Ku_ZqsppoU.IRpkUpvXtfVAtrhPw.Bdl2bxkd4Fv1FCX7q.LRXkY5J_TVg dZvbHP.8LMknjQrJEqqyMTnxkhVlqG8X0o4l7h8M8aMo0FjrjS8EPECCjnV0 I3zZTInVB63v.T3sfE7RAQK_kzDfRCvKVPAfoyaRUndjDaAYwwd6e_ggYgNl M2Ab1nAiH.0E1l5ZwBBVCRpLNp98ufbPvmmvmyKuIrjH4RFAn8gQiC3JuqGU 0EV3RGg9OfUbS7Slmv6qTQjYQp073VqpT_yAw1gvlAgBYUmCaoqtrPUdGOG9 ylgcAfLDIr1yw0nNoDuWIJXNZVxYSHpMFAQldndIRi5GdR.1_tWSzmZ5wPXf a1VInirdY2CDHY1QOTfBxgCLpJrv0Ldlh5tXJg7kzQmm3Kvecd7N4THY7I35 Jhc4suoGsEjUBRBal1zQ24T.uXd6fgYPEDVYIYuNeSauoSBh91gInuMZfdVp l4Uit.NfEwIVpUtW1H2HDUsArKZoWFw-- Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Fri, 29 Mar 2013 08:54:08 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gRnJpLCAzLzI5LzEzLCBQaWVwZXIsIEplZmZyZXkgRSA8amVmZnJleS5lLnBpZXBlckBpbnRlbC5jb20.IHdyb3RlOgoKPiBGcm9tOiBQaWVwZXIsIEplZmZyZXkgRSA8amVmZnJleS5lLnBpZXBlckBpbnRlbC5jb20.Cj4gU3ViamVjdDogUkU6IGlnYiBhbmQgQUxUUSBpbiA5LjEtcmMzCj4gVG86ICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4sICJKYWNrIFZvZ2VsIiA8amZ2b2dlbEBnbWFpbC5jb20.LCAiTmljayBSb2dlcnMiIDxuY3JvZ2Vyc0BnbWFpbC5jb20BMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364572448.52354.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 08:54:08 -0700 (PDT) From: Barney Cordoba Subject: RE: igb and ALTQ in 9.1-rc3 To: Jack Vogel , Nick Rogers , Jeffrey EPieper In-Reply-To: <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 15:57:32 -0000 --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > From: Pieper, Jeffrey E > Subject: RE: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" , "Jack Vogel" , "Nick Rogers" > Cc: "freebsd-net@freebsd.org" , "Clement Hermann (nodens)" > Date: Friday, March 29, 2013, 11:45 AM > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4:16 PM, Jack > > Vogel > > wrote: > > > Have been kept fairly busy with other matters, > one > > thing I could do short > > > term is > > > change the defines in igb the way I did in the em > > driver so you could still > > > define > > > the older if_start entry. Right now those are > based on > > OS version and so you > > > will > > > automatically get if_transmit, but I could change > it to > > be IGB_LEGACY_TX or > > > so, > > > and that could be defined in the Makefile. > > > > > > Would this help? > > > > I'm currently using ALTQ successfully with the em > driver, so > > if igb > > behaved the same with respect to using if_start instead > of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very > familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE > kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > wrote: > > >> > > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM > -0800, > > Jack Vogel wrote: > > >> >> J> UH, maybe asking the owner of > the > > driver would help :) > > >> >> J> > > >> >> J> ... and no, I've never been > aware of > > doing anything to stop > > >> >> supporting > > >> >> altq > > >> >> J> so you wouldn't see any > commits. If > > there's something in the altq > > >> >> code > > >> >> or > > >> >> J> support (which I have nothing > to do > > with) that caused this no-one > > >> >> informed > > >> >> J> me. > > >> >> > > >> >> Switching from if_start to > if_transmit > > effectively disables ALTQ > > >> >> support. > > >> >> > > >> >> AFAIR, there is some magic > implemented in > > other drivers that makes them > > >> >> modern (that means using > if_transmit), but > > still capable to switch to > > >> >> queueing > > >> >> mode if SIOCADDALTQ was casted upon > them. > > >> >> > > >> >> > > >> > Oh, hmmm, I'll look into the matter after > my > > vacation. > > >> > > > >> > Jack > > >> > > >> Has there been any progress on resolving this > > issue? I recently ran > > >> into this problem upgrading my servers from > 8.3 to > > 9.1-RELEASE and am > > >> wondering what the latest recommendation is. > I've > > used ALTQ and igb > > >> successfully for years and it is unfortunate > it no > > longer works. > > >> Appreciate any advice. > > >> > > > >Do yourself a favor and either get a cheap dual port > 82571 card or > >2 cards and disable the IGB ports. The igb driver is > defective, and until > >they back out the new, untested multi-queue stuff you're > just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving > forward with multi > >queue just for the sake of saying that you support it; > without having > >any credible plan for implementing it. That nonsense > that Bill Macy did > >should have been tarballed up and deposited in the trash > folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb > driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that > difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the > solution is, as you say "not to hack the igb driver", then > how is it defective in this case? Or are you just directing > vitriol toward Intel? Multi-queue is working fine in igb. > > Jeff It's defective because it's been poorly implemented and has more bugs than a Manhattan hotel bed. Adding queues without a proper plan just add more lock contention. It's not a production-ready driver. As Jack once said, Intel doesn't care about performance, they're just example drivers. igb is an example of how not to do things. BC From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 16:07:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01D3D42A for ; Fri, 29 Mar 2013 16:07:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 7923CD83 for ; Fri, 29 Mar 2013 16:07:41 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so17951wib.4 for ; Fri, 29 Mar 2013 09:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EK/0HqsnX4fFwtoL7SDkwMYjvA86hL/9lIoxtIVFIOI=; b=m8bA+nwlXxOWXLDoJ3EUaHjidOYTWH/srGN2hE8H4J72YQj+md+drPD2uEo3dtaYDM FuPYJXopLe8jq9XyBnvKwkfcXSXwu95UjzJU/qcXAEqckALAXFHCG19fJk9wSX//jt8O b1Cw4hIio+4XIl0h/NFjIx5CJChO1sI9orStcHpvhSIszdp+7UrxUP39zvzeiQnVokU9 rnpBs2ae9pW5s1ftTgBea+VE1kAP+5JUYJoKVS9RehB5b5KOXqYUASAjsx9kYYR0E9++ lOhA0vmlFvO0lnq1goZwTc8k7fiQH2jzfGI+BIz7+9QoH7PWGgn5Qu3QfCSNEzCUNjnw JrIA== MIME-Version: 1.0 X-Received: by 10.180.81.232 with SMTP id d8mr67423wiy.25.1364573260037; Fri, 29 Mar 2013 09:07:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 29 Mar 2013 09:07:39 -0700 (PDT) In-Reply-To: <1364572448.52354.YahooMailClassic@web121605.mail.ne1.yahoo.com> References: <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> <1364572448.52354.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 09:07:39 -0700 X-Google-Sender-Auth: lPsFuvcJBtJU6-VpEguBEo3vYaY Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Nick Rogers , Jeffrey EPieper , "Clement Hermann \(nodens\)" , Jack Vogel , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 16:07:42 -0000 Barney, Patches gratefully accepted. Adrian On 29 March 2013 08:54, Barney Cordoba wrote: > > > --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > > > From: Pieper, Jeffrey E > > Subject: RE: igb and ALTQ in 9.1-rc3 > > To: "Barney Cordoba" , "Jack Vogel" < > jfvogel@gmail.com>, "Nick Rogers" > > Cc: "freebsd-net@freebsd.org" , "Clement > Hermann (nodens)" > > Date: Friday, March 29, 2013, 11:45 AM > > > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org > > [mailto:owner-freebsd-net@freebsd.org] > > On Behalf Of Barney Cordoba > > Sent: Friday, March 29, 2013 5:51 AM > > To: Jack Vogel; Nick Rogers > > Cc: freebsd-net@freebsd.org; > > Clement Hermann (nodens) > > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > > > > > --- On Thu, 3/28/13, Nick Rogers > > wrote: > > > > > From: Nick Rogers > > > Subject: Re: igb and ALTQ in 9.1-rc3 > > > To: "Jack Vogel" > > > Cc: "Barney Cordoba" , > > "Clement Hermann (nodens)" , > > "freebsd-net@freebsd.org" > > > > > Date: Thursday, March 28, 2013, 9:29 PM > > > On Thu, Mar 28, 2013 at 4:16 PM, Jack > > > Vogel > > > wrote: > > > > Have been kept fairly busy with other matters, > > one > > > thing I could do short > > > > term is > > > > change the defines in igb the way I did in the em > > > driver so you could still > > > > define > > > > the older if_start entry. Right now those are > > based on > > > OS version and so you > > > > will > > > > automatically get if_transmit, but I could change > > it to > > > be IGB_LEGACY_TX or > > > > so, > > > > and that could be defined in the Makefile. > > > > > > > > Would this help? > > > > > > I'm currently using ALTQ successfully with the em > > driver, so > > > if igb > > > behaved the same with respect to using if_start instead > > of > > > if_transmit > > > when ALTQ is in play, that would be great. I do not > > > completely > > > understand the change you propose as I am not very > > familiar > > > with the > > > driver internals. Any kind of patch or extra > > > Makefile/make.conf > > > definition that would allow me to build a 9-STABLE > > kernel > > > with an igb > > > driver that works again with ALTQ, ASAP, would be much > > > appreciated. > > > > > > > > > > > Jack > > > > > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > > > wrote: > > > >> > > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > > > wrote: > > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > > Smirnoff > > > >> > wrote: > > > >> > > > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM > > -0800, > > > Jack Vogel wrote: > > > >> >> J> UH, maybe asking the owner of > > the > > > driver would help :) > > > >> >> J> > > > >> >> J> ... and no, I've never been > > aware of > > > doing anything to stop > > > >> >> supporting > > > >> >> altq > > > >> >> J> so you wouldn't see any > > commits. If > > > there's something in the altq > > > >> >> code > > > >> >> or > > > >> >> J> support (which I have nothing > > to do > > > with) that caused this no-one > > > >> >> informed > > > >> >> J> me. > > > >> >> > > > >> >> Switching from if_start to > > if_transmit > > > effectively disables ALTQ > > > >> >> support. > > > >> >> > > > >> >> AFAIR, there is some magic > > implemented in > > > other drivers that makes them > > > >> >> modern (that means using > > if_transmit), but > > > still capable to switch to > > > >> >> queueing > > > >> >> mode if SIOCADDALTQ was casted upon > > them. > > > >> >> > > > >> >> > > > >> > Oh, hmmm, I'll look into the matter after > > my > > > vacation. > > > >> > > > > >> > Jack > > > >> > > > >> Has there been any progress on resolving this > > > issue? I recently ran > > > >> into this problem upgrading my servers from > > 8.3 to > > > 9.1-RELEASE and am > > > >> wondering what the latest recommendation is. > > I've > > > used ALTQ and igb > > > >> successfully for years and it is unfortunate > > it no > > > longer works. > > > >> Appreciate any advice. > > > >> > > > > > >Do yourself a favor and either get a cheap dual port > > 82571 card or > > >2 cards and disable the IGB ports. The igb driver is > > defective, and until > > >they back out the new, untested multi-queue stuff you're > > just neutering > > >your system trying to use it. > > > > > >Frankly this project made a huge mistake by moving > > forward with multi > > >queue just for the sake of saying that you support it; > > without having > > >any credible plan for implementing it. That nonsense > > that Bill Macy did > > >should have been tarballed up and deposited in the trash > > folder. The > > >biggest mess in programming history. > > > > > >That being said, the solution is not to hack the igb > > driver; its to make > > >ALTQ if_transmit compatible, which shouldn't be all that > > difficult. > > > > > >BC > > > > I may be misunderstanding what you are saying, but if the > > solution is, as you say "not to hack the igb driver", then > > how is it defective in this case? Or are you just directing > > vitriol toward Intel? Multi-queue is working fine in igb. > > > > Jeff > > It's defective because it's been poorly implemented and has more bugs > than a Manhattan hotel bed. Adding queues without a proper plan just add > more lock contention. It's not a production-ready driver. > > As Jack once said, Intel doesn't care about performance, they're just > example drivers. igb is an example of how not to do things. > > BC > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 16:27:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD9DDFF2 for ; Fri, 29 Mar 2013 16:27:54 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm26-vm1.bullet.mail.ne1.yahoo.com (nm26-vm1.bullet.mail.ne1.yahoo.com [98.138.91.61]) by mx1.freebsd.org (Postfix) with ESMTP id A9C03E6F for ; Fri, 29 Mar 2013 16:27:54 +0000 (UTC) Received: from [98.138.226.180] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:25:09 -0000 Received: from [98.138.89.246] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:25:09 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:25:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 639782.61289.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 80213 invoked by uid 60001); 29 Mar 2013 16:25:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364574309; bh=ImxqLC5IhVgH/+8U/jz8FlGWLkSjo6fsSPGoJUE1uwI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5UwvG41h0wKNzN+3ABM6CIvA3+2PApxwHJ4vJ4Cbs5tYpJ2VMxnqCj32UEm1MQQiL/m4FUYfZPPo42zgg5CLA0p/DEJCvKAJ6b/uc1uwUFI2B9eDVlLgvuE3QTH3oK0ndBUv9TEfZfzWoYTq86pA9pY+hleeJDP3IP6EL7pV6Do= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mcI3OUaO2I1QSES9cpNFqy6rv4k8++zvXEXPj8RBWpx3gzeE5UZdw8BeMZHWjLCXiTHkybf7a4ZfggudaUIbp767b1fUttpRH1I4X3th0wlrWshJygQin0SBkB39w0m2VLQmjYnXyp1lKcGqWjD3XbXtM+8gaR4Do73PjWwkZBI=; X-YMail-OSG: c7Az.DoVM1n.AHAf810eVHs9eSjnYyTYv8plQkb4tVZBDh9 jprumm5.pSPpU3WmmA6_.PQgdarpChTzSvfXUgyNDXZSJRfzoTe73yvQR4mi UHs7B7Nnkc.h2FlhLpZ.TCz3UEbtiIw7xVNmK1bpSGgVRc2rsalEJH6IHpCf ui6Rgp8jJF09VKvcoVNp7dxUDDyvIm_qS2hA5wKWb6aJ4TMGCorl8odTaZeg dfGieCrnQkQAh_oPbyDT.jAzc22k.yCUun3KPXNDoOUfHg4TK4zJaxRD6NO0 I2dwH5OvKsNG728QYD9lRH3.ioVOUFoKje8mx3u_7R1ctOa_9TSq6mQCrPY4 op5rzYca5a0_h0X10oplxUP0X.B.zuVof0BPEzeZoYWsB1P1_BuwcINea21A YiY2gGxFJ2uU5p8q4hKh4WCrhijfSl7MP8fbWy8Fispxhw6UDVhyp4E5jYtZ FFfSUTCKt4_9PdqM47jjadJ50iN5w1oc3E8gUGQ4sjRHSGpxYdeA4R8CHxb0 T31qrbvUIBvV8cNPo7XVaizhjZXRPKQ-- Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Fri, 29 Mar 2013 09:25:09 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gRnJpLCAzLzI5LzEzLCBQaWVwZXIsIEplZmZyZXkgRSA8amVmZnJleS5lLnBpZXBlckBpbnRlbC5jb20.IHdyb3RlOgoKPiBGcm9tOiBQaWVwZXIsIEplZmZyZXkgRSA8amVmZnJleS5lLnBpZXBlckBpbnRlbC5jb20.Cj4gU3ViamVjdDogUkU6IGlnYiBhbmQgQUxUUSBpbiA5LjEtcmMzCj4gVG86ICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4sICJKYWNrIFZvZ2VsIiA8amZ2b2dlbEBnbWFpbC5jb20.LCAiTmljayBSb2dlcnMiIDxuY3JvZ2Vyc0BnbWFpbC5jb20BMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364574309.74010.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 09:25:09 -0700 (PDT) From: Barney Cordoba Subject: RE: igb and ALTQ in 9.1-rc3 To: Jack Vogel , Nick Rogers , Jeffrey EPieper In-Reply-To: <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 16:27:54 -0000 --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > From: Pieper, Jeffrey E > Subject: RE: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" , "Jack Vogel" , "Nick Rogers" > Cc: "freebsd-net@freebsd.org" , "Clement Hermann (nodens)" > Date: Friday, March 29, 2013, 11:45 AM > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4:16 PM, Jack > > Vogel > > wrote: > > > Have been kept fairly busy with other matters, > one > > thing I could do short > > > term is > > > change the defines in igb the way I did in the em > > driver so you could still > > > define > > > the older if_start entry. Right now those are > based on > > OS version and so you > > > will > > > automatically get if_transmit, but I could change > it to > > be IGB_LEGACY_TX or > > > so, > > > and that could be defined in the Makefile. > > > > > > Would this help? > > > > I'm currently using ALTQ successfully with the em > driver, so > > if igb > > behaved the same with respect to using if_start instead > of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very > familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE > kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > wrote: > > >> > > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM > -0800, > > Jack Vogel wrote: > > >> >> J> UH, maybe asking the owner of > the > > driver would help :) > > >> >> J> > > >> >> J> ... and no, I've never been > aware of > > doing anything to stop > > >> >> supporting > > >> >> altq > > >> >> J> so you wouldn't see any > commits. If > > there's something in the altq > > >> >> code > > >> >> or > > >> >> J> support (which I have nothing > to do > > with) that caused this no-one > > >> >> informed > > >> >> J> me. > > >> >> > > >> >> Switching from if_start to > if_transmit > > effectively disables ALTQ > > >> >> support. > > >> >> > > >> >> AFAIR, there is some magic > implemented in > > other drivers that makes them > > >> >> modern (that means using > if_transmit), but > > still capable to switch to > > >> >> queueing > > >> >> mode if SIOCADDALTQ was casted upon > them. > > >> >> > > >> >> > > >> > Oh, hmmm, I'll look into the matter after > my > > vacation. > > >> > > > >> > Jack > > >> > > >> Has there been any progress on resolving this > > issue? I recently ran > > >> into this problem upgrading my servers from > 8.3 to > > 9.1-RELEASE and am > > >> wondering what the latest recommendation is. > I've > > used ALTQ and igb > > >> successfully for years and it is unfortunate > it no > > longer works. > > >> Appreciate any advice. > > >> > > > >Do yourself a favor and either get a cheap dual port > 82571 card or > >2 cards and disable the IGB ports. The igb driver is > defective, and until > >they back out the new, untested multi-queue stuff you're > just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving > forward with multi > >queue just for the sake of saying that you support it; > without having > >any credible plan for implementing it. That nonsense > that Bill Macy did > >should have been tarballed up and deposited in the trash > folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb > driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that > difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the > solution is, as you say "not to hack the igb driver", then > how is it defective in this case? Or are you just directing > vitriol toward Intel? Multi-queue is working fine in igb. > > Jeff It works like crap. Your definition of "works" is that it doesnt crash. Mine is that it works better with multiple queues than with 1, which it doesn't. And if you load a system up, it will blow up with multiqueue before it will with 1 queue. The point of using Multiqueue isn't to exhaust all of the cpus instead of just 2. It's to get past the wall of using only 2 cpus when they're exhausted. The goal is to increase the capacity of the system; not to make it look like you're using more cpus without any analysis of overall system efficiency. That's my definition of defective. The default tuning is wrong also, because is ASSumes that you only have 1 card in the box. So if you have 2 cards, it has 2 rx queues contending for the same cpus, which is exactly the opposite of what you want. There's no vitriol towards Intel. That's what Jack said; that Intel drivers are just samples and they're not optimized. Obviously some drivers are better than others because he's spent more time on them. What I don't like is that nobody ever tells anyone which drivers are good and which suck. If you think that a driver is a driver then you should be doing something else with your life other than networking. The truth is that there is no plan for multiqueue; the idea that spreading things across cpus randomly is better is just plain wrong; in fact there's a strong case to be made to keep things on the same cpu (and in the same cache). Igb is a college project. Using it will make your system slower than using good single queue cards. BC From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 16:36:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DAEB3370 for ; Fri, 29 Mar 2013 16:36:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0DDEBB for ; Fri, 29 Mar 2013 16:36:16 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id pb11so707235veb.34 for ; Fri, 29 Mar 2013 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yRZNiDbBQYYyDOo3FbTkN4gboGuzhoZzZuRInwJRBWI=; b=b+9/DrFQXMUefiQCmQAOROD1XuybQ1HKqm0OTdUUcXsjBXfysfE2tOijuT3cq/1U92 MSalQvxetQdXqrdbFVeYFHHmPssOEVYt1duHVzqJuo7UaU26h6Fa67PVCw8d8MS6wVwu rswA6sKf0FZqxG6qlUTLdeID954cfGZzIwWtrb4JTo22QanR8qKp7In41FLEWuqAiI0e AZzvVQeT0W2GWdt4yE2zhjRF3C59DrHRv1XJZ1e3zvxO+9ZaFJNlfP5pi//8KMsJlD3F PgAua/v+pxLdQ/tDFqX+aragA76E2W27b7tcOtpKnL5u93vG6tAj/X8Jr+xQKhR7NUnO gRvw== MIME-Version: 1.0 X-Received: by 10.52.92.225 with SMTP id cp1mr1981587vdb.41.1364574969928; Fri, 29 Mar 2013 09:36:09 -0700 (PDT) Received: by 10.220.140.14 with HTTP; Fri, 29 Mar 2013 09:36:09 -0700 (PDT) In-Reply-To: <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> References: <1364561471.47223.YahooMailClassic@web121602.mail.ne1.yahoo.com> <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> Date: Fri, 29 Mar 2013 09:36:09 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Jack Vogel To: "Pieper, Jeffrey E" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Nick Rogers , Barney Cordoba , "Clement Hermann \(nodens\)" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 16:36:16 -0000 Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago realized its pointless to attempt anything like a fair conversation with him. The only thing he's ever contributed is slander and pseudo-critique... another poison thread I'm done with. Jack On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E < jeffrey.e.pieper@intel.com> wrote: > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , "Clement Hermann > (nodens)" , "freebsd-net@freebsd.org" < > freebsd-net@freebsd.org> > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4:16 PM, Jack > > Vogel > > wrote: > > > Have been kept fairly busy with other matters, one > > thing I could do short > > > term is > > > change the defines in igb the way I did in the em > > driver so you could still > > > define > > > the older if_start entry. Right now those are based on > > OS version and so you > > > will > > > automatically get if_transmit, but I could change it to > > be IGB_LEGACY_TX or > > > so, > > > and that could be defined in the Makefile. > > > > > > Would this help? > > > > I'm currently using ALTQ successfully with the em driver, so > > if igb > > behaved the same with respect to using if_start instead of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > wrote: > > >> > > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, > > Jack Vogel wrote: > > >> >> J> UH, maybe asking the owner of the > > driver would help :) > > >> >> J> > > >> >> J> ... and no, I've never been aware of > > doing anything to stop > > >> >> supporting > > >> >> altq > > >> >> J> so you wouldn't see any commits. If > > there's something in the altq > > >> >> code > > >> >> or > > >> >> J> support (which I have nothing to do > > with) that caused this no-one > > >> >> informed > > >> >> J> me. > > >> >> > > >> >> Switching from if_start to if_transmit > > effectively disables ALTQ > > >> >> support. > > >> >> > > >> >> AFAIR, there is some magic implemented in > > other drivers that makes them > > >> >> modern (that means using if_transmit), but > > still capable to switch to > > >> >> queueing > > >> >> mode if SIOCADDALTQ was casted upon them. > > >> >> > > >> >> > > >> > Oh, hmmm, I'll look into the matter after my > > vacation. > > >> > > > >> > Jack > > >> > > >> Has there been any progress on resolving this > > issue? I recently ran > > >> into this problem upgrading my servers from 8.3 to > > 9.1-RELEASE and am > > >> wondering what the latest recommendation is. I've > > used ALTQ and igb > > >> successfully for years and it is unfortunate it no > > longer works. > > >> Appreciate any advice. > > >> > > > >Do yourself a favor and either get a cheap dual port 82571 card or > >2 cards and disable the IGB ports. The igb driver is defective, and until > >they back out the new, untested multi-queue stuff you're just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving forward with multi > >queue just for the sake of saying that you support it; without having > >any credible plan for implementing it. That nonsense that Bill Macy did > >should have been tarballed up and deposited in the trash folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the solution is, as > you say "not to hack the igb driver", then how is it defective in this > case? Or are you just directing vitriol toward Intel? Multi-queue is > working fine in igb. > > Jeff > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 16:38:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 24C0B421 for ; Fri, 29 Mar 2013 16:38:20 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm20-vm3.bullet.mail.ne1.yahoo.com (nm20-vm3.bullet.mail.ne1.yahoo.com [98.138.91.150]) by mx1.freebsd.org (Postfix) with ESMTP id BE9D8EDB for ; Fri, 29 Mar 2013 16:38:19 +0000 (UTC) Received: from [98.138.90.56] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:38:13 -0000 Received: from [98.138.89.249] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:38:13 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:38:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 116813.73420.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 75373 invoked by uid 60001); 29 Mar 2013 16:38:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364575093; bh=IaBDNWRrhp1cCzTi10sVLF97aUR3J26yGWl7UjYQVYA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SqV7z3i255b+4de9zJgIK2p0SFdfqKGJZrOi6BLMDFXCdLeIdCThLvSLLQMrc+S+usLmTLao3vre4hmcnouqeovQ960umsb5ffO6phhYh+DCwrh//Yq/VgRIxzVLhIKTTAs8NxK0pcu6lcWPtoPxQ4B08cS9MyLWTICnfGm3dLk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VAVJk8ajY83yvRCF2rKvorS+R/0kCPXlvOseENWhWa9uZPMzl77tNDQjGm+MuQyCZgb8eqb2E20VrXOxsMeWI7wnqCreMucPU7Gc+hn7NoTa8pW3JbbKwe9YkCJR7rFPrzg2sJq6sRPO2auPSK1S68xymUe0izC3BLwe6CUwAHU=; X-YMail-OSG: 66QEh9EVM1moOjSftUOueGCjHfQ.qwmtJXu1W2beXmYVafO C1X9YEzhyto6luWnaUGT0wYfpnI3x0_NQB1wdSJnQuW2r3kTvBmcR5GhMz_. R24xCFwC0WpBpCHBQjPOmcVmhPk5NotxMhT21KiocBzij7hwb18DNkm4ePAf _WvcgtqRCOqUuGVkPzERCJkACKakOVhHmfqowzjZ7DlIADn7eP.2wwVhvLgs VDl5BTsfgzKySrOeklDHs6CvitljfbtEk7D9jPjUe5obSQzWN7Ts7HC5xSh. 1sHwjqU5DF1ZUKV.aQBPQWvrfVQZpGqU8HHT63GjOoitzRlSvA3XYQ8hJ_L5 GdtsV5R8chREZRiTvpeUhhBN_IvlS8DAD4nAqR4scumXw3OkYZcaBAJ7mpPI 1JfrGO2ivRwIAdCWIHumrlVcpVGXNu_YVwGXe5wZLlIhpspe7XQ_inxRJ9rG e3.q2uhLXsJqw7YNZ4ArkKFAZ7yQv3dcSqbqId7ovJeZpcVz5syAECbzK_hS UDwXmCQqyVdD7N8ouAvaXO_e_XMlwZg-- Received: from [98.203.118.124] by web121604.mail.ne1.yahoo.com via HTTP; Fri, 29 Mar 2013 09:38:12 PDT X-Rocket-MIMEInfo: 002.001, aXQgbmVlZHMgYSBsb3QgbW9yZSB0aGFuIGEgcGF0Y2guIEl0IG5lZWRzIHRvIGJlIGNvbXBsZXRlbHkgcmUtdGh1bmsNCg0KLS0tIE9uIEZyaSwgMy8yOS8xMywgQWRyaWFuIENoYWRkIDxhZHJpYW5AZnJlZWJzZC5vcmc.IHdyb3RlOg0KDQpGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4NClN1YmplY3Q6IFJlOiBpZ2IgYW5kIEFMVFEgaW4gOS4xLXJjMw0KVG86ICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4NCkNjOiAiSmFjayBWb2dlbCIgPGpmdm9nZWwBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.139.530 Message-ID: <1364575092.74048.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 09:38:12 -0700 (PDT) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Nick Rogers , Jeffrey EPieper , "Clement Hermann \(nodens\)" , Jack Vogel , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 16:38:20 -0000 it needs a lot more than a patch. It needs to be completely re-thunk --- On Fri, 3/29/13, Adrian Chadd wrote: From: Adrian Chadd Subject: Re: igb and ALTQ in 9.1-rc3 To: "Barney Cordoba" Cc: "Jack Vogel" , "Nick Rogers" , "Jeffrey EPieper" , "freebsd-net@freebsd.org" , "Clement Hermann (nodens)" Date: Friday, March 29, 2013, 12:07 PM Barney, Patches gratefully accepted. Adrian On 29 March 2013 08:54, Barney Cordoba wrote: --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > From: Pieper, Jeffrey E > Subject: RE: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" , "Jack Vogel" , "Nick Rogers" > Cc: "freebsd-net@freebsd.org" , "Clement Hermann (nodens)" > Date: Friday, March 29, 2013, 11:45 AM > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4:16 PM, Jack > > Vogel > > wrote: > > > Have been kept fairly busy with other matters, > one > > thing I could do short > > > term is > > > change the defines in igb the way I did in the em > > driver so you could still > > > define > > > the older if_start entry. Right now those are > based on > > OS version and so you > > > will > > > automatically get if_transmit, but I could change > it to > > be IGB_LEGACY_TX or > > > so, > > > and that could be defined in the Makefile. > > > > > > Would this help? > > > > I'm currently using ALTQ successfully with the em > driver, so > > if igb > > behaved the same with respect to using if_start instead > of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very > familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE > kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > wrote: > > >> > > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM > -0800, > > Jack Vogel wrote: > > >> >> J> UH, maybe asking the owner of > the > > driver would help :) > > >> >> J> > > >> >> J> ... and no, I've never been > aware of > > doing anything to stop > > >> >> supporting > > >> >> altq > > >> >> J> so you wouldn't see any > commits. If > > there's something in the altq > > >> >> code > > >> >> or > > >> >> J> support (which I have nothing > to do > > with) that caused this no-one > > >> >> informed > > >> >> J> me. > > >> >> > > >> >> Switching from if_start to > if_transmit > > effectively disables ALTQ > > >> >> support. > > >> >> > > >> >> AFAIR, there is some magic > implemented in > > other drivers that makes them > > >> >> modern (that means using > if_transmit), but > > still capable to switch to > > >> >> queueing > > >> >> mode if SIOCADDALTQ was casted upon > them. > > >> >> > > >> >> > > >> > Oh, hmmm, I'll look into the matter after > my > > vacation. > > >> > > > >> > Jack > > >> > > >> Has there been any progress on resolving this > > issue? I recently ran > > >> into this problem upgrading my servers from > 8.3 to > > 9.1-RELEASE and am > > >> wondering what the latest recommendation is. > I've > > used ALTQ and igb > > >> successfully for years and it is unfortunate > it no > > longer works. > > >> Appreciate any advice. > > >> > > > >Do yourself a favor and either get a cheap dual port > 82571 card or > >2 cards and disable the IGB ports. The igb driver is > defective, and until > >they back out the new, untested multi-queue stuff you're > just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving > forward with multi > >queue just for the sake of saying that you support it; > without having > >any credible plan for implementing it. That nonsense > that Bill Macy did > >should have been tarballed up and deposited in the trash > folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb > driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that > difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the > solution is, as you say "not to hack the igb driver", then > how is it defective in this case? Or are you just directing > vitriol toward Intel? Multi-queue is working fine in igb. > > Jeff It's defective because it's been poorly implemented and has more bugs than a Manhattan hotel bed. Adding queues without a proper plan just add more lock contention. It's not a production-ready driver. As Jack once said, Intel doesn't care about performance, they're just example drivers. igb is an example of how not to do things. BC _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 16:48:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 931E86D2 for ; Fri, 29 Mar 2013 16:48:13 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by mx1.freebsd.org (Postfix) with ESMTP id 486FBF40 for ; Fri, 29 Mar 2013 16:48:12 +0000 (UTC) Received: from [98.138.90.54] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:42:50 -0000 Received: from [98.138.84.38] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:42:50 -0000 Received: from [127.0.0.1] by smtp106.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 16:42:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364575370; bh=A78o+PA7h9WTqgGB1lMnZSuXWiTeyz51EMUbY0MGbZI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=p90HHaETASrIkp5I5l3X6YZbC+RN625Q7/R4Rj8+O7p/ue8iAsZyPUctz85WoiDXX+UWmlIOpGMDSzVEq0C0KABLJghZIf64oPDHFVndMpzIIhx5sffcMXMvwZ3oW6clAYIVHThuBQQTC87Sgx5927tz++DWqqZ9SRwwZfo6txQ= X-Yahoo-Newman-Id: 679641.44572.bm@smtp106.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: u3_SBo0VM1lCqiCX_IUnvpLpzj83kzCwLpCG11rGjTlTRzL HWCF5.v8f22k1UUaHqVgmx3r8jjnjEATNzcDtjzh5eQr.vXUDKj3cFR20WUp IYyrOPm5YfzNAxbsWeWKy8FwAJD5eK5w6FxUj9JQqy_JDWdzXPPkrz8LftJE PxzuZsYrDqZFYcpgHYa8xYYLgC7VyQNS2ySC.t_alhnblOLwbtIAj5BgWWBp rMiuf2ZClYrTv2ig7j2uJvTWoCEI2p78DJTMkDbDoH3bGhNm1eUDuXh2VoK3 _hl4PNNI6.58vZrlhJI2uO1rEiE_1k9FbCBzYJ62423SZ51a8carwPwakkHU 0QLIYIUav.OD5UKTs_BxbHuZAeWZDa6SRnHqoy6dQVz1qHQ.mwbbWy8GTuqZ 9AznCysBFxLaHNuYCYKfSXpKpi0Zsu8jV2hO2NcnFZO88YG9wvv4pGo_1rXK aW44ITCY5uzZa X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [10.64.26.99] (scott4long@69.53.237.126 with plain) by smtp106.mail.ne1.yahoo.com with SMTP; 29 Mar 2013 09:42:50 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: igb and ALTQ in 9.1-rc3 From: Scott Long In-Reply-To: <1364575092.74048.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Fri, 29 Mar 2013 10:42:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364575092.74048.YahooMailClassic@web121604.mail.ne1.yahoo.com> To: Barney Cordoba X-Mailer: Apple Mail (2.1503) Cc: Nick Rogers , Adrian Chadd , Jeffrey EPieper , "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 16:48:13 -0000 Comedy gold. It's been a while since I've seen this much idiocy from = you, Barney. Hopefully the rest of the mailing list will blackhole you, = as I'm about to, and we can all get back to real work. Scott On Mar 29, 2013, at 10:38 AM, Barney Cordoba = wrote: > it needs a lot more than a patch. It needs to be completely re-thunk >=20 > --- On Fri, 3/29/13, Adrian Chadd wrote: >=20 > From: Adrian Chadd > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" > Cc: "Jack Vogel" , "Nick Rogers" = , "Jeffrey EPieper" , = "freebsd-net@freebsd.org" , "Clement Hermann = (nodens)" > Date: Friday, March 29, 2013, 12:07 PM >=20 > Barney, > Patches gratefully accepted. >=20 >=20 >=20 > Adrian >=20 >=20 >=20 > On 29 March 2013 08:54, Barney Cordoba = wrote: >=20 >=20 >=20 >=20 >=20 > --- On Fri, 3/29/13, Pieper, Jeffrey E = wrote: >=20 >=20 >=20 >> From: Pieper, Jeffrey E >=20 >> Subject: RE: igb and ALTQ in 9.1-rc3 >=20 >> To: "Barney Cordoba" , "Jack Vogel" = , "Nick Rogers" >=20 >=20 >> Cc: "freebsd-net@freebsd.org" , "Clement = Hermann (nodens)" >=20 >=20 >> Date: Friday, March 29, 2013, 11:45 AM >=20 >>=20 >=20 >>=20 >=20 >> -----Original Message----- >=20 >> From: owner-freebsd-net@freebsd.org >=20 >> [mailto:owner-freebsd-net@freebsd.org] >=20 >> On Behalf Of Barney Cordoba >=20 >> Sent: Friday, March 29, 2013 5:51 AM >=20 >> To: Jack Vogel; Nick Rogers >=20 >> Cc: freebsd-net@freebsd.org; >=20 >> Clement Hermann (nodens) >=20 >> Subject: Re: igb and ALTQ in 9.1-rc3 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> --- On Thu, 3/28/13, Nick Rogers >=20 >> wrote: >=20 >>=20 >=20 >>> From: Nick Rogers >=20 >>> Subject: Re: igb and ALTQ in 9.1-rc3 >=20 >>> To: "Jack Vogel" >=20 >>> Cc: "Barney Cordoba" , >=20 >> "Clement Hermann (nodens)" , >=20 >> "freebsd-net@freebsd.org" >=20 >> >=20 >>> Date: Thursday, March 28, 2013, 9:29 PM >=20 >>> On Thu, Mar 28, 2013 at 4:16 PM, Jack >=20 >>> Vogel >=20 >>> wrote: >=20 >>>> Have been kept fairly busy with other matters, >=20 >> one >=20 >>> thing I could do short >=20 >>>> term is >=20 >>>> change the defines in igb the way I did in the em >=20 >>> driver so you could still >=20 >>>> define >=20 >>>> the older if_start entry. Right now those are >=20 >> based on >=20 >>> OS version and so you >=20 >>>> will >=20 >>>> automatically get if_transmit, but I could change >=20 >> it to >=20 >>> be IGB_LEGACY_TX or >=20 >>>> so, >=20 >>>> and that could be defined in the Makefile. >=20 >>>>=20 >=20 >>>> Would this help? >=20 >>>=20 >=20 >>> I'm currently using ALTQ successfully with the em >=20 >> driver, so >=20 >>> if igb >=20 >>> behaved the same with respect to using if_start instead >=20 >> of >=20 >>> if_transmit >=20 >>> when ALTQ is in play, that would be great. I do not >=20 >>> completely >=20 >>> understand the change you propose as I am not very >=20 >> familiar >=20 >>> with the >=20 >>> driver internals. Any kind of patch or extra >=20 >>> Makefile/make.conf >=20 >>> definition that would allow me to build a 9-STABLE >=20 >> kernel >=20 >>> with an igb >=20 >>> driver that works again with ALTQ, ASAP, would be much >=20 >>> appreciated. >=20 >>>=20 >=20 >>>>=20 >=20 >>>> Jack >=20 >>>>=20 >=20 >>>>=20 >=20 >>>>=20 >=20 >>>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers >=20 >> >=20 >>> wrote: >=20 >>>>>=20 >=20 >>>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel >=20 >> >=20 >>> wrote: >=20 >>>>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb >=20 >>> Smirnoff >=20 >>>>>> wrote: >=20 >>>>>>=20 >=20 >>>>>>> On Mon, Dec 10, 2012 at 03:31:19PM >=20 >> -0800, >=20 >>> Jack Vogel wrote: >=20 >>>>>>> J> UH, maybe asking the owner of >=20 >> the >=20 >>> driver would help :) >=20 >>>>>>> J> >=20 >>>>>>> J> ... and no, I've never been >=20 >> aware of >=20 >>> doing anything to stop >=20 >>>>>>> supporting >=20 >>>>>>> altq >=20 >>>>>>> J> so you wouldn't see any >=20 >> commits. If >=20 >>> there's something in the altq >=20 >>>>>>> code >=20 >>>>>>> or >=20 >>>>>>> J> support (which I have nothing >=20 >> to do >=20 >>> with) that caused this no-one >=20 >>>>>>> informed >=20 >>>>>>> J> me. >=20 >>>>>>>=20 >=20 >>>>>>> Switching from if_start to >=20 >> if_transmit >=20 >>> effectively disables ALTQ >=20 >>>>>>> support. >=20 >>>>>>>=20 >=20 >>>>>>> AFAIR, there is some magic >=20 >> implemented in >=20 >>> other drivers that makes them >=20 >>>>>>> modern (that means using >=20 >> if_transmit), but >=20 >>> still capable to switch to >=20 >>>>>>> queueing >=20 >>>>>>> mode if SIOCADDALTQ was casted upon >=20 >> them. >=20 >>>>>>>=20 >=20 >>>>>>>=20 >=20 >>>>>> Oh, hmmm, I'll look into the matter after >=20 >> my >=20 >>> vacation. >=20 >>>>>>=20 >=20 >>>>>> Jack >=20 >>>>>=20 >=20 >>>>> Has there been any progress on resolving this >=20 >>> issue? I recently ran >=20 >>>>> into this problem upgrading my servers from >=20 >> 8.3 to >=20 >>> 9.1-RELEASE and am >=20 >>>>> wondering what the latest recommendation is. >=20 >> I've >=20 >>> used ALTQ and igb >=20 >>>>> successfully for years and it is unfortunate >=20 >> it no >=20 >>> longer works. >=20 >>>>> Appreciate any advice. >=20 >>>>>=20 >=20 >>>=20 >=20 >>> Do yourself a favor and either get a cheap dual port >=20 >> 82571 card or >=20 >>> 2 cards and disable the IGB ports. The igb driver is >=20 >> defective, and until >=20 >>> they back out the new, untested multi-queue stuff you're >=20 >> just neutering >=20 >>> your system trying to use it. >=20 >>>=20 >=20 >>> Frankly this project made a huge mistake by moving >=20 >> forward with multi >=20 >>> queue just for the sake of saying that you support it; >=20 >> without having >=20 >>> any credible plan for implementing it. That nonsense >=20 >> that Bill Macy did >=20 >>> should have been tarballed up and deposited in the trash >=20 >> folder. The >=20 >>> biggest mess in programming history. >=20 >>>=20 >=20 >>> That being said, the solution is not to hack the igb >=20 >> driver; its to make >=20 >>> ALTQ if_transmit compatible, which shouldn't be all that >=20 >> difficult. >=20 >>>=20 >=20 >>> BC >=20 >>=20 >=20 >> I may be misunderstanding what you are saying, but if the >=20 >> solution is, as you say "not to hack the igb driver", then >=20 >> how is it defective in this case? Or are you just directing >=20 >> vitriol toward Intel? Multi-queue is working fine in igb. >=20 >>=20 >=20 >> Jeff >=20 >=20 >=20 > It's defective because it's been poorly implemented and has more bugs >=20 > than a Manhattan hotel bed. Adding queues without a proper plan just = add >=20 > more lock contention. It's not a production-ready driver. >=20 >=20 >=20 > As Jack once said, Intel doesn't care about performance, they're just >=20 > example drivers. igb is an example of how not to do things. >=20 >=20 >=20 > BC >=20 > _______________________________________________ >=20 > freebsd-net@freebsd.org mailing list >=20 > http://lists.freebsd.org/mailman/listinfo/freebsd-net >=20 > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 17:04:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DE1D8B68 for ; Fri, 29 Mar 2013 17:04:21 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7D9FBD for ; Fri, 29 Mar 2013 17:04:21 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id cz11so744045veb.10 for ; Fri, 29 Mar 2013 10:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gg8gCKIiE8sQEhhVkc2iQPtluGuGLEdmHrE3xM2rLIU=; b=YAtQ7QfJlhZxumDqBGCLKyrUB8SxsULuKHc6Fz7rRe65XSlxaqEoYBlhQBCnUAwP1y wrEnS+a+YgdpK5RC0EmryzLFvxcmRC2w5sgDtjk8lHE0iPLw3dAVHLTOjbAUg7T39izG 4GpMXGLKvmo5bgsSAZN3Ow2kUCMjDoTSFASk1HgNCkXwE+g4iZw4LxhyPaN3M5d1f/gS d+DrYuE//fMcW4f+NrIGMRKe6Ml3aCVooenh1DUp8jpBO4Dt213igJj2vEB23T4nad30 A8ECpebGafXLXF42qZqH5B+mUci62qeHcYprY3ELFLIrQD/vKrFRyJWMQ+U87KbLEXy6 TyAA== MIME-Version: 1.0 X-Received: by 10.58.40.9 with SMTP id t9mr2456705vek.10.1364576655588; Fri, 29 Mar 2013 10:04:15 -0700 (PDT) Received: by 10.52.176.131 with HTTP; Fri, 29 Mar 2013 10:04:15 -0700 (PDT) In-Reply-To: References: <1364561471.47223.YahooMailClassic@web121602.mail.ne1.yahoo.com> <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> Date: Fri, 29 Mar 2013 10:04:15 -0700 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Nick Rogers To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: "Pieper, Jeffrey E" , "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 17:04:21 -0000 On Fri, Mar 29, 2013 at 9:36 AM, Jack Vogel wrote: > Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago > realized its pointless to > attempt anything like a fair conversation with him. The only thing he's ever > contributed is slander > and pseudo-critique... another poison thread I'm done with. > > Jack Multiqueue or not, I would appreciate any help with this thread's original issue. Whether or not its the ideal thing to do, I cannot simply just replace the NICs with an em(4) variant, as I have hundreds of customers/systems already in production running 8.3 and relying on the igb driver + ALTQ. I need to be able to upgrade these systems to 9.1 without making hardware changes. > > > > On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E > wrote: >> >> >> >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] >> On Behalf Of Barney Cordoba >> Sent: Friday, March 29, 2013 5:51 AM >> To: Jack Vogel; Nick Rogers >> Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) >> Subject: Re: igb and ALTQ in 9.1-rc3 >> >> >> >> --- On Thu, 3/28/13, Nick Rogers wrote: >> >> > From: Nick Rogers >> > Subject: Re: igb and ALTQ in 9.1-rc3 >> > To: "Jack Vogel" >> > Cc: "Barney Cordoba" , "Clement Hermann >> > (nodens)" , "freebsd-net@freebsd.org" >> > >> > Date: Thursday, March 28, 2013, 9:29 PM >> > On Thu, Mar 28, 2013 at 4:16 PM, Jack >> > Vogel >> > wrote: >> > > Have been kept fairly busy with other matters, one >> > thing I could do short >> > > term is >> > > change the defines in igb the way I did in the em >> > driver so you could still >> > > define >> > > the older if_start entry. Right now those are based on >> > OS version and so you >> > > will >> > > automatically get if_transmit, but I could change it to >> > be IGB_LEGACY_TX or >> > > so, >> > > and that could be defined in the Makefile. >> > > >> > > Would this help? >> > >> > I'm currently using ALTQ successfully with the em driver, so >> > if igb >> > behaved the same with respect to using if_start instead of >> > if_transmit >> > when ALTQ is in play, that would be great. I do not >> > completely >> > understand the change you propose as I am not very familiar >> > with the >> > driver internals. Any kind of patch or extra >> > Makefile/make.conf >> > definition that would allow me to build a 9-STABLE kernel >> > with an igb >> > driver that works again with ALTQ, ASAP, would be much >> > appreciated. >> > >> > > >> > > Jack >> > > >> > > >> > > >> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers >> > wrote: >> > >> >> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel >> > wrote: >> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb >> > Smirnoff >> > >> > wrote: >> > >> > >> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, >> > Jack Vogel wrote: >> > >> >> J> UH, maybe asking the owner of the >> > driver would help :) >> > >> >> J> >> > >> >> J> ... and no, I've never been aware of >> > doing anything to stop >> > >> >> supporting >> > >> >> altq >> > >> >> J> so you wouldn't see any commits. If >> > there's something in the altq >> > >> >> code >> > >> >> or >> > >> >> J> support (which I have nothing to do >> > with) that caused this no-one >> > >> >> informed >> > >> >> J> me. >> > >> >> >> > >> >> Switching from if_start to if_transmit >> > effectively disables ALTQ >> > >> >> support. >> > >> >> >> > >> >> AFAIR, there is some magic implemented in >> > other drivers that makes them >> > >> >> modern (that means using if_transmit), but >> > still capable to switch to >> > >> >> queueing >> > >> >> mode if SIOCADDALTQ was casted upon them. >> > >> >> >> > >> >> >> > >> > Oh, hmmm, I'll look into the matter after my >> > vacation. >> > >> > >> > >> > Jack >> > >> >> > >> Has there been any progress on resolving this >> > issue? I recently ran >> > >> into this problem upgrading my servers from 8.3 to >> > 9.1-RELEASE and am >> > >> wondering what the latest recommendation is. I've >> > used ALTQ and igb >> > >> successfully for years and it is unfortunate it no >> > longer works. >> > >> Appreciate any advice. >> > >> >> > >> >Do yourself a favor and either get a cheap dual port 82571 card or >> >2 cards and disable the IGB ports. The igb driver is defective, and until >> >they back out the new, untested multi-queue stuff you're just neutering >> >your system trying to use it. >> > >> >Frankly this project made a huge mistake by moving forward with multi >> >queue just for the sake of saying that you support it; without having >> >any credible plan for implementing it. That nonsense that Bill Macy did >> >should have been tarballed up and deposited in the trash folder. The >> >biggest mess in programming history. >> > >> >That being said, the solution is not to hack the igb driver; its to make >> >ALTQ if_transmit compatible, which shouldn't be all that difficult. >> > >> >BC >> >> I may be misunderstanding what you are saying, but if the solution is, as >> you say "not to hack the igb driver", then how is it defective in this case? >> Or are you just directing vitriol toward Intel? Multi-queue is working fine >> in igb. >> >> Jeff >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 17:10:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F302CD8 for ; Fri, 29 Mar 2013 17:10:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id E7D01FF9 for ; Fri, 29 Mar 2013 17:10:15 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b12so567222wgh.6 for ; Fri, 29 Mar 2013 10:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1cffbw1dEO4I0nxVknBDxtbezgko8W7fRSdz30sXNks=; b=lFArNW6Pb/X8qQX1+1AbSLhYfhAI/ZUv6KJ+gF/jAbpNVW5Bx5sxBxlAcKN5GVDeZ6 GrLrbrNME5dYHGQGS2C18XeMTEU6fs++DGQz8CbOTAUBTixV7TibPuYiBng6dTLZr9CY EwYUL7G1L+vg/zS3wga/jzpdAd8iZzBsHfKEUN6Xd30C65g0dHt3JRzOhjhkQA64hSOP aDB0NlstqaKhTzA1l7W9KvRAoT6+WTSBc4iQlUI8qKWXP7D5Lo1K+2A/0Inwm6RkULcz wssXfEhT6x3lm8dNH5mBlXPjmj8RUL0iWbrPdA/Yzs5qZJnntiIbkMnDwB1YpaTxsJBt f5Eg== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr4717432wjb.24.1364577008532; Fri, 29 Mar 2013 10:10:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 29 Mar 2013 10:10:08 -0700 (PDT) In-Reply-To: References: <1364561471.47223.YahooMailClassic@web121602.mail.ne1.yahoo.com> <2A35EA60C3C77D438915767F458D65687D46B19E@ORSMSX101.amr.corp.intel.com> Date: Fri, 29 Mar 2013 10:10:08 -0700 X-Google-Sender-Auth: H-yGYoPBdN88jmLjGnYjus3SE5c Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Adrian Chadd To: Nick Rogers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Pieper, Jeffrey E" , "freebsd-net@freebsd.org" , "Clement Hermann \(nodens\)" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 17:10:16 -0000 On 29 March 2013 10:04, Nick Rogers wrote: > Multiqueue or not, I would appreciate any help with this thread's > original issue. Whether or not its the ideal thing to do, I cannot > simply just replace the NICs with an em(4) variant, as I have hundreds > of customers/systems already in production running 8.3 and relying on > the igb driver + ALTQ. I need to be able to upgrade these systems to > 9.1 without making hardware changes. > > If it's that critical, have you thought about contracting out that task to a developer? adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 29 21:31:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B39FBBF3; Fri, 29 Mar 2013 21:31:21 +0000 (UTC) (envelope-from carl.shapiro@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id EC3E7BD7; Fri, 29 Mar 2013 21:31:20 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so365544eek.39 for ; Fri, 29 Mar 2013 14:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UNRVeLlZ3+LV1qGwRyfHk/1RtGcJ+c2dGt68gzMzVqU=; b=Xs84vx7JVZwaigHnDXo1VAOnsgbv2RPy9I/Pt2Vg6Tt5nEOCwmARa+OcMoCYmT70og 8wopwBt64V9hCYfF9qeHQWDOjyHfXh0gY7JDFffO6wUcONcrZdV/s6ZbukOj3oTYUM65 O4p5hr1SbtVEy9xHMAdNZeECXlnlDUXXbZS4y2tcT49eGppmznK5EphrMnUJTUCU8dn0 pgcMroRBKRw91EIMh64aGa4e4E9t3rOsa+ZOX19GX7Gp3a9FmLhCVKdDuYahmerkmve6 jAtatIus0FxBYX9PQsYuRUfo6S9HwMnU64wRHDZBz26pZvPJtVH9jjVE9tTbgYWg4uel 7Ifw== X-Received: by 10.14.207.200 with SMTP id n48mr11887242eeo.4.1364592679631; Fri, 29 Mar 2013 14:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.129.2 with HTTP; Fri, 29 Mar 2013 14:30:59 -0700 (PDT) In-Reply-To: <515475C7.6010404@FreeBSD.org> References: <515475C7.6010404@FreeBSD.org> From: Carl Shapiro Date: Fri, 29 Mar 2013 14:30:59 -0700 Message-ID: Subject: Re: close(2) while accept(2) is blocked To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 21:31:21 -0000 On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon wrote: > But the summary seems to be is that currently it is not possible to break > a thread > out of accept(2) (at least without resorting to signals). > This is a known problem for Java. Closing a socket that another thread is block on is supposed to unblock a thread and throw a SocketException. http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#close() In other operating systems, such as Solaris and MacOS X, closing the descriptor causes blocked system calls to return with an error. FreeBSD (and Linux) do not behave this way. There, a JVM must do extra bookkeeping to associate file descriptors with threads blocked on the descriptor. This allows the close method to identify blocked threads and send them a signal. On those threads the caller of the blocking method must further distinguish an error return as being caused by a signal sent on behalf of close. It is not obvious whether there is any benefit to having the current blocking behaviour. Threads are an afterthought in UNIX so this could just be an oversight. It would make a high-level language runtimes simpler if FreeBSD behaved more like Solaris and MacOS X. From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 00:03:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2D05BA1; Sat, 30 Mar 2013 00:03:02 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8B57D11A; Sat, 30 Mar 2013 00:03:02 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 32D7FB82A; Fri, 29 Mar 2013 16:54:31 -0700 (PDT) To: Carl Shapiro Subject: Re: close(2) while accept(2) is blocked In-reply-to: Your message of "Fri, 29 Mar 2013 14:30:59 PDT." References: <515475C7.6010404@FreeBSD.org> Comments: In-reply-to Carl Shapiro message dated "Fri, 29 Mar 2013 14:30:59 -0700." Date: Fri, 29 Mar 2013 16:54:31 -0700 From: Bakul Shah Message-Id: <20130329235431.32D7FB82A@mail.bitblocks.com> Cc: freebsd-net@freebsd.org, Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 00:03:02 -0000 On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro wrote: > > In other operating systems, such as Solaris and MacOS X, closing the > descriptor causes blocked system calls to return with an error. What happens if you select() on a socket and another thread closes this socket? Ideally select() should return (with EINTR?) so that the blocking thread can some cleanup action. And if you do that, the blocking accept() case is not really different. There is no point in *not* telling blocking threads that the descriptor they're waiting on is one EBADF and nothing is going to happen. > It is not obvious whether there is any benefit to having the current > blocking behaviour. This may need some new kernel code but IMHO this is worth fixing. From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 02:16:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 55478580 for ; Sat, 30 Mar 2013 02:16:42 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 06C2A8B9 for ; Sat, 30 Mar 2013 02:16:41 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r2U2Gds0014605; Fri, 29 Mar 2013 22:16:39 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r2U2GdMv014602; Fri, 29 Mar 2013 22:16:39 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20822.19207.597798.216479@hergotha.csail.mit.edu> Date: Fri, 29 Mar 2013 22:16:39 -0400 From: Garrett Wollman To: Rick Macklem Subject: IPsec crash in TCP, also NFS DRC patches (was: Re: Limits on jumbo mbuf cluster allocation) In-Reply-To: <75232221.3844453.1363146480616.JavaMail.root@erie.cs.uoguelph.ca> References: <20798.44871.601547.24628@hergotha.csail.mit.edu> <75232221.3844453.1363146480616.JavaMail.root@erie.cs.uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 29 Mar 2013 22:16:40 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 02:16:42 -0000 < said: > The patch includes a lot of drc2.patch and drc3.patch, so don't try > and apply it to a patched kernel. Hopefully it will apply cleanly to > vanilla sources. > Tha patch has been minimally tested. Well, it's taken a long time, but I was finally able to get some testing. The user whose OpenStack cluster jobs had eaten previous file servers killed this one, too, but not in a way that's attributable to the NFS code. He was able to put on a fairly heavy load from about 630 virtual machines in our cluster without the server even getting particularly busy. Another cluster job, however, repeatedly panicked the server. Thankfully, there's a backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8074ee11 stack pointer = 0x28:0xffffff9a469ee6d0 frame pointer = 0x28:0xffffff9a469ee710 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq260: ix0:que 3) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1ce trap_fatal() at trap_fatal+0x290 trap_pfault() at trap_pfault+0x21c trap() at trap+0x365 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff8074ee11, rsp = 0xffffff9a469ee6d0, rbp = 0xffffff9a469ee710 --- ipsec_getpolicybysock() at ipsec_getpolicybysock+0x31 ipsec46_in_reject() at ipsec46_in_reject+0x24 ipsec4_in_reject() at ipsec4_in_reject+0x9 tcp_input() at tcp_input+0x498 ip_input() at ip_input+0x1de netisr_dispatch_src() at netisr_dispatch_src+0x20b ether_demux() at ether_demux+0x14d ether_nh_input() at ether_nh_input+0x1f4 netisr_dispatch_src() at netisr_dispatch_src+0x20b ixgbe_rxeof() at ixgbe_rxeof+0x1cb ixgbe_msix_que() at ixgbe_msix_que+0xa8 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa6 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff9a469eecf0, rbp = 0 --- ipsec_setspidx_inpcb() is inlined here; the fault is on the line: error = ipsec_setspidx(m, &inp->inp_sp->sp_in->spidx, 1); where inp->inp_sp is being dereferenced: 0xffffffff8074ee02 : mov 0xf0(%rdx),%rax 0xffffffff8074ee09 : mov $0x1,%edx 0xffffffff8074ee0e : mov %rcx,%r15 0xffffffff8074ee11 : mov (%rax),%rsi <-- FAULT! 0xffffffff8074ee14 : add $0x34,%rsi 0xffffffff8074ee18 : callq 0xffffffff8074e6f0 (inp is in %rdx here). The crash occurs when the clients are making about 200 connections per second. (We're not sure if this is by design or if it's a broken NAT implementation on the OpenStack nodes. My money is on a broken NAT, because we were also seeing lots of data being sent on apparently-closed connections. The kernel was also logging many [ECONNABORTED] errors when nfsd tried to accept() new client connections. A capture is available if anyone wants to look at this in more detail, although obviously not from the traffic that actually caused the crash.) inp_sp is declared thus: struct inpcbpolicy *inp_sp; /* (s) for IPSEC */ The locking code "(s)" is supposed to indicate "protected by another subsystem's locks", but there is no locking at all in ipsec_getpolicybysock(), so that seems to be a misstatement at best. I quickly installed a new kernel with IPSEC disabled (we have no need for it), and it seems to have survived further abuse, although it seems that the user's test jobs were winding down at that time as well so I can't say for certain that it wouldn't have crashed somewhere else. -GAWollman From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 14:42:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7BE5398A; Sat, 30 Mar 2013 14:42:08 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC71A21; Sat, 30 Mar 2013 14:42:08 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id un3so978783obb.10 for ; Sat, 30 Mar 2013 07:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7AUJTuCy+/SERyXdqWuGv3pCZtH7G0xukywf0T/GUJo=; b=Fx9WUhO9Gm2sO6DEnvRGu0IgSmjqTNv7SHZClM60biHBV4Fy5hhEUzxvM2PdXHNb4T iw9Fk6oQ2vhtkkIkRllYd2JG4ZH5zO58mMTRPygGW6QcdlpK7epsa1WBVwu1UvYzUCPA PY8ZRKbZKEr3UYKrTggj12KLyCHAbzpR2jhD3pT3Te8jxZPnamiKHlu3+AnjeOe6WE5x qwlRLWJIOeMzbKx58gzuZn0nbeRgQhZOHZTFl7H27byTeiu7QKfIXejuAWpjropVa0GS Wa0cXz18HQ7vi0DhAUxybaO3HJeBYN4By60p054av9ZN/MF3vj4Mo31e0bgFxem9gHOe PCGQ== MIME-Version: 1.0 X-Received: by 10.60.172.84 with SMTP id ba20mr2025368oec.10.1364654527809; Sat, 30 Mar 2013 07:42:07 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Sat, 30 Mar 2013 07:42:07 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Sat, 30 Mar 2013 07:42:07 -0700 (PDT) In-Reply-To: References: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> <51559F9B.3060608@semihalf.com> Date: Sat, 30 Mar 2013 10:42:07 -0400 Message-ID: Subject: Re: vlan with modified MAC fails to communicate From: Ryan Stone To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , Pablo Ribalta Lorenzo , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 14:42:08 -0000 ath isn't Ethernet. :) From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 14:43:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3DBC9AB7 for ; Sat, 30 Mar 2013 14:43:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id C9F2EA45 for ; Sat, 30 Mar 2013 14:43:43 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so1054850wgh.25 for ; Sat, 30 Mar 2013 07:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MXIaBHpNcvJt0uGnCJM0em2plF8zMhwjgHptNtanP4o=; b=LNRc2PIO57mo0XlKlCnv6MRGpkZjjWdVojAAVeqO7mdyPP6wYgLtt3dhAtyOE0Fdfo hISWD5ZJiZEIr/UishPL4zBXATgmZRnbo4IUQuTnwZa4JxSnqAkZLQOkjpJN2ceDxd1U m4By6LEb29G3e7BSi+OSGUUtn/UVx++2LQazEuXK9Nb4IhtjaMXg4P8ENT5TVbPcEotx Uxdn9f1Ap7EiKYOCZ48FTEeh4e2GHXbMtepzdL1ZobhQ3TypRemeAKq4KIsBD1WFAdpS /smtbTsfUg1CahanfOXlOPfeSzZlKqEtNvU6PGmyBqirQuluELS+YxzuBlIxOWEG1xZg vdYA== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr2734251wic.29.1364654617669; Sat, 30 Mar 2013 07:43:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Sat, 30 Mar 2013 07:43:37 -0700 (PDT) In-Reply-To: References: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> <51559F9B.3060608@semihalf.com> Date: Sat, 30 Mar 2013 07:43:37 -0700 X-Google-Sender-Auth: M1CwQbfNsU7r27Ejnbw6kJutCoU Message-ID: Subject: Re: vlan with modified MAC fails to communicate From: Adrian Chadd To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , Pablo Ribalta Lorenzo , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 14:43:44 -0000 On 30 March 2013 07:42, Ryan Stone wrote: > ath isn't Ethernet. :) > Hah. At some level it is. :-) The point being, if the NIC has some idea of a "destined for me" filter mask, this concept is doable. Adrian From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 16:14:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE728F2B; Sat, 30 Mar 2013 16:14:41 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 852B8F16; Sat, 30 Mar 2013 16:14:41 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r2UGEYF6026692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Mar 2013 09:14:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r2UGEYwp026691; Sat, 30 Mar 2013 09:14:34 -0700 (PDT) (envelope-from jmg) Date: Sat, 30 Mar 2013 09:14:34 -0700 From: John-Mark Gurney To: Bakul Shah Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130330161434.GG76354@funkthat.com> Mail-Followup-To: Bakul Shah , Carl Shapiro , freebsd-net@freebsd.org, Andriy Gapon , FreeBSD Hackers References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130329235431.32D7FB82A@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 30 Mar 2013 09:14:34 -0700 (PDT) Cc: freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 16:14:41 -0000 Bakul Shah wrote this message on Fri, Mar 29, 2013 at 16:54 -0700: > On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro wrote: > > > > In other operating systems, such as Solaris and MacOS X, closing the > > descriptor causes blocked system calls to return with an error. > > What happens if you select() on a socket and another thread > closes this socket? Ideally select() should return (with > EINTR?) so that the blocking thread can some cleanup action. > And if you do that, the blocking accept() case is not really > different. > > There is no point in *not* telling blocking threads that the > descriptor they're waiting on is one EBADF and nothing is > going to happen. > > > It is not obvious whether there is any benefit to having the current > > blocking behaviour. > > This may need some new kernel code but IMHO this is worth fixing. As someone else pointed out in this thread, if a userland program depends upon this behavior, it has a race condition in it... Thread 1 Thread 2 Thread 3 enters routine to read enters routine to close calls close(3) open() returns 3 does read(3) for orignal fd How can the original threaded program ensure that thread 2 doesn't create a new fd in between? So even if you use a lock, this won't help, because as far as I know, there is no enter read and unlock mutex call yet... I decided long ago that this is only solvable by proper use of locking and ensuring that if you call close (the syscall), that you do not have any other thread that may use the fd. It's the close routine's (not syscall) function to make sure it locks out other threads and all other are out of the code path that will use the fd before it calls close.. If someone could describe how this new eject a person from read could be done in a race safe way, then I'd say go ahead w/ it... Otherwise we're just moving the race around, and letting people think that they have solved the problem when they haven't... I think I remeber another thread about this from a year or two ago, but I couldn't find it... If someone finds it, posting a link would be nice.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 16:54:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A63B2559 for ; Sat, 30 Mar 2013 16:54:45 +0000 (UTC) (envelope-from markd-freebsd-net@bushwire.net) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id 7C33DC5 for ; Sat, 30 Mar 2013 16:54:44 +0000 (UTC) Received: (qmail 12664 invoked by uid 1001); 30 Mar 2013 16:48:03 -0000 Delivered-To: qmda-intercept-freebsd-net@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=2004; d=bushwire.net; b=3IJ6OWc4TVBvKz6r35kPNDJrHdeaAiBcoNehaDN/D/As6rvzxr3z+YWNJKvx2RWa; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=16; b=36; l=C18R71D32M65F45T27C51S48R42?69?46?38M17C39C27I50; Comments: QMDA 0.3 Received: (qmail 12657 invoked by uid 1001); 30 Mar 2013 16:48:03 -0000 Date: 30 Mar 2013 16:48:03 +0000 Message-ID: <20130330164803.12656.qmail@f5-external.bushwire.net> From: "Mark" To: freebsd-net@freebsd.org Subject: Re: close(2) while accept(2) is blocked References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130330161434.GG76354@funkthat.com> Cc: FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 16:54:45 -0000 > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2 Thread 3 > enters routine to read > enters routine to close > calls close(3) > open() returns 3 > does read(3) for orignal fd > > How can the original threaded program ensure that thread 2 doesn't > create a new fd in between? So even if you use a lock, this won't > help, because as far as I know, there is no enter read and unlock > mutex call yet... > > I decided long ago that this is only solvable by proper use of locking > and ensuring that if you call close (the syscall), that you do not have > any other thread that may use the fd. It's the close routine's (not > syscall) function to make sure it locks out other threads and all other > are out of the code path that will use the fd before it calls close.. > > If someone could describe how this new eject a person from read could > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > we're just moving the race around, and letting people think that they > have solved the problem when they haven't... Right. The only "safe" way is to have all blocking syscalls on the same fd in the same process return to userland. This would need to be initiated in the close() syscall. Btw. Threads aren't the only scenario. A signal handler can also close the fd. Maybe not advised, but I have used this "technique" to force a return from a blocking accept() call since about FBSD4.x Mark. From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 18:04:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C92C61F; Sat, 30 Mar 2013 18:04:47 +0000 (UTC) (envelope-from rlp@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id B7BBC396; Sat, 30 Mar 2013 18:04:46 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9B3D4D4C44; Sat, 30 Mar 2013 19:04:44 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Bg6ssCl7Fqd5; Sat, 30 Mar 2013 19:04:44 +0100 (CET) Received: from webmail.semihalf.com (semihalf.com [206.130.101.55]) by smtp.semihalf.com (Postfix) with ESMTPSA id 14C13D4C25; Sat, 30 Mar 2013 19:04:42 +0100 (CET) MIME-Version: 1.0 Date: Sat, 30 Mar 2013 12:04:40 -0600 From: Pablo Ribalta Lorenzo To: Adrian Chadd Subject: Re: vlan with modified MAC fails to communicate In-Reply-To: References: <1364561838.74177.YahooMailClassic@web121605.mail.ne1.yahoo.com> <51559F9B.3060608@semihalf.com> Message-ID: <29d7f4b41db63f9410075b1881f813b6@smtp.semihalf.com> X-Sender: rlp@semihalf.com User-Agent: RoundCube Webmail/0.2.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: Barney Cordoba , Ryan Stone , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 18:04:47 -0000 Hi guys, In my case, my NIC driver is strictly for ethernet, if not Adrian's idea would be a phenomenal solution for my issue, but maybe it's useful for me in the long run, so thanks for providing some insight. As for if_vlan.c, I verified that in the case when NIC's MAC adress is modified, it updates the values in the vlan to keep them in sync. However, I don't see this behavior when the changes are performed over the vlan. >From what I see, looks like this behavior from FreeBSD side is expected and the changes should be incorporated to my NIC. Set the NIC to promisc mode whenever both MAC addresses are not equal looks like a good workaround, however try to work out some improvement in the packet filtering method looks more like a fix to me. What holds me back is the inherent loss of performance in promisc mode, but I need to see if I'm able to live with this overhead :) From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 19:56:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAB73816 for ; Sat, 30 Mar 2013 19:56:56 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [IPv6:2001:470:c004::5]) by mx1.freebsd.org (Postfix) with ESMTP id 80C59944 for ; Sat, 30 Mar 2013 19:56:56 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.5/8.14.5) with ESMTP id r2UJm2PX061547; Sat, 30 Mar 2013 14:48:03 -0500 (CDT) (envelope-from mike@karels.net) Message-Id: <201303301948.r2UJm2PX061547@mail.karels.net> To: Pablo Ribalta Lorenzo From: Mike Karels Subject: Re: vlan with modified MAC fails to communicate In-reply-to: Your message of Sat, 30 Mar 2013 12:04:40 -0600. <29d7f4b41db63f9410075b1881f813b6@smtp.semihalf.com> Date: Sat, 30 Mar 2013 14:48:02 -0500 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mike@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:56:56 -0000 > As for if_vlan.c, I verified that in the case when NIC's MAC adress is > modified, it updates the values in the vlan to keep them in sync. However, > I don't see this behavior when the changes are performed over the vlan. There is no existing driver API to add MAC addresses in FreeBSD, which is what would be required to support different MAC addresses for different VLANs. I have added such an API @work (McAfee, in our firewall clusters), but it is limited to a small number of drivers and exactly one additional MAC in the current implementation. A more general implementation would support varying numbers of MACs per NIC before dropping into promiscuous mode. > >From what I see, looks like this behavior from FreeBSD side is expected and > the changes should be incorporated to my NIC. I'm not sure what you mean, but there is no existing code to propagate a MAC change on a VLAN to its parent device. I think it is a bug that a change appears to work. > Set the NIC to promisc mode whenever both MAC addresses are not equal looks > like a good workaround, however try to work out some improvement in the > packet filtering method looks more like a fix to me. What holds me back is > the inherent loss of performance in promisc mode, but I need to see if I'm > able to live with this overhead :) This may not be so bad on a switched network. Current drivers give you all multicasts as well as all unicasts in promiscuous mode, but you really don't need all multicasts in this case. Mike From owner-freebsd-net@FreeBSD.ORG Sat Mar 30 20:22:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA21DAB1; Sat, 30 Mar 2013 20:22:50 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id B9C15A0F; Sat, 30 Mar 2013 20:22:50 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id F218BB82A; Sat, 30 Mar 2013 13:22:49 -0700 (PDT) To: John-Mark Gurney Subject: Re: close(2) while accept(2) is blocked In-reply-to: Your message of "Sat, 30 Mar 2013 09:14:34 PDT." <20130330161434.GG76354@funkthat.com> References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> Comments: In-reply-to John-Mark Gurney message dated "Sat, 30 Mar 2013 09:14:34 -0700." Date: Sat, 30 Mar 2013 13:22:49 -0700 From: Bakul Shah Message-Id: <20130330202249.F218BB82A@mail.bitblocks.com> Cc: freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 20:22:51 -0000 On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney wrote: > > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2 Thread 3 > enters routine to read > enters routine to close > calls close(3) > open() returns 3 > does read(3) for orignal fd > > How can the original threaded program ensure that thread 2 doesn't > create a new fd in between? So even if you use a lock, this won't > help, because as far as I know, there is no enter read and unlock > mutex call yet... It is worse. Consider: fd = open(file,...); read(fd, ...); No guarantee read() gets data from the same opened file! Another thread could've come along, closed fd and pointed it to another file. So nothing is safe. Might as well stop using threads, right?! We are talking about cooperative threads where you don't have to assume the worst case. Here not being notified on a close event can complicate things. As an example, I have done something like this in the past: A frontend process validating TCP connections and then passing on valid TCP connections to another process for actual service (via sendmsg() over a unix domain). All the worker threads in service process can do a recvmsg() on the same fd. They process whatever tcp connection they get. Now what happens when the frontend process is restarted for some reason? All the worker threads need to eventually reconnect to a new unix domain posted by the new frontend process. You can handle this multiple ways but terminating all the blocking syscalls on the now invalid fd is the simplest solution from a user perspective. > I decided long ago that this is only solvable by proper use of locking > and ensuring that if you call close (the syscall), that you do not have > any other thread that may use the fd. It's the close routine's (not > syscall) function to make sure it locks out other threads and all other > are out of the code path that will use the fd before it calls close.. If you lock before close(), you have to lock before every other syscall on that fd. That complicates userland coding and slows down things when this can be handled more simply in the kernel. Another usecase is where N worker threads all accept() on the same fd. Single threading using a lock defeats any performance gain. > If someone could describe how this new eject a person from read could > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > we're just moving the race around, and letting people think that they > have solved the problem when they haven't... In general it just makes sense to notify everyone waiting on something that the situation has changed and they are going to have to wait forever. The kernel should already have the necessary information about which threads are sleeping on a fd. Wake them all up. On being awakened they see that the fd is no longer valid and all return with a count of data already read or -1 and EBADF. Doing the equivalent in userland is complicated. Carl has pointed out how BSD and Linux have required a workaround compared to Solaris and OS X (in Java and IIRC, the Go runtime). Seems like we have a number of usecases and this is something worth fixing.