From owner-freebsd-net@FreeBSD.ORG Sun Dec 9 17:56:35 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A123EB7; Sun, 9 Dec 2012 17:56:35 +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 6B6CA8FC16; Sun, 9 Dec 2012 17:56:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB9HuZ3g098720; Sun, 9 Dec 2012 17:56:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB9HuZeh098716; Sun, 9 Dec 2012 17:56:35 GMT (envelope-from linimon) Date: Sun, 9 Dec 2012 17:56:35 GMT Message-Id: <201212091756.qB9HuZeh098716@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174087: [tcp] Problems with ephemeral port selection 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, 09 Dec 2012 17:56:35 -0000 Old Synopsis: Problems with ephemeral port selection New Synopsis: [tcp] Problems with ephemeral port selection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Dec 9 17:56:08 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174087 From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 03:55:47 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1D814F6; Mon, 10 Dec 2012 03:55:47 +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 AAB6A8FC0C; Mon, 10 Dec 2012 03:55:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBA3tlvC034842; Mon, 10 Dec 2012 03:55:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBA3tl7h034838; Mon, 10 Dec 2012 03:55:47 GMT (envelope-from linimon) Date: Mon, 10 Dec 2012 03:55:47 GMT Message-Id: <201212100355.qBA3tl7h034838@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174311: [em][lagg] Can't create lagg on recent CURRENT (2012.12.05) 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, 10 Dec 2012 03:55:48 -0000 Synopsis: [em][lagg] Can't create lagg on recent CURRENT (2012.12.05) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 10 03:55:39 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174311 From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 10:03:11 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 552AD1B0 for ; Mon, 10 Dec 2012 10:03:11 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id A98018FC17 for ; Mon, 10 Dec 2012 10:03:09 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qBAA382O084236; Mon, 10 Dec 2012 14:03:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBAA386M084235; Mon, 10 Dec 2012 14:03:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 10 Dec 2012 14:03:08 +0400 From: Gleb Smirnoff To: Garrett Cooper Subject: Re: Can't create lagg interfaces on recent HEAD (2012.12.05 based sources) Message-ID: <20121210100308.GA48639@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 10 Dec 2012 10:03:11 -0000 On Fri, Dec 07, 2012 at 12:49:18PM -0800, Garrett Cooper wrote: G> I can't seem to create a lagg'ed interface on HEAD with ixgbe G> (it's failing when creating a cloned interface), whereas creating it G> on 9.1-STABLE built from a couple weeks ago just worked. Ideas? Have you recompiled the if_lagg.ko together with the kernel? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 11:04:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F9CCBF8 for ; Mon, 10 Dec 2012 11:04:10 +0000 (UTC) (envelope-from nodens2099@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF2778FC08 for ; Mon, 10 Dec 2012 11:04:09 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2898748obc.13 for ; Mon, 10 Dec 2012 03:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=XwVAxQmTAo4hHcZ7zcxipKuD29QChFE7U/vD6RLYFmk=; b=CvJPuuKvN4sHnOTydr9YFg39MleBae+IAQws9493JE631oDiq2do1qMRv/VS2D7xFq Tj2hMyxqAF6azkVkejia8NBF0CoRusfxc7NqzkGnfbQPT/3ASqjnuVaOfodJjyZADyG6 kriL5cZzx2NvEt/ZWVTLBoNwYljidEO5/C84E3b9IKwFnR9f1MHZKjG96ZMOQzGMmdF5 JDlg6M+D71x25rvo9/fWUVstgsX4B5O/8WstGw+4l9VSGWqvOfSTve0Bf3HXClEsFYmc p99cRFndLn2ICU9ditjQBVPW3DKOypR28Gls9ldl5r8nzfBKyd2mW8gLwM7r3LlboX62 lPPQ== Received: by 10.60.30.167 with SMTP id t7mr7475447oeh.44.1355137448930; Mon, 10 Dec 2012 03:04:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.151.106 with HTTP; Mon, 10 Dec 2012 03:03:48 -0800 (PST) From: =?UTF-8?Q?Cl=C3=A9ment_Hermann_=28nodens=29?= Date: Mon, 10 Dec 2012 12:03:48 +0100 Message-ID: Subject: igb and ALTQ in 9.1-rc3 To: freebsd-net@freebsd.org 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 11:04:10 -0000 Hi there, I'm trying to install a new pf/altq router. I needed to use 9.1-rc3 due to RAID driver issues. Everything works find on my quad port intel card (igb), but when I try to load my ruleset I get the following error : pfctl: igb0 : driver does not support ALTQ altq(4) states that igb is supported. There are some references to altq in if_igb.c (include opt_altq in an ifdef), but they are not in the em driver (though my ruleset load fine with a em card). Could anyone tell me if igb is supposed to support altq or not ? Thanks, Cl=C3=A9ment (nodens) From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 11:06:47 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD8CBF04 for ; Mon, 10 Dec 2012 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 907B98FC08 for ; Mon, 10 Dec 2012 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAB6l9n064310 for ; Mon, 10 Dec 2012 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAB6lpH064308 for freebsd-net@FreeBSD.org; Mon, 10 Dec 2012 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Dec 2012 11:06:47 GMT Message-Id: <201212101106.qBAB6lpH064308@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, 10 Dec 2012 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/174311 net [em][lagg] Can't create lagg on recent CURRENT (2012.1 o kern/174087 net [tcp] Problems with ephemeral port selection 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/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171697 net [ip6] [ndp] panic when changing routes 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/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/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 [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m 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/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/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 p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation 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 430 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 16:03:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D8A7E8A; Mon, 10 Dec 2012 16:03:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E09208FC16; Mon, 10 Dec 2012 16:03:44 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so3258764obc.13 for ; Mon, 10 Dec 2012 08:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CiER/IwolpM7xblOqUp+mu/FS0wlt9gbuXPqAyt534Q=; b=kqV6enaFVXp1MjQXuFf7TCbDJEDpTURTLKFqAKmmBmAeagTUkDoZxA1jILL4biFo8u 26iyjJKR1WB/fNFKl0Eb1LQHBXCkL4fK3hUbiYcWWlBQ2lsY7hnF6tKmOwoSqDKZ7N2i QOhUnw2dvXBxHILHNVuWABHHL1K59kZb0kXgkbxDxC/UJSqC4Ih+PAyyPDQEmPUQ9o7g ztoPpBeYoCsH5cGmKaa1XPsShdrVdNn8TWPHoRms9JJDPFFZ4bpRuG1jpDB+NFO5fkMt xVP/2pjo03dOa8s86XMGQ2uR25aTWdmIeiaK96FPCc0kbAm8+2Cyh9ftsBA1DoMwye2o 0Kkg== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr7753925obc.83.1355155424188; Mon, 10 Dec 2012 08:03:44 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 08:03:43 -0800 (PST) In-Reply-To: <20121210100308.GA48639@FreeBSD.org> References: <20121210100308.GA48639@FreeBSD.org> Date: Mon, 10 Dec 2012 08:03:43 -0800 Message-ID: Subject: Re: Can't create lagg interfaces on recent HEAD (2012.12.05 based sources) From: Garrett Cooper To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 10 Dec 2012 16:03:45 -0000 On Mon, Dec 10, 2012 at 2:03 AM, Gleb Smirnoff wrote: > On Fri, Dec 07, 2012 at 12:49:18PM -0800, Garrett Cooper wrote: > G> I can't seem to create a lagg'ed interface on HEAD with ixgbe > G> (it's failing when creating a cloned interface), whereas creating it > G> on 9.1-STABLE built from a couple weeks ago just worked. Ideas? > > Have you recompiled the if_lagg.ko together with the kernel? Ugh, good guess. Somehow it appears that it was picking up if_lagg.ko from kernel.old and this error message only magically appeared in the last couple hours on the machine (or I missed it previously in the console noise). Rebuilding/reinstalling the kernel to verify that it works after reboot. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 16:11:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1B21FD; Mon, 10 Dec 2012 16:11:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9CB8FC15; Mon, 10 Dec 2012 16:11:06 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3441171oag.13 for ; Mon, 10 Dec 2012 08:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UskusPLVVGfGp6E3G4G82LT5AWMRL0RYHTqZbCANLgk=; b=1CewXtCo/cL5PKWkZONEt4wJccqexEVjEKJeuo0zWTEsXKP3nTcDfpZbMQaDfQbUKD j3LO4N2AufH3yKJJyaaqXSL2Fw6BA3IzU345gLtLfzna2ObcXATtaXvAb+qZY86eWPC/ 3iRUMc+2V7pXto36H/7D7l3N7tlcVsZctqYwpBBOJI5NRumnZy/THILe21tvr7I1HAMM IzEJydCyhNn08MPULP7rd8LGpsUnsSPx03rWjnOfifErUFlZpLiigolTWmP07sybdY5c iUzIeY3nC/H3IdaG8owDdG2CQcuf+Y6nhWSTYaEbOrDDMSGd4CgTzX9hElZgGWaJ3o30 V7zg== MIME-Version: 1.0 Received: by 10.60.172.178 with SMTP id bd18mr7952868oec.133.1355155865809; Mon, 10 Dec 2012 08:11:05 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 08:11:05 -0800 (PST) In-Reply-To: References: <20121210100308.GA48639@FreeBSD.org> Date: Mon, 10 Dec 2012 08:11:05 -0800 Message-ID: Subject: Re: Can't create lagg interfaces on recent HEAD (2012.12.05 based sources) From: Garrett Cooper To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 10 Dec 2012 16:11:06 -0000 On Mon, Dec 10, 2012 at 8:03 AM, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 2:03 AM, Gleb Smirnoff wrote: >> On Fri, Dec 07, 2012 at 12:49:18PM -0800, Garrett Cooper wrote: >> G> I can't seem to create a lagg'ed interface on HEAD with ixgbe >> G> (it's failing when creating a cloned interface), whereas creating it >> G> on 9.1-STABLE built from a couple weeks ago just worked. Ideas? >> >> Have you recompiled the if_lagg.ko together with the kernel? > > Ugh, good guess. Somehow it appears that it was picking up > if_lagg.ko from kernel.old and this error message only magically > appeared in the last couple hours on the machine (or I missed it > previously in the console noise). Rebuilding/reinstalling the kernel > to verify that it works after reboot. Turns out the part about it picking up the module from kernel.old was just not noting that someone else had logged into the box and tried to load the 9.1 KLD. So, still building and installing, but at least I know now that there weren't any daemons in the machine (just off it ;)..). Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 16:21:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EC3E47E; Mon, 10 Dec 2012 16:21:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDA028FC14; Mon, 10 Dec 2012 16:21:57 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so3287693obc.13 for ; Mon, 10 Dec 2012 08:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w+g9YKWtyM+IeoE/VF/c7Ah+IdGPqaYKZClwl8U7tPc=; b=SM8t5EsXWtTwzfXsS1jewnkYCNIJslFWKXRwOOSntIl3bFFeS6N0BL/meYNgp+Q8/x aVNsOIp2lqSV/IYGK9jZgQrBBInWsIeBFIHcjTRpVP8gZ2XxMWOWzCw5UEBGlbeer12B IlMEnG0tZUMIsbFLN7jZORANSSLpOeZUKdIosY+VxCKaVq0i0Yg/NAKyjqcKe+Oxo/eP /l9HcMrFHdK4vC3oTJJCPjdxh5wR/o6Nw1k6X6EBWnLiqZtS3j2WRGsft97/JTVLEPgZ oe2kLQnwyJRNE7z2qhVijbpAgkd6fL9HiW3Ut9wIwpI7V4PvrU4/ZJ5rAiibHHEVOAay PVqA== MIME-Version: 1.0 Received: by 10.182.36.8 with SMTP id m8mr2086492obj.93.1355156517342; Mon, 10 Dec 2012 08:21:57 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 08:21:57 -0800 (PST) In-Reply-To: References: <20121210100308.GA48639@FreeBSD.org> Date: Mon, 10 Dec 2012 08:21:57 -0800 Message-ID: Subject: Re: Can't create lagg interfaces on recent HEAD (2012.12.05 based sources) From: Garrett Cooper To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 10 Dec 2012 16:21:58 -0000 On Mon, Dec 10, 2012 at 8:11 AM, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 8:03 AM, Garrett Cooper wrote: >> On Mon, Dec 10, 2012 at 2:03 AM, Gleb Smirnoff wrote: >>> On Fri, Dec 07, 2012 at 12:49:18PM -0800, Garrett Cooper wrote: >>> G> I can't seem to create a lagg'ed interface on HEAD with ixgbe >>> G> (it's failing when creating a cloned interface), whereas creating it >>> G> on 9.1-STABLE built from a couple weeks ago just worked. Ideas? >>> >>> Have you recompiled the if_lagg.ko together with the kernel? >> >> Ugh, good guess. Somehow it appears that it was picking up >> if_lagg.ko from kernel.old and this error message only magically >> appeared in the last couple hours on the machine (or I missed it >> previously in the console noise). Rebuilding/reinstalling the kernel >> to verify that it works after reboot. > > Turns out the part about it picking up the module from kernel.old > was just not noting that someone else had logged into the box and > tried to load the 9.1 KLD. So, still building and installing, but at > least I know now that there weren't any daemons in the machine (just > off it ;)..). Yup -- that was it. Sorry for the noise (wish there was a more humanized message for this, but now that I know what to look for I'll avoid making the same mistake twice). -Garrett From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 16:30:01 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 623659D7 for ; Mon, 10 Dec 2012 16:30: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 2C2A28FC1A for ; Mon, 10 Dec 2012 16:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAGU0iU091052 for ; Mon, 10 Dec 2012 16:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAGU0mG091051; Mon, 10 Dec 2012 16:30:00 GMT (envelope-from gnats) Date: Mon, 10 Dec 2012 16:30:00 GMT Message-Id: <201212101630.qBAGU0mG091051@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Garrett Cooper Subject: Re: kern/174311: [em][lagg] Can' t create lagg on recent CURRENT (2012.12.05) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Garrett Cooper List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:30:01 -0000 The following reply was made to PR kern/174311; it has been noted by GNATS. From: Garrett Cooper To: bug-followup@FreeBSD.org, yanegomi@gmail.com Cc: Subject: Re: kern/174311: [em][lagg] Can't create lagg on recent CURRENT (2012.12.05) Date: Mon, 10 Dec 2012 08:20:34 -0800 Please close; was user error. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 16:49:52 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CCBFBD; Mon, 10 Dec 2012 16:49:52 +0000 (UTC) (envelope-from delphij@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 49DD78FC0C; Mon, 10 Dec 2012 16:49:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAGnqKD091642; Mon, 10 Dec 2012 16:49:52 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAGnqQV091638; Mon, 10 Dec 2012 16:49:52 GMT (envelope-from delphij) Date: Mon, 10 Dec 2012 16:49:52 GMT Message-Id: <201212101649.qBAGnqQV091638@freefall.freebsd.org> To: yanegomi@gmail.com, delphij@FreeBSD.org, freebsd-net@FreeBSD.org From: delphij@FreeBSD.org Subject: Re: kern/174311: [em][lagg] Can't create lagg on recent CURRENT (2012.12.05) 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, 10 Dec 2012 16:49:52 -0000 Synopsis: [em][lagg] Can't create lagg on recent CURRENT (2012.12.05) State-Changed-From-To: open->closed State-Changed-By: delphij State-Changed-When: Mon Dec 10 16:48:43 UTC 2012 State-Changed-Why: Closed per submitter request: it seems to be an ABI mismatch between kernel and module. http://www.freebsd.org/cgi/query-pr.cgi?pr=174311 From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 22:09:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 121492C8 for ; Mon, 10 Dec 2012 22:09:15 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) by mx1.freebsd.org (Postfix) with ESMTP id A1EAE8FC08 for ; Mon, 10 Dec 2012 22:09:14 +0000 (UTC) Received: from [98.138.226.176] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2012 22:09:08 -0000 Received: from [98.138.89.170] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2012 22:09:08 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 10 Dec 2012 22:09:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 437966.79776.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 72629 invoked by uid 60001); 10 Dec 2012 22:09:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1355177348; bh=Gdyy28nKfMcJCZKqgEkEJkkgcc4KEuAAYPkD5vXF/+U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HmcQQ30P3wNAvnyqoRxpg9IYswOWSTJKhh3pPQlM0Rn6QJjokJ1yTS15XmKIoOHHj6DtThwC+B3KZrBOJLkkoGOpKQ5XTuSwPAZ6hjGGTMCy2nastOhQhtzkWULKDzhNULY4DmjisxL/bXPW6JSN0xZ7fNKAia/2J4+5VzMBTxo= 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:Content-Transfer-Encoding; b=L/KnWnnQZ2wtJfp7zJAszo5v++mQIQmUHyFLR2pwOsjK5G2N76xcbpv8G+wRVUBSQRvi+QM8XtLkUJco0c1CPBZHqxaQuqCig90ACC7k7JSwziFxNTvWnqLbBRIQXSiGGbIk9P+IfzOw2ya/HHtIK/v7zfN95SdSJZmlFRYRb1U=; X-YMail-OSG: fXFI.aEVM1kkeJsCuQSMfSfejYwtfXt4W5Am4hyDeEqjqfz NhjT6TGQ4wUta8CHkwJgR9J9owvx1jFH2W9bXxRYpqDJPzhMIQ6p1NKwC_5V kG.4fastRcKJz6Oxlz5bR6EX9ei3pPFBklWFUXLb7G6wdaFLJUQJ4V90uznJ BDJLL180Llco1ylw5vNNI9KlSs9Gd5dQj7k8XD6BffpK1sGtoKEed31MpEtF 4GEJy7nSnCXqHnzxcmcXclg9rVUpOazWPceyD2NQ7M7O4goGIKSrsIDZEwLP q6G_SZV5qd2LrGS8a41vg2vrcY7Ab1ap9qCQvocJLzcOzSzpRW5AIMcLkwhP bRtLrZ04bkUfJpeu65vFzdjedOxL9W6bC8_ogvx3BnljRuoMBOAvwvFnVLeL rYTIQpGhC6pYB7J406zZpyPKzFbO79fAvA7OkvaHuRyXVy2YzpNwLTDePzWG wOmNEpdSjimKYET_agOKkw257k6Km7eKwre3B9Yo2MKsiM7uMr.iuUgjcyrt 8jpsRfeKiBwRPpUhKWxyEGgxL4ZtGsw-- Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Mon, 10 Dec 2012 14:09:08 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gTW9uLCAxMi8xMC8xMiwgQ2zDqW1lbnQgSGVybWFubiAobm9kZW5zKSA8bm9kZW5zMjA5OUBnbWFpbC5jb20.IHdyb3RlOgoKPiBGcm9tOiBDbMOpbWVudCBIZXJtYW5uIChub2RlbnMpIDxub2RlbnMyMDk5QGdtYWlsLmNvbT4KPiBTdWJqZWN0OiBpZ2IgYW5kIEFMVFEgaW4gOS4xLXJjMwo.IFRvOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZwo.IERhdGU6IE1vbmRheSwgRGVjZW1iZXIgMTAsIDIwMTIsIDY6MDMgQU0KPiBIaSB0aGVyZSwKPiAKPiBJJ20gdHJ5aW5nIHRvIGluc3RhbGwgYSBuZXcBMAEBAQE- X-Mailer: YahooMailClassic/15.1.1 YahooMailWebService/0.8.128.478 Message-ID: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Mon, 10 Dec 2012 14:09:08 -0800 (PST) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 10 Dec 2012 22:09:15 -0000 =0A=0A--- On Mon, 12/10/12, Cl=E9ment Hermann (nodens) wrote:=0A=0A> From: Cl=E9ment Hermann (nodens) =0A= > Subject: igb and ALTQ in 9.1-rc3=0A> To: freebsd-net@freebsd.org=0A> Date= : Monday, December 10, 2012, 6:03 AM=0A> Hi there,=0A> =0A> I'm trying to i= nstall a new pf/altq router. I needed to use=0A> 9.1-rc3 due to=0A> RAID dr= iver issues.=0A> =0A> Everything works find on my quad port intel card (igb= ), but=0A> when I try to=0A> load my ruleset I get the following error :=0A= > =0A> pfctl: igb0 : driver does not support ALTQ=0A> =0A> altq(4) states t= hat igb is supported. There are some=0A> references to altq in=0A> if_igb.c= (include opt_altq in an ifdef), but they are not in=0A> the em driver=0A> = (though my ruleset load fine with a em card).=0A> =0A> Could anyone tell me= if igb is supposed to support altq or=0A> not ?=0A> =0A> Thanks,=0A> =0A> = Cl=E9ment (nodens)=0A=0AI'll take a guess that the ALTQ description was wri= tten before igb=0Astopped supporting it.=0A From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 22:22:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7047AEB; Mon, 10 Dec 2012 22:22:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0E68FC0C; Mon, 10 Dec 2012 22:22:35 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3979299oag.13 for ; Mon, 10 Dec 2012 14:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=x0xcM9zuZk9bcCSa7Fam6zHpDk0wORQlZwWrvFYczqM=; b=iHsuuMpf5rowce53n8vgUZ/XHoABrGYzYh5pXUxDyMxElWcY/aD1AZIPP6daDwEea7 AEX8AZYPy+aaB0qaFgYr4HZd8HE11qCZT5ZeALacaRi4fcQIe+pGY2tMN37EwwgsIHn1 BM76TQBd/S2+yZBvcpnjsQjAdFCkJYXUO+2gP0n3bZqB9Kn5dDLFNG7cx+fYkA9asetp Agjp9sqxF4PTscKWXBi1fsYI5fOrauFNEMfqxknFpdcVw31i3HZmal126QCbLR2IY9vM iMbsOI2krkQOPr+wNY2JJzP1hkvcutvYnb1u+Fr/yyTfeJLD+GDheGsayultOZsDwYkc D7Mw== MIME-Version: 1.0 Received: by 10.60.172.164 with SMTP id bd4mr7664871oec.51.1355178153559; Mon, 10 Dec 2012 14:22:33 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 14:22:33 -0800 (PST) Date: Mon, 10 Dec 2012 14:22:33 -0800 Message-ID: Subject: "Memory modified after free" - by whom? From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 10 Dec 2012 22:22:36 -0000 I noticed this while checking the logs on one of my test boxes after restarting the network. Any idea where I should start looking into this (has IPv6 enabled but wasn't using it, em/cxgbe/ixgbe interfaces with the ixgbe interfaces lagged previously, but now not)? It looks suspiciously like the same size as a jumbo frame, but I'm not 100% sure if that's the real problem. Thanks, -Garrett Dec 10 14:03:12 wf158 kernel: em0: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:13 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:15 wf158 kernel: em0: link state changed to UP Dec 10 14:03:15 wf158 dhclient: New IP Address (em0): 10.7.169.89 Dec 10 14:03:15 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 Dec 10 14:03:15 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 Dec 10 14:03:15 wf158 dhclient: New Routers (em0): 10.7.160.1 Dec 10 14:03:16 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:16 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:31 wf158 kernel: in6_purgeaddr: err=65, destination address delete failed Dec 10 14:03:31 wf158 dhclient[4539]: My address (10.7.169.89) was deleted, dhclient exiting Dec 10 14:03:32 wf158 dhclient[4521]: short write: wanted 20 got 0 bytes Dec 10 14:03:32 wf158 dhclient[4521]: exiting. Dec 10 14:03:33 wf158 kernel: em0: link state changed to DOWN Dec 10 14:03:33 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:34 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:36 wf158 kernel: em0: link state changed to UP Dec 10 14:03:36 wf158 dhclient: New IP Address (em0): 10.7.169.89 Dec 10 14:03:36 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 Dec 10 14:03:36 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 Dec 10 14:03:36 wf158 dhclient: New Routers (em0): 10.7.160.1 Dec 10 14:05:34 wf158 kernel: Memory modified after free 0xffffff81c016d000(9216) val=ffffffff @ 0xffffff81c016d000 Dec 10 14:05:35 wf158 kernel: Memory modified after free 0xffffff81b5cdc000(9216) val=ffffffff @ 0xffffff81b5cdc000 # uname -a FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r+2760369-dirty: Mon Dec 10 08:04:46 PST 2012 root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 22:43:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DB3A3D8 for ; Mon, 10 Dec 2012 22:43:11 +0000 (UTC) (envelope-from nodens2099@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A734B8FC16 for ; Mon, 10 Dec 2012 22:43:10 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so1799718wey.13 for ; Mon, 10 Dec 2012 14:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bQOn4XaB+3D2IDUlEK+zg/R/pCaG2VcLyR2f3zSawDI=; b=hYETqSD6k3nHHj7wYdEU+UIQt3SuLdRLfnSRDoO4oRmGdPoRE8cFy4aOdtjlb1jsZb P+Jw4bP8n9qA5E8XvbLo4vIPL8+rFR6+LKfjbNBgkwLlykkMaD7QTzGIIFTZTnJXrUct +0+a1kI1vLES4zWqX7EElGkP6J7tvBYotNpc/LRTzdxc6cYq3i58GpYi9qIVxQFURThF koRaI8J5Lc9YMqQo/wH4vRWEfhCb+sIKP2HUkEg+t2b3f+wcjP6sPTB363IJ8CkWDh1m SjwedHKSVyjBvEObBMmu8OMhJg2cdlmiswS3pBmAYJ54wewmxl0nZUgOM6BgyF//UKLj 1WvA== Received: by 10.180.20.177 with SMTP id o17mr13432537wie.18.1355179384419; Mon, 10 Dec 2012 14:43:04 -0800 (PST) Received: from [192.168.99.2] (fon38-4-88-185-152-198.fbx.proxad.net. [88.185.152.198]) by mx.google.com with ESMTPS id bd7sm13702716wib.8.2012.12.10.14.43.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 14:43:03 -0800 (PST) Message-ID: <50C6656E.3020601@gmail.com> Date: Mon, 10 Dec 2012 23:42:54 +0100 From: "Clement Hermann (nodens)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> In-Reply-To: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Mon, 10 Dec 2012 22:43:11 -0000 Le 10/12/2012 23:09, Barney Cordoba a écrit : > > --- On Mon, 12/10/12, Clément Hermann (nodens) wrote: > >> altq(4) states that igb is supported. There are some >> references to altq in >> if_igb.c (include opt_altq in an ifdef), but they are not in >> the em driver >> (though my ruleset load fine with a em card). >> >> Could anyone tell me if igb is supposed to support altq or >> not ? >> >> Thanks, >> >> Clément (nodens) > I'll take a guess that the ALTQ description was written before igb > stopped supporting it. > Well, that is a plausible explanation. I thought it might be something like that, but since I didn't find any changelog or commit saying "dropping support for altq on igb" I was hoping to be wrong. So you're positive igb does not support altq anymore ? -- Clement Hermann (nodens) - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?" Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/ Vous trouverez ma clef publique sur le serveur public pgp.mit.edu. Please find my public key on the public keyserver pgp.mit.edu. From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 23:10:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5251DAC1; Mon, 10 Dec 2012 23:10:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D7D7E8FC18; Mon, 10 Dec 2012 23:10:58 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo14so3993039vcb.13 for ; Mon, 10 Dec 2012 15:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jVSaj4ddHb8ClAuhxbdz12tOufj15Iy1jdIcaEojd4o=; b=cGtzDIbbvBgm9IL57W/nyW3FIyIdgbX9h5cgblcAp8dW7sfQ3uuw6j5ivMczE0n3DI wNwx6JAwQo8rSFo5535gSJ0D7crqTy0/5B2zJnLu2xG9MSq3Y2Bd2IjXQ8lh3wjxLyq8 hadOKVUExa2f+kiUlWSG9Z7tOIIVYGtE6jlIXvIab33B713neBKfnWg7DuJNTavGn6BE 4KFB6GSFCftSFGzPL2VDMB8npFEReuYUIV2C4PSe80XSRj75YmhrIb1fBdrUpQCFPb0A V8yUqXo72XNZFi12odWoeS3uCQgSt9OyI1YRorlrpeNUEto4C7OB8D2cEBIORtXzPHuy LQwg== MIME-Version: 1.0 Received: by 10.52.98.36 with SMTP id ef4mr8696461vdb.104.1355181057877; Mon, 10 Dec 2012 15:10:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.201.202 with HTTP; Mon, 10 Dec 2012 15:10:57 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 15:10:57 -0800 X-Google-Sender-Auth: 3G7VBInCSBJYmiogDZC4pCVBkyE Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, FreeBSD Current 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, 10 Dec 2012 23:10:59 -0000 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf after it's finalised/freed. I have a similar bug showing up on ath(4) RX. :( adrian On 10 December 2012 14:22, Garrett Cooper wrote: > I noticed this while checking the logs on one of my test boxes > after restarting the network. Any idea where I should start looking > into this (has IPv6 enabled but wasn't using it, em/cxgbe/ixgbe > interfaces with the ixgbe interfaces lagged previously, but now not)? > It looks suspiciously like the same size as a jumbo frame, but I'm not > 100% sure if that's the real problem. > Thanks, > -Garrett > > Dec 10 14:03:12 wf158 kernel: em0: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:13 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:15 wf158 kernel: em0: link state changed to UP > Dec 10 14:03:15 wf158 dhclient: New IP Address (em0): 10.7.169.89 > Dec 10 14:03:15 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 > Dec 10 14:03:15 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 > Dec 10 14:03:15 wf158 dhclient: New Routers (em0): 10.7.160.1 > Dec 10 14:03:16 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:16 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:31 wf158 kernel: in6_purgeaddr: err=65, destination > address delete failed > Dec 10 14:03:31 wf158 dhclient[4539]: My address (10.7.169.89) was > deleted, dhclient exiting > Dec 10 14:03:32 wf158 dhclient[4521]: short write: wanted 20 got 0 bytes > Dec 10 14:03:32 wf158 dhclient[4521]: exiting. > Dec 10 14:03:33 wf158 kernel: em0: link state changed to DOWN > Dec 10 14:03:33 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:34 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:36 wf158 kernel: em0: link state changed to UP > Dec 10 14:03:36 wf158 dhclient: New IP Address (em0): 10.7.169.89 > Dec 10 14:03:36 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 > Dec 10 14:03:36 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 > Dec 10 14:03:36 wf158 dhclient: New Routers (em0): 10.7.160.1 > Dec 10 14:05:34 wf158 kernel: Memory modified after free > 0xffffff81c016d000(9216) val=ffffffff @ 0xffffff81c016d000 > Dec 10 14:05:35 wf158 kernel: Memory modified after free > 0xffffff81b5cdc000(9216) val=ffffffff @ 0xffffff81b5cdc000 > > # uname -a > FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 > r+2760369-dirty: Mon Dec 10 08:04:46 PST 2012 > root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 > _______________________________________________ > 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 Mon Dec 10 23:18:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD229523; Mon, 10 Dec 2012 23:18:46 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9028FC12; Mon, 10 Dec 2012 23:18:46 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2289828pbc.13 for ; Mon, 10 Dec 2012 15:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U1bh6ZSvMw9khWC+8oQT5O6hNcR+B9frvdyIdwe0I6Q=; b=qkBLsSI2KaCuHhxua9JfeJv/fRq9upt6KNGewi2M5Wk35BxdOhjsFzHuOP0hCGp1Lh BuhDPqizYWnjN3Asmy8GK3rLa2SxjV/UMhSWSdriEmroIfgNRaT6UziJr/STCwSreTqC m4QQBb3CScKR14CSHLmYlVzhbpGzThGKs22jvVjJaqUpFKVhPCDcvntylM6nT6Cp4mpH B5JwYv5LuwRZinziDTgvJffTndClxTp/p4PsB7fAoeNiCTtT1g5/fVsK2B2vuUTiN8dt xXcFM8niQwhGiKizujdSWK1xB826aO+31rEqqb9/YgdKXvTCD9t2BJnoD1tQfWhImR75 9gVg== MIME-Version: 1.0 Received: by 10.66.80.68 with SMTP id p4mr39868443pax.35.1355181525767; Mon, 10 Dec 2012 15:18:45 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.166 with HTTP; Mon, 10 Dec 2012 15:18:45 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 15:18:45 -0800 X-Google-Sender-Auth: j0Wm823QFKo7Tm0elWmqQK7-aR0 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: mdf@FreeBSD.org To: Adrian Chadd , Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, FreeBSD Current 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, 10 Dec 2012 23:18:46 -0000 On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: > 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf > after it's finalised/freed. > > I have a similar bug showing up on ath(4) RX. :( Compile with DEBUG_MEMGUARD in the kernel configuration, and then set vm.memguard.desc to the name of the UMA zone used for the 9216 byte allocations, mbuf_jumbo_9k. This should cause a panic when the memory is touched after free. Cheers, matthew > On 10 December 2012 14:22, Garrett Cooper wrote: >> I noticed this while checking the logs on one of my test boxes >> after restarting the network. Any idea where I should start looking >> into this (has IPv6 enabled but wasn't using it, em/cxgbe/ixgbe >> interfaces with the ixgbe interfaces lagged previously, but now not)? >> It looks suspiciously like the same size as a jumbo frame, but I'm not >> 100% sure if that's the real problem. >> Thanks, >> -Garrett >> >> Dec 10 14:03:12 wf158 kernel: em0: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:13 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:15 wf158 kernel: em0: link state changed to UP >> Dec 10 14:03:15 wf158 dhclient: New IP Address (em0): 10.7.169.89 >> Dec 10 14:03:15 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 >> Dec 10 14:03:15 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 >> Dec 10 14:03:15 wf158 dhclient: New Routers (em0): 10.7.160.1 >> Dec 10 14:03:16 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:16 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:31 wf158 kernel: in6_purgeaddr: err=65, destination >> address delete failed >> Dec 10 14:03:31 wf158 dhclient[4539]: My address (10.7.169.89) was >> deleted, dhclient exiting >> Dec 10 14:03:32 wf158 dhclient[4521]: short write: wanted 20 got 0 bytes >> Dec 10 14:03:32 wf158 dhclient[4521]: exiting. >> Dec 10 14:03:33 wf158 kernel: em0: link state changed to DOWN >> Dec 10 14:03:33 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:34 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:36 wf158 kernel: em0: link state changed to UP >> Dec 10 14:03:36 wf158 dhclient: New IP Address (em0): 10.7.169.89 >> Dec 10 14:03:36 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 >> Dec 10 14:03:36 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 >> Dec 10 14:03:36 wf158 dhclient: New Routers (em0): 10.7.160.1 >> Dec 10 14:05:34 wf158 kernel: Memory modified after free >> 0xffffff81c016d000(9216) val=ffffffff @ 0xffffff81c016d000 >> Dec 10 14:05:35 wf158 kernel: Memory modified after free >> 0xffffff81b5cdc000(9216) val=ffffffff @ 0xffffff81b5cdc000 >> >> # uname -a >> FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >> r+2760369-dirty: Mon Dec 10 08:04:46 PST 2012 >> root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 >> _______________________________________________ >> 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 23:21:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 145838EA; Mon, 10 Dec 2012 23:21:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9043D8FC13; Mon, 10 Dec 2012 23:21:45 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so4011130vba.13 for ; Mon, 10 Dec 2012 15:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KgcJGKZWpZSMhGc6NXwpKpFHRWM6NdN5JQUMoRt2H0M=; b=UDohXtR8AUHB4lMTLKFskKu2qk8TtmFEFQMJEfqDEBjyigysaNsekFVmtkgF7Q1vW/ HzYveLYOVHhHM7DAQ+51SvRgPnqxAFjymYPfWhmrqRypacKguWU/lrlcnYbiRgX/5zwl auk+y6WeziFpRBNltiPKwe0xPIuznFuBDs9sasLYXRPYsaHnHSYGuIFQkKdsk3SeUX0l JF3hx89o/dCLlqS3rHTiFy9I4K2q6ZpgKoY0Tjcey+SAaCmqKkG7RANPBG2U8JtlOSTU WNQDQoMq1qQXRG8KDAsCeZ4vLsOCmNZ6LkB3M/CwEVA1ubjiTJtkZr5gBQnEseX7a30N sE9Q== MIME-Version: 1.0 Received: by 10.58.239.162 with SMTP id vt2mr10326635vec.1.1355181704741; Mon, 10 Dec 2012 15:21:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.201.202 with HTTP; Mon, 10 Dec 2012 15:21:44 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 15:21:44 -0800 X-Google-Sender-Auth: 9lN_vMmu972aJdTl6GNcFAu1w6c Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Adrian Chadd To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-net@freebsd.org, FreeBSD Current 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, 10 Dec 2012 23:21:46 -0000 On 10 December 2012 15:18, wrote: > On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >> after it's finalised/freed. >> >> I have a similar bug showing up on ath(4) RX. :( > > Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > vm.memguard.desc to the name of the UMA zone used for the 9216 byte > allocations, mbuf_jumbo_9k. This should cause a panic when the memory > is touched after free. Right, but I think its a _hardware_ access after the buffer has been freed.. Adrian From owner-freebsd-net@FreeBSD.ORG Mon Dec 10 23:31:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13F47D7E for ; Mon, 10 Dec 2012 23:31:20 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B37D08FC0C for ; Mon, 10 Dec 2012 23:31:19 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so4020172vba.13 for ; Mon, 10 Dec 2012 15:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WTnInkYtx5CpHbSRv9cMv5yXVEfoakL0+YrSnFCyCJk=; b=CM+kGPWzKYyCW9vVUKRG07LtbkuMQHQKJQMpHtWE+CRXjyz6RDttTsjBJRAM7E//3S LuvB54CJiGYivZGMMP17JoHAROUlNAOZA4ETWVSNHFSTDs1An+OTPT/6NuIg8VfFE09z AX7BsgmPI6oLO6WdLI/dzqhZKKxz/F9K7tfKU92UnIR4ngSdc8Xy9cSMYIlSLx9TClOI CY7eeuDDwvtx8zr4Bj0RkJy9iSjGyzT0aon5xkDaEm/ZC+Ay1ZRtNwr2Nb+av5WE48Ag s5S2C7prSNoHXX5riF7gHEc2eLoj6Yphj5LYPsWMmGxlmRZW8lnid8uRVvDWL1XFkXAY pNtw== MIME-Version: 1.0 Received: by 10.52.240.146 with SMTP id wa18mr8479154vdc.47.1355182279216; Mon, 10 Dec 2012 15:31:19 -0800 (PST) Received: by 10.220.50.6 with HTTP; Mon, 10 Dec 2012 15:31:19 -0800 (PST) In-Reply-To: <50C6656E.3020601@gmail.com> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> Date: Mon, 10 Dec 2012 15:31:19 -0800 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Jack Vogel To: "Clement Hermann (nodens)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , 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, 10 Dec 2012 23:31:20 -0000 UH, maybe asking the owner of the driver would help :) ... and no, I've never been aware of doing anything to stop supporting altq so you wouldn't see any commits. If there's something in the altq code or support (which I have nothing to do with) that caused this no-one informed me. Jack On Mon, Dec 10, 2012 at 2:42 PM, Clement Hermann (nodens) < nodens2099@gmail.com> wrote: > Le 10/12/2012 23:09, Barney Cordoba a =E9crit : > > > > --- On Mon, 12/10/12, Cl=E9ment Hermann (nodens) > wrote: > > > >> altq(4) states that igb is supported. There are some > >> references to altq in > >> if_igb.c (include opt_altq in an ifdef), but they are not in > >> the em driver > >> (though my ruleset load fine with a em card). > >> > >> Could anyone tell me if igb is supposed to support altq or > >> not ? > >> > >> Thanks, > >> > >> Cl=E9ment (nodens) > > I'll take a guess that the ALTQ description was written before igb > > stopped supporting it. > > > > Well, that is a plausible explanation. I thought it might be something > like that, but since I didn't find any changelog or commit saying > "dropping support for altq on igb" I was hoping to be wrong. > > So you're positive igb does not support altq anymore ? > > > -- > Clement Hermann (nodens) > - "L'air pur ? c'est pas en RL, =E7a ? c'est pas hors charte ?" > Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/ > > Vous trouverez ma clef publique sur le serveur public pgp.mit.edu. > Please find my public key on the public keyserver pgp.mit.edu. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 01:37:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8F8C9F3; Tue, 11 Dec 2012 01:37:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44F1A8FC0C; Tue, 11 Dec 2012 01:37:17 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4142047oag.13 for ; Mon, 10 Dec 2012 17:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cWNkoDULkc/Uje2L8kLnPciq24V/jCjHh6F67TwbbCs=; b=DPStZoY6aAiAnOFNpGRbfmDnp1AuCtrxcqNbjv6toRWtg1uAPOh3g9UQ4dW8gwFb/t OemnD4Q2Qjro67dhRGhO0AoEOv/qfqq/R6akZ0q9OEHSWyzJIFjYO2aeMv7eX54T9eaS yRilSvZ7P9gaozFo9V7ECEfItIpd/BOHxTNohmeDkZ4gqKkk8hLK2iv/5J+3TcKJZutM aIhNo6A/dAUXuz/sinSA09F2iosXcBLULpOYytRdAF7hsiNWUh9mqXhEttEzLiU3PlAp N9moztY8vzT7Bziw0blXS6dbj3fATei0yGXMGJ25ggEbBCuwegt8F59xUZ3gyXsFcdd0 IzoA== MIME-Version: 1.0 Received: by 10.182.131.100 with SMTP id ol4mr8421128obb.38.1355189837412; Mon, 10 Dec 2012 17:37:17 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 17:37:17 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 17:37:17 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: mdf@freebsd.org, FreeBSD Current , 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, 11 Dec 2012 01:37:18 -0000 On Mon, Dec 10, 2012 at 3:21 PM, Adrian Chadd wrote: > On 10 December 2012 15:18, wrote: >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >>> after it's finalised/freed. >>> >>> I have a similar bug showing up on ath(4) RX. :( >> >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory >> is touched after free. > > Right, but I think its a _hardware_ access after the buffer has been freed.. At least that will give me an idea of who to punt the bug over to next (assuming it lists the driver) -- one of the network folks, jfv, or np :). It seems to be a recent change that's causing this (it's spewing out these warnings every couple seconds), but that might also be related to me getting lagg working on CURRENT as my last known base was 9-STABLE and a lot of networking changes haven't been MFCed :). I could probably look through the code too after compiling it, but it would take too long. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 02:34:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CC3B46A; Tue, 11 Dec 2012 02:34:09 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E26D8FC12; Tue, 11 Dec 2012 02:34:08 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so2546103pad.13 for ; Mon, 10 Dec 2012 18:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=5c1hnPCGJJ7zTmRNDZ70C1RWwdEhcT02D5zQljfG6JM=; b=NkgDfwFsLM5sfdTBr7Lk64kVRKFoe9DWB0TdGegGqmTzdTnCGum88IIEPKl+QjLK3l RnAP+ViYLhUhkO45FcJC6nlHGKJ4eiUOYYTMwVocPlk2A2657QYgm8hOSBOu7pb9dgfM bP31I3BRNyNbHW0pt9ipuSJJYpoZoun9yHqLwOpLXNCBU0a53z2p+HNEAz4hbWZJa0Kq p6TiHwZshwx3VcE7NRp6yg7WP6ckLspX/fLMpPOtx8PFHp0saTdhEO5zKZsOj1RVr4wr nuHIrnlV2uP9B5N4HoCEeo6dxvijc0035s55gr2yz4SeI7uTl9kCuMv1o462PIHvCjEU NrdA== Received: by 10.68.239.104 with SMTP id vr8mr44547947pbc.59.1355193242646; Mon, 10 Dec 2012 18:34:02 -0800 (PST) Received: from itx (c-24-6-45-85.hsd1.ca.comcast.net. [24.6.45.85]) by mx.google.com with ESMTPS id na7sm438594pbc.48.2012.12.10.18.33.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 18:34:00 -0800 (PST) Date: Mon, 10 Dec 2012 18:33:54 -0800 From: Navdeep Parhar To: Garrett Cooper Subject: Re: "Memory modified after free" - by whom? Message-ID: <20121211023354.GA1916@itx> Mail-Followup-To: Garrett Cooper , Adrian Chadd , mdf@freebsd.org, FreeBSD Current , freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mdf@freebsd.org, Adrian Chadd , FreeBSD Current , 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, 11 Dec 2012 02:34:09 -0000 On Mon, Dec 10, 2012 at 05:37:17PM -0800, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 3:21 PM, Adrian Chadd wrote: > > On 10 December 2012 15:18, wrote: > >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: > >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf > >>> after it's finalised/freed. > >>> > >>> I have a similar bug showing up on ath(4) RX. :( > >> > >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte > >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory > >> is touched after free. > > > > Right, but I think its a _hardware_ access after the buffer has been freed.. > > At least that will give me an idea of who to punt the bug over to > next (assuming it lists the driver) -- one of the network folks, jfv, > or np :). It seems to be a recent change that's causing this (it's > spewing out these warnings every couple seconds), but that might also > be related to me getting lagg working on CURRENT as my last known base > was 9-STABLE and a lot of networking changes haven't been MFCed :). If you suspect it's a DMA from the NIC after the 9K cluster has been freed, see if the "corrupt" portion looks anything like an Ethernet frame. If it does then the DMAC in the frame will tell you who to follow up with -- jfv@ or me :-) (btw, your log had "val=ffffffff" so I think it's something else..) Regards, Navdeep > I could probably look through the code too after compiling it, but > it would take too long. > Thanks! > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 07:34:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7ABC3D7 for ; Tue, 11 Dec 2012 07:34:11 +0000 (UTC) (envelope-from nodens2099@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 619D78FC15 for ; Tue, 11 Dec 2012 07:34:11 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so1950244wey.13 for ; Mon, 10 Dec 2012 23:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Yi3u3CQnmR5/tsAX0AWZkDeJbf+a8MRWRstwdu79IQw=; b=k4Nne7+gA8VlTmWLz00Z/0iLIkHyQ12duVPaY6/zku46o0syiHWne0fETJkTAxHRVS yxoSrjKB3PrXPaz7SUBcVLCQOIc+frx4lYCfLUhQuKcEGJj+uqfaFj3S6ZZ9WEDe9TNh kRs92yig1MRKETWEs6FuEdV1GwBDJroRt3KDNp6CwH8eQIKU8eY4w0Ibucsgbjb5lNvr TDDC1aw0DYUPuCJEUWqUMv+OWwpiwxHuj2EvM5tgv8zSbaDOcPByenvcpW25vQJ8GnnI NXaN+LDYQ0HdpAJAf9WeoGz2H6cMH4ESgRNDIJQWU6ADJVYtFv2rilxVlZOrhRVLU/Uk DkjQ== Received: by 10.216.203.205 with SMTP id f55mr307786weo.170.1355211249852; Mon, 10 Dec 2012 23:34:09 -0800 (PST) Received: from [192.168.99.2] (fon38-4-88-185-152-198.fbx.proxad.net. [88.185.152.198]) by mx.google.com with ESMTPS id i6sm13139435wix.5.2012.12.10.23.34.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 23:34:09 -0800 (PST) Message-ID: <50C6E1EF.4030800@gmail.com> Date: Tue, 11 Dec 2012 08:34:07 +0100 From: "Clement Hermann (nodens)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: Jack Vogel Subject: Re: igb and ALTQ in 9.1-rc3 References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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, 11 Dec 2012 07:34:11 -0000 Le 11/12/2012 00:31, Jack Vogel a écrit : > UH, maybe asking the owner of the driver would help :) Indeed. I just assumed anyone on the mailing list would be more knowledgeable than I am. Sorry about that. > > ... and no, I've never been aware of doing anything to stop supporting > altq > so you wouldn't see any commits. If there's something in the altq code or > support (which I have nothing to do with) that caused this no-one informed > me. > Well, that good news (sort of), so there is a bug somewhere (or we misconfigured something, but we triple-checked, so that is possible but unlikely). How can we help ? It does work with the em driver on another card. I'm not at work today, but I can ask someone to gather information and send them to the list. Thanks again. -- Clement Hermann (nodens) - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?" Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/ Vous trouverez ma clef publique sur le serveur public pgp.mit.edu. Please find my public key on the public keyserver pgp.mit.edu. From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 07:53:45 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FDCA2D7; Tue, 11 Dec 2012 07:53:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9794D8FC14; Tue, 11 Dec 2012 07:53:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qBB7rheP090531; Tue, 11 Dec 2012 11:53:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBB7rhx9090530; Tue, 11 Dec 2012 11:53:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 11 Dec 2012 11:53:43 +0400 From: Gleb Smirnoff To: mdf@FreeBSD.org Subject: Re: "Memory modified after free" - by whom? Message-ID: <20121211075343.GT48639@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , freebsd-net@FreeBSD.org, Adrian Chadd , FreeBSD Current 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, 11 Dec 2012 07:53:45 -0000 On Mon, Dec 10, 2012 at 03:18:45PM -0800, mdf@freebsd.org wrote: m> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: m> > 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf m> > after it's finalised/freed. m> > m> > I have a similar bug showing up on ath(4) RX. :( m> m> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set m> vm.memguard.desc to the name of the UMA zone used for the 9216 byte m> allocations, mbuf_jumbo_9k. This should cause a panic when the memory m> is touched after free. DEBUG_MEMGUARD doesn't work with cluster zone, I'm afraid it won't work with mbuf_jumbo_9k, too, but I didn't try this. The problem is documented in BUGS in memguard(9). -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 07:58:55 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73106681 for ; Tue, 11 Dec 2012 07:58:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id E08D58FC08 for ; Tue, 11 Dec 2012 07:58:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qBB7wrLM090575; Tue, 11 Dec 2012 11:58:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBB7wrMP090574; Tue, 11 Dec 2012 11:58:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 11 Dec 2012 11:58:53 +0400 From: Gleb Smirnoff To: Jack Vogel Subject: Re: igb and ALTQ in 9.1-rc3 Message-ID: <20121211075853.GU48639@FreeBSD.org> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Tue, 11 Dec 2012 07:58:55 -0000 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. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 09:09:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D7A946C; Tue, 11 Dec 2012 09:09:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CFD8C8FC12; Tue, 11 Dec 2012 09:09:45 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so4449399vba.13 for ; Tue, 11 Dec 2012 01:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yeuu3d7ucBKNGzcOfMt4h54sVi6tgvrewDjX4dZstKQ=; b=0f5HoX1cIfurSsXDlQeRONuqKANp3m7XCtIAGCqL0Lekbh7jW1v4Hl0u1u884N9B5I rkzjSSpGsns5YbKX9COfMplHH0i/SNUqk0eqk2PGExMIeSBWC9FfZqOK1j737fPHFZ0M ulyJcEcuhqLIiyUMTrXosxCtD49b/KKsCS6VlOOKPSVFsvF5ftlRrNDrMV1yTOqsAYZI 1jngtBH+VaAQbFT2gr/G/E3eVMoUpu/tiUBoCrDYrk9ASm6LwhdXM3OENkMgKKUfslx0 KEyLiBU/8sylcqy6ymUVPM4mWK7ACm/V16bPfJOdmt1RDZGY5NXJtvDvbn7YvvGmpzNJ E2PQ== MIME-Version: 1.0 Received: by 10.58.2.71 with SMTP id 7mr11073587ves.42.1355216985047; Tue, 11 Dec 2012 01:09:45 -0800 (PST) Received: by 10.220.50.6 with HTTP; Tue, 11 Dec 2012 01:09:44 -0800 (PST) In-Reply-To: <20121211075853.GU48639@FreeBSD.org> References: <1355177348.71087.YahooMailClassic@web121601.mail.ne1.yahoo.com> <50C6656E.3020601@gmail.com> <20121211075853.GU48639@FreeBSD.org> Date: Tue, 11 Dec 2012 01:09:44 -0800 Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Jack Vogel To: Gleb Smirnoff 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: Tue, 11 Dec 2012 09:09:46 -0000 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 From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 13:07:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD4E6943 for ; Tue, 11 Dec 2012 13:07:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm33-vm0.bullet.mail.ne1.yahoo.com (nm33-vm0.bullet.mail.ne1.yahoo.com [98.138.229.64]) by mx1.freebsd.org (Postfix) with ESMTP id 641F98FC12 for ; Tue, 11 Dec 2012 13:07:52 +0000 (UTC) Received: from [98.138.90.51] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 11 Dec 2012 13:05:40 -0000 Received: from [98.138.89.164] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 11 Dec 2012 13:05:40 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 11 Dec 2012 13:05:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 662570.40619.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 59848 invoked by uid 60001); 11 Dec 2012 13:05:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1355231140; bh=WrtQIzIn2bcsgWdDB2QFcP79JWB4wrF31lALsLyZWlg=; 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=ftFYXvkYZMsVxbH/pihZWt+/NUYAfaAT/6kj6t+sGoyOGs4AYpDGsp8TwqbPx6SDhYWMT64MyvBzVfvP+enjg44jRCLns1op2m+8KMZFe5QKsTzXWwQPN06NVKxyU3PgJjuuITw23ZHhoHf9U9MjeBlKODU66x2PLayr+rAStJc= 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=KapWBLryRel5Uh+JwCh/mdxsrviOFPOGr5kPJBoWpJudEeObJuySukWQfl9SrgujsOxG0n9y6mOipVWGOKPTcvtZYI/INzYiOsftfp8mbhLCq7/SH2PVmwn6yxYjrtymka49lAeCvjEWXxe+3neSwSdmwAZahs/HtQZIWV3ILjo=; X-YMail-OSG: btnGKskVM1k5SEmMaGPdihdoIfmY_Zy_OVsm5vF.di5NZHb alKtIKA3nHZ_zG_Ps13alg7DltVazX83RICwAKVFq8fzOeldj1R7fDQo0MHM lWjzxiFSd76T_tcnPSwxjC6McjLikxt.B2RxRcSLUijINF31M4_PkL9MNXDm zoY3cVUd773uP5_KliiYa3s9susW.wvqNpGVyqTx2YIuLJRYtTOqrKFQ3mD7 7HTA.D1YcZbiOQfQ26jVG0ivuCQfSzVn.7QT_cYGh1IaQTD585tE73lx4K3n fgquoz_SWu5Jjr0UcldFowdOZwbFp2idszxT6FDKgR0JLbh2oGEKo1rFWS1T BrLe6S8Z_0MO_nQ9nYqFOQpSyse0veHRTHDK2.Za4kF9AcFob0cigg2gGbHd UTnRINAv7U3eo1DhjJmRb36HSw6rx_don8u4LWw6I65eHEW3jEU7Z.x7Zstu 2L5uvE719stIF6DE97Z1uhB5dusIWUCegoNzqZzxbQS9fRhB6vjOCWzPm.K2 ceWTIL0CrpU_efKIBD_nrTuGQba2WjQ-- Received: from [174.48.128.27] by web121603.mail.ne1.yahoo.com via HTTP; Tue, 11 Dec 2012 05:05:40 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gVHVlLCAxMi8xMS8xMiwgR2xlYiBTbWlybm9mZiA8Z2xlYml1c0BGcmVlQlNELm9yZz4gd3JvdGU6Cgo.IEZyb206IEdsZWIgU21pcm5vZmYgPGdsZWJpdXNARnJlZUJTRC5vcmc.Cj4gU3ViamVjdDogUmU6IGlnYiBhbmQgQUxUUSBpbiA5LjEtcmMzCj4gVG86ICJKYWNrIFZvZ2VsIiA8amZ2b2dlbEBnbWFpbC5jb20.Cj4gQ2M6ICJDbGVtZW50IEhlcm1hbm4gKG5vZGVucykiIDxub2RlbnMyMDk5QGdtYWlsLmNvbT4sICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.1 YahooMailWebService/0.8.128.478 Message-ID: <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 11 Dec 2012 05:05:40 -0800 (PST) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: Jack Vogel , Gleb Smirnoff In-Reply-To: <20121211075853.GU48639@FreeBSD.org> 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: Tue, 11 Dec 2012 13:07:52 -0000 --- On Tue, 12/11/12, Gleb Smirnoff wrote: > From: Gleb Smirnoff > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Jack Vogel" > Cc: "Clement Hermann (nodens)" , "Barney Cordoba" , freebsd-net@FreeBSD.org > Date: Tuesday, December 11, 2012, 2:58 AM > 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. > It seems pretty difficult to say that something is compatible with something else if it hasn't been tested in a few years. It seems to me that ATLQ is the one that should handle if_transmit. although it's a good argument for having a raw "send" function in drivers. Ethernet drivers don't need more than a send() routing that loads a packet into the ring. The decision on what to do if you can't queue a packet should be in the network layer, if we must still call things layers. "start" is a leftover from a day when you stuffed a buffer and waited for an interrupt to stuff in another. The whole idea is antiquated. Imagine drivers that pull packets off of a card and simply queue it; and that you simply submit a packet to be queued for transmit. Instead of trying to find 35 programmers that understand all of the lock BS, you only need to have a couple. I always disable all of the gobbledegook like checksum offloading. They just muddy the water and have very little effect on performance. A modern cpu can do a checksum as fast as you can manage the "capabilities" without disrupting the processing path. With FreeBSD, every driver is an experience. Some suck so bad that they should come with a warning. The MSK driver is completely useless, as an example. BC From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 14:15:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AD942CC; Tue, 11 Dec 2012 14:15:28 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id EE8508FC19; Tue, 11 Dec 2012 14:15:27 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id a19so3308122qad.13 for ; Tue, 11 Dec 2012 06:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iITQRuEnCTVF00sTOHXJ52HlNIPgQHcnBVDx+bEYVvI=; b=Gk5y4GWl9FV07z9IFEGk86Akd9agChMJK7ATak8/mFA0ByRxWTsS428XS9L1NWwQNs g2+jHdbYkolFH6tH6KkGaDZXd/7F9A/qWsmtt/Ld5AJlx91VBZ0GkNhB1IbTkW+kKZcO WaSCsCgkm7M7+31svME4RvYAic5rxw0DqJxA5w2W4lTYxiVuPlX/cUoISzEgeoz1fmSm yXrrHxfvzFZBvB9Lc4Dc8P/XBbvauAhD1DP5VXVnO2jWJ++gmn51Jq/Vava7N9ukNRaV dghjR2Kut5Tv6n5nasJPg2nMzIX/qAbc/QrwA40acDhw8tg73C8lLXc4W7zX2e6QBvle jpuQ== MIME-Version: 1.0 Received: by 10.224.223.17 with SMTP id ii17mr27342030qab.13.1355235326687; Tue, 11 Dec 2012 06:15:26 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Tue, 11 Dec 2012 06:15:26 -0800 (PST) In-Reply-To: <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 11 Dec 2012 15:15:26 +0100 X-Google-Sender-Auth: mKg0NFgU4S5GYBybC4kFhgK64ak Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , "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: Tue, 11 Dec 2012 14:15:28 -0000 On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba wrote: > > > --- On Tue, 12/11/12, Gleb Smirnoff wrote: > > > From: Gleb Smirnoff > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Clement Hermann (nodens)" , "Barney Cordoba" > , freebsd-net@FreeBSD.org > > Date: Tuesday, December 11, 2012, 2:58 AM > > 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. > > > > It seems pretty difficult to say that something is compatible with > something else if it hasn't been tested in a few years. > > It seems to me that ATLQ is the one that should handle if_transmit. > although it's a good argument for having a raw "send" function in > drivers. Ethernet drivers don't need more than a send() routing that > loads a packet into the ring. The decision on what to do if you can't > queue a packet should be in the network layer, if we must still call > things layers. > > "start" is a leftover from a day when you stuffed a buffer and waited > for an interrupt to stuff in another. The whole idea is antiquated. > > Imagine drivers that pull packets off of a card and simply queue it; > and that you simply submit a packet to be queued for transmit. Instead > of trying to find 35 programmers that understand all of the lock BS, > you only need to have a couple. > > I always disable all of the gobbledegook like checksum offloading. They > just muddy the water and have very little effect on performance. A modern > cpu can do a checksum as fast as you can manage the "capabilities" without > disrupting the processing path. > > With FreeBSD, every driver is an experience. Some suck so bad that they > should come with a warning. The MSK driver is completely useless, as > an example. > > > 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" > During implementation of if_transmit altq was not considered at all. The default if_transmit provides some compatibility but that is void since altq has not been converted to call if_transmit after processing the mbuf. ALTQ can be adapted quite easily to if_transmit model it just wasn't done at the time. With if_transmit model it can even be modularized and not be a compile kernel option since the queue of the iface is abstracted now. I have always wanted to do a diff but have not yet got to it. The change is quite simple just provide an altq_transmit default method and just hook into if_transmit model on the fly. You surely need to handle some iface events and enable altq based on request but its is not a hard to implement. I will always have this in my TODO but not sure when i can get to it. -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 14:56:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DEB71EC for ; Tue, 11 Dec 2012 14:56:29 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id BD1B98FC0C for ; Tue, 11 Dec 2012 14:56:28 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id k13so16841239iea.22 for ; Tue, 11 Dec 2012 06:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GWvTHyIl0n5t73k/Zce4Lswq2uMLLL1a6v4eba+Pt6w=; b=tU3l+ZLJs6mb3lCzI3B7G8wOob23buB/e6zjjq0qX2Xon17WO3Lc94pay77ypnLCC8 Um1ToA2LtNp+YF54YiTTHnukUmod7E1XziEH1uFPXG+oJ8M197B+xwcAIjkCdYhC+509 mqqCAMEPKAz+K+eYWFDujifvZsWeN1ZnzAwmNU/Wq6YIyj9r9Pk4n3xaz5E5dUtO4cqK UvL/f6J+QyH3a/P6kR5maRau2pnNQf8o936eQGavcxAzcrhTEIfbJ2EoWqKHKSMuz8r2 LLOwLTVZXtTlzaqhw7Yyz3LQZ5uB9sfAuwWXSqiSQxLfa82ioMh9YmKm8H5c72yQPiZc UgDg== Received: by 10.50.57.232 with SMTP id l8mr10297107igq.54.1355237782015; Tue, 11 Dec 2012 06:56:22 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id eo7sm9541353igc.12.2012.12.11.06.56.20 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 06:56:20 -0800 (PST) Message-ID: <50C74990.2090803@gmail.com> Date: Tue, 11 Dec 2012 09:56:16 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: igb and ALTQ in 9.1-rc3 References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: nodens2099@gmail.com 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, 11 Dec 2012 14:56:29 -0000 On 11/12/2012 9:15 AM, Ermal Luçi wrote: > On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba wrote: > >> >> --- On Tue, 12/11/12, Gleb Smirnoff wrote: >> >>> From: Gleb Smirnoff >>> Subject: Re: igb and ALTQ in 9.1-rc3 >>> To: "Jack Vogel" >>> Cc: "Clement Hermann (nodens)" , "Barney Cordoba" >> , freebsd-net@FreeBSD.org >>> Date: Tuesday, December 11, 2012, 2:58 AM >>> 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. >>> >> It seems pretty difficult to say that something is compatible with >> something else if it hasn't been tested in a few years. >> >> It seems to me that ATLQ is the one that should handle if_transmit. >> although it's a good argument for having a raw "send" function in >> drivers. Ethernet drivers don't need more than a send() routing that >> loads a packet into the ring. The decision on what to do if you can't >> queue a packet should be in the network layer, if we must still call >> things layers. >> >> "start" is a leftover from a day when you stuffed a buffer and waited >> for an interrupt to stuff in another. The whole idea is antiquated. >> >> Imagine drivers that pull packets off of a card and simply queue it; >> and that you simply submit a packet to be queued for transmit. Instead >> of trying to find 35 programmers that understand all of the lock BS, >> you only need to have a couple. >> >> I always disable all of the gobbledegook like checksum offloading. They >> just muddy the water and have very little effect on performance. A modern >> cpu can do a checksum as fast as you can manage the "capabilities" without >> disrupting the processing path. >> >> With FreeBSD, every driver is an experience. Some suck so bad that they >> should come with a warning. The MSK driver is completely useless, as >> an example. >> >> >> 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" >> > During implementation of if_transmit altq was not considered at all. > The default if_transmit provides some compatibility but that is void since > altq has not been converted to call if_transmit after processing the mbuf. > > ALTQ can be adapted quite easily to if_transmit model it just wasn't done > at the time. > With if_transmit model it can even be modularized and not be a compile > kernel option since the queue of the iface is abstracted now. > > I have always wanted to do a diff but have not yet got to it. > The change is quite simple just provide an altq_transmit default method and > just hook into if_transmit model on the fly. > You surely need to handle some iface events and enable altq based on > request but its is not a hard to implement. > > I will always have this in my TODO but not sure when i can get to it. > The issue is not only that igb doesn't support if_transmit or if_start method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK for all of its enqueue/dequeue operations. A simple drop in of if_transmit is bound to cause race conditions on any multiqueue driver with ALTQ. I do have a patch set for this on igb but its ugly and needs more work although it should get you going. Let me know if your interested I will clean it up and send it over. For more information on ALTQ discussion and igb please read this thread: http://freebsd.1045724.n5.nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html Best regards, Karim. From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 16:26:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73AA3B78 for ; Tue, 11 Dec 2012 16:26:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm29-vm1.bullet.mail.ne1.yahoo.com (nm29-vm1.bullet.mail.ne1.yahoo.com [98.138.90.63]) by mx1.freebsd.org (Postfix) with ESMTP id 246458FC08 for ; Tue, 11 Dec 2012 16:26:50 +0000 (UTC) Received: from [98.138.90.57] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 11 Dec 2012 16:26:50 -0000 Received: from [98.138.89.174] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 11 Dec 2012 16:26:50 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 11 Dec 2012 16:26:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 280023.88466.bm@omp1030.mail.ne1.yahoo.com Received: (qmail 52681 invoked by uid 60001); 11 Dec 2012 16:26:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1355243210; bh=rEOLtMtESV47afRWtSWcPHagYwn2Lgcg+Zw1cLq6qYo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mj1TOP0rEQNQnbvKqqTXuupvM84g+xZcFUS1mV3VzcdhUAiWwS24neS1XhcmvjdmsOqb4hlFpemRt6pFPqPgvtZBWwg6VmiMt6gH6AN9C+xvfZxr4Ul7xPI4NjItSisQQlRz3AyjbSozuzOXB7V9dyO7tfvlP6E4UBH8tctDOds= 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:Content-Transfer-Encoding; b=D0+QJOKDEiyMiZ2FuvGFOfg7+Gijx46Q0FlJH27vSq51ifP6nj1KzQWE/BPVk3pR7/Xbqo8mlK9RGt79VuRI9JzZkskNN9d0KJhPyucinYyTICSXSrxjgnRA0Sea2KgYA67jwyXZrY1Qucs8zt/4/Yb/f2e8h4mcUQxy18OkEvA=; X-YMail-OSG: FEF4EMUVM1nArnn8bPm7CAL24AP0PaaisuPbBGHTgHfsUJu Q88m_XW4bJqi9lQpKTxqE Received: from [174.48.128.27] by web121606.mail.ne1.yahoo.com via HTTP; Tue, 11 Dec 2012 08:26:49 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gVHVlLCAxMi8xMS8xMiwgS2FyaW0gRm9kaWwtTGVtZWxpbiA8Zm9kaWxsZW1saW5rYXJpbUBnbWFpbC5jb20.IHdyb3RlOgoKPiBGcm9tOiBLYXJpbSBGb2RpbC1MZW1lbGluIDxmb2RpbGxlbWxpbmthcmltQGdtYWlsLmNvbT4KPiBTdWJqZWN0OiBSZTogaWdiIGFuZCBBTFRRIGluIDkuMS1yYzMKPiBUbzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcKPiBDYzogbm9kZW5zMjA5OUBnbWFpbC5jb20KPiBEYXRlOiBUdWVzZGF5LCBEZWNlbWJlciAxMSwgMjAxMiwgOTo1NiBBTQo.IE9uIDExLzEyLzIBMAEBAQE- X-Mailer: YahooMailClassic/15.1.1 YahooMailWebService/0.8.128.478 Message-ID: <1355243209.48529.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Tue, 11 Dec 2012 08:26:49 -0800 (PST) From: Barney Cordoba Subject: Re: igb and ALTQ in 9.1-rc3 To: freebsd-net@freebsd.org, Karim Fodil-Lemelin In-Reply-To: <50C74990.2090803@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: nodens2099@gmail.com 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, 11 Dec 2012 16:26:51 -0000 =0A=0A--- On Tue, 12/11/12, Karim Fodil-Lemelin wrote:=0A=0A> From: Karim Fodil-Lemelin =0A> = Subject: Re: igb and ALTQ in 9.1-rc3=0A> To: freebsd-net@freebsd.org=0A> Cc= : nodens2099@gmail.com=0A> Date: Tuesday, December 11, 2012, 9:56 AM=0A> On= 11/12/2012 9:15 AM, Ermal Lu=E7i=0A> wrote:=0A> > On Tue, Dec 11, 2012 at = 2:05 PM, Barney Cordoba wrote:=0A> >=0A> >>=0A> >= > --- On Tue, 12/11/12, Gleb Smirnoff =0A> wrote:=0A> = >>=0A> >>> From: Gleb Smirnoff =0A> >>> Subject: Re: i= gb and ALTQ in 9.1-rc3=0A> >>> To: "Jack Vogel" =0A> >>>= Cc: "Clement Hermann (nodens)" ,=0A> "Barney Cordoba= "=0A> >> ,=0A> freebsd-net@FreeBSD.org=0A> >>> Da= te: Tuesday, December 11, 2012, 2:58 AM=0A> >>> On Mon, Dec 10, 2012 at 03:= 31:19PM=0A> >>> -0800, Jack Vogel wrote:=0A> >>> J> UH, maybe asking the ow= ner of the driver=0A> would help=0A> >>> :)=0A> >>> J>=0A> >>> J> ... and n= o, I've never been aware of=0A> doing anything to=0A> >>> stop supporting a= ltq=0A> >>> J> so you wouldn't see any commits. If=0A> there's something=0A= > >>> in the altq code or=0A> >>> J> support (which I have nothing to do wi= th)=0A> that caused=0A> >>> this no-one informed=0A> >>> J> me.=0A> >>>=0A>= >>> Switching from if_start to if_transmit=0A> effectively disables=0A> >>= > ALTQ support.=0A> >>>=0A> >>> AFAIR, there is some magic implemented in o= ther=0A> drivers that=0A> >>> makes them=0A> >>> modern (that means using i= f_transmit), but=0A> still capable to=0A> >>> switch to queueing=0A> >>> mo= de if SIOCADDALTQ was casted upon them.=0A> >>>=0A> >> It seems pretty diff= icult to say that something is=0A> compatible with=0A> >> something else if= it hasn't been tested in a few=0A> years.=0A> >>=0A> >> It seems to me tha= t ATLQ is the one that should=0A> handle if_transmit.=0A> >> although it's = a good argument for having a raw=0A> "send" function in=0A> >> drivers. Eth= ernet drivers don't need more than a=0A> send() routing that=0A> >> loads a= packet into the ring. The decision on what=0A> to do if you can't=0A> >> q= ueue a packet should be in the=A0 network=0A> layer, if we must still call= =0A> >> things layers.=0A> >>=0A> >> "start" is a leftover from a day when = you stuffed a=0A> buffer and waited=0A> >> for an interrupt to stuff in ano= ther. The whole=0A> idea is antiquated.=0A> >>=0A> >> Imagine drivers that = pull packets off of a card and=0A> simply queue it;=0A> >> and that you sim= ply submit a packet to be queued=0A> for transmit. Instead=0A> >> of trying= to find 35 programmers that understand=0A> all of the lock BS,=0A> >> you = only need to have a couple.=0A> >>=0A> >> I always disable all of the gobbl= edegook like=0A> checksum offloading. They=0A> >> just muddy the water and = have very little effect on=0A> performance. A modern=0A> >> cpu can do a ch= ecksum as fast as you can manage the=0A> "capabilities" without=0A> >> disr= upting the processing path.=0A> >>=0A> >> With FreeBSD, every driver is an = experience. Some=0A> suck so bad that they=0A> >> should come with a warnin= g. The MSK driver is=0A> completely useless, as=0A> >> an example.=0A> >>= =0A> >>=0A> >> BC=0A> >> _______________________________________________=0A= > >> freebsd-net@freebsd.org=0A> mailing list=0A> >> http://lists.freebsd.o= rg/mailman/listinfo/freebsd-net=0A> >> To unsubscribe, send any mail to "fr= eebsd-net-unsubscribe@freebsd.org"=0A> >>=0A> > During implementation of if= _transmit altq was not=0A> considered at all.=0A> > The default if_transmit= provides some compatibility but=0A> that is void since=0A> > altq has not = been converted to call if_transmit after=0A> processing the mbuf.=0A> >=0A>= > ALTQ can be adapted quite easily to if_transmit model=0A> it just wasn't= done=0A> > at the time.=0A> > With if_transmit model it can even be modula= rized and=0A> not be a compile=0A> > kernel option since the queue of the i= face is=0A> abstracted now.=0A> >=0A> > I have always wanted to do a diff b= ut have not yet got=0A> to it.=0A> > The change is quite simple just provid= e an=0A> altq_transmit default method and=0A> > just hook into if_transmit = model on the fly.=0A> > You surely need to handle some iface events and ena= ble=0A> altq based on=0A> > request but its is not a hard to implement.=0A>= >=0A> > I will always have this in my TODO but not sure when i=0A> can get= to it.=0A> >=0A> The issue is not only that igb doesn't support if_transmi= t=0A> or if_start =0A> method but that ALTQ isn't multiqueue ready and stil= l uses=0A> the IFQ_LOCK =0A> for all of its enqueue/dequeue operations. A s= imple drop in=0A> of =0A> if_transmit is bound to cause race conditions on = any=0A> multiqueue driver =0A> with ALTQ.=0A> =0A> I do have a patch set fo= r this on igb but its ugly and needs=0A> more work =0A> although it should = get you going. Let me know if your=0A> interested I will =0A> clean it up a= nd send it over. For more information on ALTQ=0A> discussion =0A> and igb p= lease read this thread: =0A> http://freebsd.1045724.n5.nabble.com/em-igb-if= -transmit-drbr-and-ALTQ-td5760338.html=0A> =0A> Best regards,=0A> =0A> Kari= m.=0A=0AAt minimum, the drivers should make multiqueue an option, at least= =0Auntil it works better than a single queue driver. Many MOBOs have igb=0A= nics on board and such a mainstream NIC shouldn't be strapped using=0Aexper= imental code that clearly isn't ready for prime time.=0A=0ABC=0A From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 16:27:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9D1EC3B for ; Tue, 11 Dec 2012 16:27:53 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by mx1.freebsd.org (Postfix) with ESMTP id 648588FC08 for ; Tue, 11 Dec 2012 16:27:53 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id b12so2718383qca.18 for ; Tue, 11 Dec 2012 08:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7sihbZmECs2ScqAjATYTHB6p9ZmScds3unMcNu4X6UM=; b=tU+kPYt/gB/bLw0LCp15KkugA4O1QsuC2W0dGjnufRwlu87Xwkl+pjAIEeAJs7VKcs tD3Ig3BfRUpZZ+qB6mobTWVETBFc8SERReY2uFgnpam/D+F8P6RHPguc6jXBcr1OT2JT K1ZmxlpVuM3OrMXf/pPBP8Z1ZPzyz4M7gFnkyCwAAR9ScbfBV5iimir9Rt2Yww3fsxV5 aNRJUfweAuGtmCWbtEO7zA3f8AI+8PwdQCOZpOD/zAheLQt0fxskgQEM5NlLLTPEe0ug Rpkhsbc2pzlqehPlUJyPLJhNq6j5KbodeySuyodt5dRTtGhxsoimHNKGSQTfUjr8IOg4 GTRw== MIME-Version: 1.0 Received: by 10.49.103.162 with SMTP id fx2mr41293170qeb.1.1355243272391; Tue, 11 Dec 2012 08:27:52 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Tue, 11 Dec 2012 08:27:52 -0800 (PST) In-Reply-To: <50C74990.2090803@gmail.com> References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> Date: Tue, 11 Dec 2012 17:27:52 +0100 X-Google-Sender-Auth: -L64TaJdGJNlktlWzYgklngqqiE Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , "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: Tue, 11 Dec 2012 16:27:53 -0000 On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin < fodillemlinkarim@gmail.com> wrote: > On 11/12/2012 9:15 AM, Ermal Lu=E7i wrote: > >> On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba > >**wrote: >> >> >>> --- On Tue, 12/11/12, Gleb Smirnoff wrote: >>> >>> From: Gleb Smirnoff >>>> Subject: Re: igb and ALTQ in 9.1-rc3 >>>> To: "Jack Vogel" >>>> Cc: "Clement Hermann (nodens)" , "Barney Cordoba= " >>>> >>> , freebsd-net@FreeBSD.org >>> >>>> Date: Tuesday, December 11, 2012, 2:58 AM >>>> 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. >>>> >>>> It seems pretty difficult to say that something is compatible with >>> something else if it hasn't been tested in a few years. >>> >>> It seems to me that ATLQ is the one that should handle if_transmit. >>> although it's a good argument for having a raw "send" function in >>> drivers. Ethernet drivers don't need more than a send() routing that >>> loads a packet into the ring. The decision on what to do if you can't >>> queue a packet should be in the network layer, if we must still call >>> things layers. >>> >>> "start" is a leftover from a day when you stuffed a buffer and waited >>> for an interrupt to stuff in another. The whole idea is antiquated. >>> >>> Imagine drivers that pull packets off of a card and simply queue it; >>> and that you simply submit a packet to be queued for transmit. Instead >>> of trying to find 35 programmers that understand all of the lock BS, >>> you only need to have a couple. >>> >>> I always disable all of the gobbledegook like checksum offloading. They >>> just muddy the water and have very little effect on performance. A mode= rn >>> cpu can do a checksum as fast as you can manage the "capabilities" >>> without >>> disrupting the processing path. >>> >>> With FreeBSD, every driver is an experience. Some suck so bad that they >>> should come with a warning. The MSK driver is completely useless, as >>> an example. >>> >>> >>> 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= >>> " >>> >>> During implementation of if_transmit altq was not considered at all. >> The default if_transmit provides some compatibility but that is void sin= ce >> altq has not been converted to call if_transmit after processing the mbu= f. >> >> ALTQ can be adapted quite easily to if_transmit model it just wasn't don= e >> at the time. >> With if_transmit model it can even be modularized and not be a compile >> kernel option since the queue of the iface is abstracted now. >> >> I have always wanted to do a diff but have not yet got to it. >> The change is quite simple just provide an altq_transmit default method >> and >> just hook into if_transmit model on the fly. >> You surely need to handle some iface events and enable altq based on >> request but its is not a hard to implement. >> >> I will always have this in my TODO but not sure when i can get to it. >> >> The issue is not only that igb doesn't support if_transmit or if_start > method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK f= or > all of its enqueue/dequeue operations. A simple drop in of if_transmit is > bound to cause race conditions on any multiqueue driver with ALTQ. > > I do have a patch set for this on igb but its ugly and needs more work > although it should get you going. Let me know if your interested I will > clean it up and send it over. For more information on ALTQ discussion and > igb please read this thread: http://freebsd.1045724.n5.** > nabble.com/em-igb-if-transmit-**drbr-and-ALTQ-td5760338.html > > Best regards, > > Karim. > > ALTQ needs to do serialization of packets to apply its policy. While it can be extended to map driver queues to ALTQ queues that is not easy done without getting some interface to the driver to communicate. The poor man implementation would be to pass an index argument when calling driver transmit routine. > > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 18:03:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1391BF5E for ; Tue, 11 Dec 2012 18:03:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 95AE98FC13 for ; Tue, 11 Dec 2012 18:03:32 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2625298wgh.31 for ; Tue, 11 Dec 2012 10:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3jzheEa6p9UIZYEEdiLs83zL2pYDI2215s21hu3z25I=; b=pwoK9Fvolr+F8C0KuD9Byz/exCv/in0rVSeekHfPr7avO80IutKaKz2fse/Z+kh3Ff AD+l23qE/pe9LKNACOE0uV+jnn5z/+p3MdZhLqLjGMxf2DdaujT+oPgAlKIXb+GkG7t9 r6TygfQec1lDRONVI+LvlKJAX8+AaD0AFPZXds1m8gysc7/himbcRqsiu0Um5aE+deYX xxiqIWRXb7neK2DMDzp2D8iBNn2/zBjl8SrHHh647fSkKfrFE24Bi42Dk2WMMkCWA4hz P+3eVxfg5T77q0CsKWRuZU5gJTAbz5d23dM+WsPaCpg/vEh41iiDiE09eOiJ4ML8FUg6 Zzew== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr1996168wjc.1.1355249009965; Tue, 11 Dec 2012 10:03:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 11 Dec 2012 10:03:29 -0800 (PST) In-Reply-To: <1355243209.48529.YahooMailClassic@web121606.mail.ne1.yahoo.com> References: <50C74990.2090803@gmail.com> <1355243209.48529.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Tue, 11 Dec 2012 10:03:29 -0800 X-Google-Sender-Auth: qwqunlC0NUpfoMTptE8Rsj9Ai1s 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 Cc: Karim Fodil-Lemelin , freebsd-net@freebsd.org, nodens2099@gmail.com 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, 11 Dec 2012 18:03:33 -0000 The if_transmit versus multiqueue thing is orthogonal. I'm planning to make net80211 and ath(4) use if_transmit instead of if_start. It won't be a multi-queue driver; I'm actually going down the path of if_transmit specifically so I can control the TX queue serialisation and actively _serialise_ frame TX, instead of implementing a multi-queue driver. ALTQ as a concept needs to be glued in a different way. It can't just override the queue macros like it does. That's just plain ew. net80211 has some rather quirky behaviour, unfortunately. I won't go into it here. Suffice to say, I can't just use the IFQ macros, the if_queue as it stands, nor buf_ring. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 20:06:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDC705B8; Tue, 11 Dec 2012 20:06:53 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6995A8FC1A; Tue, 11 Dec 2012 20:06:53 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c13so15878057ieb.31 for ; Tue, 11 Dec 2012 12:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=POHgZ+jSKqd4Stn9wZbFmNSjCNAPjjyE7S4N52T7d+o=; b=TF4WdYUpLos9oWj/fwhwiMuY02//PREwsKVn/4+1KUI4H9lXd+0ymh7PzM8kmweyII B2WvcTefWuuAUMlFLfMN1W9jFwxBR0Q3Ras3Npf5qGDQ7IMEFLKj4DpSyS3e8RvWSNTx CFJ1cSukoVbfVzxfAQQciNr+AQRRT+s9h3LtdhGHeK47qaSrOfPhl5bGXs6HUR2ef4L5 tpJ5e4M+T7ocBwT4rcsPx/U716m/RXJJmU2IVBM8wpv7kIdka5C0MBkYG2HSVwvC02hy CvEwWrwwe3vpYqmR+H679XhZfVVnnVDqcMx5daZcLQ2DFGXp8pctAv5j+E2qEjaXlA6m Z0BQ== Received: by 10.50.236.104 with SMTP id ut8mr11159202igc.20.1355256406875; Tue, 11 Dec 2012 12:06:46 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id s20sm10265873igs.10.2012.12.11.12.06.45 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 12:06:45 -0800 (PST) Message-ID: <50C79252.5000509@gmail.com> Date: Tue, 11 Dec 2012 15:06:42 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: igb and ALTQ in 9.1-rc3 References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Karim Fodil-Lemelin , freebsd-net , "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: Tue, 11 Dec 2012 20:06:53 -0000 On 11/12/2012 11:27 AM, Ermal Luçi wrote: > On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin < > fodillemlinkarim@gmail.com> wrote: > >> On 11/12/2012 9:15 AM, Ermal Luçi wrote: >> >>> On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba >>> **wrote: >>> >>>> --- On Tue, 12/11/12, Gleb Smirnoff wrote: >>>> >>>> From: Gleb Smirnoff >>>>> Subject: Re: igb and ALTQ in 9.1-rc3 >>>>> To: "Jack Vogel" >>>>> Cc: "Clement Hermann (nodens)" , "Barney Cordoba" >>>>> >>>> , freebsd-net@FreeBSD.org >>>> >>>>> Date: Tuesday, December 11, 2012, 2:58 AM >>>>> 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. >>>>> >>>>> It seems pretty difficult to say that something is compatible with >>>> something else if it hasn't been tested in a few years. >>>> >>>> It seems to me that ATLQ is the one that should handle if_transmit. >>>> although it's a good argument for having a raw "send" function in >>>> drivers. Ethernet drivers don't need more than a send() routing that >>>> loads a packet into the ring. The decision on what to do if you can't >>>> queue a packet should be in the network layer, if we must still call >>>> things layers. >>>> >>>> "start" is a leftover from a day when you stuffed a buffer and waited >>>> for an interrupt to stuff in another. The whole idea is antiquated. >>>> >>>> Imagine drivers that pull packets off of a card and simply queue it; >>>> and that you simply submit a packet to be queued for transmit. Instead >>>> of trying to find 35 programmers that understand all of the lock BS, >>>> you only need to have a couple. >>>> >>>> I always disable all of the gobbledegook like checksum offloading. They >>>> just muddy the water and have very little effect on performance. A modern >>>> cpu can do a checksum as fast as you can manage the "capabilities" >>>> without >>>> disrupting the processing path. >>>> >>>> With FreeBSD, every driver is an experience. Some suck so bad that they >>>> should come with a warning. The MSK driver is completely useless, as >>>> an example. >>>> >>>> >>>> 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 >>>> " >>>> >>>> During implementation of if_transmit altq was not considered at all. >>> The default if_transmit provides some compatibility but that is void since >>> altq has not been converted to call if_transmit after processing the mbuf. >>> >>> ALTQ can be adapted quite easily to if_transmit model it just wasn't done >>> at the time. >>> With if_transmit model it can even be modularized and not be a compile >>> kernel option since the queue of the iface is abstracted now. >>> >>> I have always wanted to do a diff but have not yet got to it. >>> The change is quite simple just provide an altq_transmit default method >>> and >>> just hook into if_transmit model on the fly. >>> You surely need to handle some iface events and enable altq based on >>> request but its is not a hard to implement. >>> >>> I will always have this in my TODO but not sure when i can get to it. >>> >>> The issue is not only that igb doesn't support if_transmit or if_start >> method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK for >> all of its enqueue/dequeue operations. A simple drop in of if_transmit is >> bound to cause race conditions on any multiqueue driver with ALTQ. >> >> I do have a patch set for this on igb but its ugly and needs more work >> although it should get you going. Let me know if your interested I will >> clean it up and send it over. For more information on ALTQ discussion and >> igb please read this thread: http://freebsd.1045724.n5.** >> nabble.com/em-igb-if-transmit-**drbr-and-ALTQ-td5760338.html >> >> Best regards, >> >> Karim. >> >> > ALTQ needs to do serialization of packets to apply its policy. > While it can be extended to map driver queues to ALTQ queues that is not > easy done without getting some interface to the driver to communicate. > The poor man implementation would be to pass an index argument when calling > driver transmit routine. > I doubt it is realistic to map ALTQ queues to driver queues since ALTQ can have many more queues then what any driver would need and those queues are controlled by users in so many ways it is almost impossible to cater for all cases in all device drivers. This could lead to TX rings being quickly filled up and packets being dropped. A good example of this would be to have two ALTQ queues. One very fast 1Gbps and one very slow 512Kbps. Having to reference packets through indexes inside the driver queues for each of the corresponding packets in ALTQ's fast queue would result in too much overhead IMO and a potential ring exhaustion by the slow queue. Both queues having different queue backlog criteria for achieving their rate they must be maintained somewhat separately (which is what ALTQ does through its class_queue). ALTQ needs to be both a consumer and a producer of a device driver (or ideally to some interface to it). It needs to be able to 'consume' packets from an outgoing path to enqueue them and some way (historically if_start) to tell a driver to send a given packet. While the enqueue operation is usually through a direct dispatch the dequeuing can be done asynchronously by a timer through ALTQ's token bucket regulator. Not unlike buf ring ALTQ can, in the same if_transmit works, enqueue a packet and dequeue another packet to be sent. What is needed is a clear API for sending packets and a comprehensive set of rules for locking TX queues. Right now FreeBSD has ifqueue (if_start) with its well known IFQ_LOCK and if_transmit (drbr) with driver managed TX locks and while it seems the trend is to move towards if_transmit, the transition is not completed and the locking too much dependent on the driver implementation to be currently useable by ALTQ. Karim. From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 20:24:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FE47A11 for ; Tue, 11 Dec 2012 20:24:56 +0000 (UTC) (envelope-from kfodil-lemelin@xiplink.com) Received: from smtp121.dfw.emailsrvr.com (smtp121.dfw.emailsrvr.com [67.192.241.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4165E8FC08 for ; Tue, 11 Dec 2012 20:24:55 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A57163C1BD9 for ; Tue, 11 Dec 2012 15:17:03 -0500 (EST) X-Virus-Scanned: OK Received: from smtp137.ord.emailsrvr.com (smtp137.ord.emailsrvr.com [173.203.6.137]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id 88D013C1B1B for ; Tue, 11 Dec 2012 15:17:03 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id E1534300D8; Tue, 11 Dec 2012 15:16:56 -0500 (EST) X-Virus-Scanned: OK Received: by smtp18.relay.ord1a.emailsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 7A546300D7; Tue, 11 Dec 2012 15:16:56 -0500 (EST) Message-ID: <50C794B6.8030303@xiplink.com> Date: Tue, 11 Dec 2012 15:16:54 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: igb and ALTQ in 9.1-rc3 References: <50C74990.2090803@gmail.com> <1355243209.48529.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karim Fodil-Lemelin , Barney Cordoba , nodens2099@gmail.com, 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, 11 Dec 2012 20:24:56 -0000 On 11/12/2012 1:03 PM, Adrian Chadd wrote: > The if_transmit versus multiqueue thing is orthogonal. Indeed, although ALTQ isn't using if_transmit and doing a simple drop in (replacing if_start with if_transmit) breaks ALTQ with multiqueue capable drivers. > > I'm planning to make net80211 and ath(4) use if_transmit instead of > if_start. It won't be a multi-queue driver; I'm actually going down > the path of if_transmit specifically so I can control the TX queue > serialisation and actively _serialise_ frame TX, instead of > implementing a multi-queue driver. > > ALTQ as a concept needs to be glued in a different way. It can't just > override the queue macros like it does. That's just plain ew. I agree. I think ALTQ should maintain its own queues and locks and not rely on drivers for queue management. > > net80211 has some rather quirky behaviour, unfortunately. I won't go > into it here. Suffice to say, I can't just use the IFQ macros, the > if_queue as it stands, nor buf_ring. > > > > Adrian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 21:36:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0E893C0; Tue, 11 Dec 2012 21:36:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id E9B538FC13; Tue, 11 Dec 2012 21:36:34 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2730478wgh.31 for ; Tue, 11 Dec 2012 13:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=f7A5Xop8UvBZ3/wk9kRqqlnaXQI8gmdy6uLK7pYKR6Q=; b=MmZqcMp0YTXOv7pdAXWT+vLtQyHtGASWSkYZ7GWuLLpaopGr8DcEiNN7DotvulnWEF TE3to3hcoyDgFsdwUPwZVuE8KVTZ2zqzu7rbpECcPpZCt+LHAHYRWz5KJfD7EQlV/8tO 5WwgXG36+2MeKc+qvXStTJUnFBJ1yCEnyL43NqgISrz37KU4kw8MZh//m2rmXRIUZjX9 /6g+5YwXfAk7Ok7eVfCZLMvSIGIsPKpFb58f1xu1ELT+uIwBLXL8US/08TueCgkoPce/ dzKyI9hQyD55UkgQccuAnq/VWr+Yd8skm4o3CmrnWzm43EBLvM4Kxwg7D2/JoitYTb4W tR9g== MIME-Version: 1.0 Received: by 10.180.78.1 with SMTP id x1mr19091700wiw.17.1355261793225; Tue, 11 Dec 2012 13:36:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 11 Dec 2012 13:36:33 -0800 (PST) In-Reply-To: <50C79252.5000509@gmail.com> References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> <50C79252.5000509@gmail.com> Date: Tue, 11 Dec 2012 13:36:33 -0800 X-Google-Sender-Auth: stLR7CXJSfiXiPiS4YHnyc3_kjY Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Adrian Chadd To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , "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: Tue, 11 Dec 2012 21:36:35 -0000 .. the ALTQ compatibility stuff for buf_ring and drbr_* is just plain ew. The question is, who is going to step up and make that work? I'm certainly not going to; when I teach net80211 and ath(4) about if_transmit, I'm going to do it in a way that breaks ALTQ. And it'll stay broken until I've ironed out all of the 802.11 and driver related kinks that exist, and then it'll only come back up once we've all come up with a much more sensible way to stuff this kind of queue management into our network drivers. We -know- we need a much more generic implementation of packet queue management. Someone just needs to come up with one. :-) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 21:49:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01CE86B4 for ; Tue, 11 Dec 2012 21:49:24 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 569578FC15 for ; Tue, 11 Dec 2012 21:49:22 +0000 (UTC) Received: (qmail 9829 invoked from network); 11 Dec 2012 23:18:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Dec 2012 23:18:18 -0000 Message-ID: <50C7AA58.5050909@networx.ch> Date: Tue, 11 Dec 2012 22:49:12 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: igb and ALTQ in 9.1-rc3 References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> <50C79252.5000509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karim Fodil-Lemelin , =?ISO-8859-1?Q?Erma?= =?ISO-8859-1?Q?l_Lu=E7i?= , "Clement Hermann \(nodens\)" , 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: Tue, 11 Dec 2012 21:49:24 -0000 On 11.12.2012 22:36, Adrian Chadd wrote: > .. the ALTQ compatibility stuff for buf_ring and drbr_* is just plain ew. > > The question is, who is going to step up and make that work? I'm > certainly not going to; when I teach net80211 and ath(4) about > if_transmit, I'm going to do it in a way that breaks ALTQ. And it'll > stay broken until I've ironed out all of the 802.11 and driver related > kinks that exist, and then it'll only come back up once we've all come > up with a much more sensible way to stuff this kind of queue > management into our network drivers. > > We -know- we need a much more generic implementation of packet queue > management. Someone just needs to come up with one. :-) As I've said earlier I'm working and cleaning up of the stack/driver interface and API. It started out to better integrate the offload capabilities, reduce code duplication and to audit their usage in the drivers. While doing that I've noticed, as others have, a couple more issues including the queuing problem. So work is under way and by early next year a prototype for further discussion should be ready. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 21:55:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00A95AFC; Tue, 11 Dec 2012 21:55:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 46ED68FC08; Tue, 11 Dec 2012 21:55:09 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so2347240wib.13 for ; Tue, 11 Dec 2012 13:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hn8SOSKBi/cNj0t+jJWPLIcxKxF0MFjCGcB6KXZV/II=; b=VcFV7Ffo7GnUHsG26cj4iqOHB7QwC7+0GKrIUW0y8dsfxluNWafZ2XdYbhD0u39w3P GmjkulajKqp8UpnUgDqvGfrDfNj6fB79lmH5gl2LZqaN/Xd4VOsLu+COK7B3VW0xEaOU SJlmvWQDKKksc0ABcWb+3CSi6YRVnTbDmDiFpcYvTHlzcpVPHW1MXlloXfc0qkcekbaL Z6iXu3e7cijDc8TCRv2vqnyumKPrLkSw/SBoFpGpAm9YKWFj2VoorUTrTQNvjNhViihi 1dd3kYWNnu9iLxO8f+FVzuQ4zJWfj8iJO/t7DvBme0YOu2R/UmjtStRRd0tbCMDUMXuo JBXw== MIME-Version: 1.0 Received: by 10.194.120.132 with SMTP id lc4mr3027559wjb.59.1355262908949; Tue, 11 Dec 2012 13:55:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 11 Dec 2012 13:55:08 -0800 (PST) In-Reply-To: <50C7AA58.5050909@networx.ch> References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> <50C79252.5000509@gmail.com> <50C7AA58.5050909@networx.ch> Date: Tue, 11 Dec 2012 13:55:08 -0800 X-Google-Sender-Auth: K8RPBDc5gDAjpXLUnC6UzQ56yCE Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: Karim Fodil-Lemelin , =?ISO-8859-1?Q?Ermal_Lu=E7i?= , "Clement Hermann \(nodens\)" , 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: Tue, 11 Dec 2012 21:55:11 -0000 On 11 December 2012 13:49, Andre Oppermann wrote: >> We -know- we need a much more generic implementation of packet queue >> management. Someone just needs to come up with one. :-) > > > As I've said earlier I'm working and cleaning up of the stack/driver > interface and API. It started out to better integrate the offload > capabilities, reduce code duplication and to audit their usage in the > drivers. While doing that I've noticed, as others have, a couple more > issues including the queuing problem. So work is under way and by > early next year a prototype for further discussion should be ready. Sweet. Hopefully I'll have undone the rest of the if_start stuff in net80211 by then. I'm still stuck trying to figure out the right way to represent 802.11 fragments given how the net80211 stack was left before I inherited it. ieee80211_fragment() creates a chain of mbufs representing the fragment chain; I need to process those as an atomic entity rather than a frame at a time. Neither buf_ring nor if_queue are suitable for this. I can serialise the frames coming into net80211 but until I figure out a queue mechanism that lets me queue mbuf _chains_, I'll be stuck. buf_ring is suitable with this, with some modifications (ie, checking each mbuf is an mbuf list, rather than just calling m_freem() on the single mbuf) but the ALQ bits kill that. Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 22:02:05 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A0AAFDF; Tue, 11 Dec 2012 22:02:05 +0000 (UTC) (envelope-from andre@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 13C8F8FC16; Tue, 11 Dec 2012 22:02:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBBM245H010404; Tue, 11 Dec 2012 22:02:04 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBBM24sO010400; Tue, 11 Dec 2012 22:02:04 GMT (envelope-from andre) Date: Tue, 11 Dec 2012 22:02:04 GMT Message-Id: <201212112202.qBBM24sO010400@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Subject: Re: kern/174087: [tcp] Problems with ephemeral port selection 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, 11 Dec 2012 22:02:05 -0000 Synopsis: [tcp] Problems with ephemeral port selection Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Dec 11 22:01:32 UTC 2012 Responsible-Changed-Why: Looking into it. http://www.freebsd.org/cgi/query-pr.cgi?pr=174087 From owner-freebsd-net@FreeBSD.ORG Wed Dec 12 07:49:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10AEE9A7 for ; Wed, 12 Dec 2012 07:49:33 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF74C8FC08 for ; Wed, 12 Dec 2012 07:49:32 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so175544qcs.13 for ; Tue, 11 Dec 2012 23:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xhiQw2Helfx1yj/4jeLUyT/3mT31rrWa1in5fIMIrpE=; b=OHn08aKKBsoUN5aTY6shxotHECSQYvKxH6PgqUJNRLFoBtMS+9knRrtt/MQdlDfNG1 Ltw1CvxLoqlZI+tXjA/UoNlvTzOen9T5cIi0cHbGECOrdWhn3lzgZL0UPAnbKuYV9Fy7 Ii4Pm1/AD4a5Rgm9FlSg8Kljh08oa0QhqbAb8RUj3MjaqkRkbJR/viPJpi4DGFVlzUd7 tD0iakO3nOr22DJvmjVNMVpN8i1IScr7X7zCY9w8hGFnjCK5IPL4kH9hvnPKmCXdhdPH +xaTXxqP+kGE52T9y9Mlo3tOm6KuaL1SnizVbg/PUouMxV8sCHmuxr5p5oDokfBtgM88 nCpw== MIME-Version: 1.0 Received: by 10.49.132.69 with SMTP id os5mr234184qeb.28.1355298571882; Tue, 11 Dec 2012 23:49:31 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Tue, 11 Dec 2012 23:49:31 -0800 (PST) In-Reply-To: <50C79252.5000509@gmail.com> References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> <50C79252.5000509@gmail.com> Date: Wed, 12 Dec 2012 08:49:31 +0100 X-Google-Sender-Auth: t0-N_rV5l-KACPMjlgEMMLISIOw Message-ID: Subject: Re: igb and ALTQ in 9.1-rc3 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , "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: Wed, 12 Dec 2012 07:49:33 -0000 On Tue, Dec 11, 2012 at 9:06 PM, Karim Fodil-Lemelin < fodillemlinkarim@gmail.com> wrote: > On 11/12/2012 11:27 AM, Ermal Lu=E7i wrote: > >> On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin < >> fodillemlinkarim@gmail.com> wrote: >> >> On 11/12/2012 9:15 AM, Ermal Lu=E7i wrote: >>> >>> On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba < >>>> barney_cordoba@yahoo.com >>>> >>>>> **wrote: >>>>> >>>> >>>> --- On Tue, 12/11/12, Gleb Smirnoff wrote: >>>>> >>>>> From: Gleb Smirnoff >>>>> >>>>>> Subject: Re: igb and ALTQ in 9.1-rc3 >>>>>> To: "Jack Vogel" >>>>>> Cc: "Clement Hermann (nodens)" , "Barney >>>>>> Cordoba" >>>>>> >>>>>> , freebsd-net@FreeBSD.org >>>>> >>>>> Date: Tuesday, December 11, 2012, 2:58 AM >>>>>> 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. >>>>>> >>>>>> It seems pretty difficult to say that something is compatible with >>>>>> >>>>> something else if it hasn't been tested in a few years. >>>>> >>>>> It seems to me that ATLQ is the one that should handle if_transmit. >>>>> although it's a good argument for having a raw "send" function in >>>>> drivers. Ethernet drivers don't need more than a send() routing that >>>>> loads a packet into the ring. The decision on what to do if you can't >>>>> queue a packet should be in the network layer, if we must still call >>>>> things layers. >>>>> >>>>> "start" is a leftover from a day when you stuffed a buffer and waited >>>>> for an interrupt to stuff in another. The whole idea is antiquated. >>>>> >>>>> Imagine drivers that pull packets off of a card and simply queue it; >>>>> and that you simply submit a packet to be queued for transmit. Instea= d >>>>> of trying to find 35 programmers that understand all of the lock BS, >>>>> you only need to have a couple. >>>>> >>>>> I always disable all of the gobbledegook like checksum offloading. Th= ey >>>>> just muddy the water and have very little effect on performance. A >>>>> modern >>>>> cpu can do a checksum as fast as you can manage the "capabilities" >>>>> without >>>>> disrupting the processing path. >>>>> >>>>> With FreeBSD, every driver is an experience. Some suck so bad that th= ey >>>>> should come with a warning. The MSK driver is completely useless, as >>>>> an example. >>>>> >>>>> >>>>> BC >>>>> ______________________________****_________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-net >>>>> >>>>> > >>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**fre** >>>>> ebsd.org >>>>> > >>>>> >>>>> " >>>>> >>>>> During implementation of if_transmit altq was not considered at all= . >>>>> >>>> The default if_transmit provides some compatibility but that is void >>>> since >>>> altq has not been converted to call if_transmit after processing the >>>> mbuf. >>>> >>>> ALTQ can be adapted quite easily to if_transmit model it just wasn't >>>> done >>>> at the time. >>>> With if_transmit model it can even be modularized and not be a compile >>>> kernel option since the queue of the iface is abstracted now. >>>> >>>> I have always wanted to do a diff but have not yet got to it. >>>> The change is quite simple just provide an altq_transmit default metho= d >>>> and >>>> just hook into if_transmit model on the fly. >>>> You surely need to handle some iface events and enable altq based on >>>> request but its is not a hard to implement. >>>> >>>> I will always have this in my TODO but not sure when i can get to it. >>>> >>>> The issue is not only that igb doesn't support if_transmit or if_sta= rt >>>> >>> method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK >>> for >>> all of its enqueue/dequeue operations. A simple drop in of if_transmit = is >>> bound to cause race conditions on any multiqueue driver with ALTQ. >>> >>> I do have a patch set for this on igb but its ugly and needs more work >>> although it should get you going. Let me know if your interested I will >>> clean it up and send it over. For more information on ALTQ discussion a= nd >>> igb please read this thread: http://freebsd.1045724.n5.** >>> nabble.com/em-igb-if-transmit-****drbr-and-ALTQ-td5760338.html >>> **>> drbr-and-ALTQ-td5760338.html >>> > >>> >>> Best regards, >>> >>> Karim. >>> >>> >>> ALTQ needs to do serialization of packets to apply its policy. >> While it can be extended to map driver queues to ALTQ queues that is not >> easy done without getting some interface to the driver to communicate. >> The poor man implementation would be to pass an index argument when >> calling >> driver transmit routine. >> >> I doubt it is realistic to map ALTQ queues to driver queues since ALTQ > can have many more queues then what any driver would need and those queue= s > are controlled by users in so many ways it is almost impossible to cater > for all cases in all device drivers. This could lead to TX rings being > quickly filled up and packets being dropped. A good example of this would > be to have two ALTQ queues. One very fast 1Gbps and one very slow 512Kbps= . > Having to reference packets through indexes inside the driver queues for > each of the corresponding packets in ALTQ's fast queue would result in to= o > much overhead IMO and a potential ring exhaustion by the slow queue. Both > queues having different queue backlog criteria for achieving their rate > they must be maintained somewhat separately (which is what ALTQ does > through its class_queue). > > That is a matter of policy rather than implementation. If the implementation is there the policy maker can decide to do 1:1 mapping with hw queues since it provides quite a bit of flexibility and avoids buffering to much. > ALTQ needs to be both a consumer and a producer of a device driver (or > ideally to some interface to it). It needs to be able to 'consume' packet= s > from an outgoing path to enqueue them and some way (historically if_start= ) > to tell a driver to send a given packet. While the enqueue operation is > usually through a direct dispatch the dequeuing can be done asynchronousl= y > by a timer through ALTQ's token bucket regulator. Not unlike buf ring ALT= Q > can, in the same if_transmit works, enqueue a packet and dequeue another > packet to be sent. > > Dummynet does the same and ALTQ would be quite similar to it in that regard when it gets moved to if_transmit. They just hook in different level and ALTQ does not need a looping by the place it chose to hook in. > What is needed is a clear API for sending packets and a comprehensive set > of rules for locking TX queues. Right now FreeBSD has ifqueue (if_start) > with its well known IFQ_LOCK and if_transmit (drbr) with driver managed T= X > locks and while it seems the trend is to move towards if_transmit, the > transition is not completed and the locking too much dependent on the > driver implementation to be currently useable by ALTQ. > > Karim. > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Wed Dec 12 14:36:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A658C58; Wed, 12 Dec 2012 14:36:24 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id D4DEB8FC0A; Wed, 12 Dec 2012 14:36:23 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so2016899iec.13 for ; Wed, 12 Dec 2012 06:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PrCEWtpTs8vy36fdue68gM/1Y+ValUvZJoC/V1SkPyg=; b=YqiBuyPxYlFJk3OoI5gjdvk6NjvB8qsMdz9iobBOTTilvvhGuXLOCze5ZnZLB3lK5I GMw7r9M83t6tLUGI4w0CXBeiQCK6EJ9yEvQNXKU3+9+gEB1gcMwYyH949lCRk4KAfv4M C65bDUk9EuUOGteMNRWoCu+v7F+UzIp2wxtPwMdQKVQgGJ00nIOut9t+cOaGNYbWKVek Xmg4QUVZ16fA2Nl8gTltdd8//7tqP3K2oFeBPUqrgnr+mMjBwYnGkKBsiOmWAfOZ664i VdJxtMUZi+k+Yx1GO8q40JutJMVVyzhIZ695qnT4fKEk3p1XwYqS9HirpQguCXtgnJez ENoA== Received: by 10.50.33.174 with SMTP id s14mr1009426igi.11.1355322982967; Wed, 12 Dec 2012 06:36:22 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id uj11sm1871421igb.15.2012.12.12.06.36.20 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 06:36:21 -0800 (PST) Message-ID: <50C89660.8070806@gmail.com> Date: Wed, 12 Dec 2012 09:36:16 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: igb and ALTQ in 9.1-rc3 References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> <50C79252.5000509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Karim Fodil-Lemelin , freebsd-net , "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: Wed, 12 Dec 2012 14:36:24 -0000 On 12/12/2012 2:49 AM, Ermal Luçi wrote: > On Tue, Dec 11, 2012 at 9:06 PM, Karim Fodil-Lemelin < > fodillemlinkarim@gmail.com> wrote: > >> On 11/12/2012 11:27 AM, Ermal Luçi wrote: >> >>> On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin < >>> fodillemlinkarim@gmail.com> wrote: >>> >>> On 11/12/2012 9:15 AM, Ermal Luçi wrote: >>>> On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba < >>>>> barney_cordoba@yahoo.com >>>>> >>>>>> **wrote: >>>>>> >>>>> --- On Tue, 12/11/12, Gleb Smirnoff wrote: >>>>>> From: Gleb Smirnoff >>>>>> >>>>>>> Subject: Re: igb and ALTQ in 9.1-rc3 >>>>>>> To: "Jack Vogel" >>>>>>> Cc: "Clement Hermann (nodens)" , "Barney >>>>>>> Cordoba" >>>>>>> >>>>>>> , freebsd-net@FreeBSD.org >>>>>> Date: Tuesday, December 11, 2012, 2:58 AM >>>>>>> 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. >>>>>>> >>>>>>> It seems pretty difficult to say that something is compatible with >>>>>>> >>>>>> something else if it hasn't been tested in a few years. >>>>>> >>>>>> It seems to me that ATLQ is the one that should handle if_transmit. >>>>>> although it's a good argument for having a raw "send" function in >>>>>> drivers. Ethernet drivers don't need more than a send() routing that >>>>>> loads a packet into the ring. The decision on what to do if you can't >>>>>> queue a packet should be in the network layer, if we must still call >>>>>> things layers. >>>>>> >>>>>> "start" is a leftover from a day when you stuffed a buffer and waited >>>>>> for an interrupt to stuff in another. The whole idea is antiquated. >>>>>> >>>>>> Imagine drivers that pull packets off of a card and simply queue it; >>>>>> and that you simply submit a packet to be queued for transmit. Instead >>>>>> of trying to find 35 programmers that understand all of the lock BS, >>>>>> you only need to have a couple. >>>>>> >>>>>> I always disable all of the gobbledegook like checksum offloading. They >>>>>> just muddy the water and have very little effect on performance. A >>>>>> modern >>>>>> cpu can do a checksum as fast as you can manage the "capabilities" >>>>>> without >>>>>> disrupting the processing path. >>>>>> >>>>>> With FreeBSD, every driver is an experience. Some suck so bad that they >>>>>> should come with a warning. The MSK driver is completely useless, as >>>>>> an example. >>>>>> >>>>>> >>>>>> BC >>>>>> ______________________________****_________________ >>>>>> freebsd-net@freebsd.org mailing list >>>>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-net >>>>>> >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**fre** >>>>>> ebsd.org >>>>>> " >>>>>> >>>>>> During implementation of if_transmit altq was not considered at all. >>>>>> >>>>> The default if_transmit provides some compatibility but that is void >>>>> since >>>>> altq has not been converted to call if_transmit after processing the >>>>> mbuf. >>>>> >>>>> ALTQ can be adapted quite easily to if_transmit model it just wasn't >>>>> done >>>>> at the time. >>>>> With if_transmit model it can even be modularized and not be a compile >>>>> kernel option since the queue of the iface is abstracted now. >>>>> >>>>> I have always wanted to do a diff but have not yet got to it. >>>>> The change is quite simple just provide an altq_transmit default method >>>>> and >>>>> just hook into if_transmit model on the fly. >>>>> You surely need to handle some iface events and enable altq based on >>>>> request but its is not a hard to implement. >>>>> >>>>> I will always have this in my TODO but not sure when i can get to it. >>>>> >>>>> The issue is not only that igb doesn't support if_transmit or if_start >>>>> >>>> method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK >>>> for >>>> all of its enqueue/dequeue operations. A simple drop in of if_transmit is >>>> bound to cause race conditions on any multiqueue driver with ALTQ. >>>> >>>> I do have a patch set for this on igb but its ugly and needs more work >>>> although it should get you going. Let me know if your interested I will >>>> clean it up and send it over. For more information on ALTQ discussion and >>>> igb please read this thread: http://freebsd.1045724.n5.** >>>> nabble.com/em-igb-if-transmit-****drbr-and-ALTQ-td5760338.html >>>> **>>> drbr-and-ALTQ-td5760338.html >>>> Best regards, >>>> >>>> Karim. >>>> >>>> >>>> ALTQ needs to do serialization of packets to apply its policy. >>> While it can be extended to map driver queues to ALTQ queues that is not >>> easy done without getting some interface to the driver to communicate. >>> The poor man implementation would be to pass an index argument when >>> calling >>> driver transmit routine. >>> >>> I doubt it is realistic to map ALTQ queues to driver queues since ALTQ >> can have many more queues then what any driver would need and those queues >> are controlled by users in so many ways it is almost impossible to cater >> for all cases in all device drivers. This could lead to TX rings being >> quickly filled up and packets being dropped. A good example of this would >> be to have two ALTQ queues. One very fast 1Gbps and one very slow 512Kbps. >> Having to reference packets through indexes inside the driver queues for >> each of the corresponding packets in ALTQ's fast queue would result in too >> much overhead IMO and a potential ring exhaustion by the slow queue. Both >> queues having different queue backlog criteria for achieving their rate >> they must be maintained somewhat separately (which is what ALTQ does >> through its class_queue). >> >> That is a matter of policy rather than implementation. > If the implementation is there the policy maker can decide to do 1:1 > mapping with hw queues since it provides quite a bit of flexibility and > avoids buffering to much. Still unrealistic in my opinion since there is a chance there won't be enough HW queues for a 1:1 mapping. 1:1 implies the hardware supports enough HW queues for a given policy. I can easily use over 30 ALTQ HFSC classes on igb currently and igb only support 8 HW queues. > > >> ALTQ needs to be both a consumer and a producer of a device driver (or >> ideally to some interface to it). It needs to be able to 'consume' packets >> from an outgoing path to enqueue them and some way (historically if_start) >> to tell a driver to send a given packet. While the enqueue operation is >> usually through a direct dispatch the dequeuing can be done asynchronously >> by a timer through ALTQ's token bucket regulator. Not unlike buf ring ALTQ >> can, in the same if_transmit works, enqueue a packet and dequeue another >> packet to be sent. >> >> > Dummynet does the same and ALTQ would be quite similar to it in that regard > when it gets moved to if_transmit. > They just hook in different level and ALTQ does not need a looping by the > place it chose to hook in. I haven't looked at dummynet in years (I use it everyday but I haven't looked at the 8.x+ code) but I last time I checked, dummnet maintains its own sets of queues and does its own serialization separately from the driver queues. And in the same way ALTQ can sometimes queue and not transmit on an enqueue operation, dummynet can queue packets in its queues and wait for a timer to trigger the transmit of a frame. If you want to delay a packet you must be able to hold the transmissions and trigger it at a later time and for this I think it would be a mistake to clog the small number driver queues. > >> What is needed is a clear API for sending packets and a comprehensive set >> of rules for locking TX queues. Right now FreeBSD has ifqueue (if_start) >> with its well known IFQ_LOCK and if_transmit (drbr) with driver managed TX >> locks and while it seems the trend is to move towards if_transmit, the >> transition is not completed and the locking too much dependent on the >> driver implementation to be currently useable by ALTQ. >> >> Karim. >> > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 03:50:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68F80F82 for ; Thu, 13 Dec 2012 03:50:44 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD8B48FC12 for ; Thu, 13 Dec 2012 03:50:43 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1345273lah.13 for ; Wed, 12 Dec 2012 19:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wYe6FQRwWUQrKTsApUNswmwGWPoTsLjaOJXzBcTK05k=; b=p6se/h8tZSaLQ/r+xRffRfSNJIqUCZjAa1sVFqPacqXAa33i4l4z0zBJmIHkB6erIC OrFE/YXakZulLM7Lsk+g/eICYyqjt7U3YdaOGd1UYBsLlpVpB9I34sVW6hSCbxmmoDw6 HboyqRPyq51BvKeiF36dcZR6tJPPiPIiT+sVkST0hoFBizTaM/WPywMVSuMfo9BzN2Dk oOSyAltkZGCdtANpFj2px6958f0difwFkR1ghD3ExZqr/1RFs+sn4cMzKCh3R4JTrzK8 9N5PUJrIbsPZD8zpB80RUithgLkQnzbmSQr1tDmpMz1VVEUjrObr0nCbX1Q9AEeOXOhn BECg== MIME-Version: 1.0 Received: by 10.112.47.168 with SMTP id e8mr320400lbn.46.1355370642542; Wed, 12 Dec 2012 19:50:42 -0800 (PST) Received: by 10.112.61.33 with HTTP; Wed, 12 Dec 2012 19:50:42 -0800 (PST) Date: Wed, 12 Dec 2012 22:50:42 -0500 Message-ID: Subject: ipv6 route ignores MTU. From: Zaphod Beeblebrox To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 13 Dec 2012 03:50:44 -0000 On a: FreeBSD virtual.accountingreality.com 9.1-RC2 FreeBSD 9.1-RC2 #6 r241240: Sat Oct 6 01:43:35 EDT 2012 root@virtual.accountingreality.com:/usr/obj/usr/src/sys/VRA amd64 I have set a high MTU: em0: flags=8843 metric 0 mtu 9014 options=4019b ether 00:15:17:0d:04:a8 inet x.y.z.q netmask 0xffffffe0 broadcast x.y.z.q1 inet6 fe80::215:17ff:fe0d:4a8%em0 prefixlen 64 scopeid 0x5 inet6 2001:1928:1::52 prefixlen 64 inet 192.168.221.2 netmask 0xffffff00 broadcast 192.168.221.255 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active curiously, although: [1:2:301]root@virtual:~> route -n get 192.168.221.84 route to: 192.168.221.84 destination: 192.168.221.0 mask: 255.255.255.0 interface: em0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 9014 1 0 shows the correct MTU, [1:5:304]root@virtual:~> route -n get -inet6 2001:1928:1::84 route to: 2001:1928:1::84 destination: 2001:1928:1:: mask: ffff:ffff:ffff:ffff:: interface: em0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 shows the wrong MTU. The MTU in this case is set in the ifconfig_em0 rc.conf entry and the machine has been rebooted. From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 09:51:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD8DEE2F for ; Thu, 13 Dec 2012 09:51:57 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 37D3E8FC12 for ; Thu, 13 Dec 2012 09:51:56 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id qBD9lOBB040219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2012 09:47:24 GMT Date: Thu, 13 Dec 2012 09:47:12 +0000 From: Karl Pielorz To: freebsd-net@freebsd.org Subject: Arp table size - any adjustments? Message-ID: <523DE5571B5BE81B8BA1846F@MightyAtom.tdx.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 13 Dec 2012 09:51:57 -0000 Hi, I have an FreeBSD amd64 9-STABLE system running as a router for various bits and pieces - this has a 'lot' of hosts on it's LAN (literally thousands) - most are NAT end points etc. Looking at the output from 'arp -a -n' it regularly lists 2,000-3,000 entries. Is there anything I need to tune for this kind of quantity (or more), or is it all 'auto-adjusting' on 9.0-S onwards? Thanks, -Karl From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 11:33:36 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A96659E8 for ; Thu, 13 Dec 2012 11:33:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2989D8FC14 for ; Thu, 13 Dec 2012 11:33:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qBDBXXra009901; Thu, 13 Dec 2012 15:33:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBDBXXDo009900; Thu, 13 Dec 2012 15:33:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 13 Dec 2012 15:33:33 +0400 From: Gleb Smirnoff To: Karl Pielorz Subject: Re: Arp table size - any adjustments? Message-ID: <20121213113333.GT97487@FreeBSD.org> References: <523DE5571B5BE81B8BA1846F@MightyAtom.tdx.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <523DE5571B5BE81B8BA1846F@MightyAtom.tdx.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 13 Dec 2012 11:33:36 -0000 On Thu, Dec 13, 2012 at 09:47:12AM +0000, Karl Pielorz wrote: K> I have an FreeBSD amd64 9-STABLE system running as a router for various K> bits and pieces - this has a 'lot' of hosts on it's LAN (literally K> thousands) - most are NAT end points etc. K> K> Looking at the output from 'arp -a -n' it regularly lists 2,000-3,000 K> entries. Is there anything I need to tune for this kind of quantity (or K> more), or is it all 'auto-adjusting' on 9.0-S onwards? Nope, there is no autotuning here yet. The hash table size is hardcoded in sys/net/if_llatbl.h. The name of constant is LLTBL_HASHTBL_SIZE. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 11:46:29 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3E02B97 for ; Thu, 13 Dec 2012 11:46:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5AD8FC08 for ; Thu, 13 Dec 2012 11:46:27 +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 NAA14855 for ; Thu, 13 Dec 2012 13:46:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9C012.8020306@FreeBSD.org> Date: Thu, 13 Dec 2012 13:46:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: ng_ether naming X-Enigmail-Version: 1.4.6 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, 13 Dec 2012 11:46:29 -0000 ng_ether uses if_xname for naming its nodes. This could be troublesome for mapping interface names to their ng_ether companions in the face of interface renaming capability. Especially given that interface renaming and ng_ether _module_ loading may happen in an arbitrary order. I am not sure how to solve this best. One possibility is to use if_dname+if_dunit combination for ng_ether naming. This should be stable and available for querying. This behavior should also be backward compatible with ng_ether being compiled into kernel (if_dname+if_dunit == if_xname before any renaming could occur). Another possibility is to do ng_ether renaming when its interface is renamed. This seems nicer but appears to be more work and more intrusive, because interfaces would have to know about their ng_ether nodes. What do you think? Thank you. And just in case: $ ifconfig -l net0 lo0 $ ngctl list There are 2 total nodes: Name: re0 Type: ether ID: 00000001 Num hooks: 0 Name: ngctl11353 Type: socket ID: 00000003 Num hooks: 0 -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 12:09:03 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECDF8912; Thu, 13 Dec 2012 12:09:03 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 81ACD8FC14; Thu, 13 Dec 2012 12:09:02 +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 1Tj7eR-000Ef6-Mw; Thu, 13 Dec 2012 16:12:31 +0400 Message-ID: <50C9C55A.5090900@ipfw.ru> Date: Thu, 13 Dec 2012 16:08:58 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: ng_ether naming References: <50C9C012.8020306@FreeBSD.org> In-Reply-To: <50C9C012.8020306@FreeBSD.org> 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: Thu, 13 Dec 2012 12:09:04 -0000 On 13.12.2012 15:46, Andriy Gapon wrote: > > ng_ether uses if_xname for naming its nodes. > This could be troublesome for mapping interface names to their ng_ether companions > in the face of interface renaming capability. Especially given that interface > renaming and ng_ether _module_ loading may happen in an arbitrary order. > > I am not sure how to solve this best. > > One possibility is to use if_dname+if_dunit combination for ng_ether naming. This > should be stable and available for querying. This behavior should also be > backward compatible with ng_ether being compiled into kernel (if_dname+if_dunit == > if_xname before any renaming could occur). > > Another possibility is to do ng_ether renaming when its interface is renamed. > This seems nicer but appears to be more work and more intrusive, because > interfaces would have to know about their ng_ether nodes. Not exactly. You can register for ifnet_departure_event and ifnet_arrival_event. Interface renaming is done via sending departure event with old name and arrvial event with new one. > > What do you think? > Thank you. > > And just in case: > $ ifconfig -l > net0 lo0 > $ ngctl list > There are 2 total nodes: > Name: re0 Type: ether ID: 00000001 Num hooks: 0 > Name: ngctl11353 Type: socket ID: 00000003 Num hooks: 0 > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 16:15:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E36FB54A; Thu, 13 Dec 2012 16:15:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACC48FC15; Thu, 13 Dec 2012 16:15:07 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TjBI7-0002Zy-NK; Thu, 13 Dec 2012 18:05:43 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: igb issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2012 18:05:43 +0200 From: Daniel Braniss Message-ID: 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: Thu, 13 Dec 2012 16:15:09 -0000 hi, I'm trying out a 4way Dell PowerEdge C5125/AMD server with onboard Intel(R) PRO/1000 Network Connection version - 2.3.1 when running FreeBsd 8.3 (from sometime around Nov 2) all is ok. with latest (at least Fridays') 9.1-PRERELEASE it's getting 'constipated'. It seems that NFS writes slowdown to a halt, and so I'm getting 'not responding' errors. I am using the same kernel on different hosts with out any problems, even with Intel(R) PRO/1000 Network Connection version - 2.3.4 Any ideas? danny From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 16:25:09 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A06FC8FF for ; Thu, 13 Dec 2012 16:25:09 +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 E80DF8FC0C for ; Thu, 13 Dec 2012 16:25:08 +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 SAA17808; Thu, 13 Dec 2012 18:25:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50CA0161.1060000@FreeBSD.org> Date: Thu, 13 Dec 2012 18:25:05 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , freebsd-net@FreeBSD.org Subject: Re: ng_ether naming References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> In-Reply-To: <50C9C55A.5090900@ipfw.ru> X-Enigmail-Version: 1.4.6 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, 13 Dec 2012 16:25:09 -0000 on 13/12/2012 14:08 Alexander V. Chernikov said the following: > On 13.12.2012 15:46, Andriy Gapon wrote: >> >> ng_ether uses if_xname for naming its nodes. >> This could be troublesome for mapping interface names to their ng_ether companions >> in the face of interface renaming capability. Especially given that interface >> renaming and ng_ether _module_ loading may happen in an arbitrary order. >> >> I am not sure how to solve this best. >> >> One possibility is to use if_dname+if_dunit combination for ng_ether naming. This >> should be stable and available for querying. This behavior should also be >> backward compatible with ng_ether being compiled into kernel (if_dname+if_dunit == >> if_xname before any renaming could occur). >> >> Another possibility is to do ng_ether renaming when its interface is renamed. >> This seems nicer but appears to be more work and more intrusive, because >> interfaces would have to know about their ng_ether nodes. > > Not exactly. You can register for ifnet_departure_event and ifnet_arrival_event. > > Interface renaming is done via sending departure event with old name and arrvial > event with new one. Good to know. Thank you! So which approach sounds better? Or maybe there is even a better one? >> >> What do you think? >> Thank you. >> >> And just in case: >> $ ifconfig -l >> net0 lo0 >> $ ngctl list >> There are 2 total nodes: >> Name: re0 Type: ether ID: 00000001 Num hooks: 0 >> Name: ngctl11353 Type: socket ID: 00000003 Num hooks: 0 >> > > -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 17:00:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D00C2ED; Thu, 13 Dec 2012 17:00:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 006F88FC12; Thu, 13 Dec 2012 17:00:33 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2643088vba.13 for ; Thu, 13 Dec 2012 09:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SPoUhDujy35hd39TFAPq1PpYsacpLIeX8ky3kerzuPQ=; b=e6NCSUiQlCfSgxt/Hj3gggAs7Wc62IRF4IbVJoAfMHhIrewGsptcHrfgCEEgB8r3LL Ljl2wM6i8CKujkEgl3T28umQL0oV/GmbihfyR901+n2utkRXhvDIQvNxIduEfw10g71c 9VZftIpW3FOSNR7kXjLd1Cusf0yPqCOlBVJaoZ7eCKwVA8GsSlAXWh38Y25rCSoU6S+E 8+zXhhzn4mgmDIaKzIzWgOdOulzgyb0kp/MFlvYK3bSwm+TFe1/1nfJyCX6SvR1WVbje 4IWkjvMnltqVjUebqfgby4a/UT/OMKo7j7MWz9aUAq6Xwfi51iMg2NWk6ixB9MZ7ZGu+ 3kMw== MIME-Version: 1.0 Received: by 10.52.240.146 with SMTP id wa18mr3980042vdc.47.1355418033055; Thu, 13 Dec 2012 09:00:33 -0800 (PST) Received: by 10.220.50.6 with HTTP; Thu, 13 Dec 2012 09:00:32 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 09:00:32 -0800 Message-ID: Subject: Re: igb issues From: Jack Vogel To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, freebsd-stable@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, 13 Dec 2012 17:00:34 -0000 Try putting the driver from 9.1 back onto 8.3 and see if you still see a problem. That will indicate if its in the driver or the stack/OS. If you have any question about doing this send me email. Is NFS using UDP or TCP? Regards, Jack On Thu, Dec 13, 2012 at 8:05 AM, Daniel Braniss wrote: > hi, > I'm trying out a 4way Dell PowerEdge C5125/AMD server with onboard > Intel(R) PRO/1000 Network Connection version - 2.3.1 > > when running FreeBsd 8.3 (from sometime around Nov 2) all is ok. > with latest (at least Fridays') 9.1-PRERELEASE it's getting 'constipated'. > > It seems that NFS writes slowdown to a halt, and so I'm getting 'not > responding' errors. > > I am using the same kernel on different hosts with out any problems, > even with Intel(R) PRO/1000 Network Connection version - 2.3.4 > > Any ideas? > > danny > > > _______________________________________________ > 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 Dec 13 18:57:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36B5EA4D; Thu, 13 Dec 2012 18:57:51 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C82478FC0A; Thu, 13 Dec 2012 18:57:50 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so3386503qaq.13 for ; Thu, 13 Dec 2012 10:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pT+pxG7MCHP1BnNjsavf17J1jtD+A/dFrmNYKKI9Ksw=; b=YbfQMy2vUUcHeIsBwXSFSmtxMzExyDZydJEOiG04BOT74adZ3vcN+bcrEO6ueqrSzY zH5QQ9JJFLlzC5MGH0dg0doIQSda1+MjtmyK3+gmrCuFOS7ZhiYmzrK9fVrJF6gksqvi qdCgX0Y73FhP6fRGpdzmuohrWSi2ze9i4sZwex94xRyzS+wgykJ4eMu4n+PmXJv1klcY Yn+OOXOtNp+wiK6AhBTkDbCElNU16Lf8b0mlyilPShGhnyxMHdnXC3hT3zy3RApI/Ng3 KSecSSPLLnP6I9qxbta0/GcvLsvDYrgJNOVug+eQNSJobTpYraHDMgkWys/2ifHp5vOH 17uQ== MIME-Version: 1.0 Received: by 10.49.133.68 with SMTP id pa4mr1520059qeb.50.1355425069817; Thu, 13 Dec 2012 10:57:49 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Thu, 13 Dec 2012 10:57:49 -0800 (PST) In-Reply-To: <50CA0161.1060000@FreeBSD.org> References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> <50CA0161.1060000@FreeBSD.org> Date: Thu, 13 Dec 2012 19:57:49 +0100 X-Google-Sender-Auth: D6uMwek53fxpIhJbdPDnDdxSO9U Message-ID: Subject: Re: ng_ether naming From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , "Alexander V. Chernikov" 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, 13 Dec 2012 18:57:51 -0000 On Thu, Dec 13, 2012 at 5:25 PM, Andriy Gapon wrote: > on 13/12/2012 14:08 Alexander V. Chernikov said the following: > > On 13.12.2012 15:46, Andriy Gapon wrote: > >> > >> ng_ether uses if_xname for naming its nodes. > >> This could be troublesome for mapping interface names to their ng_ether > companions > >> in the face of interface renaming capability. Especially given that > interface > >> renaming and ng_ether _module_ loading may happen in an arbitrary order. > >> > >> I am not sure how to solve this best. > >> > >> One possibility is to use if_dname+if_dunit combination for ng_ether > naming. This > >> should be stable and available for querying. This behavior should also > be > >> backward compatible with ng_ether being compiled into kernel > (if_dname+if_dunit == > >> if_xname before any renaming could occur). > >> > >> Another possibility is to do ng_ether renaming when its interface is > renamed. > >> This seems nicer but appears to be more work and more intrusive, because > >> interfaces would have to know about their ng_ether nodes. > > > > Not exactly. You can register for ifnet_departure_event and > ifnet_arrival_event. > > > > Interface renaming is done via sending departure event with old name and > arrvial > > event with new one. > > Good to know. Thank you! > > > So which approach sounds better? > Or maybe there is even a better one? > > The best is interface event handling. Just recopy the new name from if_xname and should be done. > >> > >> What do you think? > >> Thank you. > >> > >> And just in case: > >> $ ifconfig -l > >> net0 lo0 > >> $ ngctl list > >> There are 2 total nodes: > >> Name: re0 Type: ether ID: 00000001 Num > hooks: 0 > >> Name: ngctl11353 Type: socket ID: 00000003 Num > hooks: 0 > >> > > > > > > > -- > Andriy Gapon > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Thu Dec 13 19:31:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 007B154E for ; Thu, 13 Dec 2012 19:31:52 +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 A8B9B8FC12 for ; Thu, 13 Dec 2012 19:31:52 +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 qBDJVpnS036373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 11:31:51 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id qBDJVprK036372; Thu, 13 Dec 2012 11:31:51 -0800 (PST) (envelope-from jmg) Date: Thu, 13 Dec 2012 11:31:51 -0800 From: John-Mark Gurney To: Zaphod Beeblebrox Subject: Re: ipv6 route ignores MTU. Message-ID: <20121213193151.GE1563@funkthat.com> Mail-Followup-To: Zaphod Beeblebrox , FreeBSD Net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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]); Thu, 13 Dec 2012 11:31:51 -0800 (PST) Cc: 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: Thu, 13 Dec 2012 19:31:53 -0000 Zaphod Beeblebrox wrote this message on Wed, Dec 12, 2012 at 22:50 -0500: > FreeBSD virtual.accountingreality.com 9.1-RC2 FreeBSD 9.1-RC2 #6 r241240: > Sat Oct 6 01:43:35 EDT 2012 > root@virtual.accountingreality.com:/usr/obj/usr/src/sys/VRA > amd64 > > I have set a high MTU: > > em0: flags=8843 metric 0 mtu 9014 > > options=4019b > ether 00:15:17:0d:04:a8 > inet x.y.z.q netmask 0xffffffe0 broadcast x.y.z.q1 > inet6 fe80::215:17ff:fe0d:4a8%em0 prefixlen 64 scopeid 0x5 > inet6 2001:1928:1::52 prefixlen 64 > inet 192.168.221.2 netmask 0xffffff00 broadcast 192.168.221.255 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > curiously, although: > > [1:2:301]root@virtual:~> route -n get 192.168.221.84 > route to: 192.168.221.84 > destination: 192.168.221.0 > mask: 255.255.255.0 > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 9014 1 0 > > shows the correct MTU, > > [1:5:304]root@virtual:~> route -n get -inet6 2001:1928:1::84 > route to: 2001:1928:1::84 > destination: 2001:1928:1:: > mask: ffff:ffff:ffff:ffff:: > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > shows the wrong MTU. > > The MTU in this case is set in the ifconfig_em0 rc.conf entry and the > machine has been rebooted. Are you sure that the mtu is set before the ipv6 address is assigned to the interface? The route inherits what ever MTU was on the interface when the route was created... It will be clamped if it is lower, but will not be increased... This is so you can set the MTU on a route (say you have a broken low memory device that only accept 512 byte packets) and it will stay the way you set it.. -- 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 Fri Dec 14 06:05:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3372AC09 for ; Fri, 14 Dec 2012 06:05:42 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4548FC16 for ; Fri, 14 Dec 2012 06:05:41 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so2463992lbb.13 for ; Thu, 13 Dec 2012 22:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nw0jJBDBrqpOLMFX/ltKMLD9d4jkNt7ffaIhZi/E2ag=; b=ju2UVH2yfOVg14Fd55+cqaAp/JTBHUC9cfpUemzAGemyufsdqUKkXGK06x5b7TnOuO vE4AbKdWaEOR5xtNtpP4P58u4tyNtv2GVbI5um3Qya11I1ly2nV3i6f5PIKI2+Q4ZSwC cneuAAqBX2XcdDAaBGj0TsdSP3JrczWjY8eq+gDVi5LrUHq6zcc2OLnSAiCjwQeFomah LwlvN8oUCGrZlqFhX/gkqjmMyzniYWz98DST/kotI8ZZm630QLG8kpK+S00w2MhKPW/O C/rjucaXJB73MlXBD8qkJVcUt7MMu4BW5YZPEad2pEFbvxc0ACTn90P0vvi7zRhO//fZ Xb5Q== MIME-Version: 1.0 Received: by 10.112.26.41 with SMTP id i9mr1875206lbg.77.1355465140118; Thu, 13 Dec 2012 22:05:40 -0800 (PST) Received: by 10.112.61.33 with HTTP; Thu, 13 Dec 2012 22:05:39 -0800 (PST) In-Reply-To: <20121213193151.GE1563@funkthat.com> References: <20121213193151.GE1563@funkthat.com> Date: Fri, 14 Dec 2012 01:05:39 -0500 Message-ID: Subject: Re: ipv6 route ignores MTU. From: Zaphod Beeblebrox To: Zaphod Beeblebrox , FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 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, 14 Dec 2012 06:05:42 -0000 On Thu, Dec 13, 2012 at 2:31 PM, John-Mark Gurney wrote: > > The MTU in this case is set in the ifconfig_em0 rc.conf entry and the > > machine has been rebooted. > > Are you sure that the mtu is set before the ipv6 address is assigned > to the interface? The route inherits what ever MTU was on the interface > when the route was created... It will be clamped if it is lower, but > will not be increased... This is so you can set the MTU on a route > (say you have a broken low memory device that only accept 512 byte packets) > and it will stay the way you set it.. Ordinarily, I would expect that since the MTU setting is in the ifconfig_em0 configuration line, this was sufficient. However, I realize now that this is not the case. Putting the MTU into the ipv6_ifconfig line did the trick. This is a rather serious violation of POLA --- I would suggest that some thought should be given to how this is configured and documented. From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 08:21:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEF7D8FA; Fri, 14 Dec 2012 08:21:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6DA8FC12; Fri, 14 Dec 2012 08:21:20 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TjQWE-000Eja-43; Fri, 14 Dec 2012 10:21:18 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Jack Vogel Subject: Re: igb issues In-reply-to: References: Comments: In-reply-to Jack Vogel message dated "Thu, 13 Dec 2012 09:00:32 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Dec 2012 10:21:18 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-net@freebsd.org, freebsd-stable@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, 14 Dec 2012 08:21:21 -0000 Hi Jack, > --20cf30780b4661e6f904d0bedadd > Content-Type: text/plain; charset=ISO-8859-1 > > Try putting the driver from 9.1 back onto 8.3 and see if you still > see a problem. That will indicate if its in the driver or the stack/OS. > If you have any question about doing this send me email. > > Is NFS using UDP or TCP? > > Regards, short version: All is OK, sorry for the noise. long version: after sending off the message, I found a nic that I could plug into the box, did that, and before switching to use the em card, I tried another run with the igb, and surprice! all is ok, I will now have to go through logs to see what happend, but my guess is that the switch this host was connected was under heavy load, it has a cluster of HPCs. thanks, have a nice weekend and season greatings! danny > > Jack > > > On Thu, Dec 13, 2012 at 8:05 AM, Daniel Braniss wrote: > > > hi, > > I'm trying out a 4way Dell PowerEdge C5125/AMD server with onboard > > Intel(R) PRO/1000 Network Connection version - 2.3.1 > > > > when running FreeBsd 8.3 (from sometime around Nov 2) all is ok. > > with latest (at least Fridays') 9.1-PRERELEASE it's getting 'constipated'. > > > > It seems that NFS writes slowdown to a halt, and so I'm getting 'not > > responding' errors. > > > > I am using the same kernel on different hosts with out any problems, > > even with Intel(R) PRO/1000 Network Connection version - 2.3.4 > > > > Any ideas? > > > > danny > > > > > > _______________________________________________ > > 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" > > > > --20cf30780b4661e6f904d0bedadd > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Try putting the driver from 9.1 back onto 8.3 and see if you still
see = > a problem. That will indicate if its in the driver or the stack/OS.
iv>If you have any question about doing this send me email.

>
Is NFS using UDP or TCP?

Regards,
= >

Jack


On Th= > u, Dec 13, 2012 at 8:05 AM, Daniel Braniss < "mailto:danny@cs.huji.ac.il" target=3D"_blank">danny@cs.huji.ac.il><= > /span> wrote:
>
x #ccc solid;padding-left:1ex">hi,
> I'm trying out a 4way Dell PowerEdge C5125/AMD server with onboard
> =A0 =A0 =A0 =A0 Intel(R) PRO/1000 Network Connection version - 2.3.1
>
> when running FreeBsd 8.3 (from sometime around Nov 2) all is ok.
> with latest (at least Fridays') 9.1-PRERELEASE it's getting 'co= > nstipated'.
>
> It seems that NFS writes slowdown to a halt, and so I'm getting 'no= > t
> responding' errors.
>
> I am using the same kernel on different hosts with out any problems,
> even with Intel(R) PRO/1000 Network Connection version - 2.3.4
>
> Any ideas?
>
> danny
>
>
> _______________________________________________
> freebsd-net@freebsd.org mail= > ing list
> "_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to " cribe@freebsd.org">freebsd-net-unsubscribe@freebsd.org"
>

> > --20cf30780b4661e6f904d0bedadd-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 17:02:06 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31EE8E9B; Fri, 14 Dec 2012 17:02:06 +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 47EEE8FC13; Fri, 14 Dec 2012 17:02:04 +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 TAA29490; Fri, 14 Dec 2012 19:02:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50CB5B8A.8030703@FreeBSD.org> Date: Fri, 14 Dec 2012 19:02:02 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: ng_ether naming References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> <50CA0161.1060000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net , "Alexander V. Chernikov" 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, 14 Dec 2012 17:02:06 -0000 on 13/12/2012 20:57 Ermal Luçi said the following: > > > > On Thu, Dec 13, 2012 at 5:25 PM, Andriy Gapon > wrote: > > on 13/12/2012 14:08 Alexander V. Chernikov said the following: > > On 13.12.2012 15:46, Andriy Gapon wrote: > >> > >> ng_ether uses if_xname for naming its nodes. > >> This could be troublesome for mapping interface names to their ng_ether > companions > >> in the face of interface renaming capability. Especially given that interface > >> renaming and ng_ether _module_ loading may happen in an arbitrary order. > >> > >> I am not sure how to solve this best. > >> > >> One possibility is to use if_dname+if_dunit combination for ng_ether > naming. This > >> should be stable and available for querying. This behavior should also be > >> backward compatible with ng_ether being compiled into kernel > (if_dname+if_dunit == > >> if_xname before any renaming could occur). > >> > >> Another possibility is to do ng_ether renaming when its interface is renamed. > >> This seems nicer but appears to be more work and more intrusive, because > >> interfaces would have to know about their ng_ether nodes. > > > > Not exactly. You can register for ifnet_departure_event and ifnet_arrival_event. > > > > Interface renaming is done via sending departure event with old name and arrvial > > event with new one. > > Good to know. Thank you! > > > So which approach sounds better? > Or maybe there is even a better one? > > > The best is interface event handling. > Just recopy the new name from if_xname and should be done. There is one problem with the current code which would automatically apply to the interface renaming handling. ng_ether does not do any validation or "normalization" of if_xname and the name can contain symbols which are prohibited in a netgraph name, such as '.' for example. ng_name_node would fail and warning would be logged but a node would stay unnamed. I am a bit reluctant to write "netgraph name escaping" code myself. Perhaps it already exists in some place? -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 17:38:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10554BA7; Fri, 14 Dec 2012 17:38:09 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2822C8FC0C; Fri, 14 Dec 2012 17:38:07 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1843321bkc.13 for ; Fri, 14 Dec 2012 09:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ef82+PJpHFiKg7pL+eTCyosgplcl4cXmoyU7iOhq+pQ=; b=Dr69lFtkn61Jo6YKl4c/IsMtytoZ50dzTWV1yy9WR/jNyUpdEvF8MDSDoRCQR791NL U8mzVE1XMXZnHVwt3yiEDPi0wXt9lNk2rCDt6IPsGxSiKNH04Ebp56nXoGJpGJLxd2w/ +VBh1ob7BqDFPf5dMqrGIU2JoBR64v6P91AO5SaXkeeC1f8IJSdnzS8T2VCp0cjh2Zi9 vdBHb8uQA9Uw++VAkTI+ipfBwn+chKMvXGvxhlC8kVNS8SZZjMz7CyH3PXwyIRY74phe AjOZe3Lx7u1OJ261QNjxoicG3GwmzTASmO1aP3OM+VJ7EdKqIklyQB2HmvmbkFoJ66WK 9Mug== Received: by 10.204.13.28 with SMTP id z28mr3098107bkz.113.1355506686920; Fri, 14 Dec 2012 09:38:06 -0800 (PST) Received: from [10.0.0.3] ([93.152.184.10]) by mx.google.com with ESMTPS id u3sm5281348bkw.9.2012.12.14.09.38.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 09:38:06 -0800 (PST) Subject: Re: ng_ether naming Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: <50CB5B8A.8030703@FreeBSD.org> Date: Fri, 14 Dec 2012 19:38:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75277A1B-B434-4220-A800-9004C29DA92A@gmail.com> References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> <50CA0161.1060000@FreeBSD.org> <50CB5B8A.8030703@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1499) Cc: =?iso-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , "Alexander V. Chernikov" 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, 14 Dec 2012 17:38:09 -0000 On Dec 14, 2012, at 7:02 PM, Andriy Gapon wrote: > on 13/12/2012 20:57 Ermal Lu=E7i said the following: >>=20 >>=20 >>=20 >> On Thu, Dec 13, 2012 at 5:25 PM, Andriy Gapon > > wrote: >>=20 >> on 13/12/2012 14:08 Alexander V. Chernikov said the following: >>> On 13.12.2012 15:46, Andriy Gapon wrote: >>>>=20 >>>> ng_ether uses if_xname for naming its nodes. >>>> This could be troublesome for mapping interface names to their = ng_ether >> companions >>>> in the face of interface renaming capability. Especially given = that interface >>>> renaming and ng_ether _module_ loading may happen in an arbitrary = order. >>>>=20 >>>> I am not sure how to solve this best. >>>>=20 >>>> One possibility is to use if_dname+if_dunit combination for = ng_ether >> naming. This >>>> should be stable and available for querying. This behavior should = also be >>>> backward compatible with ng_ether being compiled into kernel >> (if_dname+if_dunit =3D=3D >>>> if_xname before any renaming could occur). >>>>=20 >>>> Another possibility is to do ng_ether renaming when its interface = is renamed. >>>> This seems nicer but appears to be more work and more intrusive, = because >>>> interfaces would have to know about their ng_ether nodes. >>>=20 >>> Not exactly. You can register for ifnet_departure_event and = ifnet_arrival_event. >>>=20 >>> Interface renaming is done via sending departure event with old name = and arrvial >>> event with new one. >>=20 >> Good to know. Thank you! >>=20 >>=20 >> So which approach sounds better? >> Or maybe there is even a better one? >>=20 >>=20 >> The best is interface event handling. >> Just recopy the new name from if_xname and should be done. >=20 > There is one problem with the current code which would automatically = apply to the > interface renaming handling. > ng_ether does not do any validation or "normalization" of if_xname and = the name > can contain symbols which are prohibited in a netgraph name, such as = '.' for example. > ng_name_node would fail and warning would be logged but a node would = stay unnamed. > I am a bit reluctant to write "netgraph name escaping" code myself. = Perhaps it > already exists in some place? >=20 > --=20 > Andriy Gapon > _______________________________________________ > 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" Hi, Some time ago I had similar issue : = http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027982.html The patch is also in : kern/154850 -- Nikolay= From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 18:04:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACBDE4A9 for ; Fri, 14 Dec 2012 18:04:38 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7AB8FC14 for ; Fri, 14 Dec 2012 18:04:38 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBEI4WVu017817 for ; Fri, 14 Dec 2012 10:04:38 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBEI4RgH017816; Fri, 14 Dec 2012 10:04:27 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 10:04:27 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2012 10:04:27 -0800 (PST) Subject: MAC cloning available like Linux has? From: "Chris H" To: "freebsd-net" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 14 Dec 2012 18:04:38 -0000 Greetings, I attempted another BSD install on another piece of hardware the other day. I'm evaluating a different ISP, and the gateway/router/modem they provided, has 1 ether, which I currently use on my server, and 1 USB(3) port that I had intended to use with the new install. Problem I ran into, was that BSD generates random (fake) MAC(3) addresses, when utilizing the CDCE(4)/ue0. This worked just fine during the install. But the modem "held" the MAC(3) generated during the install, and I now have no idea how to tell BSD to use that MAC(3) when negotiating with the modem. I had absolutely no difficulty assigning the MAC(3) address when spinning up several "live" Linux distro(s) -- they provide the following: su password: *** ifconfig eth1 down ifconfig eth0 hw ether ##:##:##:##:##:## dhclient eth0 blah, blah, blah And I'm connected. Couldn't manage that with BSD. What must I do? Is it even possible? If so, can it be assigned for use on a permanent basis? Thank you for all your time, and consideration. --Chris From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 18:11:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51A596B9 for ; Fri, 14 Dec 2012 18:11:11 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 22EE28FC18 for ; Fri, 14 Dec 2012 18:11:10 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBEIB6sF017980 for ; Fri, 14 Dec 2012 10:11:12 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBEIB1UH017974; Fri, 14 Dec 2012 10:11:01 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 10:11:01 -0800 (PST) Message-ID: In-Reply-To: References: Date: Fri, 14 Dec 2012 10:11:01 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "freebsd-net" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 14 Dec 2012 18:11:11 -0000 > Greetings, > I attempted another BSD install on another piece of hardware the > other day. I'm evaluating a different ISP, and the gateway/router/modem > they provided, has 1 ether, which I currently use on my server, and 1 > USB(3) port that I had intended to use with the new install. Problem I > ran into, was that BSD generates random (fake) MAC(3) addresses, when > utilizing the CDCE(4)/ue0. This worked just fine during the install. > But the modem "held" the MAC(3) generated during the install, and I > now have no idea how to tell BSD to use that MAC(3) when negotiating > with the modem. I had absolutely no difficulty assigning the MAC(3) > address when spinning up several "live" Linux distro(s) -- they provide > the following: > su > password: *** > ifconfig eth1 down > ifconfig eth0 hw ether ##:##:##:##:##:## > dhclient eth0 > blah, blah, blah EDIT those _should_ have all read "eth1" in the session quoted above. Sorry. > > And I'm connected. > Couldn't manage that with BSD. What must I do? Is it even possible? > If so, can it be assigned for use on a permanent basis? > > Thank you for all your time, and consideration. > > --Chris > > _______________________________________________ > 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 Dec 14 18:15:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24F5091E for ; Fri, 14 Dec 2012 18:15:54 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D4A438FC08 for ; Fri, 14 Dec 2012 18:15:52 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so3690276obc.13 for ; Fri, 14 Dec 2012 10:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GpvHnCWKuewcuCWuJiUN+THEPPPrhcQ+qA40l4Tj5ss=; b=UK7c9rChgtn+aGP/c8GmndPpwkBNS5Ms1o/v9B/lMkdq+IihlXS0M2Jl/OcIYSnmSt /D7IRnCr7mX9/MJGKel201QQtB2wbWrcqL01OemeoXlFWy9aCkVJ1lwv5nVTlluuLt83 2E6iPZl9riObuq7PGDInhJSBa9Y/xzpYqqGXxTWTNNNY2SUOvR5ZWR0GGyx/y1gKvC29 zL2gAfTCwVA8bs1GhrcWHWb75BMkF6Y6hJcagIVQIpJ3r6Pr8uPpn2rWEibXB1xaQG5C zQUp2Td3HeFRFkUPaAaFyIbvPcoD8ZOaqZKNp4dMa4WbesHLrQIz8ih/bNXd3nxkNwCP J/Uw== MIME-Version: 1.0 Received: by 10.182.124.98 with SMTP id mh2mr5269822obb.88.1355508952099; Fri, 14 Dec 2012 10:15:52 -0800 (PST) Received: by 10.76.80.104 with HTTP; Fri, 14 Dec 2012 10:15:51 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 12:15:51 -0600 Message-ID: Subject: Re: MAC cloning available like Linux has? From: Adam Vande More To: Chris H Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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, 14 Dec 2012 18:15:54 -0000 On Fri, Dec 14, 2012 at 12:11 PM, Chris H wrote: > > Greetings, > > I attempted another BSD install on another piece of hardware the > > other day. I'm evaluating a different ISP, and the gateway/router/modem > > they provided, has 1 ether, which I currently use on my server, and 1 > > USB(3) port that I had intended to use with the new install. Problem I > > ran into, was that BSD generates random (fake) MAC(3) addresses, when > > utilizing the CDCE(4)/ue0. This worked just fine during the install. > > But the modem "held" the MAC(3) generated during the install, and I > > now have no idea how to tell BSD to use that MAC(3) when negotiating > > with the modem. I had absolutely no difficulty assigning the MAC(3) > > address when spinning up several "live" Linux distro(s) -- they provide > > the following: > > su > > password: *** > > ifconfig eth1 down > > ifconfig eth0 hw ether ##:##:##:##:##:## > > dhclient eth0 > > blah, blah, blah > EDIT > those _should_ have all read "eth1" in the session quoted above. > Sorry. > > > > And I'm connected. > > Couldn't manage that with BSD. What must I do? Is it even possible? > > If so, can it be assigned for use on a permanent basis? > > > > Thank you for all your time, and consideration. > > http://lmgtfy.com/?q=freebsd+change+mac+address -- Adam Vande More From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 18:42:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32640302 for ; Fri, 14 Dec 2012 18:42:45 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id B67918FC12 for ; Fri, 14 Dec 2012 18:42:44 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBEIgdcr018532 for ; Fri, 14 Dec 2012 10:42:45 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBEIgYUe018529; Fri, 14 Dec 2012 10:42:34 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 10:42:34 -0800 (PST) Message-ID: In-Reply-To: References: Date: Fri, 14 Dec 2012 10:42:34 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "freebsd-net" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 14 Dec 2012 18:42:45 -0000 > On Fri, Dec 14, 2012 at 12:11 PM, Chris H wrote: > >> > Greetings, >> > I attempted another BSD install on another piece of hardware the >> > other day. I'm evaluating a different ISP, and the gateway/router/modem >> > they provided, has 1 ether, which I currently use on my server, and 1 >> > USB(3) port that I had intended to use with the new install. Problem I >> > ran into, was that BSD generates random (fake) MAC(3) addresses, when >> > utilizing the CDCE(4)/ue0. This worked just fine during the install. >> > But the modem "held" the MAC(3) generated during the install, and I >> > now have no idea how to tell BSD to use that MAC(3) when negotiating >> > with the modem. I had absolutely no difficulty assigning the MAC(3) >> > address when spinning up several "live" Linux distro(s) -- they provide >> > the following: >> > su >> > password: *** >> > ifconfig eth1 down >> > ifconfig eth0 hw ether ##:##:##:##:##:## >> > dhclient eth0 >> > blah, blah, blah >> EDIT >> those _should_ have all read "eth1" in the session quoted above. >> Sorry. >> > >> > And I'm connected. >> > Couldn't manage that with BSD. What must I do? Is it even possible? >> > If so, can it be assigned for use on a permanent basis? >> > >> > Thank you for all your time, and consideration. >> >> > http://lmgtfy.com/?q=freebsd+change+mac+address Well that was fairly insulting. :( > > -- > Adam Vande More > _______________________________________________ > 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 Dec 14 22:46:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 945B1697 for ; Fri, 14 Dec 2012 22:46:43 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7A58FC18 for ; Fri, 14 Dec 2012 22:46:42 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBEMkcwC021834 for ; Fri, 14 Dec 2012 14:46:44 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBEMkXpa021828; Fri, 14 Dec 2012 14:46:33 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 14:46:33 -0800 (PST) Message-ID: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> In-Reply-To: References: Date: Fri, 14 Dec 2012 14:46:33 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "freebsd-net" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 14 Dec 2012 22:46:43 -0000 > On Fri, Dec 14, 2012 at 12:11 PM, Chris H wrote: > >> > Greetings, >> > I attempted another BSD install on another piece of hardware the >> > other day. I'm evaluating a different ISP, and the gateway/router/modem >> > they provided, has 1 ether, which I currently use on my server, and 1 >> > USB(3) port that I had intended to use with the new install. Problem I >> > ran into, was that BSD generates random (fake) MAC(3) addresses, when >> > utilizing the CDCE(4)/ue0. This worked just fine during the install. >> > But the modem "held" the MAC(3) generated during the install, and I >> > now have no idea how to tell BSD to use that MAC(3) when negotiating >> > with the modem. I had absolutely no difficulty assigning the MAC(3) >> > address when spinning up several "live" Linux distro(s) -- they provide >> > the following: >> > su >> > password: *** >> > ifconfig eth1 down >> > ifconfig eth0 hw ether ##:##:##:##:##:## >> > dhclient eth0 >> > blah, blah, blah >> EDIT >> those _should_ have all read "eth1" in the session quoted above. >> Sorry. >> > >> > And I'm connected. >> > Couldn't manage that with BSD. What must I do? Is it even possible? >> > If so, can it be assigned for use on a permanent basis? >> > >> > Thank you for all your time, and consideration. >> >> > http://lmgtfy.com/?q=freebsd+change+mac+address Further internet searches provided useless, incorrect information. So, just for kicks, I spun up, and installed a copy PC-BSD-9. The LXDE desktop provided a network applet that allowed to use the hardware MAC(3), or one of my choosing. I chose my own. But even that failed. So I attempted to use: # ifconfig ue0 ether ##:##:##:##:##:## # ifconfig ue0 ether ##:##:##:##:##:## # dhclient ue0 blah, blah, blah # ping yahoo.com 64 bytes from 98.138.253.109: icmp_seq=0 ttl=53 time=48.867 ms 64 bytes from 98.138.253.109: icmp_seq=1 ttl=53 time=51.118 ms 64 bytes from 98.138.253.109: icmp_seq=2 ttl=53 time=80.145 ms 64 bytes from 98.138.253.109: icmp_seq=3 ttl=53 time=48.964 ms OK. So it is possible with BSD. Let's try to make it permanent! adding any of the following attempts failed miserably: ifconfig_ue0="ether ##:##:##:##:##:## DHCP" ifconfig_ue0="DHCP" ifconfig_ue0_alias0="ether ##:##:##:##:##:##" So apparently it's not possible (for me) to accomplish this with anything but Linux. Bummer, have used BSD exclusively since the early 80's. Couldn't imagine having to use anything else. :( > > -- > Adam Vande More > _______________________________________________ > 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 Dec 14 22:51:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EC13B22 for ; Fri, 14 Dec 2012 22:51:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id F2C788FC12 for ; Fri, 14 Dec 2012 22:51:28 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so810321wib.13 for ; Fri, 14 Dec 2012 14:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=o6Dy8j/qq8zRon1q70c5Zr9rsnpkksGyPzt8cAT1YHw=; b=udJI6H0K1bcjnaegYhK4+m1CIqrHvJgvxDfwl5sJnL9kcdB6FgxpN4wjMGoAV6xf1o 8wbC+evgD4UlOYD2ZlHxpnY9gjLvnEi3tGxtsG0JKmKL/b2/B8m//B1Rz11+CH2MCuLk 3DtJdIrHuypbpYdaKQIk1GILejxA5I98rZFCn4cJnJ8CtCC0oCnk9VVGjfDFrdUofVF6 fXjYlO/94ECNWaNZmzCD3pLgLodCNNXGMar19UAEXeurw3sOEow+PvMwxoQ7eH/WfH8D vEokGvEwCz3A/nTb297I5CoWDAsGORJhyLotpXlcLBg7rz/60ZxklYdMcltoAVQmxdxH re0w== X-Received: by 10.180.87.39 with SMTP id u7mr5044804wiz.6.1355525487660; Fri, 14 Dec 2012 14:51:27 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id d9sm4684657wiw.0.2012.12.14.14.51.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 14:51:26 -0800 (PST) Date: Fri, 14 Dec 2012 23:51:16 +0100 From: Mateusz Guzik To: Chris H Subject: Re: MAC cloning available like Linux has? Message-ID: <20121214225116.GA25128@dft-labs.eu> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 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, 14 Dec 2012 22:51:29 -0000 On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote: > > On Fri, Dec 14, 2012 at 12:11 PM, Chris H wrote: > > > >> > Greetings, > >> > I attempted another BSD install on another piece of hardware the > >> > other day. I'm evaluating a different ISP, and the gateway/router/modem > >> > they provided, has 1 ether, which I currently use on my server, and 1 > >> > USB(3) port that I had intended to use with the new install. Problem I > >> > ran into, was that BSD generates random (fake) MAC(3) addresses, when > >> > utilizing the CDCE(4)/ue0. This worked just fine during the install. > >> > But the modem "held" the MAC(3) generated during the install, and I > >> > now have no idea how to tell BSD to use that MAC(3) when negotiating > >> > with the modem. I had absolutely no difficulty assigning the MAC(3) > >> > address when spinning up several "live" Linux distro(s) -- they provide > >> > the following: > >> > su > >> > password: *** > >> > ifconfig eth1 down > >> > ifconfig eth0 hw ether ##:##:##:##:##:## > >> > dhclient eth0 > >> > blah, blah, blah > >> EDIT > >> those _should_ have all read "eth1" in the session quoted above. > >> Sorry. > >> > > >> > And I'm connected. > >> > Couldn't manage that with BSD. What must I do? Is it even possible? > >> > If so, can it be assigned for use on a permanent basis? > >> > > >> > Thank you for all your time, and consideration. > >> > >> > > http://lmgtfy.com/?q=freebsd+change+mac+address > > Further internet searches provided useless, incorrect information. > So, just for kicks, I spun up, and installed a copy PC-BSD-9. > The LXDE desktop provided a network applet that allowed to use > the hardware MAC(3), or one of my choosing. I chose my own. > But even that failed. So I attempted to use: > > # ifconfig ue0 ether ##:##:##:##:##:## > # ifconfig ue0 > ether ##:##:##:##:##:## > # dhclient ue0 > blah, blah, blah > # ping yahoo.com > 64 bytes from 98.138.253.109: icmp_seq=0 ttl=53 time=48.867 ms > 64 bytes from 98.138.253.109: icmp_seq=1 ttl=53 time=51.118 ms > 64 bytes from 98.138.253.109: icmp_seq=2 ttl=53 time=80.145 ms > 64 bytes from 98.138.253.109: icmp_seq=3 ttl=53 time=48.964 ms > > OK. So it is possible with BSD. Let's try to make it permanent! > adding any of the following attempts failed miserably: > ifconfig_ue0="ether ##:##:##:##:##:## DHCP" > > ifconfig_ue0="DHCP" > ifconfig_ue0_alias0="ether ##:##:##:##:##:##" > > So apparently it's not possible (for me) to accomplish this > with anything but Linux. Bummer, have used BSD exclusively > since the early 80's. Couldn't imagine having to use anything > else. :( > > ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" -- Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 23:02:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0B11CDE for ; Fri, 14 Dec 2012 23:02:24 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8C08FC0C for ; Fri, 14 Dec 2012 23:02:23 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so3244566lbb.13 for ; Fri, 14 Dec 2012 15:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m/G5lFrR82C+eJPyJCqQTkDAO2zC8EmVQ8r3qdf14Lk=; b=FHjLAhDXKJYVaEW7Z3ey9czEijw6f2xU1g9vXcjLey/Bl7SaWXHgxH3PUF9eWJ3q5q e5WsVZ31tSa3RIGpoXgO2rE+WaOUo+eMBRVxBVCRgecCFXsAgT84foCVHgD488nZZ2f7 6DlJy00IzbDS/0AJIie8OBPXQtJQ/xdlr28pCYaIqVa7X739ByhPYgD6fj/NWNg3IiFw 7c7VZd4x/zxzUFhslEg0+pJ6N2QM2uQqboUP3RRxyTxaYDCIWZHYIuzQFLCqeWDPaDTA RRV4Mt/nlEPtjshzlhIdWIlB4PEq2IEgRPxcnkTVy2wcPrSZk4+BPB/qMoUikTBkVawM VKgw== MIME-Version: 1.0 Received: by 10.152.125.237 with SMTP id mt13mr4008378lab.45.1355526142890; Fri, 14 Dec 2012 15:02:22 -0800 (PST) Received: by 10.114.81.40 with HTTP; Fri, 14 Dec 2012 15:02:22 -0800 (PST) In-Reply-To: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> Date: Fri, 14 Dec 2012 15:02:22 -0800 Message-ID: Subject: Re: MAC cloning available like Linux has? From: Freddie Cash To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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, 14 Dec 2012 23:02:24 -0000 On Fri, Dec 14, 2012 at 2:46 PM, Chris H wrote: > ifconfig_ue0="DHCP" > ifconfig_ue0_alias0="ether ##:##:##:##:##:##" > > So apparently it's not possible (for me) to accomplish this > with anything but Linux. Bummer, have used BSD exclusively > since the early 80's. Couldn't imagine having to use anything > else. :( > You're just not trying hard enough, or thinking logically enough. ;) ifconfig then dhclient works. Yet you configure rc.conf to do dhclient then ifconfig. :) Reverse your rc.conf entries to match what you did at the command prompt: ifconfig_ue0="ether blah blah blah" ifconfig_ue0_alias0="DHCP" -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 23:04:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6037ED95; Fri, 14 Dec 2012 23:04:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 21A928FC0C; Fri, 14 Dec 2012 23:04:18 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id C3DCE23F763; Fri, 14 Dec 2012 18:04:16 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us C3DCE23F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Fri, 14 Dec 2012 18:04:14 -0500 From: Glen Barber To: Chris H Subject: Re: MAC cloning available like Linux has? Message-ID: <20121214230414.GF1959@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7mxbaLlpDEyR1+x6" Content-Disposition: inline In-Reply-To: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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, 14 Dec 2012 23:04:18 -0000 --7mxbaLlpDEyR1+x6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote: > OK. So it is possible with BSD. Let's try to make it permanent! > adding any of the following attempts failed miserably: > ifconfig_ue0=3D"ether ##:##:##:##:##:## DHCP" >=20 > ifconfig_ue0=3D"DHCP" > ifconfig_ue0_alias0=3D"ether ##:##:##:##:##:##" >=20 Try this: ifconfig_ue0=3D"DHCP" create_args_ue0=3D"ether ##:##:##:##:##:##" Glen --7mxbaLlpDEyR1+x6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQy7BuAAoJEFJPDDeguUajrK4H/3bDAchcxfNMFKmOctJmvK8b mW+ltqNXQX28bt6OMFH86A7gYwdvlDUC4u35ul9ZN2q/QrqayoihVLgeNfFKG2a/ jfW6smb+03ZZxa4Z5UAmukx+H1dLJTmBtJT7XUmDqncsk0ePl4tMvh1vLvMrgJdG 9U1YJZ5kuFrxHr3J7C54OnkGxjvQgcF1TdpjmZOFVn4+kwOX22cOnzkEs3H4XRHr yerhWEGYyEPyRP67+zwEEBwBpQbK6ArCzNwv5n4Dyckg0orf/5y8aljGomYOqfYW 8DDsP7LRbllLa0ybwAJjqpR7TF6h5Uh9AZePCwfwUCgUYDh4IYndlhUG1Q/iNlo= =JZle -----END PGP SIGNATURE----- --7mxbaLlpDEyR1+x6-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 23:47:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 355AB849 for ; Fri, 14 Dec 2012 23:47:48 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id EFA848FC13 for ; Fri, 14 Dec 2012 23:47:47 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBENlh7F022881; Fri, 14 Dec 2012 15:47:49 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBENlcX4022878; Fri, 14 Dec 2012 15:47:38 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 15:47:38 -0800 (PST) Message-ID: <636512a271832085a0bd5b44fe32f2a9.authenticated@ultimatedns.net> In-Reply-To: <20121214225116.GA25128@dft-labs.eu> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214225116.GA25128@dft-labs.eu> Date: Fri, 14 Dec 2012 15:47:38 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Mateusz Guzik" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 14 Dec 2012 23:47:48 -0000 Greetings, and thank you for taking the time to respond... > On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote: >> > On Fri, Dec 14, 2012 at 12:11 PM, Chris H wrote: >> > >> >> > Greetings, >> >> > I attempted another BSD install on another piece of hardware the >> >> > other day. I'm evaluating a different ISP, and the gateway/router/modem >> >> > they provided, has 1 ether, which I currently use on my server, and 1 >> >> > USB(3) port that I had intended to use with the new install. Problem I >> >> > ran into, was that BSD generates random (fake) MAC(3) addresses, when >> >> > utilizing the CDCE(4)/ue0. This worked just fine during the install. >> >> > But the modem "held" the MAC(3) generated during the install, and I >> >> > now have no idea how to tell BSD to use that MAC(3) when negotiating >> >> > with the modem. I had absolutely no difficulty assigning the MAC(3) >> >> > address when spinning up several "live" Linux distro(s) -- they provide >> >> > the following: >> >> > su >> >> > password: *** >> >> > ifconfig eth1 down >> >> > ifconfig eth0 hw ether ##:##:##:##:##:## >> >> > dhclient eth0 >> >> > blah, blah, blah >> >> EDIT >> >> those _should_ have all read "eth1" in the session quoted above. >> >> Sorry. >> >> > >> >> > And I'm connected. >> >> > Couldn't manage that with BSD. What must I do? Is it even possible? >> >> > If so, can it be assigned for use on a permanent basis? >> >> > >> >> > Thank you for all your time, and consideration. >> >> >> >> >> > http://lmgtfy.com/?q=freebsd+change+mac+address >> >> Further internet searches provided useless, incorrect information. >> So, just for kicks, I spun up, and installed a copy PC-BSD-9. >> The LXDE desktop provided a network applet that allowed to use >> the hardware MAC(3), or one of my choosing. I chose my own. >> But even that failed. So I attempted to use: >> >> # ifconfig ue0 ether ##:##:##:##:##:## >> # ifconfig ue0 >> ether ##:##:##:##:##:## >> # dhclient ue0 >> blah, blah, blah >> # ping yahoo.com >> 64 bytes from 98.138.253.109: icmp_seq=0 ttl=53 time=48.867 ms >> 64 bytes from 98.138.253.109: icmp_seq=1 ttl=53 time=51.118 ms >> 64 bytes from 98.138.253.109: icmp_seq=2 ttl=53 time=80.145 ms >> 64 bytes from 98.138.253.109: icmp_seq=3 ttl=53 time=48.964 ms >> >> OK. So it is possible with BSD. Let's try to make it permanent! >> adding any of the following attempts failed miserably: >> ifconfig_ue0="ether ##:##:##:##:##:## DHCP" >> >> ifconfig_ue0="DHCP" >> ifconfig_ue0_alias0="ether ##:##:##:##:##:##" >> >> So apparently it's not possible (for me) to accomplish this >> with anything but Linux. Bummer, have used BSD exclusively >> since the early 80's. Couldn't imagine having to use anything >> else. :( >> >> > > ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" BRILLIANT! If _only_ I had not overlooked that semicolon. :/ Thank you Mateusz Guzik! Greatly appreciated. > > -- > Mateusz Guzik > From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 23:50:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F31518F9 for ; Fri, 14 Dec 2012 23:50:43 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id BAC608FC0A for ; Fri, 14 Dec 2012 23:50:43 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBENoeKu022936; Fri, 14 Dec 2012 15:50:46 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBENoY5L022930; Fri, 14 Dec 2012 15:50:34 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 15:50:35 -0800 (PST) Message-ID: In-Reply-To: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> Date: Fri, 14 Dec 2012 15:50:35 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Freddie Cash" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 14 Dec 2012 23:50:44 -0000 > On Fri, Dec 14, 2012 at 2:46 PM, Chris H wrote: > >> ifconfig_ue0="DHCP" >> ifconfig_ue0_alias0="ether ##:##:##:##:##:##" >> >> So apparently it's not possible (for me) to accomplish this >> with anything but Linux. Bummer, have used BSD exclusively >> since the early 80's. Couldn't imagine having to use anything >> else. :( >> > > You're just not trying hard enough, or thinking logically enough. ;) Or _too_ hard -- making it harder than it really is. ;) > > ifconfig then dhclient works. Yet you configure rc.conf to do dhclient > then ifconfig. :) D'OH! > > Reverse your rc.conf entries to match what you did at the command prompt: > > ifconfig_ue0="ether blah blah blah" > ifconfig_ue0_alias0="DHCP" Thanks/1 That will _clearly_ work. Thanks for Freddie, for taking the time to respond. > > -- > Freddie Cash > fjwcash@gmail.com > From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 23:52:27 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3048D9A4; Fri, 14 Dec 2012 23:52:27 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id EB48C8FC0C; Fri, 14 Dec 2012 23:52:26 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBENqNJ8022991; Fri, 14 Dec 2012 15:52:29 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBENqIS1022988; Fri, 14 Dec 2012 15:52:18 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 15:52:18 -0800 (PST) Message-ID: In-Reply-To: <20121214230414.GF1959@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> Date: Fri, 14 Dec 2012 15:52:18 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Glen Barber" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 14 Dec 2012 23:52:27 -0000 > On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote: >> OK. So it is possible with BSD. Let's try to make it permanent! >> adding any of the following attempts failed miserably: >> ifconfig_ue0="ether ##:##:##:##:##:## DHCP" >> >> ifconfig_ue0="DHCP" >> ifconfig_ue0_alias0="ether ##:##:##:##:##:##" >> > > Try this: > > ifconfig_ue0="DHCP" > create_args_ue0="ether ##:##:##:##:##:##" Excellent! I had never heard/seen the _args_ option for NIC's before. Thank you! --Chris > > Glen > > From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 02:58:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 047A617B; Sat, 15 Dec 2012 02:58:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A9C1B8FC16; Sat, 15 Dec 2012 02:58:15 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so4072702obc.13 for ; Fri, 14 Dec 2012 18:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=bpao4GkdnNftxJLx0fQ93eUa1Se75pVjABGOYcuICPA=; b=pxoizyyB0cjtrZlaIbx5yUH3Qg3qwEPvlT7Nzu4CWiP1gGud0qZZJKUI7liZ2ZD0sF APO7RzQ05sgkoZgeeMoT9sTl3Og1S0Uve8UGkB+BTQ/iDC8d6QfR03EL6ka8UwYrMjqd vHboYIcbrPqOO3J5rDienrfVBDY8Ecq4N08uE64ZDAJFhcKMBJ10fw+kA6Xf0tU57UTU hIBrIq+bNPx/3aDY+aMM01ac4sidG9YrBn9BuTm/RtB3euIPSUhsB4ptG4VVkY2bRzpl YyDIE11+a1Ht0MIQwlDQspjzcf0XgGSXTVlQqAZrjmCejRRemCcEa5G7wD2zEHgpmwgf FveA== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr6309049obc.83.1355540294941; Fri, 14 Dec 2012 18:58:14 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 14 Dec 2012 18:58:14 -0800 (PST) Date: Fri, 14 Dec 2012 18:58:14 -0800 Message-ID: Subject: LOR with ixgbe+lagg and panic with ixgbe related to an uninitialized stack variable From: Garrett Cooper To: Jack F Vogel Content-Type: text/plain; charset=ISO-8859-1 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, 15 Dec 2012 02:58:16 -0000 Hi, Seeing the following LOR on CURRENT when scping files over two L3 lagged ixgbe interfaces: lock order reversal: 1st 0xfffffe000d15a118 ix0:rx(1) (ix0:rx(1)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4353 2nd 0xfffffe01334ada08 if_lagg rwlock (if_lagg rwlock) @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1276 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fc5740 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fc57f0 witness_checkorder() at witness_checkorder+0xc00/frame 0xffffff8496fc5880 __rw_rlock() at __rw_rlock+0x98/frame 0xffffff8496fc5920 lagg_input() at lagg_input+0x38/frame 0xffffff8496fc5960 ether_nh_input() at ether_nh_input+0x171/frame 0xffffff8496fc5990 netisr_dispatch_src() at netisr_dispatch_src+0x90/frame 0xffffff8496fc5a00 tcp_lro_flush() at tcp_lro_flush+0x197/frame 0xffffff8496fc5a20 ixgbe_rxeof() at ixgbe_rxeof+0x5f2/frame 0xffffff8496fc5ad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff8496fc5b20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8496fc5b60 ithread_loop() at ithread_loop+0x161/frame 0xffffff8496fc5bb0 fork_exit() at fork_exit+0x84/frame 0xffffff8496fc5bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496fc5bf0 --- trap 0, rip = 0, rsp = 0xffffff8496fc5cb0, rbp = 0 --- lock order reversal: 1st 0xfffffe000d15a118 ix0:rx(1) (ix0:rx(1)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4353 2nd 0xfffffe0133003da8 tcpinp (tcpinp) @ /usr/src/sys/netinet/in_pcb.c:1785 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fc5570 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fc5620 witness_checkorder() at witness_checkorder+0xc00/frame 0xffffff8496fc56b0 _rw_wlock_cookie() at _rw_wlock_cookie+0x63/frame 0xffffff8496fc56f0 in_pcblookup_hash() at in_pcblookup_hash+0xba/frame 0xffffff8496fc5740 tcp_input() at tcp_input+0x60e/frame 0xffffff8496fc5870 ip_input() at ip_input+0xb2/frame 0xffffff8496fc58c0 netisr_dispatch_src() at netisr_dispatch_src+0x90/frame 0xffffff8496fc5930 ether_demux() at ether_demux+0x143/frame 0xffffff8496fc5960 ether_nh_input() at ether_nh_input+0x325/frame 0xffffff8496fc5990 netisr_dispatch_src() at netisr_dispatch_src+0x90/frame 0xffffff8496fc5a00 tcp_lro_flush() at tcp_lro_flush+0x197/frame 0xffffff8496fc5a20 ixgbe_rxeof() at ixgbe_rxeof+0x5f2/frame 0xffffff8496fc5ad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff8496fc5b20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8496fc5b60 ithread_loop() at ithread_loop+0x161/frame 0xffffff8496fc5bb0 fork_exit() at fork_exit+0x84/frame 0xffffff8496fc5bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496fc5bf0 --- trap 0, rip = 0, rsp = 0xffffff8496fc5cb0, rbp = 0 --- # uname -a FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r+5a05236: Wed Dec 12 17:35:14 PST 2012 root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 I ran into a panic under similar conditions with a slightly older kernel (12/05): Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ix1:rx(0) (ix1:rx(0)) r = 0 (0xfffffe000d14e808) locked @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4353 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff849702d530 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff849702d5e0 witness_warn() at witness_warn+0x4a3/frame 0xffffff849702d6a0 trap_pfault() at trap_pfault+0x5a/frame 0xffffff849702d750 trap() at trap+0x659/frame 0xffffff849702d960 calltrap() at calltrap+0x8/frame 0xffffff849702d960 --- trap 0xc, rip = 0xffffffff8185a82f, rsp = 0xffffff849702da20, rbp = 0xffffff849702dad0 --- ixgbe_rxeof() at ixgbe_rxeof+0x20f/frame 0xffffff849702dad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff849702db20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff849702db60 ithread_loop() at ithread_loop+0x161/frame 0xffffff849702dbb0 fork_exit() at fork_exit+0x84/frame 0xffffff849702dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff849702dbf0 --- trap 0, rip = 0, rsp = 0xffffff849702dcb0, rbp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8185a82f stack pointer = 0x28:0xffffff849702da20 frame pointer = 0x28:0xffffff849702dad0 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 db> x/s version version: FreeBSD 10.0-CURRENT #3 r+5a05236: Wed Dec 12 17:35:14 PST 2012\012 root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC\012 db> show alllocks Process 1052 (syslogd) thread 0xfffffe000adfe000 (100180) exclusive lockmgr bufwait (bufwait) r = 0 (0xffffff8454152ba0) locked @ /usr/src/sys/kern/vfs_bio.c:2633 exclusive lockmgr ufs (ufs) r = 0 (0xfffffe015d0e9668) locked @ /usr/src/sys/kern/vfs_syscalls.c:3438 Process 12 (intr) thread 0xfffffe000adcf900 (100208) exclusive sleep mutex ix1:rx(0) (ix1:rx(0)) r = 0 (0xfffffe000d14e808) locked @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4353 I don't have much to go off of for the panic, but I figured I should just post these "in case" these are potentially known issues, or if they aren't known, potential items to watch for. Thoughts? -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 07:26:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1827F4A for ; Sat, 15 Dec 2012 07:26:19 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id BCCD98FC0C for ; Sat, 15 Dec 2012 07:26:19 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBF7QB0h003607 for ; Fri, 14 Dec 2012 23:26:18 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBF7Q6bU003604; Fri, 14 Dec 2012 23:26:06 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 14 Dec 2012 23:26:06 -0800 (PST) Message-ID: <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> In-Reply-To: <20121214230414.GF1959@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> Date: Fri, 14 Dec 2012 23:26:06 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "freebsd-net" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 15 Dec 2012 07:26:20 -0000 > On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote: >> OK. So it is possible with BSD. Let's try to make it permanent! >> adding any of the following attempts failed miserably: >> ifconfig_ue0="ether ##:##:##:##:##:## DHCP" >> >> ifconfig_ue0="DHCP" >> ifconfig_ue0_alias0="ether ##:##:##:##:##:##" >> Well, dfeeling "armed, and dangerous" with the new knowledge gained from Mateusz Guzik, Freddie Cash, and Glen Barber, I downloaded CD1 of RELENG_9, and installed it. I attempted to use the suggestions previously provided. However, they were either rejected, or quietly ignored. :( with: ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" the ether isn't honored (ignored) ifconfig_ue0="ether blah blah blah" ifconfig_ue0_alias0="DHCP" throws an error (but spins by too fast to catch) /var/log/messages would probably reveal it. ifconfig_ue0="DHCP" create_args_ue0="ether ##:##:##:##:##:##" create_args is simply ignored. I don't get it. I've tried every imaginable incarnation I could possibly conceive. Is it even possible? I had really hoped to turn this into a gateway, and while Linux will "clone" the MAC(3). I don't trust it (security wise). Is Linux' DHCP more robust than BSD'?! Hard to imagine, but I'm completely at a loss. --Chris From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 11:53:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CD2459B; Sat, 15 Dec 2012 11:53:47 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id DB66D8FC16; Sat, 15 Dec 2012 11:53:46 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 7560023F763; Sat, 15 Dec 2012 06:53:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us 7560023F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Sat, 15 Dec 2012 06:53:43 -0500 From: Glen Barber To: Chris H Subject: Re: MAC cloning available like Linux has? Message-ID: <20121215115343.GC1342@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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, 15 Dec 2012 11:53:47 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: > ifconfig_ue0=3D"DHCP" > create_args_ue0=3D"ether ##:##:##:##:##:##" > create_args is simply ignored. >=20 Ignored how? What commands are you running to verify it works? For me, create_args_IFNAME works fine on my firewall. > I don't get it. I've tried every imaginable incarnation I > could possibly conceive. Is it even possible? I had really > hoped to turn this into a gateway, and while Linux will > "clone" the MAC(3). I don't trust it (security wise). > Is Linux' DHCP more robust than BSD'?! Hard to imagine, > but I'm completely at a loss. >=20 I do not think this is DHCP related. It is more differentiation between the two with regards to how interface creation is handled. Glen --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQzGTHAAoJEFJPDDeguUajIQ8IAJZ9yP/2J7gSJJrHS5vwzRAX j6H76bDOxKmumbv2sUPF8COIptmGMahOwZCoeX9fG4geFqTS5Evm5UVn3Wnyj0Ip qUaKQLBP6nUH3lswTky7+qLdYJnKlnf/phacZ6YZCGrJrJS70WTIDuclRX3N/gQP ewnG3R91nStewX4xgaqxIBGF9btJAsN7XfEyuGgomDtdoW8Jy+Es7Ux0Pdn+PGP+ Q6nD66FediJu/Tf38lb77Dv/G3GXDyRY3PPyeL0d+XeIONYGRfccewpEQg+ZmYfl 5HfPF/gdIr3FJ/w4+7AavrSjxg5uVGOTfUi6syaXh7JexCOHjZrubEDxk47jBpA= =njJj -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 16:10:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1E37CE2 for ; Sat, 15 Dec 2012 16:10:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 8553E8FC0A for ; Sat, 15 Dec 2012 16:10:56 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qBFGAbKD092155; Sat, 15 Dec 2012 09:10:37 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qBFGAbDZ092152; Sat, 15 Dec 2012 09:10:37 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 15 Dec 2012 09:10:37 -0700 (MST) From: Warren Block To: Chris H Subject: Re: MAC cloning available like Linux has? In-Reply-To: <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> Message-ID: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 15 Dec 2012 09:10:37 -0700 (MST) Cc: 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, 15 Dec 2012 16:10:56 -0000 On Fri, 14 Dec 2012, Chris H wrote: > with: ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" > the ether isn't honored (ignored) Remove the semicolon. I don't know if the order of parameters there matters, but think that the rc scripts just look for the presence of DHCP. This just worked in a VM here. From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 18:11:58 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30F37790; Sat, 15 Dec 2012 18:11:58 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id D53968FC12; Sat, 15 Dec 2012 18:11:57 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFIBl7l016737; Sat, 15 Dec 2012 10:11:53 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFIBfWi016733; Sat, 15 Dec 2012 10:11:41 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 10:11:41 -0800 (PST) Message-ID: <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> In-Reply-To: <20121215115343.GC1342@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> Date: Sat, 15 Dec 2012 10:11:41 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Glen Barber" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 15 Dec 2012 18:11:58 -0000 Hello Glen, and thank you for your reply. > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >> ifconfig_ue0="DHCP" >> create_args_ue0="ether ##:##:##:##:##:##" >> create_args is simply ignored. >> > > Ignored how? What commands are you running to verify it works? > For me, create_args_IFNAME works fine on my firewall. Unfortunately, it had no affect for me. The ue0 maintained the same MAC it started with. Out of desperation, I even tried it in /boot/loader.conf. One thing I think might be worth noting; I see bge appears to interrupt the process, as it attaches to ue0. I don't have the RELENG_9 drive plugged in, as I write this, or I could paste the message here. Is it possible this is more an RC(8) problem, than anything else? I notice since 8.2, the RC(8) seems to have some differences. For example; it used to be possible to declare: ifconfig__alias#="ether ##:##:##:##:##:##" But when I attempt to try this now, I receive an error indicating something about requiring an ""inet" when using ipv4". but adding an inet 1p,v.4.address stanza to it, causes an error as well. > >> I don't get it. I've tried every imaginable incarnation I >> could possibly conceive. Is it even possible? I had really >> hoped to turn this into a gateway, and while Linux will >> "clone" the MAC(3). I don't trust it (security wise). >> Is Linux' DHCP more robust than BSD'?! Hard to imagine, >> but I'm completely at a loss. >> > > I do not think this is DHCP related. It is more differentiation between > the two with regards to how interface creation is handled. Agreed. > > Glen > > Thank you again, for taking the time to reply. --Chris From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 18:19:33 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CBFAD12; Sat, 15 Dec 2012 18:19:33 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id BF9438FC0C; Sat, 15 Dec 2012 18:19:32 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id B946223F763; Sat, 15 Dec 2012 13:19:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us B946223F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Sat, 15 Dec 2012 13:19:28 -0500 From: Glen Barber To: Chris H Subject: Re: MAC cloning available like Linux has? Message-ID: <20121215181928.GC1344@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RIYY1s2vRbPFwWeW" Content-Disposition: inline In-Reply-To: <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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, 15 Dec 2012 18:19:33 -0000 --RIYY1s2vRbPFwWeW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: > Hello Glen, and thank you for your reply. > > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: > >> ifconfig_ue0=3D"DHCP" > >> create_args_ue0=3D"ether ##:##:##:##:##:##" > >> create_args is simply ignored. > >> > > > > Ignored how? What commands are you running to verify it works? > > For me, create_args_IFNAME works fine on my firewall. >=20 > Unfortunately, it had no affect for me. > The ue0 maintained the same MAC it started with. > Out of desperation, I even tried it in /boot/loader.conf. It is not a loader(8) tunable, it is part of the rc(8) system. You did not answer the important part of what I asked - how are you testing? Are you rebooting the machine? Are you using the netif rc script? Glen --RIYY1s2vRbPFwWeW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQzL8wAAoJEFJPDDeguUajikgH/2QY7qBKIcnK+mcCgamHNLRo heujsMJGXlp2WDhdffgM3hBYw5hnZZNKzpYoHgqArxVzakKrO1zTT10Sl9q4jMSV j+R7C8IC5EsqeKKMTeVrzyPJa3KhwzhT2J7lnoeW+dZYaj4xLdsLAoMaUMhKmVzb M9S9CKd5KIGMxMXYjqLvdFXnGg14rhahvkjLXSXEVd7HUxJH5kzfHGxntgcUIUeG ztNGDLlrsj8F+BaE864QTavMF+S9dSNzAdTBAd8cPwagIyqfIod9blujQBOcbLId BGTqAYRhEjyCVhQrY6YG1BCLQJ8XibzxJXJMXK7p60p/y+JnZaBHcpnnhrZF8e0= =XnlV -----END PGP SIGNATURE----- --RIYY1s2vRbPFwWeW-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 18:32:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8111E4E7 for ; Sat, 15 Dec 2012 18:32:37 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8E88FC0C for ; Sat, 15 Dec 2012 18:32:36 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFIWVEf017095; Sat, 15 Dec 2012 10:32:37 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFIWQct017089; Sat, 15 Dec 2012 10:32:26 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 10:32:26 -0800 (PST) Message-ID: <7c1f744c7fe2224cf7cc0f07bc4aee76.authenticated@ultimatedns.net> In-Reply-To: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 10:32:26 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Warren Block" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 15 Dec 2012 18:32:37 -0000 Greetings Warren, and thank you for your reply. > On Fri, 14 Dec 2012, Chris H wrote: > >> with: ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" >> the ether isn't honored (ignored) > > Remove the semicolon. I don't know if the order of parameters there > matters, but think that the rc scripts just look for the presence of > DHCP. > > This just worked in a VM here. > I'm afraid I didn't have the same experience trying that. :( Out of curiosity, what version did you use? I used the CD image of 9.0 I downloaded from freebsd.org yesterday. Thank you again, for taking the time to respond. --Chris From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 18:36:54 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E953F5B7; Sat, 15 Dec 2012 18:36:54 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id AD2818FC0A; Sat, 15 Dec 2012 18:36:54 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFIaogF017172; Sat, 15 Dec 2012 10:36:56 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFIaj7u017166; Sat, 15 Dec 2012 10:36:45 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 10:36:45 -0800 (PST) Message-ID: <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> In-Reply-To: <20121215181928.GC1344@glenbarber.us> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> Date: Sat, 15 Dec 2012 10:36:45 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Glen Barber" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 15 Dec 2012 18:36:55 -0000 > On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >> Hello Glen, and thank you for your reply. >> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >> >> ifconfig_ue0="DHCP" >> >> create_args_ue0="ether ##:##:##:##:##:##" >> >> create_args is simply ignored. >> >> >> > >> > Ignored how? What commands are you running to verify it works? >> > For me, create_args_IFNAME works fine on my firewall. >> >> Unfortunately, it had no affect for me. >> The ue0 maintained the same MAC it started with. >> Out of desperation, I even tried it in /boot/loader.conf. > > It is not a loader(8) tunable, it is part of the rc(8) system. > > You did not answer the important part of what I asked - how are you > testing? Are you rebooting the machine? Are you using the netif rc > script? Ahh. Sorry, my bad. Rebooting. I have no difficulty issuing: ifconfig ue0 down ifconfig ue0 ether ##:##:##:##:##:## dhclient ue0 This method will always return the expected/desired results. > > Glen > > Thanks for the reply. --Chris From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 19:59:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06704562; Sat, 15 Dec 2012 19:59:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 520BC8FC13; Sat, 15 Dec 2012 19:59:10 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2114541wey.13 for ; Sat, 15 Dec 2012 11:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r43cHpM7sJoTENdPqIi5FVgpC9gK2/ESqTW7ardXSU8=; b=gNI2D1Pb5+Pz+Gps0nCQqhGU2LXCg170LHBuepFdkjb/5QRbgKs/fgqszqMR0ppYB1 y6XKkKFthlCXNqvczZaG1LJqVbbD6nIYRr2bzLKIA20Ih8NepK/bI2AMfaXWu7WGQGRh QlNclKBQcbuHiJirlDduLa2tZ4Idq4Et9fgy77SRbKazw0VOo6QWCTzVjjcaDB9VjXCC e/nzU4iAwvxUn4ol2GqDCVsXho5mdXeGZRu/Iwj4nrVtlBiYYscFx7uo9Q/AouSeAZTn 59ZQr8BV6kqtfxPBKP9BlZcacLHHcWSr8TIUApHkbUW4r5LuMkeKYTzNAoN6W5i8kLdp wvYg== MIME-Version: 1.0 Received: by 10.180.88.71 with SMTP id be7mr8528269wib.17.1355601549882; Sat, 15 Dec 2012 11:59:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 15 Dec 2012 11:59:09 -0800 (PST) In-Reply-To: <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 11:59:09 -0800 X-Google-Sender-Auth: 1wOlbfHRO3MOgCz8_X3bseEX6hw Message-ID: Subject: Re: MAC cloning available like Linux has? From: Adrian Chadd To: Chris H Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , 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, 15 Dec 2012 19:59:12 -0000 Hi, Please file a PR for this. I think this (and mac address setup/changing on net80211, similar issues) needs both some better documentation/FAQ entries and updates to the rc scripts. I think we may want to add an ifconfig_X_ether="" to set the L2 address appropriately for an interface. Thanks, Adrian On 15 December 2012 10:36, Chris H wrote: >> On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >>> Hello Glen, and thank you for your reply. >>> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >>> >> ifconfig_ue0="DHCP" >>> >> create_args_ue0="ether ##:##:##:##:##:##" >>> >> create_args is simply ignored. >>> >> >>> > >>> > Ignored how? What commands are you running to verify it works? >>> > For me, create_args_IFNAME works fine on my firewall. >>> >>> Unfortunately, it had no affect for me. >>> The ue0 maintained the same MAC it started with. >>> Out of desperation, I even tried it in /boot/loader.conf. >> >> It is not a loader(8) tunable, it is part of the rc(8) system. >> >> You did not answer the important part of what I asked - how are you >> testing? Are you rebooting the machine? Are you using the netif rc >> script? > > Ahh. Sorry, my bad. Rebooting. > > I have no difficulty issuing: > ifconfig ue0 down > ifconfig ue0 ether ##:##:##:##:##:## > dhclient ue0 > > This method will always return the expected/desired results. > >> >> Glen >> >> > Thanks for the reply. > > --Chris > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 20:35:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BCC9B34 for ; Sat, 15 Dec 2012 20:35:04 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC308FC1D for ; Sat, 15 Dec 2012 20:35:04 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qBFKYoP4093697; Sat, 15 Dec 2012 13:34:50 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qBFKYo7e093694; Sat, 15 Dec 2012 13:34:50 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 15 Dec 2012 13:34:50 -0700 (MST) From: Warren Block To: Chris H Subject: Re: MAC cloning available like Linux has? In-Reply-To: <7c1f744c7fe2224cf7cc0f07bc4aee76.authenticated@ultimatedns.net> Message-ID: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <7c1f744c7fe2224cf7cc0f07bc4aee76.authenticated@ultimatedns.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 15 Dec 2012 13:34:50 -0700 (MST) Cc: 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, 15 Dec 2012 20:35:04 -0000 On Sat, 15 Dec 2012, Chris H wrote: > Greetings Warren, and thank you for your reply. > >> On Fri, 14 Dec 2012, Chris H wrote: >> >>> with: ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" >>> the ether isn't honored (ignored) >> >> Remove the semicolon. I don't know if the order of parameters there >> matters, but think that the rc scripts just look for the presence of >> DHCP. >> >> This just worked in a VM here. >> > > I'm afraid I didn't have the same experience trying that. :( > Out of curiosity, what version did you use? I used the CD > image of 9.0 I downloaded from freebsd.org yesterday. 9.0-RELEASE. The string I have in rc.conf: ifconfig_le0="ether 80:01:01:01:01:01 DHCP" dhclient runs, and the MAC address is set to that according to ifconfig output. Is it possible that USB Ethernet adapters (or drivers) don't allow changing the MAC address? Seems silly, but... From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 20:51:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D875D50C; Sat, 15 Dec 2012 20:51:21 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id A4C068FC13; Sat, 15 Dec 2012 20:51:21 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFKpGXu019652; Sat, 15 Dec 2012 12:51:22 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFKpBVZ019648; Sat, 15 Dec 2012 12:51:11 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 12:51:11 -0800 (PST) Message-ID: <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> In-Reply-To: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 12:51:11 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Adrian Chadd" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Glen Barber , 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, 15 Dec 2012 20:51:21 -0000 > Hi, > > Please file a PR for this. I think this (and mac address Greetings Adrian, and thank you for your reply. > setup/changing on net80211, similar issues) needs both some better > documentation/FAQ entries and updates to the rc scripts. > > I think we may want to add an ifconfig_X_ether="" to set the L2 > address appropriately for an interface. > > Thanks, > > > > Adrian Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and experimented with installing 8.2. But I think I stumbled onto something. I don't know (yet) if this will carry over to 9.x yet. But here's what I discovered: in rc.conf, adding the following (order is important!), everything works as expected/desired/anticipated; --- begin rc,conf -------------------------------------------------------------- ifconfig_ue0="ether ##:##:##:##:##:##" ifconfig_ue0_alias0="DHCP" *** or *** ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" followed by defaultrouter="kno.wn.gate.way" --applies for static only --- end rc,conf -------------------------------------------------------------- So. It appears this will be the answer. _However_ I can't swear to it until I spin up && install a (fresh) copy of RELENG_9. I'll do so, and report back. Thanks again, for your reply. --Chris > > On 15 December 2012 10:36, Chris H wrote: >>> On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >>>> Hello Glen, and thank you for your reply. >>>> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >>>> >> ifconfig_ue0="DHCP" >>>> >> create_args_ue0="ether ##:##:##:##:##:##" >>>> >> create_args is simply ignored. >>>> >> >>>> > >>>> > Ignored how? What commands are you running to verify it works? >>>> > For me, create_args_IFNAME works fine on my firewall. >>>> >>>> Unfortunately, it had no affect for me. >>>> The ue0 maintained the same MAC it started with. >>>> Out of desperation, I even tried it in /boot/loader.conf. >>> >>> It is not a loader(8) tunable, it is part of the rc(8) system. >>> >>> You did not answer the important part of what I asked - how are you >>> testing? Are you rebooting the machine? Are you using the netif rc >>> script? >> >> Ahh. Sorry, my bad. Rebooting. >> >> I have no difficulty issuing: >> ifconfig ue0 down >> ifconfig ue0 ether ##:##:##:##:##:## >> dhclient ue0 >> >> This method will always return the expected/desired results. >> >>> >>> Glen >>> >>> >> Thanks for the reply. >> >> --Chris >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 20:56:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7067B5F1 for ; Sat, 15 Dec 2012 20:56:33 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2138FC1B for ; Sat, 15 Dec 2012 20:56:32 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFKuSW0019759; Sat, 15 Dec 2012 12:56:34 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFKuN3I019755; Sat, 15 Dec 2012 12:56:23 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 12:56:23 -0800 (PST) Message-ID: <4c9c9af10a32342c5d10cf130df7439b.authenticated@ultimatedns.net> In-Reply-To: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <7c1f744c7fe2224cf7cc0f07bc4aee76.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 12:56:23 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Warren Block" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 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, 15 Dec 2012 20:56:33 -0000 Hello Warren, and thank you for your reply. > On Sat, 15 Dec 2012, Chris H wrote: > >> Greetings Warren, and thank you for your reply. >> >>> On Fri, 14 Dec 2012, Chris H wrote: >>> >>>> with: ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" >>>> the ether isn't honored (ignored) >>> >>> Remove the semicolon. I don't know if the order of parameters there >>> matters, but think that the rc scripts just look for the presence of >>> DHCP. >>> >>> This just worked in a VM here. >>> >> >> I'm afraid I didn't have the same experience trying that. :( >> Out of curiosity, what version did you use? I used the CD >> image of 9.0 I downloaded from freebsd.org yesterday. > > 9.0-RELEASE. The string I have in rc.conf: > > ifconfig_le0="ether 80:01:01:01:01:01 DHCP" > > dhclient runs, and the MAC address is set to that according to ifconfig > output. > > Is it possible that USB Ethernet adapters (or drivers) don't allow > changing the MAC address? Seems silly, but... > Well, as I mentioned in my OP; works perfect in Linux, and also if I apply it manually at a CLI. But was a no-go via RC(8). However, I stumbled onto something that seems to work consistently (see my reply to Adrian's post). Thanks again, for taking the time to respond. --Chris From owner-freebsd-net@FreeBSD.ORG Sat Dec 15 22:12:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50B40E74; Sat, 15 Dec 2012 22:12:08 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF938FC1E; Sat, 15 Dec 2012 22:12:07 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFMC2F7021613; Sat, 15 Dec 2012 14:12:08 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFMBvUB021607; Sat, 15 Dec 2012 14:11:57 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 14:11:57 -0800 (PST) Message-ID: <476652410abd01eff09cf38132ebd0f6.authenticated@ultimatedns.net> In-Reply-To: <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 14:11:57 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Adrian Chadd" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Glen Barber , 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, 15 Dec 2012 22:12:08 -0000 >> Hi, >> >> Please file a PR for this. I think this (and mac address > Greetings Adrian, and thank you for your reply. > >> setup/changing on net80211, similar issues) needs both some better >> documentation/FAQ entries and updates to the rc scripts. >> >> I think we may want to add an ifconfig_X_ether="" to set the L2 >> address appropriately for an interface. >> >> Thanks, >> >> >> >> Adrian > > Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and > experimented with installing 8.2. But I think I stumbled onto > something. I don't know (yet) if this will carry over to 9.x yet. > But here's what I discovered: > > in rc.conf, adding the following (order is important!), everything > works as expected/desired/anticipated; > > --- begin rc,conf -------------------------------------------------------------- > ifconfig_ue0="ether ##:##:##:##:##:##" > > ifconfig_ue0_alias0="DHCP" > > *** or *** > > ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" > > followed by > defaultrouter="kno.wn.gate.way" --applies for static only > --- end rc,conf -------------------------------------------------------------- > > So. It appears this will be the answer. _However_ I can't swear to it > until I spin up && install a (fresh) copy of RELENG_9. > I'll do so, and report back. > > Thanks again, for your reply. > > --Chris OK. The results are in -- Using the RC(8) declarations I listed above work not only in RELENG_8, but also in RELENG_9. I just performed an install from the 9.0 CD I downloaded from freebsd.org on 12-12-14. Everything (both as STATIC, and as DHCP) worked as expected/anticipated. Is this still worth a PR(1)? Best wishes, and thanks again, to everyone that took the time to help! --Chris > > > >> >> On 15 December 2012 10:36, Chris H wrote: >>>> On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >>>>> Hello Glen, and thank you for your reply. >>>>> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >>>>> >> ifconfig_ue0="DHCP" >>>>> >> create_args_ue0="ether ##:##:##:##:##:##" >>>>> >> create_args is simply ignored. >>>>> >> >>>>> > >>>>> > Ignored how? What commands are you running to verify it works? >>>>> > For me, create_args_IFNAME works fine on my firewall. >>>>> >>>>> Unfortunately, it had no affect for me. >>>>> The ue0 maintained the same MAC it started with. >>>>> Out of desperation, I even tried it in /boot/loader.conf. >>>> >>>> It is not a loader(8) tunable, it is part of the rc(8) system. >>>> >>>> You did not answer the important part of what I asked - how are you >>>> testing? Are you rebooting the machine? Are you using the netif rc >>>> script? >>> >>> Ahh. Sorry, my bad. Rebooting. >>> >>> I have no difficulty issuing: >>> ifconfig ue0 down >>> ifconfig ue0 ether ##:##:##:##:##:## >>> dhclient ue0 >>> >>> This method will always return the expected/desired results. >>> >>>> >>>> Glen >>>> >>>> >>> Thanks for the reply. >>> >>> --Chris >>> >>> >>> _______________________________________________ >>> 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 Sat Dec 15 22:13:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA81CF4E for ; Sat, 15 Dec 2012 22:13:36 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id B5A0F8FC12 for ; Sat, 15 Dec 2012 22:13:36 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBFMDWsb021661 for ; Sat, 15 Dec 2012 14:13:38 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBFMDRIv021655; Sat, 15 Dec 2012 14:13:27 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 14:13:27 -0800 (PST) Message-ID: <02ac4c73535fcea9e25b8bd07db0ce02.authenticated@ultimatedns.net> In-Reply-To: <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 14:13:27 -0800 (PST) Subject: Re: MAC cloning available like Linux has? [SOLVED] From: "Chris H" To: "freebsd-net" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 15 Dec 2012 22:13:37 -0000 >> Hi, >> >> Please file a PR for this. I think this (and mac address > Greetings Adrian, and thank you for your reply. > >> setup/changing on net80211, similar issues) needs both some better >> documentation/FAQ entries and updates to the rc scripts. >> >> I think we may want to add an ifconfig_X_ether="" to set the L2 >> address appropriately for an interface. >> >> Thanks, >> >> >> >> Adrian > > Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and > experimented with installing 8.2. But I think I stumbled onto > something. I don't know (yet) if this will carry over to 9.x yet. > But here's what I discovered: > > in rc.conf, adding the following (order is important!), everything > works as expected/desired/anticipated; > > --- begin rc,conf -------------------------------------------------------------- > ifconfig_ue0="ether ##:##:##:##:##:##" > > ifconfig_ue0_alias0="DHCP" > > *** or *** > > ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" > > followed by > defaultrouter="kno.wn.gate.way" --applies for static only > --- end rc,conf -------------------------------------------------------------- > > So. It appears this will be the answer. _However_ I can't swear to it > until I spin up && install a (fresh) copy of RELENG_9. > I'll do so, and report back. > > Thanks again, for your reply. > > --Chris OK. The results are in -- Using the RC(8) declarations I listed above work not only in RELENG_8, but also in RELENG_9. I just performed an install from the 9.0 CD I downloaded from freebsd.org on 12-12-14. Everything (both as STATIC, and as DHCP) worked as expected/anticipated. Is this still worth a PR(1)? Best wishes, and thanks again, to everyone that took the time to help! --Chris > > > >> >> On 15 December 2012 10:36, Chris H wrote: >>>> On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >>>>> Hello Glen, and thank you for your reply. >>>>> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >>>>> >> ifconfig_ue0="DHCP" >>>>> >> create_args_ue0="ether ##:##:##:##:##:##" >>>>> >> create_args is simply ignored. >>>>> >> >>>>> > >>>>> > Ignored how? What commands are you running to verify it works? >>>>> > For me, create_args_IFNAME works fine on my firewall. >>>>> >>>>> Unfortunately, it had no affect for me. >>>>> The ue0 maintained the same MAC it started with. >>>>> Out of desperation, I even tried it in /boot/loader.conf. >>>> >>>> It is not a loader(8) tunable, it is part of the rc(8) system. >>>> >>>> You did not answer the important part of what I asked - how are you >>>> testing? Are you rebooting the machine? Are you using the netif rc >>>> script? >>> >>> Ahh. Sorry, my bad. Rebooting. >>> >>> I have no difficulty issuing: >>> ifconfig ue0 down >>> ifconfig ue0 ether ##:##:##:##:##:## >>> dhclient ue0 >>> >>> This method will always return the expected/desired results. >>> >>>> >>>> Glen >>>> >>>> >>> Thanks for the reply. >>> >>> --Chris >>> >>> >>> _______________________________________________ >>> 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" >