From owner-freebsd-net@FreeBSD.ORG Sun Oct 3 03:02:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15A53106566B; Sun, 3 Oct 2010 03:02:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-17.mx.aerioconnect.net [216.240.47.77]) by mx1.freebsd.org (Postfix) with ESMTP id EC7068FC0A; Sun, 3 Oct 2010 03:02:30 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9332SlH027907; Sat, 2 Oct 2010 20:02:28 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 474632D6012; Sat, 2 Oct 2010 20:02:27 -0700 (PDT) Message-ID: <4CA7F26C.7030408@freebsd.org> Date: Sat, 02 Oct 2010 20:03:08 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <4CA6FF9A.9090502@minibofh.org> <4CA7A103.3050000@freebsd.org> In-Reply-To: <4CA7A103.3050000@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Jordi Espasa Clofent , freebsd-net@freebsd.org Subject: Re: TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 03:02:31 -0000 On 10/2/10 2:15 PM, Andre Oppermann wrote: > On 02.10.2010 11:47, Jordi Espasa Clofent wrote: >> Hi all, >> >> I've read this interesting article: >> http://www.packetstan.com/2010/09/openbsd-timestamps.html >> >> The question is simple >> >> ¿Is there some way in FreeBSD to randomize the TCP timestamps as >> OpenBSD does by default? I guess >> some sysctl statement should do it, but I don't know. > > The timestamps on FreeBSD for passive open are randomized as > long as you use SYN cookies (enabled by default). For passive > open they are not (yet) randomized. which one of those 'passive' is supposed to be 'active'? From owner-freebsd-net@FreeBSD.ORG Sun Oct 3 13:01:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347FA106566C; Sun, 3 Oct 2010 13:01:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0618FC15; Sun, 3 Oct 2010 13:01:35 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5F96A73098; Sun, 3 Oct 2010 15:13:30 +0200 (CEST) Date: Sun, 3 Oct 2010 15:13:30 +0200 From: Luigi Rizzo To: FreeBSD Net , Rui Paulo , Juli Mallett , Ryan Stone , Robert Watson Message-ID: <20101003131330.GA85551@onelab2.iet.unipi.it> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: mbuf changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:01:36 -0000 On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote: > On 2 Oct 2010, at 21:35, Juli Mallett wrote: > > > On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote: > >> On 2 Oct 2010, at 16:29, Robert Watson wrote: > >>> On Thu, 30 Sep 2010, Julian Elischer wrote: > >>>> On 9/30/10 10:49 AM, Ryan Stone wrote: > >>>>> It's not a big thing but it would be nice to replace the m_next and m_nextpkt fields with queue.h macros. > >>>> funny, I've never even thought of that.. > >>> > >>> I have, and it's a massive change touching code all over the kernel in vast quantities. While in principle it's a good idea (consistently avoid hand-crafted linked lists), it's something I'd discourage on the basis that it probably won't significant reduce the kernel bug count, but will make it even harder for vendors with large local changes to the network stack to keep up. > >> > >> I think it could also increase the kernel bug count. Unfortunately, we can't do this incrementally. > > > > Can't we? What about a union, so that we can gradually convert things > > but keep ABI and API compatibility? I mean, as long as we use the > > right queue.h type, anyway, it should be consistent? STAILQ, > > presumably. > > Well, I don't have the layout of the mbuf struct offhand, but it's an idea worth investigating. what is the point of refactoring part of a struct that no new code is touching ? I'd like to keep this discussion on the original topics, i.e. performance-related issues (make room to embed mtags and other metadata such as FIB; have flexible per-socket initial padding so we don't always waste 100+ bytes just because ipv6+ipsec is compiled in; and so on). Please open another thread if you want to propose cosmetics or code refactoring or other unrelated changes Cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Oct 4 01:22:44 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE038106564A for ; Mon, 4 Oct 2010 01:22:44 +0000 (UTC) (envelope-from rperry@madisonip.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 839428FC1A for ; Mon, 4 Oct 2010 01:22:44 +0000 (UTC) Received: by fxm9 with SMTP id 9so3845338fxm.13 for ; Sun, 03 Oct 2010 18:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.56.4 with SMTP id w4mr8035401fag.91.1286153890852; Sun, 03 Oct 2010 17:58:10 -0700 (PDT) Received: by 10.223.120.144 with HTTP; Sun, 3 Oct 2010 17:58:10 -0700 (PDT) Date: Sun, 3 Oct 2010 19:58:10 -0500 Message-ID: From: Ryan Perry To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Rewriting SCTP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 01:22:44 -0000 I have an application that sends SCTP packets, but it does not utilize the multiple IP addresses feature. I would like to "artificially" add this to the sctp packets. What are my options? I was thinking something like pf or something of the sorts... From owner-freebsd-net@FreeBSD.ORG Mon Oct 4 11:07:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92AA11065675 for ; Mon, 4 Oct 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 802E18FC23 for ; Mon, 4 Oct 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o94B71i4065893 for ; Mon, 4 Oct 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o94B70K8065891 for freebsd-net@FreeBSD.org; Mon, 4 Oct 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Oct 2010 11:07:00 GMT Message-Id: <201010041107.o94B70K8065891@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 11:07:01 -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/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150257 net [msk] watchdog timeout o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo 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/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall 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/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using 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/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout 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/143595 net [wpi] [panic] Creating virtual interface over wpi0 in 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 conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on 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 o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) 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/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl 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 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e 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/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re 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/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze 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 kern/132885 net [wlan] 802.1x broken after SVN rev 189592 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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I 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/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o 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 kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic 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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/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 o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125332 net [ath] [panic] crash under any non-tiny networking unde 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/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/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. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o 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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) 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/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/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/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/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 f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/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/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ 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 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/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 o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 366 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 4 11:28:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16DE71065670 for ; Mon, 4 Oct 2010 11:28:30 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id A17198FC12 for ; Mon, 4 Oct 2010 11:28:29 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 89E387E87B; Mon, 4 Oct 2010 22:12:54 +1100 (EST) Message-ID: <4CA9B6AC.20403@freebsd.org> Date: Mon, 04 Oct 2010 22:12:44 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20100913 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Andre Oppermann References: <4CA5D1F0.3000307@freebsd.org> In-Reply-To: <4CA5D1F0.3000307@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Sriram Gorti Subject: Re: Question on TCP reassembly counter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 11:28:30 -0000 On 10/01/10 22:20, Andre Oppermann wrote: > On 01.10.2010 12:01, Sriram Gorti wrote: >> Hi, >> >> In the following is an observation when testing our XLR/XLS network >> driver with 16 concurrent instances of netperf on FreeBSD-CURRENT. >> Based on this observation, I have a question on which I hope to get >> some understanding from here. >> >> When running 16 concurrent netperf instances (each for about 20 >> seconds), it was found that after some number of runs performance >> degraded badly (almost by a factor of 5). All subsequent runs remained >> so. Started debugging this from TCP-side as other driver tests were >> doing fine for comparably long durations on same board+s/w. >> >> netstat indicated the following: >> >> $ netstat -s -f inet -p tcp | grep discarded >> 0 discarded for bad checksums >> 0 discarded for bad header offset fields >> 0 discarded because packet too short >> 7318 discarded due to memory problems >> >> Then, traced the "discarded due to memory problems" to the following >> counter: >> >> $ sysctl -a net.inet.tcp.reass >> net.inet.tcp.reass.overflows: 7318 >> net.inet.tcp.reass.maxqlen: 48 >> net.inet.tcp.reass.cursegments: 1594<--- // corresponds to >> V_tcp_reass_qsize variable >> net.inet.tcp.reass.maxsegments: 1600 >> >> Our guess for the need for reassembly (in this low-packet-loss test >> setup) was the lack of per-flow classification in the driver, causing >> it to spew incoming packets across the 16 h/w cpus instead of packets >> of a flow being sent to the same cpu. While we are working on >> addressing this driver limitation, debugged further to see how/why the >> V_tcp_reass_qsize grew (assuming that out-of-order segments should >> have dropped to zero at the end of the run). It was seen that this >> counter was actually growing up from the initial runs but only when it >> reached near to maxsgements, perf degradation was seen. Then, started >> looking at vmstat also to see how many of the reassembly segments were >> lost. But, there were no segments lost. We could not reconcile "no >> lost segments" with "growth of this counter across test runs". > > A patch is in the works to properly autoscale the reassembly queue > and should be comitted shortly. > >> $ sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre" >> net.inet.tcp.reass.overflows: 0 >> net.inet.tcp.reass.maxqlen: 48 >> net.inet.tcp.reass.cursegments: 147 >> net.inet.tcp.reass.maxsegments: 1600 >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >> mbuf_packet: 256, 0, 4096, 3200, 5653833, 0, 0 >> mbuf: 256, 0, 1, 2048, 4766910, 0, 0 >> mbuf_cluster: 2048, 25600, 7296, 6, 7297, 0, 0 >> mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0, 0 >> mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 >> mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 >> mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 >> tcpreass: 20, 1690, 0, 845, 1757074, 0, 0 >> >> In view of these observations, my question is: is it possible for the >> V_tcp_reass_qsize variable to be unsafely updated on SMP ? (The >> particular flavor of XLS that was used in the test had 4 cores with 4 >> h/w threads/core). I see that the tcp_reass function assumes some lock >> is taken but not sure if it is the per-socket or the global tcp lock. > > The updating of the global counter is indeed unsafe and becomes obsolete > with the autotuning patch. > > The patch is reviewed by me and ready for commit. However lstewart@ is > currently writing his thesis and has only very little spare time. I'll > send you the patch in private email so you can continue your testing. Quick update on this: patch is blocked while waiting for Jeff to review some related UMA changes. As soon as I get the all clear I'll push everything into head. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Oct 5 15:10:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E774106566B for ; Tue, 5 Oct 2010 15:10:32 +0000 (UTC) (envelope-from cosmic17@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED398FC13 for ; Tue, 5 Oct 2010 15:10:31 +0000 (UTC) Received: by bwz15 with SMTP id 15so6121061bwz.13 for ; Tue, 05 Oct 2010 08:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=HsU8SYmV7DBvlXoSku8omJWHERFvfcmP2OA1LdJtKGo=; b=V0HA597hF4uXzp2Gbj6hRvae2q+ZquFd6rvRguGtOtE/5qTEbgqfhwIyTnXF3JWC8W CHgD6Mw09xcuHbPiMKW3xQRzXECrbsF8VlSx6K32wNbY3ZJ0abbK5KLk1rQtB7LLhZo3 fBu0JaaXzEKQn/28hSPo98ow7EhZ3bZ7poogU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=jBDT1Q3LvuXUAZwQmhLDJkDgdz5Y5Abb1IBNkbnDh0xHbBDHmVMLeRNqCAdYhzjL/+ 61oLbJHJLMONXX5EuboMHZKbf8l3QVUhXoqnwsrdGZjuY17fr9+SsQq03GRG73CMmKoW rykvbSVoyFGmr6BIQXmc9kwLEFeMVpyIdCkLk= MIME-Version: 1.0 Received: by 10.204.136.71 with SMTP id q7mr8537847bkt.111.1286289918318; Tue, 05 Oct 2010 07:45:18 -0700 (PDT) Received: by 10.220.161.149 with HTTP; Tue, 5 Oct 2010 07:45:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Oct 2010 18:45:18 +0400 Message-ID: From: =?KOI8-R?B?7snLz8zByiDkzdXIwQ==?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange behavior of packet scheduling in ipfw3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:10:32 -0000 Hello! The system is: FreeBSD mysystem 8.0-STABLE-201005 FreeBSD 8.0-STABLE-201005 #0: Wed Jul 28 12:04:29 MSD 2010 root@mysystem:/usr/src/sys/amd64/compile/MYKERNEL amd64 There is firewall "ipfw3" from Luigi Rizzo with packet scheduling. There is part of firewall config (tariff with 1Mbit/s speed, for example), below (the rules for another speeds are the same): $IPFW pipe 11 config bw 1040Kbit/s mask dst-ip 0xffffffff $IPFW pipe 12 config bw 1040Kbit/s mask src-ip 0xffffffff ########pipe 11 $IPFW sched 11 config type QFQ mask dst-ip 0xffffff00 $IPFW queue 111 config sched 11 weight 10 $IPFW queue 112 config sched 11 weight 8 $IPFW queue 113 config sched 11 weight 4 $IPFW queue 114 config sched 11 weight 1 $IPFW add queue 111 ip from any to table\(10\) via igb0 out proto udp src-port 5060 $IPFW add queue 112 ip from any to table\(10\) via igb0 out proto tcp src-port 80,443,8080 $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto icmp $IPFW add queue 114 ip from any to table\(10\) via igb0 out $IPFW add queue 111 ip from any to table\(10\) via igb2 out proto udp src-port 5060 $IPFW add queue 112 ip from any to table\(10\) via igb2 out proto tcp src-port 80,443,8080 $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto icmp $IPFW add queue 114 ip from any to table\(10\) via igb2 out ########pipe 12 $IPFW sched 12 config type QFQ mask src-ip 0xffffff00 $IPFW queue 121 config sched 12 weight 10 $IPFW queue 122 config sched 12 weight 8 $IPFW queue 123 config sched 12 weight 4 $IPFW queue 124 config sched 12 weight 1 $IPFW add queue 1210 ip from table\(11\) to any via igb1 out proto udp dst-port 5060 $IPFW add queue 122 ip from table\(11\) to any via igb1 out proto tcp dst-port 80,443,8080 $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto icmp $IPFW add queue 124 ip from table\(11\) to any via igb1 out $IPFW add queue 121 ip from table\(11\) to any via igb3 out proto udp dst-port 5060 $IPFW add queue 122 ip from table\(11\) to any via igb3 out proto tcp dst-port 80,443,8080 $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto icmp $IPFW add queue 124 ip from table\(11\) to any via igb3 out Firstly, we have been tested firewall by ourself. And we had no any bad results or any problems or maybe we have not seen them in our synthetic tests. After that we have started this firewall in production. A few months later we received a message from our subscriber with speed 1Mbit/s. He had a problems with online game (big answer delay from the server). We spent a lot of time to solve this problem. Finaly we solved it. The reason was in packet scheduling: 1. we`ve tried to give to subscriber another channel (4Mbit/s) with packet scheduling - there are no such problems; 2. we`ve tried to "turn off" the packet scheduling on 1Mbit channel - there are no such problems. The utilization of subscibers channel was always 0.4Mbit/s. But the traffic from this subscriber was go on under the packet scheduling rules. That`s very strange because of: 1. net.inet.ip.dummynet.io_fast=1; 2. subscribers channel utilization 0.4Mbit/s. As I know with this option, with this firewall config and with this channel utilization (0.4Mbit/s) traffic should bypass the pipe without packet scheduling. Why subscribers traffic with all these conditions doesn`t bypass through pipe without any delays? Why his traffic was on packet scheduling rules? Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Oct 5 16:21:34 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C8D1065679 for ; Tue, 5 Oct 2010 16:21:34 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by mx1.freebsd.org (Postfix) with ESMTP id B39B98FC17 for ; Tue, 5 Oct 2010 16:21:33 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp33.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B294030159; Tue, 5 Oct 2010 12:02:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp33.relay.iad1a.emailsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 84C9130334; Tue, 5 Oct 2010 12:01:58 -0400 (EDT) Message-ID: <4CAB4BE6.3070307@xiplink.com> Date: Tue, 05 Oct 2010 12:01:42 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Luigi Rizzo References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> <20101003131330.GA85551@onelab2.iet.unipi.it> In-Reply-To: <20101003131330.GA85551@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Juli Mallett , Ryan Stone , Robert Watson , Rui Paulo , FreeBSD Net Subject: Re: mbuf changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:21:34 -0000 On 03/10/2010 9:13 AM, Luigi Rizzo wrote: > On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote: >> On 2 Oct 2010, at 21:35, Juli Mallett wrote: >> >>> On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote: >>>> On 2 Oct 2010, at 16:29, Robert Watson wrote: >>>>> On Thu, 30 Sep 2010, Julian Elischer wrote: >>>>>> On 9/30/10 10:49 AM, Ryan Stone wrote: >>>>>>> It's not a big thing but it would be nice to replace the m_next and m_nextpkt fields with queue.h macros. >>>>>> funny, I've never even thought of that.. >>>>> I have, and it's a massive change touching code all over the kernel in vast quantities. While in principle it's a good idea (consistently avoid hand-crafted linked lists), it's something I'd discourage on the basis that it probably won't significant reduce the kernel bug count, but will make it even harder for vendors with large local changes to the network stack to keep up. >>>> I think it could also increase the kernel bug count. Unfortunately, we can't do this incrementally. >>> Can't we? What about a union, so that we can gradually convert things >>> but keep ABI and API compatibility? I mean, as long as we use the >>> right queue.h type, anyway, it should be consistent? STAILQ, >>> presumably. >> Well, I don't have the layout of the mbuf struct offhand, but it's an idea worth investigating. > what is the point of refactoring part of a struct that no new code is > touching ? > > I'd like to keep this discussion on the original topics, > i.e. performance-related issues (make room to embed mtags and other > metadata such as FIB; have flexible per-socket initial padding so > we don't always waste 100+ bytes just because ipv6+ipsec is compiled > in; and so on). > Please open another thread if you want to propose cosmetics or > code refactoring or other unrelated changes > Hi, I will share some of the experience I had doing embed mtags. Hopefully its relevant :) The idea of carrying a certain amount of mbuf tags within the mbuf structure is somewhat similar but much cleaner, imo, then Linux's skbuff char cb[40 - 48] (it was 40bytes in 2.4.x ...). Now this idea is not new although as you know the devil is in the details... What we did for BSD is create a container in the mbuf and extend the API with functions we (pompously) called m_tag_fast_alloc() and m_tag_fast_free(). This means the standard m_tag_alloc() is still supported across the system and the old behavior is unchanged (list of allocated struct attached to the packet header). Whats different is the availability of a 'fast' call that directly uses the container within the mbuf, effectively avoiding those malloc and cache misses. I'll explain later how we effectively support calling m_tag_delete on a 'fast' tag. The trick to save CPU cycles was also to quickly revert back to the standard tag mechanism if some component in the system is manipulating the tag list by deleting elements. Effectively, the m_tag_fast_free is a NOP and fast tags are not deleted once allocated (unless m_free is called on the mbuf of course). When m_tag_delete is called the container simply becomes 'fast tag' invalid for further additions. This is not flexible but has the merit of reducing the overall number of operations given that almost no components are deleting tags without deleting the mbuf (loopback does but its a special case). One last thing we did is perform various operational tests to come up with the most statistically optimized container size. Now this is much easier to do on a proprietary system then for a general purpose OS but its certainly possible. Finally, we did see speed increase for our application and if someone is interested I could provide a patch although I would have to rewrite it without the proprietary bits in it. Best regards, Karim. From owner-freebsd-net@FreeBSD.ORG Tue Oct 5 20:50:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFDC0106566C for ; Tue, 5 Oct 2010 20:50:00 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 96FF28FC1D for ; Tue, 5 Oct 2010 20:50:00 +0000 (UTC) Received: by pzk7 with SMTP id 7so100222pzk.13 for ; Tue, 05 Oct 2010 13:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Fd9UOLEDZojkHf9XKBxY3i2zor1h78zdm7dMs0ECeBc=; b=D930EPxJwSICiiLnDki9SDTPTZZ13isHDcnrKJECheBYOad6P9VCc6j8lvq2sOkK9H Riai9GzaGCWdZFYv/nXRh4ugTukAyRK+HVZdZCWPDiRUw8e1OcnCIDMoX1XPW52hAInV zXd6iSlEpl3QncDt1Nl2lYw/DB7gpCu8kiWps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qW3bO8MVxQy1+D8G6cRYg8HXu8Lm6UVpIfQMjk3SEUVGe7897qneGOCAglBohWjOZh +D1B9SJBl+qeP20YZO7EbFPWZPnBcFoHNRaNQD3ownrgxvGmhG07yi/czAAg9rQ6bATY wy+S5cd6xdIh2LSzfEbxeOM4nQBkWRom099Ls= MIME-Version: 1.0 Received: by 10.142.126.1 with SMTP id y1mr10791018wfc.113.1286309986145; Tue, 05 Oct 2010 13:19:46 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Tue, 5 Oct 2010 13:19:45 -0700 (PDT) Date: Tue, 5 Oct 2010 20:19:45 +0000 Message-ID: From: Paul B Mahol To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=000e0cd30a92cb96980491e46145 Subject: ndis: fix ugly code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 20:50:00 -0000 --000e0cd30a92cb96980491e46145 Content-Type: text/plain; charset=ISO-8859-1 Hi, If clang did not complain, I would probbaly never spot it. Patch attached. --000e0cd30a92cb96980491e46145 Content-Type: text/plain; charset=US-ASCII; name="ndis.txt" Content-Disposition: attachment; filename="ndis.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 ZGlmZiAtLWdpdCBhL3N5cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMgYi9zeXMvY29tcGF0 L25kaXMvc3Vicl9udG9za3JubC5jCmluZGV4IGJhMWU0OWYuLjcxNGZjZDggMTAwNjQ0Ci0tLSBh L3N5cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMKKysrIGIvc3lzL2NvbXBhdC9uZGlzL3N1 YnJfbnRvc2tybmwuYwpAQCAtMjc0LDcgKzI3NCw2IEBAIG50b3Nrcm5sX2xpYmluaXQoKQogCWtk cGNfcXVldWUJCSprcTsKIAljYWxsb3V0X2VudHJ5CQkqZTsKIAlpbnQJCQlpOwotCWNoYXIJCQlu YW1lWzY0XTsKIAogCW10eF9pbml0KCZudG9za3JubF9kaXNwYXRjaGxvY2ssCiAJICAgICJudG9z a3JubCBkaXNwYXRjaCBsb2NrIiwgTVRYX05ESVNfTE9DSywgTVRYX0RFRnxNVFhfUkVDVVJTRSk7 CkBAIC0zMjEsOSArMzIwLDggQEAgbnRvc2tybmxfbGliaW5pdCgpCiAjZW5kaWYKIAkJa3EgPSBr cV9xdWV1ZXMgKyBpOwogCQlrcS0+a3FfY3B1ID0gaTsKLQkJc3ByaW50ZihuYW1lLCAiV2luZG93 cyBEUEMgJWQiLCBpKTsKIAkJZXJyb3IgPSBrcHJvY19jcmVhdGUobnRvc2tybmxfZHBjX3RocmVh ZCwga3EsICZwLAotCQkgICAgUkZISUdIUElELCBORElTX0tTVEFDS19QQUdFUywgbmFtZSk7CisJ CSAgICBSRkhJR0hQSUQsIE5ESVNfS1NUQUNLX1BBR0VTLCAiV2luZG93cyBEUEMgJWQiLCBpKTsK IAkJaWYgKGVycm9yKQogCQkJcGFuaWMoImZhaWxlZCB0byBsYXVuY2ggRFBDIHRocmVhZCIpOwog CX0KQEAgLTMzNCw5ICszMzIsOCBAQCBudG9za3JubF9saWJpbml0KCkKIAogCWZvciAoaSA9IDA7 IGkgPCBXT1JLSVRFTV9USFJFQURTOyBpKyspIHsKIAkJa3EgPSB3cV9xdWV1ZXMgKyBpOwotCQlz cHJpbnRmKG5hbWUsICJXaW5kb3dzIFdvcmtpdGVtICVkIiwgaSk7CiAJCWVycm9yID0ga3Byb2Nf Y3JlYXRlKG50b3Nrcm5sX3dvcmtpdGVtX3RocmVhZCwga3EsICZwLAotCQkgICAgUkZISUdIUElE LCBORElTX0tTVEFDS19QQUdFUywgbmFtZSk7CisJCSAgICBSRkhJR0hQSUQsIE5ESVNfS1NUQUNL X1BBR0VTLCAiV2luZG93cyBXb3JraXRlbSAlZCIsIGkpOwogCQlpZiAoZXJyb3IpCiAJCQlwYW5p YygiZmFpbGVkIHRvIGxhdW5jaCB3b3JraXRlbSB0aHJlYWQiKTsKIAl9CkBAIC0zMzgyLDcgKzMz NzksNiBAQCBQc0NyZWF0ZVN5c3RlbVRocmVhZChoYW5kbGUsIHJlcWFjY2Vzcywgb2JqYXR0cnMs IHBoYW5kbGUsCiAJdm9pZAkJCSp0aHJjdHg7CiB7CiAJaW50CQkJZXJyb3I7Ci0JY2hhcgkJCXRu YW1lWzEyOF07CiAJdGhyZWFkX2NvbnRleHQJCSp0YzsKIAlzdHJ1Y3QgcHJvYwkJKnA7CiAKQEAg LTMzOTMsOSArMzM4OSw4IEBAIFBzQ3JlYXRlU3lzdGVtVGhyZWFkKGhhbmRsZSwgcmVxYWNjZXNz LCBvYmphdHRycywgcGhhbmRsZSwKIAl0Yy0+dGNfdGhyY3R4ID0gdGhyY3R4OwogCXRjLT50Y190 aHJmdW5jID0gdGhyZnVuYzsKIAotCXNwcmludGYodG5hbWUsICJ3aW5kb3dzIGt0aHJlYWQgJWQi LCBudG9za3JubF9rdGgpOwogCWVycm9yID0ga3Byb2NfY3JlYXRlKG50b3Nrcm5sX3RocmZ1bmMs IHRjLCAmcCwKLQkgICAgUkZISUdIUElELCBORElTX0tTVEFDS19QQUdFUywgdG5hbWUpOworCSAg ICBSRkhJR0hQSUQsIE5ESVNfS1NUQUNLX1BBR0VTLCAiV2luZG93cyBLdGhyZWFkICVkIiwgbnRv c2tybmxfa3RoKTsKIAogCWlmIChlcnJvcikgewogCQlmcmVlKHRjLCBNX1RFTVApOwo= --000e0cd30a92cb96980491e46145-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 5 21:00:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27449106564A for ; Tue, 5 Oct 2010 21:00:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-17.mx.aerioconnect.net [216.240.47.77]) by mx1.freebsd.org (Postfix) with ESMTP id 08F058FC12 for ; Tue, 5 Oct 2010 21:00:20 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o95L0JGO007063; Tue, 5 Oct 2010 14:00:19 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 24D8D2D601D; Tue, 5 Oct 2010 14:00:18 -0700 (PDT) Message-ID: <4CAB9212.4010203@freebsd.org> Date: Tue, 05 Oct 2010 14:01:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org, "Paul B. Mahol" References: In-Reply-To: X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ndis: fix ugly code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 21:00:21 -0000 On 10/5/10 1:19 PM, Paul B Mahol wrote: > Hi, > > If clang did not complain, I would probbaly never spot it. > > Patch attached. personally I think you could use kproc_kthread_add so that a single NDIS process had three threads. > > _______________________________________________ > 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 Oct 5 21:21:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A466E106566C for ; Tue, 5 Oct 2010 21:21:33 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47ECE8FC12 for ; Tue, 5 Oct 2010 21:21:32 +0000 (UTC) Received: by wyb29 with SMTP id 29so6282541wyb.13 for ; Tue, 05 Oct 2010 14:21:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.41.2 with SMTP id m2mr10000997wbe.12.1286312180906; Tue, 05 Oct 2010 13:56:20 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.227.141.76 with HTTP; Tue, 5 Oct 2010 13:56:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Oct 2010 09:56:20 +1300 X-Google-Sender-Auth: MieN-tW0YpmSwSoq11-HGuZbNEI Message-ID: From: Andrew Thompson To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: ndis: fix ugly code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 21:21:33 -0000 On 6 October 2010 09:19, Paul B Mahol wrote: > Hi, > > If clang did not complain, I would probbaly never spot it. > > Patch attached. Committed. From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 00:27:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FDF6106566C; Wed, 6 Oct 2010 00:27:51 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id B0D3F8FC14; Wed, 6 Oct 2010 00:27:50 +0000 (UTC) Received: by qyk4 with SMTP id 4so34738qyk.13 for ; Tue, 05 Oct 2010 17:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GWVsKOTmy7TcjFlvBFT3uNhQyJK6AQF99+016EiJdEI=; b=S6OOKVSOM5dLLnDLGj20taYo1PTtGWVmf0/HNLnLOBKQQ7dIh9wa/xrAMPYVdeD9YS Vslx+nKV58aFc1eAV7BiICFDapGYSbGYt7Zb92/Y2qEsxkFp2cNxWb/iv3e1RhBNumAA 3ZE+gWzmIXHxC2WzDN5jDCh1dDyLrFlut1ezM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PsBOhttu52lAvMKUbKjrlEKGoOoTidIMcsmmvwMTqYlTDpw+hGr4Jx/ThYR+38xLQu 5FGD/zbE7JTKX4+2d/4ijMw29kzH7/AhN3KkPrMUo9KzjNK4NOuN3QMRMB4QeNMODDiW cZjXIZeD3kKE5baW6bFSmr5cq1nrmvgSjCAy0= MIME-Version: 1.0 Received: by 10.220.167.194 with SMTP id r2mr444330vcy.247.1286324864720; Tue, 05 Oct 2010 17:27:44 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Tue, 5 Oct 2010 17:27:44 -0700 (PDT) In-Reply-To: <4CAB9212.4010203@freebsd.org> References: <4CAB9212.4010203@freebsd.org> Date: Wed, 6 Oct 2010 00:27:44 +0000 Message-ID: From: Paul B Mahol To: Julian Elischer Content-Type: multipart/mixed; boundary=001636284556a0a0e90491e7d894 Cc: freebsd-net@freebsd.org Subject: Re: ndis: fix ugly code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 00:27:51 -0000 --001636284556a0a0e90491e7d894 Content-Type: text/plain; charset=ISO-8859-1 On 10/5/10, Julian Elischer wrote: > On 10/5/10 1:19 PM, Paul B Mahol wrote: >> Hi, >> >> If clang did not complain, I would probbaly never spot it. >> >> Patch attached. > > personally I think you could use kproc_kthread_add so that a single > NDIS process had three threads. Patch attached. Now we have single "ndis" kernel process with own threads. --001636284556a0a0e90491e7d894 Content-Type: text/plain; charset=US-ASCII; name="diff.txt" Content-Disposition: attachment; filename="diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 ZGlmZiAtLWdpdCBhL3N5cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMgYi9zeXMvY29tcGF0 L25kaXMvc3Vicl9udG9za3JubC5jCmluZGV4IDcxNGZjZDguLmVhZmJiN2MgMTAwNjQ0Ci0tLSBh L3N5cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMKKysrIGIvc3lzL2NvbXBhdC9uZGlzL3N1 YnJfbnRvc2tybmwuYwpAQCAtMjU0LDYgKzI1NCw3IEBAIHN0YXRpYyBpbnQzMl90IEtlRGVsYXlF eGVjdXRpb25UaHJlYWQodWludDhfdCwgdWludDhfdCwgaW50NjRfdCAqKTsKIHN0YXRpYyBpbnQz Ml90IEtlU2V0UHJpb3JpdHlUaHJlYWQoc3RydWN0IHRocmVhZCAqLCBpbnQzMl90KTsKIHN0YXRp YyB2b2lkIGR1bW15KHZvaWQpOwogCitzdGF0aWMgc3RydWN0IHByb2MgKm5kaXNwcm9jOwogc3Rh dGljIHN0cnVjdCBtdHggbnRvc2tybmxfZGlzcGF0Y2hsb2NrOwogc3RhdGljIHN0cnVjdCBtdHgg bnRvc2tybmxfaW50ZXJsb2NrOwogc3RhdGljIGtzcGluX2xvY2sgbnRvc2tybmxfY2FuY2VsbG9j azsKQEAgLTI3MCw3ICsyNzEsNyBAQCBudG9za3JubF9saWJpbml0KCkKIHsKIAlpbWFnZV9wYXRj aF90YWJsZQkqcGF0Y2g7CiAJaW50CQkJZXJyb3I7Ci0Jc3RydWN0IHByb2MJCSpwOworCXN0cnVj dCB0aHJlYWQJCSp0OwogCWtkcGNfcXVldWUJCSprcTsKIAljYWxsb3V0X2VudHJ5CQkqZTsKIAlp bnQJCQlpOwpAQCAtMzIwLDggKzMyMSw5IEBAIG50b3Nrcm5sX2xpYmluaXQoKQogI2VuZGlmCiAJ CWtxID0ga3FfcXVldWVzICsgaTsKIAkJa3EtPmtxX2NwdSA9IGk7Ci0JCWVycm9yID0ga3Byb2Nf Y3JlYXRlKG50b3Nrcm5sX2RwY190aHJlYWQsIGtxLCAmcCwKLQkJICAgIFJGSElHSFBJRCwgTkRJ U19LU1RBQ0tfUEFHRVMsICJXaW5kb3dzIERQQyAlZCIsIGkpOworCQllcnJvciA9IGtwcm9jX2t0 aHJlYWRfYWRkKG50b3Nrcm5sX2RwY190aHJlYWQsIGtxLAorCQkgICAgJm5kaXNwcm9jLCAmdCwg UkZISUdIUElELCBORElTX0tTVEFDS19QQUdFUywgIm5kaXMiLAorCQkgICAgIldpbmRvd3MgRFBD ICVkIiwgaSk7CiAJCWlmIChlcnJvcikKIAkJCXBhbmljKCJmYWlsZWQgdG8gbGF1bmNoIERQQyB0 aHJlYWQiKTsKIAl9CkBAIC0zMzIsOCArMzM0LDkgQEAgbnRvc2tybmxfbGliaW5pdCgpCiAKIAlm b3IgKGkgPSAwOyBpIDwgV09SS0lURU1fVEhSRUFEUzsgaSsrKSB7CiAJCWtxID0gd3FfcXVldWVz ICsgaTsKLQkJZXJyb3IgPSBrcHJvY19jcmVhdGUobnRvc2tybmxfd29ya2l0ZW1fdGhyZWFkLCBr cSwgJnAsCi0JCSAgICBSRkhJR0hQSUQsIE5ESVNfS1NUQUNLX1BBR0VTLCAiV2luZG93cyBXb3Jr aXRlbSAlZCIsIGkpOworCQllcnJvciA9IGtwcm9jX2t0aHJlYWRfYWRkKG50b3Nrcm5sX3dvcmtp dGVtX3RocmVhZCwga3EsCisJCSAgICAmbmRpc3Byb2MsICZ0LCBSRkhJR0hQSUQsIE5ESVNfS1NU QUNLX1BBR0VTLCAibmRpcyIsCisJCSAgICAiV2luZG93cyBXb3JraXRlbSAlZCIsIGkpOwogCQlp ZiAoZXJyb3IpCiAJCQlwYW5pYygiZmFpbGVkIHRvIGxhdW5jaCB3b3JraXRlbSB0aHJlYWQiKTsK IAl9CkBAIC0yNzAxLDcgKzI3MDQsNyBAQCBudG9za3JubF93b3JraXRlbV90aHJlYWQoYXJnKQog I2lmIF9fRnJlZUJTRF92ZXJzaW9uIDwgNTAyMTEzCiAJbXR4X2xvY2soJkdpYW50KTsKICNlbmRp ZgotCWtwcm9jX2V4aXQoMCk7CisJa3RocmVhZF9leGl0KCk7CiAJcmV0dXJuOyAvKiBub3RyZWFj aGVkICovCiB9CiAKQEAgLTMzODAsNyArMzM4Myw3IEBAIFBzQ3JlYXRlU3lzdGVtVGhyZWFkKGhh bmRsZSwgcmVxYWNjZXNzLCBvYmphdHRycywgcGhhbmRsZSwKIHsKIAlpbnQJCQllcnJvcjsKIAl0 aHJlYWRfY29udGV4dAkJKnRjOwotCXN0cnVjdCBwcm9jCQkqcDsKKwlzdHJ1Y3QgdGhyZWFkCQkq dDsKIAogCXRjID0gbWFsbG9jKHNpemVvZih0aHJlYWRfY29udGV4dCksIE1fVEVNUCwgTV9OT1dB SVQpOwogCWlmICh0YyA9PSBOVUxMKQpAQCAtMzM4OSwxNSArMzM5MiwxNiBAQCBQc0NyZWF0ZVN5 c3RlbVRocmVhZChoYW5kbGUsIHJlcWFjY2Vzcywgb2JqYXR0cnMsIHBoYW5kbGUsCiAJdGMtPnRj X3RocmN0eCA9IHRocmN0eDsKIAl0Yy0+dGNfdGhyZnVuYyA9IHRocmZ1bmM7CiAKLQllcnJvciA9 IGtwcm9jX2NyZWF0ZShudG9za3JubF90aHJmdW5jLCB0YywgJnAsCi0JICAgIFJGSElHSFBJRCwg TkRJU19LU1RBQ0tfUEFHRVMsICJXaW5kb3dzIEt0aHJlYWQgJWQiLCBudG9za3JubF9rdGgpOwor CWVycm9yID0ga3Byb2Nfa3RocmVhZF9hZGQobnRvc2tybmxfdGhyZnVuYywgdGMsICZuZGlzcHJv YywgJnQsCisJICAgIFJGSElHSFBJRCwgTkRJU19LU1RBQ0tfUEFHRVMsICJuZGlzIiwKKwkgICAg IldpbmRvd3MgS3RocmVhZCAlZCIsIG50b3Nrcm5sX2t0aCk7CiAKIAlpZiAoZXJyb3IpIHsKIAkJ ZnJlZSh0YywgTV9URU1QKTsKIAkJcmV0dXJuIChTVEFUVVNfSU5TVUZGSUNJRU5UX1JFU09VUkNF Uyk7CiAJfQogCi0JKmhhbmRsZSA9IHA7CisJKmhhbmRsZSA9IHQ7CiAJbnRvc2tybmxfa3RoKys7 CiAKIAlyZXR1cm4gKFNUQVRVU19TVUNDRVNTKTsKQEAgLTM0MzIsNyArMzQzNiw3IEBAIFBzVGVy bWluYXRlU3lzdGVtVGhyZWFkKHN0YXR1cykKICNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA8IDUwMjEx MwogCW10eF9sb2NrKCZHaWFudCk7CiAjZW5kaWYKLQlrcHJvY19leGl0KDApOworCWt0aHJlYWRf ZXhpdCgpOwogCXJldHVybiAoMCk7CS8qIG5vdHJlYWNoZWQgKi8KIH0KIApAQCAtMzc0MCw3ICsz NzQ0LDcgQEAgbnRvc2tybmxfZHBjX3RocmVhZChhcmcpCiAjaWYgX19GcmVlQlNEX3ZlcnNpb24g PCA1MDIxMTMKIAltdHhfbG9jaygmR2lhbnQpOwogI2VuZGlmCi0Ja3Byb2NfZXhpdCgwKTsKKwlr dGhyZWFkX2V4aXQoKTsKIAlyZXR1cm47IC8qIG5vdHJlYWNoZWQgKi8KIH0KIAo= --001636284556a0a0e90491e7d894-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 01:09:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8E3106566B for ; Wed, 6 Oct 2010 01:09:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-21.mx.aerioconnect.net [216.240.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id 11F758FC15 for ; Wed, 6 Oct 2010 01:09:13 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9619DIc013103; Tue, 5 Oct 2010 18:09:13 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id A792A2D6015; Tue, 5 Oct 2010 18:09:12 -0700 (PDT) Message-ID: <4CABCC67.9070907@freebsd.org> Date: Tue, 05 Oct 2010 18:09:59 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Paul B Mahol References: <4CAB9212.4010203@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: ndis: fix ugly code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 01:09:14 -0000 On 10/5/10 5:27 PM, Paul B Mahol wrote: > On 10/5/10, Julian Elischer wrote: >> On 10/5/10 1:19 PM, Paul B Mahol wrote: >>> Hi, >>> >>> If clang did not complain, I would probbaly never spot it. >>> >>> Patch attached. >> personally I think you could use kproc_kthread_add so that a single >> NDIS process had three threads. > Patch attached. Now we have single "ndis" kernel process with own threads. I don't know how ndis works. Is it possible that each ndis driver would have it's own process? or would each instance? I don't even know if it's possible to run two different ndis drivers in the same kernel. if that was the case we'd want to have a different name for each one so you can tell them, but I just don't know enough about it. From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 03:18:55 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB73106564A; Wed, 6 Oct 2010 03:18:55 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 718A48FC08; Wed, 6 Oct 2010 03:18:55 +0000 (UTC) Received: by qyk4 with SMTP id 4so188281qyk.13 for ; Tue, 05 Oct 2010 20:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4C4THqw5CNhWyQ7HwNhUfdvm5kyUnwdOVgOyp8sx1Do=; b=b89eUk/Ito7D0+RuWsvzns0IjKCWMtAK3+3FF64TDG9Sgr1D6eUNjeshcYbSc/H5NW WtgZUv0Of0q/2f0E2PHq05jllNulTQtyj6gJnjtjekxXKAgS9GtpHYb7b2GHeSmh5LBT IkzlP2FXEgJxmeL49NiPepCl2/XJVFej37yyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sR8ynS6dqDZcP7BIK0Qw7JHE5FyGHgJWlrd7MHAyHW3LHukLRR4E/IgSHCk4XC30Me l5isw9YzSxv6X3RWMPMPo4UZZYSvyPGE1gyfWSnvfPYg/ap9oMHrz0rtGVgB0tj4MQPW nwzh+qWkzzFRlVQqUuQWmjRrdn7x6mdyAHk5w= MIME-Version: 1.0 Received: by 10.224.60.133 with SMTP id p5mr8843565qah.331.1286335134791; Tue, 05 Oct 2010 20:18:54 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Tue, 5 Oct 2010 20:18:54 -0700 (PDT) In-Reply-To: <4CABCC67.9070907@freebsd.org> References: <4CAB9212.4010203@freebsd.org> <4CABCC67.9070907@freebsd.org> Date: Wed, 6 Oct 2010 03:18:54 +0000 Message-ID: From: Paul B Mahol To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: ndis: fix ugly code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 03:18:55 -0000 On 10/6/10, Julian Elischer wrote: > On 10/5/10 5:27 PM, Paul B Mahol wrote: >> On 10/5/10, Julian Elischer wrote: >>> On 10/5/10 1:19 PM, Paul B Mahol wrote: >>>> Hi, >>>> >>>> If clang did not complain, I would probbaly never spot it. >>>> >>>> Patch attached. >>> personally I think you could use kproc_kthread_add so that a single >>> NDIS process had three threads. >> Patch attached. Now we have single "ndis" kernel process with own threads. > I don't know how ndis works. Is it possible that each ndis driver > would have it's own process? or would each instance? > I don't even know if it's possible to run two different ndis drivers > in the same kernel. > if that was the case we'd want to have a different name for each one > so you can tell them, > but I just don't know enough about it. Nothing have changed in funcionality. We are just using kernel thread instead of kernel process. From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 10:03:35 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 73DB21065673; Wed, 6 Oct 2010 10:03:35 +0000 (UTC) Date: Wed, 6 Oct 2010 10:03:35 +0000 From: Alexey Dokuchaev To: net@freebsd.org Message-ID: <20101006100335.GA26843@FreeBSD.org> References: <4763016D.7060100@janh.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4763016D.7060100@janh.de> User-Agent: Mutt/1.4.2.1i Cc: Subject: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 10:03:35 -0000 On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: > In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does > not receive anything, while it does with ath or ural (even at the same > time). dmesg with debug.iwi=2 is below -- anything unusual? > > Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never > happened on 6.2-RELEASE. Just found this email sent to stable@ almost three years ago; sadly I have to confirm iwi(4) still exhibits these problems on fairly recent 7-STABLE (early Juneish). Maybe I have better luck on net@ (I am particularly interested in working monitor mode). Thanks. Any debug information will be gladly provided. Pointers where to look (revisions to try, patches, etc.) are greatly appreciated. ./danfe > iwi_newstate: INIT -> INIT flags 0x0 > enter FW state 1 > Setting MAC address to 00:0e:35:91:2b:0b > sending command idx=0 type=11 len=6 > Configuring adapter > sending command idx=1 type=6 len=20 > Setting power mode to 0 > sending command idx=2 type=17 len=4 > Setting RTS threshold to 2346 > sending command idx=3 type=15 len=4 > Setting fragmentation threshold to 2346 > sending command idx=4 type=16 len=4 > Setting .11bg supported rates (12) > sending command idx=5 type=22 len=16 > Setting .11a supported rates (0) > sending command idx=6 type=22 len=16 > Setting initialization vector to 3524349664 > sending command idx=7 type=34 len=4 > Setting wep key index 0 len 0 > sending command idx=8 type=18 len=20 > Setting wep key index 1 len 0 > sending command idx=9 type=18 len=20 > Setting wep key index 2 len 0 > sending command idx=10 type=18 len=20 > Setting wep key index 3 len 0 > sending command idx=11 type=18 len=20 > Enabling adapter > sending command idx=12 type=2 len=0 > iwi_newstate: INIT -> RUN flags 0x1 > iwi_newstate: RUN -> RUN flags 0x1 > exit FW state 1 > Setting WME parameters > sending command idx=13 type=25 len=96 From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 16:22:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02E23106564A for ; Wed, 6 Oct 2010 16:22:14 +0000 (UTC) (envelope-from arroz@guiamac.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id AEF408FC18 for ; Wed, 6 Oct 2010 16:22:13 +0000 (UTC) Received: (qmail 90955 invoked by uid 0); 6 Oct 2010 15:55:31 -0000 Received: from 193.136.153.51 (HELO ?10.5.24.253?) (193.136.153.51) by relay01.pair.com with SMTP; 6 Oct 2010 15:55:31 -0000 X-pair-Authenticated: 193.136.153.51 From: Miguel Arroz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 16:55:28 +0100 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Cannot attribute both IPv4 and IPv6 to a VLAN interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:22:14 -0000 Hello, I'm using a FreeBSD machine as a NATBox/router for two small networks. = The installed version is FreeBSD 7.1-RELEASE-p13. My network setup is one ethernet cable connecting to the NATBox, with = 3 VLANs (2 of them tagged). The non-tagged VLAN is the "outter" network, = and the other two VLANs are the two networks referred above. Here's my network config for IPv4: cloned_interfaces=3D"vlan18 vlan19" ifconfig_em0=3D"inet xxx.xxx.xxx.51 netmask 255.255.255.0" ifconfig_vlan18=3D"inet 10.5.25.254 netmask 255.255.255.0 vlan 18 = vlandev em0" ifconfig_vlan19=3D"inet 10.5.24.254 netmask 255.255.255.0 vlan 19 = vlandev em0" ifconfig_vlan18_alias0=3D"inet 10.5.25.253 netmask 0xffffffff" defaultrouter=3D"xxx.xxx.xxx.254" vlan18 has a second IP for a jail running a service needed on that = network, but it's not part of my problem. All this works fine under = IPv4, both the "inside" networks are NATed, and that's it. Now, I'm adding IPv6. The idea is having an IPv6 address on the = router, and two /64 networks for each one of the "inside" networks. But = I'm having a problem configuring the network interfaces. Although I have = no problem on the main interface, I'm not able to attribute both a = globally routable IPv6 address and an IPv4 address to the vlan = interfaces. This is what I'm trying to do: ipv6_ifconfig_em0=3D"xxx:xxx:xxx:40::460:1 prefixlen 64" ipv6_ifconfig_vlan18=3D"xxx:xxx:xxx:460:: prefixlen 64 vlan 18 vlandev = em0" ipv6_ifconfig_vlan19=3D"xxx:xxx:xxx:461:: prefixlen 64 vlan 19 vlandev = em0" ipv6_defaultrouter=3D"xxx:xxx:xxx:40::" When I run /etc/rc.d/network_ipv6 restart, among the output I get = this: ifconfig: SIOCSETVLAN: Device busy The final result is that em0 gets the correct configuration, but both = vlan18 and 19 do not. They both have the IPv4 and an fe80:... IPv6, but = not the globally routed 2001:... IPv6. Is this a known bug? Is there a workaround? Regards, Miguel Arroz From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 16:45:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AB451065694 for ; Wed, 6 Oct 2010 16:45:10 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9C28FC14 for ; Wed, 6 Oct 2010 16:45:09 +0000 (UTC) Received: from [89.21.28.38] (port=38566 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net id 1P3X76-000Jws-49; Wed, 06 Oct 2010 17:45:08 +0100 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Wed, 06 Oct 2010 17:45:08 +0100 Message-ID: <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> Date: Wed, 06 Oct 2010 17:45:08 +0100 From: a.smith@ukgrid.net To: pyunyh@gmail.com References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> <20100928222532.GD1252@michelle.cdnetworks.com> In-Reply-To: <20100928222532.GD1252@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) / FreeBSD-8.0 Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:45:10 -0000 Hi, sorry not to have replied sooner. Ive been trying to get the end user to confirm whether he has any issues with the server as it is. He still hasnt replied :( I think tho, its likely I will leave the server as is for the time being as I have no information that it isnt working correctly (other than continued watchdog messages in the logs), and wait for a more mature bge driver to be tested and released. thanks for your help, Andy. From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 16:57:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75B0D1065670 for ; Wed, 6 Oct 2010 16:57:42 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 089728FC0C for ; Wed, 6 Oct 2010 16:57:41 +0000 (UTC) Received: by ewy22 with SMTP id 22so3556404ewy.13 for ; Wed, 06 Oct 2010 09:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Q9vKgeHOroVpihxCWGCHVDPz5KxNIX6w9QPJsfrCoeo=; b=FVraTm6YhNNNNWpktN9zjPhEOGVZ46fv/tuhNfFnervPu3WGYT9UZUV9XMKHR5XzyJ mWEsawZ8yVf8pIf59l29pkUt3YfbDd5izyKxBMsmhg12roy0GfV+raMYaFEvAVQ9rvRS zlEgmHrG1KHErF/gCKLHp/K2Lq0jJX1EykdUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iXm35Z2bQFGAAW6Yql6ON3pwvHmX87Bk1A38ZDOPTvgbxoLK76vrPRNtoueOFQXFkK /HhPk3rBzrgAG1bpDbeo3/bIbJaa7vb4MMYcJ16JJxME1KzOaf3/xXvijF2ilJgOoEBu tc+3XU2Q+T+4kMD97Wo5N1B8kvsOHG650/mnc= MIME-Version: 1.0 Received: by 10.213.114.15 with SMTP id c15mr851233ebq.40.1286382696283; Wed, 06 Oct 2010 09:31:36 -0700 (PDT) Received: by 10.213.105.208 with HTTP; Wed, 6 Oct 2010 09:31:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Oct 2010 12:31:36 -0400 Message-ID: From: Ryan Stone To: Miguel Arroz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Cannot attribute both IPv4 and IPv6 to a VLAN interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:57:42 -0000 It seems to me that the mistake that you are making is that you are setting the vlan portion (e.g. vlan 18 vlandev em0) twice. The second time that the configuration is applied it fails. I believe that you want instead to put the following in rc.conf: ipv6_ifconfig_vlan18="xxx:xxx:xxx:460:: prefixlen 64" ipv6_ifconfig_vlan19="xxx:xxx:xxx:461:: prefixlen 64" From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 17:04:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A221065673 for ; Wed, 6 Oct 2010 17:04:36 +0000 (UTC) (envelope-from arroz@guiamac.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 524078FC26 for ; Wed, 6 Oct 2010 17:04:36 +0000 (UTC) Received: (qmail 29382 invoked by uid 0); 6 Oct 2010 17:04:35 -0000 Received: from 193.136.153.51 (HELO ?10.5.24.253?) (193.136.153.51) by relay01.pair.com with SMTP; 6 Oct 2010 17:04:35 -0000 X-pair-Authenticated: 193.136.153.51 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Miguel Arroz In-Reply-To: Date: Wed, 6 Oct 2010 18:04:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Stone X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Cannot attribute both IPv4 and IPv6 to a VLAN interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:04:36 -0000 Hi! You're right. :) I have the idea I had already tried that before and = it removed the IPv4 from the interface, but now it's working fine. = Thanks for the help! Regards, Miguel Arroz On 2010/10/06, at 17:31, Ryan Stone wrote: > It seems to me that the mistake that you are making is that you are > setting the vlan portion (e.g. vlan 18 vlandev em0) twice. The second > time that the configuration is applied it fails. I believe that you > want instead to put the following in rc.conf: >=20 > ipv6_ifconfig_vlan18=3D"xxx:xxx:xxx:460:: prefixlen 64" > ipv6_ifconfig_vlan19=3D"xxx:xxx:xxx:461:: prefixlen 64" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 17:21:11 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2202E106566C; Wed, 6 Oct 2010 17:21:11 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8506F8FC12; Wed, 6 Oct 2010 17:21:10 +0000 (UTC) Received: by wyb29 with SMTP id 29so7387424wyb.13 for ; Wed, 06 Oct 2010 10:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eUs6PonKCclLm5E51WTz0acVWc/sQC1SlvdhEVLTfa0=; b=IsOlDZM/zfHe9oOL6I3BNQsVa4R0TdA4btQh1utZWCz391rZD3uAwwT6zo+pHIkrHh 6uMM7QbDTdpMNEeIPxodx3rtSq8jbdD5FRzSJBO7o9Yg04YUmu5Aw2jcYxjWHYbvAHdT dTvmPRYDpGZoxYmYqoTsi3mlAuiJX9aOeDR5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=C3BSgFdGWgqbYwD5nnh8q+69Na1BfDyqy915nY0KzDOQuaP/0L6AeSbud1Xn8eoBnb lIlf+Cyn+trUQMK94B1kdmcXwHU6Ii7TrVcSXeLM4+RyRx1k1Emm4vQ04E1w/3VzUNTq wlLxCXv0wogsz5gwULCQ+38FuQwW+B27bnIIE= MIME-Version: 1.0 Received: by 10.216.2.75 with SMTP id 53mr2427430wee.48.1286384185736; Wed, 06 Oct 2010 09:56:25 -0700 (PDT) Received: by 10.216.133.133 with HTTP; Wed, 6 Oct 2010 09:56:25 -0700 (PDT) In-Reply-To: <20101006100335.GA26843@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> Date: Wed, 6 Oct 2010 11:56:25 -0500 Message-ID: From: Brandon Gooch To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:21:11 -0000 2010/10/6 Alexey Dokuchaev : > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does >> not receive anything, while it does with ath or ural (even at the same >> time). dmesg with debug.iwi=3D2 is below -- anything unusual? >> >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never >> happened on 6.2-RELEASE. > > Just found this email sent to stable@ almost three years ago; sadly I > have to confirm iwi(4) still exhibits these problems on fairly recent > 7-STABLE (early Juneish). =A0Maybe I have better luck on net@ (I am > particularly interested in working monitor mode). =A0Thanks. =A0Any debug > information will be gladly provided. =A0Pointers where to look (revisions > to try, patches, etc.) are greatly appreciated. > > ./danfe > >> iwi_newstate: INIT -> INIT flags 0x0 >> enter FW state 1 >> Setting MAC address to 00:0e:35:91:2b:0b >> sending command idx=3D0 type=3D11 len=3D6 >> Configuring adapter >> sending command idx=3D1 type=3D6 len=3D20 >> Setting power mode to 0 >> sending command idx=3D2 type=3D17 len=3D4 >> Setting RTS threshold to 2346 >> sending command idx=3D3 type=3D15 len=3D4 >> Setting fragmentation threshold to 2346 >> sending command idx=3D4 type=3D16 len=3D4 >> Setting .11bg supported rates (12) >> sending command idx=3D5 type=3D22 len=3D16 >> Setting .11a supported rates (0) >> sending command idx=3D6 type=3D22 len=3D16 >> Setting initialization vector to 3524349664 >> sending command idx=3D7 type=3D34 len=3D4 >> Setting wep key index 0 len 0 >> sending command idx=3D8 type=3D18 len=3D20 >> Setting wep key index 1 len 0 >> sending command idx=3D9 type=3D18 len=3D20 >> Setting wep key index 2 len 0 >> sending command idx=3D10 type=3D18 len=3D20 >> Setting wep key index 3 len 0 >> sending command idx=3D11 type=3D18 len=3D20 >> Enabling adapter >> sending command idx=3D12 type=3D2 len=3D0 >> iwi_newstate: INIT -> RUN flags 0x1 >> iwi_newstate: RUN -> RUN flags 0x1 >> exit FW state 1 >> Setting WME parameters >> sending command idx=3D13 type=3D25 len=3D96 I know this response isn't too helpful, but the whole Intel PRO/Wireless 2200BG/2225BG/2915ABG open-source driver situation is not too good. Same goes for the Intel 3945ABG (wpi(4)); it's very easy in both Linux and *BSDs to befuddle the Intel Wifi chips. Having said that, Bernhard Schmidt has made outstanding progress with the iwn(4) driver, supporting Intel Wireless WiFi Link 4965/1000/5000/5150/5300/6000/6050 series. Is it possible in your situation to try another wireless card? I know some notebook computers only whitelist a small set of PCI devices... -Brandon From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 17:43:00 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC191065696; Wed, 6 Oct 2010 17:43:00 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 11DC28FC17; Wed, 6 Oct 2010 17:43:00 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B79B46B2A; Wed, 6 Oct 2010 13:42:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4CAB4BE6.3070307@xiplink.com> Date: Wed, 6 Oct 2010 18:42:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C5CDDB3-73BF-4551-8F42-1FBCDB757AB6@freebsd.org> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> <20101003131330.GA85551@onelab2.iet.unipi.it> <4CAB4BE6.3070307@xiplink.com> To: Karim Fodil-Lemelin X-Mailer: Apple Mail (2.1081) Cc: Juli Mallett , Rui Paulo , Ryan Stone , Luigi Rizzo , FreeBSD Net Subject: Re: mbuf changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:43:00 -0000 On 5 Oct 2010, at 17:01, Karim Fodil-Lemelin wrote: > I will share some of the experience I had doing embed mtags. Hopefully = its relevant :) >=20 > The idea of carrying a certain amount of mbuf tags within the mbuf = structure is somewhat similar but much cleaner, imo, then Linux's skbuff = char cb[40 - 48] (it was 40bytes in 2.4.x ...). Now this idea is not new = although as you know the devil is in the details... Hi Karim: This sounds like very interesting work, and something we should figure = out how to generalize for FreeBSD. I had also been pondering something = along these lines in order to improve MAC label performance when using = ubiquitously labeled policies. Since MAC often stores references to = externally managed data from mbuf labels (i.e., deep structures, rather = than just bytes of data) it's especially important to make sure we get = the tear-down stuff right... Robert >=20 > What we did for BSD is create a container in the mbuf and extend the = API with functions we (pompously) called m_tag_fast_alloc() and = m_tag_fast_free(). This means the standard m_tag_alloc() is still = supported across the system and the old behavior is unchanged (list of = allocated struct attached to the packet header). Whats different is the = availability of a 'fast' call that directly uses the container within = the mbuf, effectively avoiding those malloc and cache misses. I'll = explain later how we effectively support calling m_tag_delete on a = 'fast' tag. >=20 > The trick to save CPU cycles was also to quickly revert back to the = standard tag mechanism if some component in the system is manipulating = the tag list by deleting elements. Effectively, the m_tag_fast_free is a = NOP and fast tags are not deleted once allocated (unless m_free is = called on the mbuf of course). When m_tag_delete is called the container = simply becomes 'fast tag' invalid for further additions. This is not = flexible but has the merit of reducing the overall number of operations = given that almost no components are deleting tags without deleting the = mbuf (loopback does but its a special case). >=20 > One last thing we did is perform various operational tests to come up = with the most statistically optimized container size. Now this is much = easier to do on a proprietary system then for a general purpose OS but = its certainly possible. >=20 > Finally, we did see speed increase for our application and if someone = is interested I could provide a patch although I would have to rewrite = it without the proprietary bits in it. >=20 > Best regards, >=20 > Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 17:43:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704A4106564A for ; Wed, 6 Oct 2010 17:43:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0E98FC16 for ; Wed, 6 Oct 2010 17:43:27 +0000 (UTC) Received: by pvc21 with SMTP id 21so2462027pvc.13 for ; Wed, 06 Oct 2010 10:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=kxeY0cqkBrx1cYAKJrPQYtu7KfDYuJImBLe+LJ8bOlA=; b=QPtdNheld8GiGyy2MhS60hMBL0N0RSuxyYiN58vY24ZxaUG/BKvq+9pP5fqij1BddT XAnwXTHSBvgdbNUcxT1LIK1sfVZA+byAyECg9aDbctXp1Ebo4xr+CTulKP9SIYK5JFbe QzXrSrl33J/v4VUiUyKzunzNbW3TKLPYSYzKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JxgUTaxP9DrDvuFd7gXdMiMiVF2YG2o+LQ3lb/Vkj4Ou7VrymLEA4iRAtIvGWAa8eO 5j6TBG/B6JYrtvLQIXCsQ06p6Vb/2ttrCK2Fc/rlGCBrtFFhbI0TqfB8TPTlwO1bG9s1 5pgxrncaoAzEqAjjjwFKAMK5u/k7QE9ymKquM= Received: by 10.142.48.2 with SMTP id v2mr7512712wfv.276.1286387006595; Wed, 06 Oct 2010 10:43:26 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w14sm1182225wfd.6.2010.10.06.10.43.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 06 Oct 2010 10:43:25 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 6 Oct 2010 10:41:39 -0700 From: Pyun YongHyeon Date: Wed, 6 Oct 2010 10:41:39 -0700 To: a.smith@ukgrid.net Message-ID: <20101006174139.GC14879@michelle.cdnetworks.com> References: <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> <20100928222532.GD1252@michelle.cdnetworks.com> <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:43:27 -0000 On Wed, Oct 06, 2010 at 05:45:08PM +0100, a.smith@ukgrid.net wrote: > Hi, > > sorry not to have replied sooner. Ive been trying to get the end > user to confirm whether he has any issues with the server as it is. He > still hasnt replied :( > I think tho, its likely I will leave the server as is for the time > being as I have no information that it isnt working correctly (other > than continued watchdog messages in the logs), and wait for a more > mature bge driver to be tested and released. > Ok, there might be a couple of edge cases not handled in bge(4). I believe things will improve over time but it depends on users feedback and testing. Anyway thanks for reporting. From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 19:40:19 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8E34106567A; Wed, 6 Oct 2010 19:40:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0DB8FC14; Wed, 6 Oct 2010 19:40:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o96JeJPh088024; Wed, 6 Oct 2010 19:40:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o96JeJoC088014; Wed, 6 Oct 2010 19:40:19 GMT (envelope-from linimon) Date: Wed, 6 Oct 2010 19:40:19 GMT Message-Id: <201010061940.o96JeJoC088014@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/151198: [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: unable to reset channel 11 (2462 MHz, flags 0x480), hal status 14" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:40:19 -0000 Old Synopsis: ath/5416 fails bgscan with "ath0: ath_chan_set: unable to reset channel 11 (2462 MHz, flags 0x480), hal status 14" New Synopsis: [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: unable to reset channel 11 (2462 MHz, flags 0x480), hal status 14" Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 6 19:40:06 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=151198 From owner-freebsd-net@FreeBSD.ORG Wed Oct 6 22:36:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63A021065672 for ; Wed, 6 Oct 2010 22:36:33 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by mx1.freebsd.org (Postfix) with ESMTP id ED6FA8FC1A for ; Wed, 6 Oct 2010 22:36:32 +0000 (UTC) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id o96MaTbC060761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 6 Oct 2010 18:36:29 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.8+Sun/8.12.10) with ESMTP id o96MZa9k026334; Wed, 6 Oct 2010 18:35:36 -0400 (EDT) Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o96MZakO026331; Wed, 6 Oct 2010 18:35:36 -0400 (EDT) X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs Date: Wed, 6 Oct 2010 18:35:36 -0400 (EDT) From: Daniel Feenberg To: Warren Block In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20101006 #4280474, check: 20101006 clean Cc: freebsd-net@freebsd.org Subject: Re: Network booting FreeBSD with gpxelinx almost works X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 22:36:33 -0000 On Sat, 25 Sep 2010, Warren Block wrote: > On Sat, 25 Sep 2010, Daniel Feenberg wrote: > >> We have been network booting FreeBSD for some time with pxeboot. So I am >> confident that we have the dhcpd.conf and the root filesystem sufficient >> for diskless booting. But now we would like to have menu of OSs to boot and >> got the idea somewhere that gpxelinux could do that for us. We copied >> gpxelinux.0 from the syslinux-4.02 distribution and replaced pxeboot with >> "gpxelinux" in the dhcpd.conf file. Indeed with a configuration file in >> pxelinux.cfg like this: >> >> default freebsd >> label freebsd >> PXE pxeboot >> >> and the root path still specified as a DHCP option, FreeBSD 8.1 does boot. >> If I replace the first line with: >> >> UI menu.c32 >> >> the client does display the menu and but if one hits return to select the >> single item offered the client merely hangs for a minute, then announces >> "boot failure". I am guessing that once the UI is interposed, somehow the >> root path isn't getting transmitted to pxeboot. > > 4.01 works, both with menu.c32 and vesamenu.c32. I can't say I've > experimented much farther, but used it when writing this: > > http://www.wonkity.com/~wblock/docs/html/pxe.html > >> All the other gpxelinux boot kernels seem to expect the information about >> the root filesystem to be specified in the pxelinux.cfg file, rather than >> in dhcpd.conf. > > FreeBSD's pxeboot isn't as versatile as others. > >> Does anyone have experience with this? FreeBSD isn't mentioned anywhere I >> can find in the syslinux or gpxelinux documentation, and the various web >> posting I have found linking FreeBSD to gpxelinux are all about do >> installations of iso files over the net. > > Yes, that's one of the reasons I wrote the article above. > We finally got the thing working - by simply dropping gpxelinux and using pxelinux instead. Daniel Feenberg From owner-freebsd-net@FreeBSD.ORG Thu Oct 7 07:44:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427C0106566B for ; Thu, 7 Oct 2010 07:44:05 +0000 (UTC) (envelope-from d.aleksandrov@eis.ru) Received: from mx.eis.ru (mx.eis.ru [62.141.120.124]) by mx1.freebsd.org (Postfix) with ESMTP id 050978FC0A for ; Thu, 7 Oct 2010 07:44:04 +0000 (UTC) Message-ID: <4CAD71A8.4080602@eis.ru> Date: Thu, 07 Oct 2010 11:07:20 +0400 From: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQu9C10LrRgdCw0L3QtNGA0L7Qsg==?= Organization: EIS MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Rcpt-To: too long (recipient list exceeded maximum allowed size of 1 bytes) X-Spam-Status: No, score=-2.9 required=7.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.0 Subject: driver for broadcom 57711E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d.aleksandrov@eis.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 07:44:05 -0000 Hi! I really need broadcom 57711E driver for my FreeBSD 8.0 i386. Does anybody have this driver already? P.S. Also wanted David Christensen who had previously tried to write a driver. Thanks in advance for help. -- Best Regards, Dmitry Aleksandrov www.eis.ru From owner-freebsd-net@FreeBSD.ORG Thu Oct 7 09:49:18 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 6FEEF1065673; Thu, 7 Oct 2010 09:49:18 +0000 (UTC) Date: Thu, 7 Oct 2010 09:49:18 +0000 From: Alexey Dokuchaev To: Brandon Gooch Message-ID: <20101007094918.GA15399@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:49:18 -0000 On Wed, Oct 06, 2010 at 11:56:25AM -0500, Brandon Gooch wrote: > 2010/10/6 Alexey Dokuchaev : > > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: > >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does > >> not receive anything, while it does with ath or ural (even at the same > >> time). dmesg with debug.iwi=2 is below -- anything unusual? > >> > >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never > >> happened on 6.2-RELEASE. > > > > Just found this email sent to stable@ almost three years ago; sadly I > > have to confirm iwi(4) still exhibits these problems on fairly recent > > 7-STABLE (early Juneish). Maybe I have better luck on net@ (I am > > particularly interested in working monitor mode). Thanks. Any debug > > information will be gladly provided. Pointers where to look (revisions > > to try, patches, etc.) are greatly appreciated. > > I know this response isn't too helpful, but the whole Intel > PRO/Wireless 2200BG/2225BG/2915ABG open-source driver situation is not > too good. I could understand that, but it looks like FreeBSD has a *regression* between 6.2 and 7.x, which is different from just "overall not too good situation". Regressions are presumably should not happen and should be easier to fix than improving entire support stack in FOSS industry. :-) > Same goes for the Intel 3945ABG (wpi(4)); it's very easy in both Linux > and *BSDs to befuddle the Intel Wifi chips. > > Having said that, Bernhard Schmidt has made outstanding progress with > the iwn(4) driver, supporting Intel Wireless WiFi Link > 4965/1000/5000/5150/5300/6000/6050 series. > > Is it possible in your situation to try another wireless card? I know > some notebook computers only whitelist a small set of PCI devices... I think there are no technical obstacles w/my laptop, and I'd gladly try something else, preferably fully working under FreeBSD (inc. monitor mode and packet injection). Any particular recommendations (aside from iwn(4) supported chips mentioned above)? Thanks. ./danfe From owner-freebsd-net@FreeBSD.ORG Thu Oct 7 12:05:01 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6828A106566B; Thu, 7 Oct 2010 12:05:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1138FC0A; Thu, 7 Oct 2010 12:05:00 +0000 (UTC) Received: by iwn8 with SMTP id 8so289788iwn.13 for ; Thu, 07 Oct 2010 05:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WVIBEeabKe9glrRnmUR3fYsG9uChfbyfhQVr3NYWZ6o=; b=YQOOTkqjdfnDR4JflSmRgbvOPV3PSVr7wIkLbxhIf1svP3iNDQXGKYYTZWx9kcKkN0 yanfFUb0hxQNrRy1mYgmxbkKE90uKz5O3iBC5qbZh2iu/jX5oasN8hNDyxcOyloL8W2r crYRuzqi31u6nJ3n+O/kzw484xUw+YQFk/nbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uQJ9GOwLmAm3iOUdSZGiONCyrBSD6cYJHWoivUV4jDak7DuDBPEhwLL52xgDo4TFSA BuTcZozIL6V9Az275x8md+oo99C1MwElWExQYQeNubZE8B1kYUpFNZn69KtwdV3Vd9hO hUSEuW1EZ2YnI2cINCXso0yR9z5OxIat/aNrg= MIME-Version: 1.0 Received: by 10.231.182.201 with SMTP id cd9mr725662ibb.21.1286451278121; Thu, 07 Oct 2010 04:34:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.171.203 with HTTP; Thu, 7 Oct 2010 04:34:37 -0700 (PDT) In-Reply-To: <20101007094918.GA15399@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> Date: Thu, 7 Oct 2010 19:34:37 +0800 X-Google-Sender-Auth: EH3BEqMXPsbMNhVbKOH-k0OUNBM Message-ID: From: Adrian Chadd To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brandon Gooch , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 12:05:01 -0000 finding where the regression happened - eg, which revision along the 6.x/head branch at the time caused the issue, would likely help Bernard very much.. Adrian 2010/10/7 Alexey Dokuchaev : > On Wed, Oct 06, 2010 at 11:56:25AM -0500, Brandon Gooch wrote: >> 2010/10/6 Alexey Dokuchaev : >> > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: >> >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does >> >> not receive anything, while it does with ath or ural (even at the sam= e >> >> time). dmesg with debug.iwi=3D2 is below -- anything unusual? >> >> >> >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never >> >> happened on 6.2-RELEASE. >> > >> > Just found this email sent to stable@ almost three years ago; sadly I >> > have to confirm iwi(4) still exhibits these problems on fairly recent >> > 7-STABLE (early Juneish). =A0Maybe I have better luck on net@ (I am >> > particularly interested in working monitor mode). =A0Thanks. =A0Any de= bug >> > information will be gladly provided. =A0Pointers where to look (revisi= ons >> > to try, patches, etc.) are greatly appreciated. >> >> I know this response isn't too helpful, but the whole Intel >> PRO/Wireless 2200BG/2225BG/2915ABG open-source driver situation is not >> too good. > > I could understand that, but it looks like FreeBSD has a *regression* > between 6.2 and 7.x, which is different from just "overall not too good > situation". =A0Regressions are presumably should not happen and should be > easier to fix than improving entire support stack in FOSS industry. =A0:-= ) > >> Same goes for the Intel 3945ABG (wpi(4)); it's very easy in both Linux >> and *BSDs to befuddle the Intel Wifi chips. >> >> Having said that, Bernhard Schmidt has made outstanding progress with >> the iwn(4) driver, supporting Intel Wireless WiFi Link >> 4965/1000/5000/5150/5300/6000/6050 series. >> >> Is it possible in your situation to try another wireless card? I know >> some notebook computers only whitelist a small set of PCI devices... > > I think there are no technical obstacles w/my laptop, and I'd gladly try > something else, preferably fully working under FreeBSD (inc. monitor > mode and packet injection). =A0Any particular recommendations (aside from > iwn(4) supported chips mentioned above)? =A0Thanks. > > ./danfe > _______________________________________________ > 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 Oct 7 12:44:21 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B18106564A for ; Thu, 7 Oct 2010 12:44:21 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id E81438FC16 for ; Thu, 7 Oct 2010 12:44:20 +0000 (UTC) Received: by gyg4 with SMTP id 4so309902gyg.13 for ; Thu, 07 Oct 2010 05:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IrcPQEzVskgw0BpWiRUiR//xhxXvsdy3l0da1YXNEyc=; b=UJWh92HNDQWm/OYsTw2eKv+N9l7aW8tBSpiWZ3KKHxTovywT1wkyxjAtV582QgWe3Q jJq/tbnzL9jcg+gvecoxdkaY2DqI0eGKYv795v2hn1kSLkh1Z9XAuVeutNHhD+NJBcrB TdjkH1byMVBNIn2eHOZkgezzlHZUcRou/fGH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Trpn5RjciOEElwDZM+xTnqYzNLejBw9YmDfzWWUYtEjszFqLCKi1vZzDvQMFSHWHkB peoTelRPJG6BRU487e7Ufuyfy3d4pCxM+fID5msBwuF+fvesMaahzJu34kbSKWBcUFck tNJ1rPfkMVLPokkJfJ9p0Zz8yLtL2xNI4NOXU= MIME-Version: 1.0 Received: by 10.151.41.17 with SMTP id t17mr981014ybj.443.1286455460216; Thu, 07 Oct 2010 05:44:20 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Thu, 7 Oct 2010 05:44:20 -0700 (PDT) In-Reply-To: References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> Date: Thu, 7 Oct 2010 12:44:20 +0000 Message-ID: From: Paul B Mahol To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , Alexey Dokuchaev , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 12:44:21 -0000 On 10/7/10, Adrian Chadd wrote: > finding where the regression happened - eg, which revision along the > 6.x/head branch at the time caused the issue, would likely help > Bernard very much.. > Also, exact instructions how to reproduce problem would help. Monitor and injection work commpletly different after vap. I do not think that kismet and aircrack-ng from ports are patched at all. From owner-freebsd-net@FreeBSD.ORG Thu Oct 7 14:25:50 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B3EE1065673; Thu, 7 Oct 2010 14:25:50 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21ED68FC18; Thu, 7 Oct 2010 14:25:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o97EPobw097764; Thu, 7 Oct 2010 14:25:50 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o97EPoIl097760; Thu, 7 Oct 2010 14:25:50 GMT (envelope-from adrian) Date: Thu, 7 Oct 2010 14:25:50 GMT Message-Id: <201010071425.o97EPoIl097760@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, adrian@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/151198: [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: unable to reset channel 11 (2462 MHz, flags 0x480), hal status 14" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:25:50 -0000 Synopsis: [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: unable to reset channel 11 (2462 MHz, flags 0x480), hal status 14" Responsible-Changed-From-To: freebsd-net->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Thu Oct 7 14:25:42 UTC 2010 Responsible-Changed-Why: my turn! http://www.freebsd.org/cgi/query-pr.cgi?pr=151198 From owner-freebsd-net@FreeBSD.ORG Thu Oct 7 18:55:41 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6DD106564A; Thu, 7 Oct 2010 18:55:41 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id B8E638FC16; Thu, 7 Oct 2010 18:55:39 +0000 (UTC) Received: by qyk30 with SMTP id 30so1223205qyk.13 for ; Thu, 07 Oct 2010 11:55:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.186.84 with SMTP id cr20mr612642qab.259.1286477402406; Thu, 07 Oct 2010 11:50:02 -0700 (PDT) Received: by 10.229.32.15 with HTTP; Thu, 7 Oct 2010 11:49:59 -0700 (PDT) X-Originating-IP: [84.180.238.142] In-Reply-To: <20101007094918.GA15399@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> Date: Thu, 7 Oct 2010 20:49:59 +0200 Message-ID: From: Bernhard Schmidt To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brandon Gooch , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:55:41 -0000 2010/10/7 Alexey Dokuchaev : > On Wed, Oct 06, 2010 at 11:56:25AM -0500, Brandon Gooch wrote: >> 2010/10/6 Alexey Dokuchaev : >> > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: >> >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does >> >> not receive anything, while it does with ath or ural (even at the sam= e >> >> time). dmesg with debug.iwi=3D2 is below -- anything unusual? >> >> >> >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never >> >> happened on 6.2-RELEASE. >> > >> > Just found this email sent to stable@ almost three years ago; sadly I >> > have to confirm iwi(4) still exhibits these problems on fairly recent >> > 7-STABLE (early Juneish). =A0Maybe I have better luck on net@ (I am >> > particularly interested in working monitor mode). =A0Thanks. =A0Any de= bug >> > information will be gladly provided. =A0Pointers where to look (revisi= ons >> > to try, patches, etc.) are greatly appreciated. >> >> I know this response isn't too helpful, but the whole Intel >> PRO/Wireless 2200BG/2225BG/2915ABG open-source driver situation is not >> too good. > > I could understand that, but it looks like FreeBSD has a *regression* > between 6.2 and 7.x, which is different from just "overall not too good > situation". =A0Regressions are presumably should not happen and should be > easier to fix than improving entire support stack in FOSS industry. =A0:-= ) Indeed, it's really a regression and that should be fixed. >> Same goes for the Intel 3945ABG (wpi(4)); it's very easy in both Linux >> and *BSDs to befuddle the Intel Wifi chips. >> >> Having said that, Bernhard Schmidt has made outstanding progress with >> the iwn(4) driver, supporting Intel Wireless WiFi Link >> 4965/1000/5000/5150/5300/6000/6050 series. >> >> Is it possible in your situation to try another wireless card? I know >> some notebook computers only whitelist a small set of PCI devices... > > I think there are no technical obstacles w/my laptop, and I'd gladly try > something else, preferably fully working under FreeBSD (inc. monitor > mode and packet injection). =A0Any particular recommendations (aside from > iwn(4) supported chips mentioned above)? =A0Thanks. Can't speak for packet injection (never played with that) but run(4) should also have pretty good support, at least there is someone actively working on it. Also ath(4) gets some love from adrian@ currently so this might also be an option. --=20 Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Oct 7 19:13:53 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2E03106564A; Thu, 7 Oct 2010 19:13:53 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 451FE8FC17; Thu, 7 Oct 2010 19:13:48 +0000 (UTC) Received: by qyk30 with SMTP id 30so1245810qyk.13 for ; Thu, 07 Oct 2010 12:13:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.198.73 with SMTP id en9mr603070qab.18.1286477017389; Thu, 07 Oct 2010 11:43:37 -0700 (PDT) Received: by 10.229.32.15 with HTTP; Thu, 7 Oct 2010 11:43:37 -0700 (PDT) X-Originating-IP: [84.180.238.142] In-Reply-To: <20101006100335.GA26843@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> Date: Thu, 7 Oct 2010 20:43:37 +0200 Message-ID: From: Bernhard Schmidt To: Alexey Dokuchaev Content-Type: multipart/mixed; boundary=20cf300fb16fa21c7d04920b4594 Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:13:54 -0000 --20cf300fb16fa21c7d04920b4594 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/10/6 Alexey Dokuchaev : > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does >> not receive anything, while it does with ath or ural (even at the same >> time). dmesg with debug.iwi=3D2 is below -- anything unusual? >> >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never >> happened on 6.2-RELEASE. > > Just found this email sent to stable@ almost three years ago; sadly I > have to confirm iwi(4) still exhibits these problems on fairly recent > 7-STABLE (early Juneish). =A0Maybe I have better luck on net@ (I am > particularly interested in working monitor mode). =A0Thanks. =A0Any debug > information will be gladly provided. =A0Pointers where to look (revisions > to try, patches, etc.) are greatly appreciated. Try the attached patch, this is basically the code from stable/6 ported to head and stable/7. I did only some basic tests but monitor mode seems to work and it is still possible to use the card in STA mode. I'm not sure why that got lost, but there must be a reason I'm not seeing right now. If someone has more knowledge about that, please let me know, otherwise I intend to commit it this weekend. --=20 Bernhard --20cf300fb16fa21c7d04920b4594 Content-Type: application/octet-stream; name="iwi_monitor-head.diff" Content-Disposition: attachment; filename="iwi_monitor-head.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gezz9pt70 SW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aXZhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdp L2lmX2l3aXZhci5oCShyZXZpc2lvbiAyMTM1MTcpCisrKyBzeXMvZGV2L2l3aS9pZl9pd2l2YXIu aAkod29ya2luZyBjb3B5KQpAQCAtMTkzLDYgKzE5Myw3IEBAIHN0cnVjdCBpd2lfc29mdGMgewog CXN0cnVjdCB0YXNrCQlzY19yZXN0YXJ0dGFzazsJLyogcmVzdGFydCBhZGFwdGVyIHByb2Nlc3Np bmcgKi8KIAlzdHJ1Y3QgdGFzawkJc2NfZGlzYXNzb2N0YXNrOwogCXN0cnVjdCB0YXNrCQlzY193 bWV0YXNrOwkvKiBzZXQgd21lIHBhcmFtZXRlcnMgKi8KKwlzdHJ1Y3QgdGFzawkJc2NfbW9uaXRv cnRhc2s7CiAKIAl1bnNpZ25lZCBpbnQJCXNjX3NvZnRsZWQgOiAxLAkvKiBlbmFibGUgTEVEIGdw aW8gc3RhdHVzICovCiAJCQkJc2NfbGVkc3RhdGU6IDEsCS8qIExFRCBvbi9vZmYgc3RhdGUgKi8K SW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdpL2lm X2l3aS5jCShyZXZpc2lvbiAyMTM1MTcpCisrKyBzeXMvZGV2L2l3aS9pZl9pd2kuYwkod29ya2lu ZyBjb3B5KQpAQCAtMTgwLDYgKzE4MCw3IEBAIHN0YXRpYyB2b2lkCWl3aV9yZWxlYXNlX2Z3X2Rt YShzdHJ1Y3QgaXdpX3NvZnRjICpzCiBzdGF0aWMgaW50CWl3aV9jb25maWcoc3RydWN0IGl3aV9z b2Z0YyAqKTsKIHN0YXRpYyBpbnQJaXdpX2dldF9maXJtd2FyZShzdHJ1Y3QgaXdpX3NvZnRjICos IGVudW0gaWVlZTgwMjExX29wbW9kZSk7CiBzdGF0aWMgdm9pZAlpd2lfcHV0X2Zpcm13YXJlKHN0 cnVjdCBpd2lfc29mdGMgKik7CitzdGF0aWMgdm9pZAlpd2lfbW9uaXRvcl9zY2FuKHZvaWQgKiwg aW50KTsKIHN0YXRpYyBpbnQJaXdpX3NjYW5jaGFuKHN0cnVjdCBpd2lfc29mdGMgKiwgdW5zaWdu ZWQgbG9uZywgaW50KTsKIHN0YXRpYyB2b2lkCWl3aV9zY2FuX3N0YXJ0KHN0cnVjdCBpZWVlODAy MTFjb20gKik7CiBzdGF0aWMgdm9pZAlpd2lfc2Nhbl9lbmQoc3RydWN0IGllZWU4MDIxMWNvbSAq KTsKQEAgLTI5Miw2ICsyOTMsNyBAQCBpd2lfYXR0YWNoKGRldmljZV90IGRldikKIAlUQVNLX0lO SVQoJnNjLT5zY19yZXN0YXJ0dGFzaywgMCwgaXdpX3Jlc3RhcnQsIHNjKTsKIAlUQVNLX0lOSVQo JnNjLT5zY19kaXNhc3NvY3Rhc2ssIDAsIGl3aV9kaXNhc3NvYywgc2MpOwogCVRBU0tfSU5JVCgm c2MtPnNjX3dtZXRhc2ssIDAsIGl3aV91cGRhdGVfd21lLCBzYyk7CisJVEFTS19JTklUKCZzYy0+ c2NfbW9uaXRvcnRhc2ssIDAsIGl3aV9tb25pdG9yX3NjYW4sIHNjKTsKIAogCWNhbGxvdXRfaW5p dF9tdHgoJnNjLT5zY193ZHRpbWVyLCAmc2MtPnNjX210eCwgMCk7CiAJY2FsbG91dF9pbml0X210 eCgmc2MtPnNjX3JmdGltZXIsICZzYy0+c2NfbXR4LCAwKTsKQEAgLTQ2MCw2ICs0NjIsNyBAQCBp d2lfZGV0YWNoKGRldmljZV90IGRldikKIAlpZWVlODAyMTFfZHJhaW50YXNrKGljLCAmc2MtPnNj X3JhZGlvZmZ0YXNrKTsKIAlpZWVlODAyMTFfZHJhaW50YXNrKGljLCAmc2MtPnNjX3Jlc3RhcnR0 YXNrKTsKIAlpZWVlODAyMTFfZHJhaW50YXNrKGljLCAmc2MtPnNjX2Rpc2Fzc29jdGFzayk7CisJ aWVlZTgwMjExX2RyYWludGFzayhpYywgJnNjLT5zY19tb25pdG9ydGFzayk7CiAKIAlpd2lfc3Rv cChzYyk7CiAKQEAgLTk4OCw3ICs5OTEsOCBAQCBpd2lfbmV3c3RhdGUoc3RydWN0IGllZWU4MDIx MXZhcCAqdmFwLCBlbnVtIGllZWU4MAogCQkJICogVGhpcyBpcyBhbGwgdG90YWxseSBib2d1cyBh bmQgbmVlZHMgdG8gYmUgcmVkb25lLgogCQkJICovCiAJCQlpd2lfYXV0aF9hbmRfYXNzb2Moc2Ms IHZhcCk7Ci0JCX0KKwkJfSBlbHNlIGlmICh2YXAtPml2X29wbW9kZSA9PSBJRUVFODAyMTFfTV9N T05JVE9SKQorCQkJaWVlZTgwMjExX3J1bnRhc2soaWMsICZzYy0+c2NfbW9uaXRvcnRhc2spOwog CQlicmVhazsKIAljYXNlIElFRUU4MDIxMV9TX0FTU09DOgogCQkvKgpAQCAtMTQwNyw2ICsxNDEx LDE4IEBAIGl3aV9ub3RpZmljYXRpb25faW50cihzdHJ1Y3QgaXdpX3NvZnRjICpzYywgc3RydWN0 CiAKIAkJSVdJX1NUQVRFX0VORChzYywgSVdJX0ZXX1NDQU5OSU5HKTsKIAorCQkvKgorCQkgKiBN b25pdG9yIG1vZGUgd29ya3MgYnkgZG9pbmcgYSBwYXNzaXZlIHNjYW4gdG8gc2V0CisJCSAqIHRo ZSBjaGFubmVsIGFuZCBlbmFibGUgcnguICBCZWNhdXNlIHdlIGRvbid0IHdhbnQKKwkJICogdG8g YWJvcnQgYSBzY2FuIGxlc3QgdGhlIGZpcm13YXJlIGNyYXNoIHdlIHNjYW4KKwkJICogZm9yIGEg c2hvcnQgcGVyaW9kIG9mIHRpbWUgYW5kIGF1dG9tYXRpY2FsbHkgcmVzdGFydAorCQkgKiB0aGUg c2NhbiB3aGVuIG5vdGlmaWVkIHRoZSBzd2VlcCBoYXMgY29tcGxldGVkLgorCQkgKi8KKwkJaWYg KHZhcC0+aXZfb3Btb2RlID09IElFRUU4MDIxMV9NX01PTklUT1IpIHsKKwkJCWllZWU4MDIxMV9y dW50YXNrKGljLCAmc2MtPnNjX21vbml0b3J0YXNrKTsKKwkJCWJyZWFrOworCQl9CisKIAkJaWYg KHNjYW4tPnN0YXR1cyA9PSBJV0lfU0NBTl9DT01QTEVURUQpIHsKIAkJCS8qIE5COiBkb24ndCBu ZWVkIHRvIGRlZmVyLCBuZXQ4MDIxMSBkb2VzIGl0IGZvciB1cyAqLwogCQkJaWVlZTgwMjExX3Nj YW5fbmV4dCh2YXApOwpAQCAtMjU1Nyw2ICsyNTczLDExIEBAIGl3aV9jb25maWcoc3RydWN0IGl3 aV9zb2Z0YyAqc2MpCiAJY29uZmlnLmFuc3dlcl9wYnJlcSA9IChpYy0+aWNfb3Btb2RlID09IElF RUU4MDIxMV9NX0lCU1MpID8gMSA6IDA7CiAJY29uZmlnLmRpc2FibGVfdW5pY2FzdF9kZWNyeXB0 aW9uID0gMTsKIAljb25maWcuZGlzYWJsZV9tdWx0aWNhc3RfZGVjcnlwdGlvbiA9IDE7CisJaWYg KGljLT5pY19vcG1vZGUgPT0gSUVFRTgwMjExX01fTU9OSVRPUikgeworCQljb25maWcuYWxsb3df aW52YWxpZF9mcmFtZXMgPSAxOworCQljb25maWcuYWxsb3dfYmVhY29uX2FuZF9wcm9iZV9yZXNw ID0gMTsKKwkJY29uZmlnLmFsbG93X21ndCA9IDE7CisJfQogCURQUklOVEYoKCJDb25maWd1cmlu ZyBhZGFwdGVyXG4iKSk7CiAJZXJyb3IgPSBpd2lfY21kKHNjLCBJV0lfQ01EX1NFVF9DT05GSUcs ICZjb25maWcsIHNpemVvZiBjb25maWcpOwogCWlmIChlcnJvciAhPSAwKQpAQCAtMjY0Miw2ICsy NjYzLDE4IEBAIHNjYW5fYmFuZChjb25zdCBzdHJ1Y3QgaWVlZTgwMjExX2NoYW5uZWwgKmMpCiAJ cmV0dXJuIElFRUU4MDIxMV9JU19DSEFOXzVHSFooYykgPyAgSVdJX0NIQU5fNUdIWiA6IElXSV9D SEFOXzJHSFo7CiB9CiAKK3N0YXRpYyB2b2lkCitpd2lfbW9uaXRvcl9zY2FuKHZvaWQgKmFyZywg aW50IG5wZW5kaW5nKQoreworCXN0cnVjdCBpZWVlODAyMTFjb20gKmljID0gYXJnOworCXN0cnVj dCBpd2lfc29mdGMgKnNjID0gaWMtPmljX2lmcC0+aWZfc29mdGM7CisJSVdJX0xPQ0tfREVDTDsK KworCUlXSV9MT0NLKHNjKTsKKwkodm9pZCkgaXdpX3NjYW5jaGFuKHNjLCAyMDAwLCAwKTsKKwlJ V0lfVU5MT0NLKHNjKTsKK30KKwogLyoKICAqIFN0YXJ0IGEgc2NhbiBvbiB0aGUgY3VycmVudCBj aGFubmVsIG9yIGFsbCBjaGFubmVscy4KICAqLwo= --20cf300fb16fa21c7d04920b4594 Content-Type: application/octet-stream; name="iwi_monitor-stable7.diff" Content-Disposition: attachment; filename="iwi_monitor-stable7.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gezza07q1 SW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aXZhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdp L2lmX2l3aXZhci5oCShyZXZpc2lvbiAyMTM1MjIpCisrKyBzeXMvZGV2L2l3aS9pZl9pd2l2YXIu aAkod29ya2luZyBjb3B5KQpAQCAtMTkzLDYgKzE5Myw3IEBAIHN0cnVjdCBpd2lfc29mdGMgewog CXN0cnVjdCB0YXNrCQlzY19zY2FuYWJvcnR0YXNrOwkvKiBjYW5jZWwgYWN0aXZlIHNjYW4gKi8K IAlzdHJ1Y3QgdGFzawkJc2NfcmVzdGFydHRhc2s7CS8qIHJlc3RhcnQgYWRhcHRlciBwcm9jZXNz aW5nICovCiAJc3RydWN0IHRhc2sJCXNjX29wc3Rhc2s7CS8qIHNjYW4gLyBhdXRoIHByb2Nlc3Np bmcgKi8KKwlzdHJ1Y3QgdGFzawkJc2NfbW9uaXRvcnRhc2s7CiAKIAl1bnNpZ25lZCBpbnQJCXNj X3NvZnRsZWQgOiAxLAkvKiBlbmFibGUgTEVEIGdwaW8gc3RhdHVzICovCiAJCQkJc2NfbGVkc3Rh dGU6IDEsCS8qIExFRCBvbi9vZmYgc3RhdGUgKi8KSW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aS5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdpL2lmX2l3aS5jCShyZXZpc2lvbiAyMTM1MjIpCisr KyBzeXMvZGV2L2l3aS9pZl9pd2kuYwkod29ya2luZyBjb3B5KQpAQCAtMTYzLDYgKzE2Myw3IEBA IHN0YXRpYyB2b2lkCWl3aV9yZWxlYXNlX2Z3X2RtYShzdHJ1Y3QgaXdpX3NvZnRjICpzCiBzdGF0 aWMgaW50CWl3aV9jb25maWcoc3RydWN0IGl3aV9zb2Z0YyAqKTsKIHN0YXRpYyBpbnQJaXdpX2dl dF9maXJtd2FyZShzdHJ1Y3QgaXdpX3NvZnRjICopOwogc3RhdGljIHZvaWQJaXdpX3B1dF9maXJt d2FyZShzdHJ1Y3QgaXdpX3NvZnRjICopOworc3RhdGljIHZvaWQJaXdpX21vbml0b3Jfc2Nhbih2 b2lkICosIGludCk7CiBzdGF0aWMgaW50CWl3aV9zY2FuY2hhbihzdHJ1Y3QgaXdpX3NvZnRjICos IHVuc2lnbmVkIGxvbmcsIGludCk7CiBzdGF0aWMgdm9pZAlpd2lfc2Nhbl9zdGFydChzdHJ1Y3Qg aWVlZTgwMjExY29tICopOwogc3RhdGljIHZvaWQJaXdpX3NjYW5fZW5kKHN0cnVjdCBpZWVlODAy MTFjb20gKik7CkBAIC0yOTEsNiArMjkyLDcgQEAgaXdpX2F0dGFjaChkZXZpY2VfdCBkZXYpCiAJ VEFTS19JTklUKCZzYy0+c2NfcmVzdGFydHRhc2ssIDAsIGl3aV9yZXN0YXJ0LCBzYyk7CiAJVEFT S19JTklUKCZzYy0+c2Nfb3BzdGFzaywgMCwgaXdpX29wcywgc2MpOwogCVRBU0tfSU5JVCgmc2Mt PnNjX3NjYW5hYm9ydHRhc2ssIDAsIGl3aV9zY2FuYWJvcnQsIHNjKTsKKwlUQVNLX0lOSVQoJnNj LT5zY19tb25pdG9ydGFzaywgMCwgaXdpX21vbml0b3Jfc2Nhbiwgc2MpOwogCWNhbGxvdXRfaW5p dF9tdHgoJnNjLT5zY193ZHRpbWVyLCAmc2MtPnNjX210eCwgMCk7CiAKIAlpZiAocGNpX2dldF9w b3dlcnN0YXRlKGRldikgIT0gUENJX1BPV0VSU1RBVEVfRDApIHsKQEAgLTk3OCw3ICs5ODAsOCBA QCBpd2lfbmV3c3RhdGUoc3RydWN0IGllZWU4MDIxMWNvbSAqaWMsIGVudW0gaWVlZTgwMgogCQkJ ICovCiAJCQlpZiAoaWMtPmljX3N0YXRlID09IElFRUU4MDIxMV9TX1NDQU4pCiAJCQkJaXdpX2Fz c29jKGljKTsKLQkJfSAKKwkJfSBlbHNlIGlmIChpYy0+aWNfb3Btb2RlID09IElFRUU4MDIxMV9N X01PTklUT1IpCisJCQl0YXNrcXVldWVfZW5xdWV1ZShzYy0+c2NfdHEsICZzYy0+c2NfbW9uaXRv cnRhc2spOwogCQlicmVhazsKIAljYXNlIElFRUU4MDIxMV9TX0lOSVQ6CiAJCS8qCkBAIC0xNDEx LDYgKzE0MTQsMTggQEAgaXdpX25vdGlmaWNhdGlvbl9pbnRyKHN0cnVjdCBpd2lfc29mdGMgKnNj LCBzdHJ1Y3QKIAogCQlJV0lfU1RBVEVfRU5EKHNjLCBJV0lfRldfU0NBTk5JTkcpOwogCisJCS8q CisJCSAqIE1vbml0b3IgbW9kZSB3b3JrcyBieSBkb2luZyBhIHBhc3NpdmUgc2NhbiB0byBzZXQK KwkJICogdGhlIGNoYW5uZWwgYW5kIGVuYWJsZSByeC4gIEJlY2F1c2Ugd2UgZG9uJ3Qgd2FudAor CQkgKiB0byBhYm9ydCBhIHNjYW4gbGVzdCB0aGUgZmlybXdhcmUgY3Jhc2ggd2Ugc2NhbgorCQkg KiBmb3IgYSBzaG9ydCBwZXJpb2Qgb2YgdGltZSBhbmQgYXV0b21hdGljYWxseSByZXN0YXJ0CisJ CSAqIHRoZSBzY2FuIHdoZW4gbm90aWZpZWQgdGhlIHN3ZWVwIGhhcyBjb21wbGV0ZWQuCisJCSAq LworCQlpZiAoaWMtPmljX29wbW9kZSA9PSBJRUVFODAyMTFfTV9NT05JVE9SKSB7CisJCQl0YXNr cXVldWVfZW5xdWV1ZShzYy0+c2NfdHEsICZzYy0+c2NfbW9uaXRvcnRhc2spOworCQkJYnJlYWs7 CisJCX0KKwogCQlpZiAoc2Nhbi0+c3RhdHVzID09IElXSV9TQ0FOX0NPTVBMRVRFRCkKIAkJCWll ZWU4MDIxMV9zY2FuX25leHQoaWMpOwogCkBAIC0yNTk1LDYgKzI2MTAsMTEgQEAgaXdpX2NvbmZp ZyhzdHJ1Y3QgaXdpX3NvZnRjICpzYykKIAljb25maWcuYW5zd2VyX3BicmVxID0gKGljLT5pY19v cG1vZGUgPT0gSUVFRTgwMjExX01fSUJTUykgPyAxIDogMDsKIAljb25maWcuZGlzYWJsZV91bmlj YXN0X2RlY3J5cHRpb24gPSAxOwogCWNvbmZpZy5kaXNhYmxlX211bHRpY2FzdF9kZWNyeXB0aW9u ID0gMTsKKwlpZiAoaWMtPmljX29wbW9kZSA9PSBJRUVFODAyMTFfTV9NT05JVE9SKSB7CisJCWNv bmZpZy5hbGxvd19pbnZhbGlkX2ZyYW1lcyA9IDE7CisJCWNvbmZpZy5hbGxvd19iZWFjb25fYW5k X3Byb2JlX3Jlc3AgPSAxOworCQljb25maWcuYWxsb3dfbWd0ID0gMTsKKwl9CiAJRFBSSU5URigo IkNvbmZpZ3VyaW5nIGFkYXB0ZXJcbiIpKTsKIAllcnJvciA9IGl3aV9jbWQoc2MsIElXSV9DTURf U0VUX0NPTkZJRywgJmNvbmZpZywgc2l6ZW9mIGNvbmZpZyk7CiAJaWYgKGVycm9yICE9IDApCkBA IC0yNzE3LDYgKzI3MzcsMTggQEAgc2Nhbl9iYW5kKGNvbnN0IHN0cnVjdCBpZWVlODAyMTFfY2hh bm5lbCAqYykKIAlyZXR1cm4gSUVFRTgwMjExX0lTX0NIQU5fNUdIWihjKSA/ICBJV0lfQ0hBTl81 R0haIDogSVdJX0NIQU5fMkdIWjsKIH0KIAorc3RhdGljIHZvaWQKK2l3aV9tb25pdG9yX3NjYW4o dm9pZCAqYXJnLCBpbnQgbnBlbmRpbmcpCit7CisJc3RydWN0IGllZWU4MDIxMWNvbSAqaWMgPSBh cmc7CisJc3RydWN0IGl3aV9zb2Z0YyAqc2MgPSBpYy0+aWNfaWZwLT5pZl9zb2Z0YzsKKwlJV0lf TE9DS19ERUNMOworCisJSVdJX0xPQ0soc2MpOworCSh2b2lkKSBpd2lfc2NhbmNoYW4oc2MsIDIw MDAsIDApOworCUlXSV9VTkxPQ0soc2MpOworfQorCiAvKgogICogU3RhcnQgYSBzY2FuIG9uIHRo ZSBjdXJyZW50IGNoYW5uZWwgb3IgYWxsIGNoYW5uZWxzLgogICovCg== --20cf300fb16fa21c7d04920b4594-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 09:16:34 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 0C34E106566C; Fri, 8 Oct 2010 09:16:34 +0000 (UTC) Date: Fri, 8 Oct 2010 09:16:34 +0000 From: Alexey Dokuchaev To: Paul B Mahol Message-ID: <20101008091633.GA21612@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Brandon Gooch , Adrian Chadd , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:16:34 -0000 On Thu, Oct 07, 2010 at 12:44:20PM +0000, Paul B Mahol wrote: > On 10/7/10, Adrian Chadd wrote: > > finding where the regression happened - eg, which revision along the > > 6.x/head branch at the time caused the issue, would likely help > > Bernard very much.. Certainly, if my resources would permit, I'd bisect to offending revision(s) myself. However, I'm away from home right now, with just my laptop with me with no free space to host another FreeBSD installation. > Also, exact instructions how to reproduce problem would help. That's easy: # aireplay-ng -9 iwi0 ;-) > Monitor and injection work commpletly different after vap. > > I do not think that kismet and aircrack-ng from ports are patched at all. This is at least partially true; SVN trunk of aircrack-ng behaves better than 1.1 version from ports (WRT infamous wi_write() problem). I will work out patches for the port after kernel side will get fixed. ./danfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 11:48:58 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459A2106564A; Fri, 8 Oct 2010 11:48:58 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 09CA68FC0C; Fri, 8 Oct 2010 11:48:57 +0000 (UTC) Received: by pwi8 with SMTP id 8so242841pwi.13 for ; Fri, 08 Oct 2010 04:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=n0kEkzPOpdhmIEPZ9hFsT/h0ZYC94rkx6JO17/ODHKE=; b=aypIQvKXzpJxxyLQ6rOLGnb5EP2ue/ed7Pk4WaSq828tOG9E3cOjgnGBTFdA7/MHRn iS+rQlATdujRIVChM4chNKAhMHVilJuuerPDcceJSZFhlYYvS+g+Xrto256//rg05gJS dgQYhWcrBnlved3JFkPNi+/8NdUom4Yhrs4tU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i3p3ufiA3A0KerPGe9tFNl264VBBTSAn6Aqw1YLvE2hIkW4h8Nf2qAzvODYJaSLbrq OwsbDR3WmhWd7grFkxvNe8LfU9ZWbABcBJ86Ffz0VJ1ytrVIGVMzG8khQMMDmhZjwyF1 CUiPCDb1WknY6lf2ScDW2F4whhzZDpeI3NQKM= MIME-Version: 1.0 Received: by 10.114.127.18 with SMTP id z18mr2486127wac.171.1286538537604; Fri, 08 Oct 2010 04:48:57 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Fri, 8 Oct 2010 04:48:57 -0700 (PDT) In-Reply-To: <20101008091633.GA21612@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> <20101008091633.GA21612@FreeBSD.org> Date: Fri, 8 Oct 2010 11:48:57 +0000 Message-ID: From: Paul B Mahol To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , Adrian Chadd , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:48:58 -0000 On 10/8/10, Alexey Dokuchaev wrote: > On Thu, Oct 07, 2010 at 12:44:20PM +0000, Paul B Mahol wrote: >> On 10/7/10, Adrian Chadd wrote: >> > finding where the regression happened - eg, which revision along the >> > 6.x/head branch at the time caused the issue, would likely help >> > Bernard very much.. > > Certainly, if my resources would permit, I'd bisect to offending > revision(s) myself. However, I'm away from home right now, with just my > laptop with me with no free space to host another FreeBSD installation. > >> Also, exact instructions how to reproduce problem would help. > > That's easy: > # aireplay-ng -9 iwi0 ;-) > >> Monitor and injection work commpletly different after vap. >> >> I do not think that kismet and aircrack-ng from ports are patched at all. > > This is at least partially true; SVN trunk of aircrack-ng behaves better > than 1.1 version from ports (WRT infamous wi_write() problem). I will > work out patches for the port after kernel side will get fixed. Heh, you are wrong, svn trunk of aircrack-ng is broken versus wi_write() "problem". Look at "famous" ticket number 666 Injection on FreeBSD (I forgot exact revision) will work only in AHDEMO mode. Unlike before you can not inject in MONITOR mode. From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 12:29:39 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id CD05C1065670; Fri, 8 Oct 2010 12:29:39 +0000 (UTC) Date: Fri, 8 Oct 2010 12:29:39 +0000 From: Alexey Dokuchaev To: Paul B Mahol Message-ID: <20101008122939.GA52927@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> <20101008091633.GA21612@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Brandon Gooch , Adrian Chadd , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:29:39 -0000 On Fri, Oct 08, 2010 at 11:48:57AM +0000, Paul B Mahol wrote: > On 10/8/10, Alexey Dokuchaev wrote: > > On Thu, Oct 07, 2010 at 12:44:20PM +0000, Paul B Mahol wrote: > >> Monitor and injection work commpletly different after vap. > >> > >> I do not think that kismet and aircrack-ng from ports are patched at all. > > > > This is at least partially true; SVN trunk of aircrack-ng behaves better > > than 1.1 version from ports (WRT infamous wi_write() problem). I will > > work out patches for the port after kernel side will get fixed. > > Heh, you are wrong, svn trunk of aircrack-ng is broken versus > wi_write() "problem". > > Look at "famous" ticket number 666 Oh, that's right, I think I've been testing SVN trunk with this patch applied (maybe with =| MONITOR hunk, which I found in another version of similar patch). Without a patch injection test fails immediately, before wi_write() gets a chance to trigger. > Injection on FreeBSD (I forgot exact revision) will work only in AHDEMO mode. > Unlike before you can not inject in MONITOR mode. I've seen people say this, but I could not find more elaborative answer. I am also not sure about AHDEMO mode, since iwi(4) reports this for me: $ ifconfig iwi0 list caps iwi0=25818300 ./danfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 12:42:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20C54106564A for ; Fri, 8 Oct 2010 12:42:54 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id D342A8FC15 for ; Fri, 8 Oct 2010 12:42:53 +0000 (UTC) Received: from [89.21.28.38] (port=34848 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net id 1P4CHk-000Bbb-3F; Fri, 08 Oct 2010 13:42:52 +0100 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Fri, 08 Oct 2010 13:42:51 +0100 Message-ID: <20101008134251.367570jyw4igvkg8@webmail2.ukgrid.net> Date: Fri, 08 Oct 2010 13:42:51 +0100 From: a.smith@ukgrid.net To: pyunyh@gmail.com References: <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> <20100928222532.GD1252@michelle.cdnetworks.com> <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> <20101006174139.GC14879@michelle.cdnetworks.com> In-Reply-To: <20101006174139.GC14879@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) / FreeBSD-8.0 Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:42:54 -0000 Quoting Pyun YongHyeon : >> > > Ok, there might be a couple of edge cases not handled in bge(4). I > believe things will improve over time but it depends on users > feedback and testing. On this particular server I really need to get it stable and leave. We are awaiting delivery of a Dell R610, I would think its likely it uses the same ethernet chipset so will be able to perform more testing on this. In theory we should have the server next week, will let you know, thanks Andy. From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 13:18:50 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 10F76106566B; Fri, 8 Oct 2010 13:18:50 +0000 (UTC) Date: Fri, 8 Oct 2010 13:18:50 +0000 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20101008131849.GA54860@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:18:50 -0000 On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > Try the attached patch, this is basically the code from stable/6 > ported to head and stable/7. I did only some basic tests but monitor > mode seems to work and it is still possible to use the card in STA > mode. > > I'm not sure why that got lost, but there must be a reason I'm not > seeing right now. If someone has more knowledge about that, please > let me know, otherwise I intend to commit it this weekend. Unfortunately, I am getting instant panic when trying any of aircrack-ng suite utilities ("ifconfig iwi0 scan/list scan" works though): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0768d42 stack pointer = 0x28:0xe4112c80 frame pointer = 0x28:0xe4112c98 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 35 (iwi0 taskq) (kgdb) bt ... #6 0xc060cae0 in trap_fatal (frame=0xe4112c40, eva=0) at /usr/src/sys/i386/i386/trap.c:941 #7 0xc060cd90 in trap_pfault (frame=0xe4112c40, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:863 #8 0xc060d7f7 in trap (frame=0xe4112c40) at /usr/src/sys/i386/i386/trap.c:541 #9 0xc05f4d9b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc0768d42 in iwi_monitor_scan (arg=0xc3dcc000, npending=4) at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2744 ... (kgdb) f 10 #10 0xc0768d42 in iwi_monitor_scan (arg=0xc3dcc000, npending=4) at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2744 2744 struct iwi_softc *sc = ic->ic_ifp->if_softc; (kgdb) l 2739 2740 static void 2741 iwi_monitor_scan(void *arg, int npending) 2742 { 2743 struct ieee80211com *ic = arg; 2744 struct iwi_softc *sc = ic->ic_ifp->if_softc; 2745 IWI_LOCK_DECL; 2746 2747 IWI_LOCK(sc); 2748 (void) iwi_scanchan(sc, 2000, 0); (kgdb) p ((struct ieee80211com *)arg)->ic_ifp $1 = (struct ifnet *) 0x0 Any suggestions? ./danfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 13:35:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AA871065672 for ; Fri, 8 Oct 2010 13:35:35 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog108.obsmtp.com (eu1sys200aog108.obsmtp.com [207.126.144.125]) by mx1.freebsd.org (Postfix) with SMTP id EB4898FC08 for ; Fri, 8 Oct 2010 13:35:33 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob108.postini.com ([207.126.147.11]) with SMTP ID DSNKTK8eJIatbXOV70dt70f4ftOCN38nsYKS@postini.com; Fri, 08 Oct 2010 13:35:34 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id 44D79FD019; Fri, 8 Oct 2010 13:35:32 +0000 (UTC) Message-ID: <4CAF1E0E.1080608@tomjudge.com> Date: Fri, 08 Oct 2010 08:35:10 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: a.smith@ukgrid.net References: <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> <20100928222532.GD1252@michelle.cdnetworks.com> <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> <20101006174139.GC14879@michelle.cdnetworks.com> <20101008134251.367570jyw4igvkg8@webmail2.ukgrid.net> In-Reply-To: <20101008134251.367570jyw4igvkg8@webmail2.ukgrid.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:35:35 -0000 On 10/08/2010 07:42 AM, a.smith@ukgrid.net wrote: > Quoting Pyun YongHyeon : > >>> >> >> Ok, there might be a couple of edge cases not handled in bge(4). I >> believe things will improve over time but it depends on users >> feedback and testing. > > On this particular server I really need to get it stable and leave. > We are awaiting delivery of a Dell R610, I would think its likely it > uses the same ethernet chipset so will be able to perform more testing > on this. In theory we should have the server next week, will let you > know, > The R610 has a NetXtream II chipset which uses the bce(4) driver. If you are going to doing heavy network traffic, or using jumbo frames I would personally recommend you fit an Intel PCIe card to this server before you put it in production. Tom -- TJU13-ARIN From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 13:48:03 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C2761065670; Fri, 8 Oct 2010 13:48:03 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E92978FC1E; Fri, 8 Oct 2010 13:47:55 +0000 (UTC) Received: by bwz6 with SMTP id 6so803522bwz.13 for ; Fri, 08 Oct 2010 06:47:48 -0700 (PDT) Received: by 10.204.133.91 with SMTP id e27mr2014543bkt.197.1286545629208; Fri, 08 Oct 2010 06:47:09 -0700 (PDT) Received: from jessie.localnet (p5B0E1DC5.dip0.t-ipconnect.de [91.14.29.197]) by mx.google.com with ESMTPS id x13sm2669459bki.12.2010.10.08.06.47.06 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 06:47:07 -0700 (PDT) From: Bernhard Schmidt To: Alexey Dokuchaev Date: Fri, 8 Oct 2010 15:47:04 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: <4763016D.7060100@janh.de> <20101008131849.GA54860@FreeBSD.org> In-Reply-To: <20101008131849.GA54860@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010081547.04586.bschmidt@techwires.net> Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:48:03 -0000 On Friday, October 08, 2010 15:18:50 you wrote: > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > > Try the attached patch, this is basically the code from stable/6 > > ported to head and stable/7. I did only some basic tests but monitor > > mode seems to work and it is still possible to use the card in STA > > mode. > > > > I'm not sure why that got lost, but there must be a reason I'm not > > seeing right now. If someone has more knowledge about that, please > > let me know, otherwise I intend to commit it this weekend. > > Unfortunately, I am getting instant panic when trying any of aircrack-ng > suite utilities ("ifconfig iwi0 scan/list scan" works though): I did only some basic tests with tcpdump -ne -i wlan0 -y IEEE802_11_RADIO in monitor mode and that did work. Will check aircrack-ng later today. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 13:48:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82C6106566B for ; Fri, 8 Oct 2010 13:48:52 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id A61C48FC16 for ; Fri, 8 Oct 2010 13:48:52 +0000 (UTC) Received: from [89.21.28.38] (port=32157 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net id 1P4DJb-000DdY-5K; Fri, 08 Oct 2010 14:48:51 +0100 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Fri, 08 Oct 2010 14:48:51 +0100 Message-ID: <20101008144851.12024aez0aoyd2qs@webmail2.ukgrid.net> Date: Fri, 08 Oct 2010 14:48:51 +0100 From: a.smith@ukgrid.net To: Tom Judge References: <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> <20100928222532.GD1252@michelle.cdnetworks.com> <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> <20101006174139.GC14879@michelle.cdnetworks.com> <20101008134251.367570jyw4igvkg8@webmail2.ukgrid.net> <4CAF1E0E.1080608@tomjudge.com> In-Reply-To: <4CAF1E0E.1080608@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) / FreeBSD-8.0 Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:48:53 -0000 Quoting Tom Judge : > > The R610 has a NetXtream II chipset which uses the bce(4) driver. If > you are going to doing heavy network traffic, or using jumbo frames I > would personally recommend you fit an Intel PCIe card to this server > before you put it in production. > Ah, ok thanks for the feedback. I dont have any intention of using jumbo frames, but I expect it to work on a gigabit switch port. Do you have personal experience that these or bad, or what is the reason not to use this chipset? thanks Andy. From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 13:53:21 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B2761065673; Fri, 8 Oct 2010 13:53:21 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 02DA68FC08; Fri, 8 Oct 2010 13:53:20 +0000 (UTC) Received: by bwz6 with SMTP id 6so811007bwz.13 for ; Fri, 08 Oct 2010 06:53:20 -0700 (PDT) Received: by 10.204.133.91 with SMTP id e27mr2014543bkt.197.1286545629208; Fri, 08 Oct 2010 06:47:09 -0700 (PDT) Received: from jessie.localnet (p5B0E1DC5.dip0.t-ipconnect.de [91.14.29.197]) by mx.google.com with ESMTPS id x13sm2669459bki.12.2010.10.08.06.47.06 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 06:47:07 -0700 (PDT) From: Bernhard Schmidt To: Alexey Dokuchaev Date: Fri, 8 Oct 2010 15:47:04 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: <4763016D.7060100@janh.de> <20101008131849.GA54860@FreeBSD.org> In-Reply-To: <20101008131849.GA54860@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010081547.04586.bschmidt@techwires.net> Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:53:21 -0000 On Friday, October 08, 2010 15:18:50 you wrote: > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > > Try the attached patch, this is basically the code from stable/6 > > ported to head and stable/7. I did only some basic tests but monitor > > mode seems to work and it is still possible to use the card in STA > > mode. > > > > I'm not sure why that got lost, but there must be a reason I'm not > > seeing right now. If someone has more knowledge about that, please > > let me know, otherwise I intend to commit it this weekend. > > Unfortunately, I am getting instant panic when trying any of aircrack-ng > suite utilities ("ifconfig iwi0 scan/list scan" works though): I did only some basic tests with tcpdump -ne -i wlan0 -y IEEE802_11_RADIO in monitor mode and that did work. Will check aircrack-ng later today. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 14:10:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69B44106566C for ; Fri, 8 Oct 2010 14:10:00 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) by mx1.freebsd.org (Postfix) with SMTP id 002CD8FC13 for ; Fri, 8 Oct 2010 14:09:58 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob115.postini.com ([207.126.147.11]) with SMTP ID DSNKTK8mNUkP3ukFxaBnNo8iGn4u06hvHgbQ@postini.com; Fri, 08 Oct 2010 14:09:59 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id 42ECAFD019; Fri, 8 Oct 2010 14:09:57 +0000 (UTC) Message-ID: <4CAF261F.4090509@tomjudge.com> Date: Fri, 08 Oct 2010 09:09:35 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: a.smith@ukgrid.net References: <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> <20100928222532.GD1252@michelle.cdnetworks.com> <20101006174508.16931ioisevmzhy8@webmail2.ukgrid.net> <20101006174139.GC14879@michelle.cdnetworks.com> <20101008134251.367570jyw4igvkg8@webmail2.ukgrid.net> <4CAF1E0E.1080608@tomjudge.com> <20101008144851.12024aez0aoyd2qs@webmail2.ukgrid.net> In-Reply-To: <20101008144851.12024aez0aoyd2qs@webmail2.ukgrid.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:10:00 -0000 On 10/08/2010 08:48 AM, a.smith@ukgrid.net wrote: > Quoting Tom Judge : > >> >> The R610 has a NetXtream II chipset which uses the bce(4) driver. If >> you are going to doing heavy network traffic, or using jumbo frames I >> would personally recommend you fit an Intel PCIe card to this server >> before you put it in production. >> > > Ah, ok thanks for the feedback. I dont have any intention of using > jumbo frames, but I expect it to work on a gigabit switch port. Do you > have personal experience that these or bad, or what is the reason not > to use this chipset? > The hardware its self seems fine, but there are some outstanding driver issues: 1) Jumbo frames will cause mbuf zone memory fragmentation leaving to dropped frames/stack lock ups (visual indication). There is a work around for this issue (define BCE_HDR_SPLIT in sys/dev/bce/if_bcereg.h). 2) There are performance issues with streams of small frames (up to about 200 bytes) where the RX ring fills up and the firmware starts dropping packets. Flow control will /fix/ the issue but really it just plasters over the issue and moves the frame drops to the egress queue on the switch. These are the current issues and they affect all Dell 10th and 11th gen hardware (2950,1950,R710,R610,R410,etc,etc). There some patches floating around that attempt to address these issues. * One to turn header splitting into a loader tunable. * Flow control is supported on all stable branches and head. I don't think it is in a release. * There is a patch to be able to tune the size of the ring buffers used by the card but from my testing it is unstable, and unusable with anything but the default values. I have spent a week trying to get the nic's stable in a R710 after which management pulled me off the work and authorized funds to fit Intel cards to the boxes. Tom -- TJU13-ARIN From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 15:15:53 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 161E2106566C; Fri, 8 Oct 2010 15:15:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 484988FC0C; Fri, 8 Oct 2010 15:15:52 +0000 (UTC) Received: by ewy27 with SMTP id 27so499148ewy.13 for ; Fri, 08 Oct 2010 08:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Dt37B/Jw6JW2COR16lMhynvgguUqdxS6nrRVzEcWKYE=; b=xf5nLOBChKzH9rvZVYCtOqtfCtSroFUzgayxRpucAqCqC3rKAZjRJJw6zSnGmgDdJj Ike84EHbg/aRQ1cowjz6hAd214aEkFAUFYraYLuJbQKnZ3EciuouMg4zP7Uo/tKEFCVQ BRiF0CcxPE/o1NwvPSzsr862sHRYRFxhuhN/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YQMGV7EeTYeJJO2kvVHY5ofInfTUpFSSQo0snkaxa0tvz+FDQw3PAiG4XlzubvJZ8R OFgGwxJ6yIzhpaKD69sZ5ExKcoVZVMlJoEUo60npLGIxZkEPd2nHZU3eSX539k47oUjY rDxAQYAbjdsd3za3advN2gtoiZMSJ6Doc+/xs= MIME-Version: 1.0 Received: by 10.14.119.7 with SMTP id m7mr1596740eeh.8.1286550945947; Fri, 08 Oct 2010 08:15:45 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Fri, 8 Oct 2010 08:15:45 -0700 (PDT) In-Reply-To: <20101008122939.GA52927@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> <20101008091633.GA21612@FreeBSD.org> <20101008122939.GA52927@FreeBSD.org> Date: Fri, 8 Oct 2010 15:15:45 +0000 Message-ID: From: Paul B Mahol To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , Adrian Chadd , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:15:53 -0000 On 10/8/10, Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 11:48:57AM +0000, Paul B Mahol wrote: >> On 10/8/10, Alexey Dokuchaev wrote: >> > On Thu, Oct 07, 2010 at 12:44:20PM +0000, Paul B Mahol wrote: >> >> Monitor and injection work commpletly different after vap. >> >> >> >> I do not think that kismet and aircrack-ng from ports are patched at >> >> all. >> > >> > This is at least partially true; SVN trunk of aircrack-ng behaves better >> > than 1.1 version from ports (WRT infamous wi_write() problem). I will >> > work out patches for the port after kernel side will get fixed. >> >> Heh, you are wrong, svn trunk of aircrack-ng is broken versus >> wi_write() "problem". >> >> Look at "famous" ticket number 666 > > Oh, that's right, I think I've been testing SVN trunk with this patch > applied (maybe with =| MONITOR hunk, which I found in another version of > similar patch). Without a patch injection test fails immediately, > before wi_write() gets a chance to trigger. > >> Injection on FreeBSD (I forgot exact revision) will work only in AHDEMO >> mode. >> Unlike before you can not inject in MONITOR mode. > > I've seen people say this, but I could not find more elaborative answer. > I am also not sure about AHDEMO mode, since iwi(4) reports this for me: > > $ ifconfig iwi0 list caps > iwi0=25818300 I'm talking about after VAP, not about 7.X, where that does not apply. Support for AHDEMO is somehow similar to MONITOR, look how bwn(4) does it. It is very straightforward. From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 15:20:12 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F41106566B; Fri, 8 Oct 2010 15:20:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0EB8FC0C; Fri, 8 Oct 2010 15:20:11 +0000 (UTC) Received: by fxm4 with SMTP id 4so418470fxm.13 for ; Fri, 08 Oct 2010 08:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JQ9HbOB/2JPIFgeftWlQLJwrcqrYDmPU7bl1zXnxxtM=; b=GTAFHw7IKeD2qxTbhG9nLmfWt5wz1lwRkaqhL7MJV0WWOR5JOos5tXdljw0bkMGyzR 7VSbp01eZilyHGiG/yWP8v0rG5HKMvTRq+J7V59sNACEhyHWEaoHxQVRG99EYw4my6Ar NSEWzfrlsI2zxKoiUP9GyOHprhqM3VxkclLnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lqiBjymuOOPelyXHeHfHJ2cYrmfKTYojjv8L1YUi2TgS1xvkThfWb6kvcuMxGrvmzA G0vOWP2s8xZ6oIeT4KSqX4CcdponGPgdjA+Qrc9fuofzVZtTJ/SmNKroMeXt1GTXOtUx Nk/xxddiv4Geh66Ti8mqRMu/m9C1vFdxR8dqg= MIME-Version: 1.0 Received: by 10.103.169.18 with SMTP id w18mr582838muo.6.1286551208833; Fri, 08 Oct 2010 08:20:08 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Fri, 8 Oct 2010 08:20:08 -0700 (PDT) In-Reply-To: <20101008131849.GA54860@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101008131849.GA54860@FreeBSD.org> Date: Fri, 8 Oct 2010 15:20:08 +0000 Message-ID: From: Paul B Mahol To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernhard Schmidt , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:20:12 -0000 On 10/8/10, Alexey Dokuchaev wrote: > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: >> Try the attached patch, this is basically the code from stable/6 >> ported to head and stable/7. I did only some basic tests but monitor >> mode seems to work and it is still possible to use the card in STA >> mode. >> >> I'm not sure why that got lost, but there must be a reason I'm not >> seeing right now. If someone has more knowledge about that, please >> let me know, otherwise I intend to commit it this weekend. > > Unfortunately, I am getting instant panic when trying any of aircrack-ng > suite utilities ("ifconfig iwi0 scan/list scan" works though): > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0768d42 > stack pointer = 0x28:0xe4112c80 > frame pointer = 0x28:0xe4112c98 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 35 (iwi0 taskq) > > (kgdb) bt > ... > #6 0xc060cae0 in trap_fatal (frame=0xe4112c40, eva=0) > at /usr/src/sys/i386/i386/trap.c:941 > #7 0xc060cd90 in trap_pfault (frame=0xe4112c40, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:863 > #8 0xc060d7f7 in trap (frame=0xe4112c40) at > /usr/src/sys/i386/i386/trap.c:541 > #9 0xc05f4d9b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #10 0xc0768d42 in iwi_monitor_scan (arg=0xc3dcc000, npending=4) > at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2744 > ... > (kgdb) f 10 > #10 0xc0768d42 in iwi_monitor_scan (arg=0xc3dcc000, npending=4) > at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2744 > 2744 struct iwi_softc *sc = ic->ic_ifp->if_softc; > (kgdb) l > 2739 > 2740 static void > 2741 iwi_monitor_scan(void *arg, int npending) > 2742 { > 2743 struct ieee80211com *ic = arg; > 2744 struct iwi_softc *sc = ic->ic_ifp->if_softc; > 2745 IWI_LOCK_DECL; > 2746 > 2747 IWI_LOCK(sc); > 2748 (void) iwi_scanchan(sc, 2000, 0); > (kgdb) p ((struct ieee80211com *)arg)->ic_ifp > $1 = (struct ifnet *) 0x0 > > Any suggestions? 7.X is buggy regarding tasqueue, I think (maybe it is net80211 bug and not iwi fault). Does it panic with tcpdump too? Try to reproduce it on CURRENT. From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 15:41:59 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id EFF1A1065798; Fri, 8 Oct 2010 15:41:59 +0000 (UTC) Date: Fri, 8 Oct 2010 15:41:59 +0000 From: Alexey Dokuchaev To: Paul B Mahol Message-ID: <20101008154159.GA81218@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> <20101008091633.GA21612@FreeBSD.org> <20101008122939.GA52927@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Brandon Gooch , Adrian Chadd , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:42:00 -0000 On Fri, Oct 08, 2010 at 03:15:45PM +0000, Paul B Mahol wrote: > On 10/8/10, Alexey Dokuchaev wrote: > > I am also not sure about AHDEMO mode, since iwi(4) reports this for me: > > > > $ ifconfig iwi0 list caps > > iwi0=25818300 > > I'm talking about after VAP, not about 7.X, where that does not apply. > > Support for AHDEMO is somehow similar to MONITOR, look how bwn(4) does it. > It is very straightforward. Ah, now it makes sense, thanks for the pointers. Unfortunately I doubt that I can test 8.x/HEAD in a near future. If I manage to, I'll report of the results here. ./danfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 15:59:17 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 280631065670; Fri, 8 Oct 2010 15:59:17 +0000 (UTC) Date: Fri, 8 Oct 2010 15:59:17 +0000 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20101008155917.GB81218@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101008131849.GA54860@FreeBSD.org> <201010081547.04586.bschmidt@techwires.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201010081547.04586.bschmidt@techwires.net> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:59:17 -0000 On Fri, Oct 08, 2010 at 03:47:04PM +0200, Bernhard Schmidt wrote: > On Friday, October 08, 2010 15:18:50 you wrote: > > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > > > Try the attached patch, this is basically the code from stable/6 > > > ported to head and stable/7. I did only some basic tests but monitor > > > mode seems to work and it is still possible to use the card in STA > > > mode. > > > > > > I'm not sure why that got lost, but there must be a reason I'm not > > > seeing right now. If someone has more knowledge about that, please > > > let me know, otherwise I intend to commit it this weekend. > > > > Unfortunately, I am getting instant panic when trying any of aircrack-ng > > suite utilities ("ifconfig iwi0 scan/list scan" works though): > > I did only some basic tests with tcpdump -ne -i wlan0 -y IEEE802_11_RADIO > in monitor mode and that did work. Will check aircrack-ng later today. Thanks. FWIW, doing "ifconfig iwi0 mediaopt monitor" panics the box immediately as well. ./danfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 16:04:22 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 2F82F106566C; Fri, 8 Oct 2010 16:04:22 +0000 (UTC) Date: Fri, 8 Oct 2010 16:04:22 +0000 From: Alexey Dokuchaev To: Paul B Mahol Message-ID: <20101008160422.GC81218@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101008131849.GA54860@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Bernhard Schmidt , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:04:22 -0000 On Fri, Oct 08, 2010 at 03:20:08PM +0000, Paul B Mahol wrote: > On 10/8/10, Alexey Dokuchaev wrote: > > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > >> Try the attached patch, this is basically the code from stable/6 > >> ported to head and stable/7. I did only some basic tests but monitor > >> mode seems to work and it is still possible to use the card in STA > >> mode. > > > > Unfortunately, I am getting instant panic when trying any of aircrack-ng > > suite utilities ("ifconfig iwi0 scan/list scan" works though): > > > > Fatal trap 12: page fault while in kernel mode > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 35 (iwi0 taskq) > > > > Any suggestions? > > 7.X is buggy regarding taskqueue, I think (maybe it is net80211 bug > and not iwi fault). That's a sad thing to hear about stable branch. > Does it panic with tcpdump too? Bernhard's tests indicate it's not. However, me doing "ifconfig iwi0 mediaopt monitor" here resulted in immediate panic (did not catch the core this time, but I'm positive it's the same as with aircrack-ng). > Try to reproduce it on CURRENT. I wish I could. I literally have no space on a hard drive to deploy another FreeBSD installation. :-( ./danfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 16:59:45 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B27F91065679; Fri, 8 Oct 2010 16:59:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 813758FC14; Fri, 8 Oct 2010 16:59:45 +0000 (UTC) Received: by pxi17 with SMTP id 17so397666pxi.13 for ; Fri, 08 Oct 2010 09:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4ejrCp+abNOHFWhSNUXuKH4+dih600PYFfpZPhysbXU=; b=dc9EorAmUxugb0bTydBT9qcP3eFvlfyXdEaDExY5Mp89Un0uJRZceO2how2KNF5NYk 4N6HLxsCtoh4yeBRYP957vd6LYD5JQDFcpsIhj3nwmYRYtsIrfv8buHzVCArGlJzjHl0 i7ZoDXiWVn6W9ELlJGGgwkDL9FtOCJG2Poxqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s/JXmi1LkN3u6tJm3BzBFa5zKORSGb1jQlYVlC56EeYTmTGwxFvYfUzPH7KfsKLsfz Fv3LwPMOIPRcjZuwvt/BDFsGf5BeIVDnH5YojAi6wHU59j/7tLxi9y3sz87YbO0qFuwk aM5d9dHZhqh0Qv8lkfEuTVnmLNHV3AjO57dp4= MIME-Version: 1.0 Received: by 10.143.160.18 with SMTP id m18mr2231018wfo.325.1286557185038; Fri, 08 Oct 2010 09:59:45 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Fri, 8 Oct 2010 09:59:44 -0700 (PDT) In-Reply-To: <20101008160422.GC81218@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101008131849.GA54860@FreeBSD.org> <20101008160422.GC81218@FreeBSD.org> Date: Fri, 8 Oct 2010 16:59:44 +0000 Message-ID: From: Paul B Mahol To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernhard Schmidt , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:59:45 -0000 On 10/8/10, Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 03:20:08PM +0000, Paul B Mahol wrote: >> On 10/8/10, Alexey Dokuchaev wrote: >> > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: >> >> Try the attached patch, this is basically the code from stable/6 >> >> ported to head and stable/7. I did only some basic tests but monitor >> >> mode seems to work and it is still possible to use the card in STA >> >> mode. >> > >> > Unfortunately, I am getting instant panic when trying any of aircrack-ng >> > suite utilities ("ifconfig iwi0 scan/list scan" works though): >> > >> > Fatal trap 12: page fault while in kernel mode >> > processor eflags = interrupt enabled, resume, IOPL = 0 >> > current process = 35 (iwi0 taskq) >> > >> > Any suggestions? >> >> 7.X is buggy regarding taskqueue, I think (maybe it is net80211 bug >> and not iwi fault). > > That's a sad thing to hear about stable branch. > >> Does it panic with tcpdump too? > > Bernhard's tests indicate it's not. However, me doing "ifconfig iwi0 > mediaopt monitor" here resulted in immediate panic (did not catch the > core this time, but I'm positive it's the same as with aircrack-ng). > Looks like SMP issue. Let me look if it is something obvious. From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 17:14:19 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3AFD106564A for ; Fri, 8 Oct 2010 17:14:18 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBFF38FC13 for ; Fri, 8 Oct 2010 17:14:18 +0000 (UTC) Received: by pxi17 with SMTP id 17so406180pxi.13 for ; Fri, 08 Oct 2010 10:14:18 -0700 (PDT) Received: by 10.114.132.2 with SMTP id f2mr3041676wad.131.1286556642170; Fri, 08 Oct 2010 09:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.77 with HTTP; Fri, 8 Oct 2010 09:50:21 -0700 (PDT) From: Eitan Adler Date: Fri, 8 Oct 2010 16:50:21 +0000 Message-ID: To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: possible bug in netif or handbook when using lagg with wlan devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:14:19 -0000 I copied my rc.conf from http://www.freebsd.org/doc/handbook/network-aggregation.html the last paragraph $cat /etc/rc.conf hostname="ByteByte" ifconfig_bge0="UP" ifconfig_bwn0="ether xyzabc UP DHCP" wlans_bwn0="wlan0" ifconfig_wlan0="UP DHCP" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP" When I do /etc/rc.d/netif restart I get: ifconfig: interface wlan0 does not exist Stopping Network: lo0 bwn0 bge0 lagg0 wlan0 lo0: ... bwn0: ... bge0: ... lagg0: ... ifconfig: interface wlan0 does not exist ifconfig: create: bad value ifconfig: UP bad value ifconfig: UP bad value ifconfig: SIOCSLAGPORT: Device bust Starting Network: lo0 bwn0 bge0 lagg0 lo0: ... bwn0: ... bge0: ... lagg0: ... -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 17:38:48 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D4B1065675; Fri, 8 Oct 2010 17:38:48 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id BDD028FC17; Fri, 8 Oct 2010 17:38:47 +0000 (UTC) Received: by fxm4 with SMTP id 4so561372fxm.13 for ; Fri, 08 Oct 2010 10:38:46 -0700 (PDT) Received: by 10.223.105.82 with SMTP id s18mr3574593fao.77.1286559523398; Fri, 08 Oct 2010 10:38:43 -0700 (PDT) Received: from julie.lab.techwires.net ([178.2.205.177]) by mx.google.com with ESMTPS id c20sm1747106fak.9.2010.10.08.10.38.40 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 10:38:42 -0700 (PDT) From: Bernhard Schmidt To: Paul B Mahol Date: Fri, 8 Oct 2010 19:36:13 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <4763016D.7060100@janh.de> <20101008160422.GC81218@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Oa1rMALqoTlYxaa" Message-Id: <201010081936.14269.bschmidt@techwires.net> Cc: Alexey Dokuchaev , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:38:48 -0000 --Boundary-00=_Oa1rMALqoTlYxaa Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Friday 08 October 2010 18:59:44 Paul B Mahol wrote: > On 10/8/10, Alexey Dokuchaev wrote: > > On Fri, Oct 08, 2010 at 03:20:08PM +0000, Paul B Mahol wrote: > >> On 10/8/10, Alexey Dokuchaev wrote: > >> > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > >> >> Try the attached patch, this is basically the code from stable/6 > >> >> ported to head and stable/7. I did only some basic tests but monitor > >> >> mode seems to work and it is still possible to use the card in STA > >> >> mode. > >> > > >> > Unfortunately, I am getting instant panic when trying any of > >> > aircrack-ng suite utilities ("ifconfig iwi0 scan/list scan" works > >> > though): > >> > > >> > Fatal trap 12: page fault while in kernel mode > >> > processor eflags = interrupt enabled, resume, IOPL = 0 > >> > current process = 35 (iwi0 taskq) > >> > > >> > Any suggestions? > >> > >> 7.X is buggy regarding taskqueue, I think (maybe it is net80211 bug > >> and not iwi fault). > > > > That's a sad thing to hear about stable branch. > > > >> Does it panic with tcpdump too? > > > > Bernhard's tests indicate it's not. However, me doing "ifconfig iwi0 > > mediaopt monitor" here resulted in immediate panic (did not catch the > > core this time, but I'm positive it's the same as with aircrack-ng). > > Looks like SMP issue. > Let me look if it is something obvious. After having another cup of coffee it's pretty obvious what's wrong.. and I really wonder how that could have worked during my tests yesterday. Just to be sure I did the same tests again today and it still worked. The only difference between what I did and your scenario is, that I didn't use ifconfig iwi0 mediaopt monitor but ifconfig iwi0 monitor instead.. anyways.. ic != sc Attached patched should behave better now. alix# kldload if_iwi iwi0: mem 0xe0040000-0xe0040fff irq 10 at device 12.0 on pci0 iwi0: Ethernet address: 00:16:6f:64:37:68 iwi0: [ITHREAD] kalix# kldload wlan_scan_sta alix# ifconfig iwi0 -mediaopt monitor alix# ifconfig iwi0 channel 1 up alix# aireplay-ng -9 iwi0 00:34:10 Trying broadcast probe requests... 00:34:12 No Answer... 00:34:12 Found 1 AP 00:34:12 Trying directed probe requests... 00:34:12 00:15:6D:84:06:6B - channel: 1 - 'aplab' wi_write(): Input/output error wi_write(): Input/output error ^C/ 6: 0% alix# tcpdump -nei iwi0 -y IEEE802_11_RADIO tcpdump: data link type IEEE802_11_RADIO tcpdump: WARNING: iwi0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on iwi0, link-type IEEE802_11_RADIO (802.11 plus BSD radio information header), capture size 96 bytes 00:37:56.039527 1.0 Mb/s 2412 MHz 11g antenna 0 37dB signal BSSID:00:15:6d:84:06 :6b DA:ff:ff:ff:ff:ff:ff SA:00:15:6d:84:06:6b Beacon (aplab) [1.0* 2.0* 5.5* 11. 0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 1, PRIVACY -- Bernhard --Boundary-00=_Oa1rMALqoTlYxaa Content-Type: text/x-patch; charset="ISO-8859-1"; name="iwi_monitor-stable7.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iwi_monitor-stable7.diff" Index: sys/dev/iwi/if_iwivar.h =================================================================== --- sys/dev/iwi/if_iwivar.h (revision 213522) +++ sys/dev/iwi/if_iwivar.h (working copy) @@ -193,6 +193,7 @@ struct iwi_softc { struct task sc_scanaborttask; /* cancel active scan */ struct task sc_restarttask; /* restart adapter processing */ struct task sc_opstask; /* scan / auth processing */ + struct task sc_monitortask; unsigned int sc_softled : 1, /* enable LED gpio status */ sc_ledstate: 1, /* LED on/off state */ Index: sys/dev/iwi/if_iwi.c =================================================================== --- sys/dev/iwi/if_iwi.c (revision 213522) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -163,6 +163,7 @@ static void iwi_release_fw_dma(struct iwi_softc *s static int iwi_config(struct iwi_softc *); static int iwi_get_firmware(struct iwi_softc *); static void iwi_put_firmware(struct iwi_softc *); +static void iwi_monitor_scan(void *, int); static int iwi_scanchan(struct iwi_softc *, unsigned long, int); static void iwi_scan_start(struct ieee80211com *); static void iwi_scan_end(struct ieee80211com *); @@ -291,6 +292,7 @@ iwi_attach(device_t dev) TASK_INIT(&sc->sc_restarttask, 0, iwi_restart, sc); TASK_INIT(&sc->sc_opstask, 0, iwi_ops, sc); TASK_INIT(&sc->sc_scanaborttask, 0, iwi_scanabort, sc); + TASK_INIT(&sc->sc_monitortask, 0, iwi_monitor_scan, sc); callout_init_mtx(&sc->sc_wdtimer, &sc->sc_mtx, 0); if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) { @@ -978,7 +980,8 @@ iwi_newstate(struct ieee80211com *ic, enum ieee802 */ if (ic->ic_state == IEEE80211_S_SCAN) iwi_assoc(ic); - } + } else if (ic->ic_opmode == IEEE80211_M_MONITOR) + taskqueue_enqueue(sc->sc_tq, &sc->sc_monitortask); break; case IEEE80211_S_INIT: /* @@ -1411,6 +1414,18 @@ iwi_notification_intr(struct iwi_softc *sc, struct IWI_STATE_END(sc, IWI_FW_SCANNING); + /* + * Monitor mode works by doing a passive scan to set + * the channel and enable rx. Because we don't want + * to abort a scan lest the firmware crash we scan + * for a short period of time and automatically restart + * the scan when notified the sweep has completed. + */ + if (ic->ic_opmode == IEEE80211_M_MONITOR) { + taskqueue_enqueue(sc->sc_tq, &sc->sc_monitortask); + break; + } + if (scan->status == IWI_SCAN_COMPLETED) ieee80211_scan_next(ic); @@ -2595,6 +2610,11 @@ iwi_config(struct iwi_softc *sc) config.answer_pbreq = (ic->ic_opmode == IEEE80211_M_IBSS) ? 1 : 0; config.disable_unicast_decryption = 1; config.disable_multicast_decryption = 1; + if (ic->ic_opmode == IEEE80211_M_MONITOR) { + config.allow_invalid_frames = 1; + config.allow_beacon_and_probe_resp = 1; + config.allow_mgt = 1; + } DPRINTF(("Configuring adapter\n")); error = iwi_cmd(sc, IWI_CMD_SET_CONFIG, &config, sizeof config); if (error != 0) @@ -2717,6 +2737,18 @@ scan_band(const struct ieee80211_channel *c) return IEEE80211_IS_CHAN_5GHZ(c) ? IWI_CHAN_5GHZ : IWI_CHAN_2GHZ; } +static void +iwi_monitor_scan(void *arg, int npending) +{ + struct ieee80211com *ic = arg; + struct iwi_softc *sc = ic->ic_ifp->if_softc; + IWI_LOCK_DECL; + + IWI_LOCK(sc); + (void) iwi_scanchan(sc, 2000, 0); + IWI_UNLOCK(sc); +} + /* * Start a scan on the current channel or all channels. */ --Boundary-00=_Oa1rMALqoTlYxaa-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 17:47:17 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 938DE1065670; Fri, 8 Oct 2010 17:47:17 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E954F8FC08; Fri, 8 Oct 2010 17:47:16 +0000 (UTC) Received: by fxm4 with SMTP id 4so567289fxm.13 for ; Fri, 08 Oct 2010 10:47:15 -0700 (PDT) Received: by 10.223.105.71 with SMTP id s7mr3655626fao.8.1286560035562; Fri, 08 Oct 2010 10:47:15 -0700 (PDT) Received: from julie.lab.techwires.net ([178.2.205.177]) by mx.google.com with ESMTPS id k4sm742434faa.8.2010.10.08.10.47.13 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 10:47:14 -0700 (PDT) From: Bernhard Schmidt To: Paul B Mahol Date: Fri, 8 Oct 2010 19:44:50 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <4763016D.7060100@janh.de> <201010081936.14269.bschmidt@techwires.net> In-Reply-To: <201010081936.14269.bschmidt@techwires.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Si1rM6hQkOin6wT" Message-Id: <201010081944.50287.bschmidt@techwires.net> Cc: Alexey Dokuchaev , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:47:17 -0000 --Boundary-00=_Si1rM6hQkOin6wT Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit On Friday 08 October 2010 19:36:13 Bernhard Schmidt wrote: > On Friday 08 October 2010 18:59:44 Paul B Mahol wrote: > > On 10/8/10, Alexey Dokuchaev wrote: > > > On Fri, Oct 08, 2010 at 03:20:08PM +0000, Paul B Mahol wrote: > > >> On 10/8/10, Alexey Dokuchaev wrote: > > >> > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote: > > >> >> Try the attached patch, this is basically the code from stable/6 > > >> >> ported to head and stable/7. I did only some basic tests but > > >> >> monitor mode seems to work and it is still possible to use the > > >> >> card in STA mode. > > >> > > > >> > Unfortunately, I am getting instant panic when trying any of > > >> > aircrack-ng suite utilities ("ifconfig iwi0 scan/list scan" works > > >> > though): > > >> > > > >> > Fatal trap 12: page fault while in kernel mode > > >> > processor eflags = interrupt enabled, resume, IOPL = 0 > > >> > current process = 35 (iwi0 taskq) > > >> > > > >> > Any suggestions? > > >> > > >> 7.X is buggy regarding taskqueue, I think (maybe it is net80211 bug > > >> and not iwi fault). > > > > > > That's a sad thing to hear about stable branch. > > > > > >> Does it panic with tcpdump too? > > > > > > Bernhard's tests indicate it's not. However, me doing "ifconfig iwi0 > > > mediaopt monitor" here resulted in immediate panic (did not catch the > > > core this time, but I'm positive it's the same as with aircrack-ng). > > > > Looks like SMP issue. > > Let me look if it is something obvious. > > After having another cup of coffee it's pretty obvious what's wrong.. and I > really wonder how that could have worked during my tests yesterday. Just to > be sure I did the same tests again today and it still worked. The only > difference between what I did and your scenario is, that I didn't use > ifconfig iwi0 mediaopt monitor > but > ifconfig iwi0 monitor > instead.. anyways.. > > ic != sc > > Attached patched should behave better now. Sorry.. correct one this time. > alix# kldload if_iwi > iwi0: mem 0xe0040000-0xe0040fff irq 10 at > device > 12.0 on pci0 > iwi0: Ethernet address: 00:16:6f:64:37:68 > iwi0: [ITHREAD] > kalix# kldload wlan_scan_sta > alix# ifconfig iwi0 -mediaopt monitor > alix# ifconfig iwi0 channel 1 up > alix# aireplay-ng -9 iwi0 > 00:34:10 Trying broadcast probe requests... > 00:34:12 No Answer... > 00:34:12 Found 1 AP > > 00:34:12 Trying directed probe requests... > 00:34:12 00:15:6D:84:06:6B - channel: 1 - 'aplab' > wi_write(): Input/output error > wi_write(): Input/output error > ^C/ 6: 0% > alix# tcpdump -nei iwi0 -y IEEE802_11_RADIO > tcpdump: data link type IEEE802_11_RADIO > tcpdump: WARNING: iwi0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on iwi0, link-type IEEE802_11_RADIO (802.11 plus BSD radio > information > header), capture size 96 bytes > 00:37:56.039527 1.0 Mb/s 2412 MHz 11g antenna 0 37dB signal > BSSID:00:15:6d:84:06 > > :6b DA:ff:ff:ff:ff:ff:ff SA:00:15:6d:84:06:6b Beacon (aplab) [1.0* 2.0* > :5.5* > > 11. > 0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 1, PRIVACY -- Bernhard --Boundary-00=_Si1rM6hQkOin6wT Content-Type: text/x-patch; charset="ISO-8859-1"; name="iwi_monitor-stable7-v2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iwi_monitor-stable7-v2.diff" Index: sys/dev/iwi/if_iwivar.h =================================================================== --- sys/dev/iwi/if_iwivar.h (revision 213584) +++ sys/dev/iwi/if_iwivar.h (working copy) @@ -193,6 +193,7 @@ struct iwi_softc { struct task sc_scanaborttask; /* cancel active scan */ struct task sc_restarttask; /* restart adapter processing */ struct task sc_opstask; /* scan / auth processing */ + struct task sc_monitortask; unsigned int sc_softled : 1, /* enable LED gpio status */ sc_ledstate: 1, /* LED on/off state */ Index: sys/dev/iwi/if_iwi.c =================================================================== --- sys/dev/iwi/if_iwi.c (revision 213584) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -163,6 +163,7 @@ static void iwi_release_fw_dma(struct iwi_softc *s static int iwi_config(struct iwi_softc *); static int iwi_get_firmware(struct iwi_softc *); static void iwi_put_firmware(struct iwi_softc *); +static void iwi_monitor_scan(void *, int); static int iwi_scanchan(struct iwi_softc *, unsigned long, int); static void iwi_scan_start(struct ieee80211com *); static void iwi_scan_end(struct ieee80211com *); @@ -291,6 +292,7 @@ iwi_attach(device_t dev) TASK_INIT(&sc->sc_restarttask, 0, iwi_restart, sc); TASK_INIT(&sc->sc_opstask, 0, iwi_ops, sc); TASK_INIT(&sc->sc_scanaborttask, 0, iwi_scanabort, sc); + TASK_INIT(&sc->sc_monitortask, 0, iwi_monitor_scan, sc); callout_init_mtx(&sc->sc_wdtimer, &sc->sc_mtx, 0); if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) { @@ -978,7 +980,8 @@ iwi_newstate(struct ieee80211com *ic, enum ieee802 */ if (ic->ic_state == IEEE80211_S_SCAN) iwi_assoc(ic); - } + } else if (ic->ic_opmode == IEEE80211_M_MONITOR) + taskqueue_enqueue(sc->sc_tq, &sc->sc_monitortask); break; case IEEE80211_S_INIT: /* @@ -1411,6 +1414,18 @@ iwi_notification_intr(struct iwi_softc *sc, struct IWI_STATE_END(sc, IWI_FW_SCANNING); + /* + * Monitor mode works by doing a passive scan to set + * the channel and enable rx. Because we don't want + * to abort a scan lest the firmware crash we scan + * for a short period of time and automatically restart + * the scan when notified the sweep has completed. + */ + if (ic->ic_opmode == IEEE80211_M_MONITOR) { + taskqueue_enqueue(sc->sc_tq, &sc->sc_monitortask); + break; + } + if (scan->status == IWI_SCAN_COMPLETED) ieee80211_scan_next(ic); @@ -2595,6 +2610,11 @@ iwi_config(struct iwi_softc *sc) config.answer_pbreq = (ic->ic_opmode == IEEE80211_M_IBSS) ? 1 : 0; config.disable_unicast_decryption = 1; config.disable_multicast_decryption = 1; + if (ic->ic_opmode == IEEE80211_M_MONITOR) { + config.allow_invalid_frames = 1; + config.allow_beacon_and_probe_resp = 1; + config.allow_mgt = 1; + } DPRINTF(("Configuring adapter\n")); error = iwi_cmd(sc, IWI_CMD_SET_CONFIG, &config, sizeof config); if (error != 0) @@ -2717,6 +2737,17 @@ scan_band(const struct ieee80211_channel *c) return IEEE80211_IS_CHAN_5GHZ(c) ? IWI_CHAN_5GHZ : IWI_CHAN_2GHZ; } +static void +iwi_monitor_scan(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + IWI_LOCK_DECL; + + IWI_LOCK(sc); + (void) iwi_scanchan(sc, 2000, 0); + IWI_UNLOCK(sc); +} + /* * Start a scan on the current channel or all channels. */ --Boundary-00=_Si1rM6hQkOin6wT-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 17:56:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50181106564A; Fri, 8 Oct 2010 17:56:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CA66D8FC15; Fri, 8 Oct 2010 17:56:53 +0000 (UTC) Received: by qyk35 with SMTP id 35so1655394qyk.13 for ; Fri, 08 Oct 2010 10:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IfT9LvQeZ7d8Fha5IgG/+Bcw7wrmkdRWLV/iXuZgX/0=; b=gfHOxnO9/UJziGsPuGVuN1MU/g17YHv5vOEacVIPxF/CGhXp0RL2siE3UcqnceAaAj W7U9DgTQOqqZF6PxJS3YOg070/i3LtmvKXqE2AVKN31k9vDM0rFqtphWb5Q2oO7/Ok6u wsNgbPhjROBIC9ntKtu1phADFeo3MFTIk3HQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cFQ7wsMN/BXNjlXR5ChnLMUmAuNW48z4IxapFiqGYNBxqKI1rv8efHqBns5cW/dOs/ uCXOJ5Oaby2Zjr08Uuv2p2qSCeZ1EMs7DJLMHhM+kE9u3ixpfbrqKxyyB/5clLCA5qE4 LAMFg7SO4tW1J1l3pDU89OZvMO+bSXcnOuKVk= MIME-Version: 1.0 Received: by 10.224.27.225 with SMTP id j33mr1784127qac.228.1286560612490; Fri, 08 Oct 2010 10:56:52 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Fri, 8 Oct 2010 10:56:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Oct 2010 19:56:52 +0200 X-Google-Sender-Auth: vz1p3-LAsWxNWYFZNLhJwF6QtDk Message-ID: From: Attilio Rao To: freebsd-net@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jack F Vogel , Ryan Stone , Sergey Kandaurov , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:56:54 -0000 2010/9/28 Attilio Rao : > In the last weeks I worked for porting the netdump infrastructure to > FreeBSD-CURRENT on the behalf of Sandvine Incorporated. > Netdump is a framework that aims for handling kernel coredumps over > the TCP/IP suite in order to dump to a separate machine than the > running one. That may be used on an interesting number of cases > involving disk-less workstations, disk driver debugging or embedded > devices. > > GENERAL FRAMEWORK ARCHITECTURE > > Netdump is composed, right now, by an userland "server" and a kernel > "client". The former is run on the target machine (where the dump will > phisically happen) and it is responsible for receiving =C2=A0the packets > containing coredumps frame and for correctly writing them on-disk. > The latter is part of the kernel installed on the source machine > (where the dump is initiated) and is responsible for building > correctly UDP packets containing the coredump frames, pushing through > the network interface and routing them appropriately. > > While the server may appear as, pretty much, a simple userland deamon > dealing with UDP packets, the client imposes interesting problems as > long as its activity is linked to handling kernel core dumping. More > precisely, as long as the client is part of the dumping mechanism and > the kernel may be in general panic conditions, netdump must ensure > "robustness" of operations. That is partially achieved by reworking > (and someway replicating) locally some UDP, ARP and IP operations, > hardsetting some values (like the default gateway, the destination and > the client address) and reducing further interactions with the kernel > just to the network interface acitivities. > More specifically, it implements a very basic UDP / IPv4 / ARP stack > separate from the standard stack (since that may not be in a > consistent state). > It can dump to a server on the same LAN or via a router (correctly > specifying the connection gateway). > In order to receive packet on critical conditions, netdump polls the > interface. Every network driver can implement hooks to be used by > netdump independently by DEVICE_POLLING option, even if it is > probabilly a good idea to share some code among them. The reference > set of hooks is contained into "struct netdump_methods". > And if_lem/if_em driver modifies may be set as reference for netdump > hooks implementation. > > In order to work into an "up and running" system (meant as with all > the devices in place) the netdump handler hooks as a pre-sync handler > (differently from other dumping routines). It however suffers some > problems typical of other dumping mechanism. For example, on DDB > entering unlocked version of polling handler is used, in order to > reduce the risk of deadlocks during inspections*. That reflects, among > the netdump methods, the existence of 2 versions of polling hooks, > where the "unlocked" is meant as reducing locking as much as possible. > > PATCH AND FURTHER WORK > > The patch is not totally complete and it is not intended to be > committed in SVN yet. What I'm looking for now is more testing and > review (in particular in terms of architecture) coverage by community. > The server should be in realtively "committable" state, though, but I > encourage its stress-testing. A manpage is provided along that should > be very easy to understand how to use it. > > Things that can be further improved, as it is now, in the client, are: > - Deciding if hardcoding of the kernel parameter is done properly. I > personally don't like the sysctl usage and I would prefer an userland > small utility used to testing and maybe add some tunables for enabling > netdump early in the boot. You may have several opinions on this > though. > - VIMAGE and IPv6 support. > - More drivers support. Right now only if_em (and if_lem) are > converted to use netdump and can be used as a draft for other device > drivers. if_ixgb should came along in the final, committing, version > too. In general I think that all drivers supporting device polling > could easilly support also netdump > - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It > should be made, instead, more neutral and more flexible to cope better > with different interfaces. It is a quite a bit of work, however, and > beyond the scope of netdump introduction (even if it could be > beneficial for it) > > Netdump has been developed on a FreeBSD project branch located here: > svn://svn.freebsd.org/base/projects/sv/ > > which could also forsee further informations about every single > change. However, for your convenience, also a patch has been made > public which is located here (against FreeBSD-CURRENT@213246): > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_0= .diff This followup is made in order to signal the code has been further refined and some bugfixes (reported mostly by pluknet@ testing) have been fixed. More support for interfaces has been added (igb, ixgb, ixgbe). You can fetch the sourcecode from projects/sv/, as described in previous e-mail, or use this other patch: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_1.d= iff I didn't try netdump with VIMAGE, but for people willing to do that, they can apply the following further patch, on top of the projects/sv/ patchset and report: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_1.f= ix.diff That is not contained in the "official" projects/sv/. Right now I plan to just move netdump_client.c to be style compliant and add further comments, and eventually commit all the infrastructure on next Friday, 15th October, if no problems are reported by reviewers and testers. You are encouraged to review and test it (and in particular I added jfv@ and rstone@ on CC in order to give them a look at driver specific parts). Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Fri Oct 8 18:07:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A497D1065672; Fri, 8 Oct 2010 18:07:33 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7445A8FC0C; Fri, 8 Oct 2010 18:07:31 +0000 (UTC) Received: by pzk33 with SMTP id 33so31961pzk.13 for ; Fri, 08 Oct 2010 11:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=m+YFBWkEwRVMfvy53gE0sm93Y/GrNBypiJ+66NSVXMs=; b=Q9ngnrz5MmYn4GHt0A2AfuhsqNp1U1rHJ1Uy+blwLtsvR43oR8Q7XEvjJ9+ZmzMMgL AsjxZU0cR9tQhrJJPSXWcvmIVlK1aQhDbL+47ENOfdMH+ZZfBVCFt+IkFuyD2Bo1sQOC UIpfDMqWkjcMVlqy48oIsX0T4HC2Kb3PHgyp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aNCCpaUlSk0AIWwBKi5J/ri2CLHLxwqTAVPhjstXz5ppvWUjHYWkUZiDnTI5P4DE0d bN3R/EEyjtDuVGL8/PLozP2TD5JCM5eqgTvUrYLdNWXelF61HgCziOmA6pKFqCkkcGrV cvqu3V2E7PUgI/zJhDBe195+fU1H78HzwxJNo= MIME-Version: 1.0 Received: by 10.142.193.18 with SMTP id q18mr2294936wff.425.1286561251234; Fri, 08 Oct 2010 11:07:31 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Fri, 8 Oct 2010 11:07:31 -0700 (PDT) In-Reply-To: <20101007094918.GA15399@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> Date: Fri, 8 Oct 2010 18:07:31 +0000 Message-ID: From: Paul B Mahol To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 18:07:33 -0000 On 10/7/10, Alexey Dokuchaev wrote: > On Wed, Oct 06, 2010 at 11:56:25AM -0500, Brandon Gooch wrote: >> 2010/10/6 Alexey Dokuchaev : >> > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote: >> >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does >> >> not receive anything, while it does with ath or ural (even at the same >> >> time). dmesg with debug.iwi=2 is below -- anything unusual? >> >> >> >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never >> >> happened on 6.2-RELEASE. >> > >> > Just found this email sent to stable@ almost three years ago; sadly I >> > have to confirm iwi(4) still exhibits these problems on fairly recent >> > 7-STABLE (early Juneish). Maybe I have better luck on net@ (I am >> > particularly interested in working monitor mode). Thanks. Any debug >> > information will be gladly provided. Pointers where to look (revisions >> > to try, patches, etc.) are greatly appreciated. >> >> I know this response isn't too helpful, but the whole Intel >> PRO/Wireless 2200BG/2225BG/2915ABG open-source driver situation is not >> too good. > > I could understand that, but it looks like FreeBSD has a *regression* > between 6.2 and 7.x, which is different from just "overall not too good > situation". Regressions are presumably should not happen and should be > easier to fix than improving entire support stack in FOSS industry. :-) > >> Same goes for the Intel 3945ABG (wpi(4)); it's very easy in both Linux >> and *BSDs to befuddle the Intel Wifi chips. >> >> Having said that, Bernhard Schmidt has made outstanding progress with >> the iwn(4) driver, supporting Intel Wireless WiFi Link >> 4965/1000/5000/5150/5300/6000/6050 series. >> >> Is it possible in your situation to try another wireless card? I know >> some notebook computers only whitelist a small set of PCI devices... > > I think there are no technical obstacles w/my laptop, and I'd gladly try > something else, preferably fully working under FreeBSD (inc. monitor > mode and packet injection). Any particular recommendations (aside from > iwn(4) supported chips mentioned above)? Thanks. Just to clear this up, iwi(4) can not support injection (see iwi_raw_xmit()) unless you manage to hack firmware ... i From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 01:15:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C316106564A; Sat, 9 Oct 2010 01:15:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 46B078FC13; Sat, 9 Oct 2010 01:15:40 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id BC9EC46B5C; Fri, 8 Oct 2010 21:15:39 -0400 (EDT) Date: Sat, 9 Oct 2010 02:15:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1924871622-1286586939=:1232" Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 01:15:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1924871622-1286586939=:1232 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 8 Oct 2010, Attilio Rao wrote: >> GENERAL FRAMEWORK ARCHITECTURE >> >> Netdump is composed, right now, by an userland "server" and a kernel >> "client". The former is run on the target machine (where the dump will >> phisically happen) and it is responsible for receiving  the packets >> containing coredumps frame and for correctly writing them on-disk. The >> latter is part of the kernel installed on the source machine (where the >> dump is initiated) and is responsible for building correctly UDP packets >> containing the coredump frames, pushing through the network interface and >> routing them appropriately. Hi Attilio: Network dumps would be a great addition to the FreeBSD debugging suite! A few casual comments and questions, I need to spend some more time pondering the implications of the current netdump design later in the week. (1) Did you consider using tftp as the network dump protocol, rather than a custom protocol? It's also a simple UDP-based, ACKed file transfer protocol, with the advantage that it's widely supported by exiting tftp daemons, packet sniffers, security devices, etc. This wouldn't require using a stock tftpd, although that would certainly be a benefit as well. The post-processing of crashdumps that seems to happen in the netdump server could, presumably, happen "offline" as easily...? (2) Have you thought about adding a checksum to the dump format, since packets are going over the wire on UDP, etc? Even an MD5 sum wouldn't be too hard to arrange: all the code is in the kernel already, requires relatively little state storage, and is designed for streamed data. (3) As the bounds checking/etc behavior in dumping grows more complex, it seems a shame to replicate it in architecture-specific code. Could we pull the mediaoffset/mediasize checking into common code? Also, a reserved size/offset of "0" meaning "no limit" sounds slightly worrying; it might be slightly more conservative to add a flags field to dumperinfo and have a flag indicating "size is no object" for netdump, rather than overloading the existing fields. Some specific patch comments: + * XXX: This should be split into machdep and non-machdep parts What MD parts are in the file? The sysctl parts of the patch have a number of issues: - Please use sysctl_handle_string rather than manual calls and string bounds checking with SYSCTL_IN/SYSCTL_OUT. In general, type-specific sysctl handlers are named sysctl_handle_, which I recommend here as well. - Please use stack-local, fixed-length string buffers as the source/destination of copyin/copyout on ifnet names, rather than the fields in the structure itself. We support interface renaming, so the field can change, and sysctl has the potential to block for extended periods mid-copyin/copyout. - Because we support ifnet renaming, "none" is probably not a good reserved name. Could you use the empty string or something similar, or just a flag to indicate that netdump is disabled? - "ifp" rather than "ifn" and "nic" is the preferred variable name for ifnet pointers throughout the kernel. - ifnets can, and are, removeable at runtime. We have a refcount, but that's not really what you want. I suggest simply looking up the ifnet by name when it's needed during a dump or for sysctl output, rather than maintaining a long-term pointer, which can become stale. Especially with the auto-detect code. - Since sysctl_nic is only used once, I'd prefer it were inlined into a use-specific handler function, avoiding the arg1/arg2 complications that make this code a bit harder to read. sysctl_ip is useful because it's used more than once, though. However, it also very much wants you to call sysctl_handle_string! +sysctl_force_crash(SYSCTL_HANDLER_ARGS) Does this belong in the netdump code? We already have some of these options in debug.kdb.*, but perhaps others should be added there as well. + /* + * get and fill a header mbuf, then chain data as an extended + * mbuf. + */ + MGETHDR(m, M_DONTWAIT, MT_DATA); The idea of calling into the mbuf allocator in this context is just freaky, and may have some truly awful side effects. I suppose this is the cost of trying to combine code paths in the network device driver rather than have an independent path in the netdump case, but it's quite unfortunate and will significantly reduce the robustness of netdumps in the face of, for example, mbuf starvation. + if (ntohs(ah->ar_hrd) != ARPHRD_ETHER && + ntohs(ah->ar_hrd) != ARPHRD_IEEE802 && + ntohs(ah->ar_hrd) != ARPHRD_ARCNET && + ntohs(ah->ar_hrd) != ARPHRD_IEEE1394) { + NETDDEBUG("nd_handle_arp: unknown hardware address fmt " + "0x%2D)\n", (unsigned char *)&ah->ar_hrd, ""); + return; + } Are you sure you don't want to just check for ETHER here? + /* XXX: Probably should check if we're the recipient MAC address */ + /* Done ethernet processing. Strip off the ethernet header */ Yes, quite probably. What if you panic in promiscuous mode? + /* + * The first write (at offset 0) is the kernel dump header. Flag it + * for the server to treat specially. XXX: This doesn't strip out the + * footer KDH, although it shouldn't hurt anything. + */ The footer allows us to confirm that the tail end of a dump matches the beginning; while probably not strictly necessary in this scenario, it's not a bad idea given the lack of a checksum. + /* Default the nic to the first available interface */ + if ((ifn = TAILQ_FIRST(&ifnet)) != NULL) do { + if ((ifn->if_flags & IFF_UP) == 0) + continue; More locking needed. I'm not sure I like the idea of defaulting to net dumping out the first interface -- in the future, we'll want to compile netdump into the kernel in GENERIC so that it's always available. But we won't want to default to doing the above for a number of reasons. This means the defaults need to be sensible and quite conservative (i.e., disabled and non-autoconfigured). + /* Default the client to the first IP on nd_nic */ + if ((ifa = TAILQ_FIRST(&nd_nic->if_addrhead)) != NULL) do { + if (ifa->ifa_addr->sa_family != AF_INET) { + continue; + } + nd_client = ((struct sockaddr_in *)ifa->ifa_addr)->sin_addr; + } while ((ifa = TAILQ_NEXT(ifa, ifa_link)) != NULL && + nd_client.s_addr == INADDR_ANY); More locking needed here too. I'm guess this code is forward-ported from an older FreeBSD version without locking here, so you will want to check for other changes in the replicated code paths, such as input / arp / etc handling. And is this really a good idea? Addresses change, and I think you aren't registering a callback to pick up the change in the event you're using an auto-configured address. In some ways, in the same way you might want to look up the ifnet to use at dump-time, you might simultaneously want to auto-configure an address then, if auto-configuration is selected (i.e., netdump is enabled and no IP is configured). - void *if_pspare[7]; + struct netdump_methods *if_ndumpfuncs; /* netdump virtual methods */ + void *if_pspare[6]; int if_ispare[4]; In HEAD, at least, you should add your field and not use the spare. The spare should only be used on a merge to a KBI-stable branch (such as 8.x). I need to ponder your changes to ifnet and to the drivers some more; I recognize the benefits of maximal code alignment, but I worry a lot about these code paths having side effects (not least, calls into memory allocators, which in turn can enter VM, etc). I wonder if, given that, we need to teach the mbuf allocator to be much more conservative if netdumping is active... There are style bugs throughout. Robert --621616949-1924871622-1286586939=:1232-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 06:02:39 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 6E4A91065696; Sat, 9 Oct 2010 06:02:39 +0000 (UTC) Date: Sat, 9 Oct 2010 06:02:39 +0000 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20101009060239.GA88618@FreeBSD.org> References: <4763016D.7060100@janh.de> <201010081936.14269.bschmidt@techwires.net> <201010081944.50287.bschmidt@techwires.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201010081944.50287.bschmidt@techwires.net> User-Agent: Mutt/1.4.2.1i Cc: Paul B Mahol , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 06:02:39 -0000 On Fri, Oct 08, 2010 at 07:44:50PM +0200, Bernhard Schmidt wrote: > On Friday 08 October 2010 19:36:13 Bernhard Schmidt wrote: > > After having another cup of coffee it's pretty obvious what's wrong. > > The only difference between what I did and your scenario is, that I > > didn't use > > ifconfig iwi0 mediaopt monitor > > but > > ifconfig iwi0 monitor I haven't look in the source yet, but what is the difference between "mediaopt monitor" and "monitor"? > > instead.. anyways.. > > > > Attached patched should behave better now. > > Sorry.. correct one this time. Much better! "airodump-ng iwi0" now sees stations in addition to APs, which means it can utilize monitor mode. "ifconfig iwi0 scan" however does not work after that (and "list scan" returns no results) even if I put adapter back to normal (from promisc and monitor modes) with ifconfig(8). kldunloading and loading module again fixes the issue. Injection test "aireplay-ng -9 iwi0" still fails, but as I've been told this is firmware issue (i.e. not possible with iwi(4)), which is also inline with dmesg: kernel: iwi0: firmware error kernel: iwi0: iwi_cmd: cmd 6 not sent, busy kernel: iwi0: device configuration failed Googling shows that people patch Linux drivers to support injection, but I do not know if any of that information is applicable to FreeBSD. Apart from that, machine seems stable, and monitor mode is fixed. Thanks a lot! ./danfe From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 06:13:52 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id A4AD5106566B; Sat, 9 Oct 2010 06:13:52 +0000 (UTC) Date: Sat, 9 Oct 2010 06:13:52 +0000 From: Alexey Dokuchaev To: Paul B Mahol Message-ID: <20101009061352.GB88618@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 06:13:52 -0000 On Fri, Oct 08, 2010 at 06:07:31PM +0000, Paul B Mahol wrote: > Just to clear this up, iwi(4) can not support injection (see iwi_raw_xmit()) > unless you manage to hack firmware ... Can you perhaps comment on this thread: http://ubuntuforums.org/showthread.php?t=242556 At a glance it looks like guys use dummy interface for packet injection, and I don't see they patch firmware in any way. If it's not a hoax, I wonder if similar techniques can be used under FreeBSD. ./danfe From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 06:36:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1751F1065694 for ; Sat, 9 Oct 2010 06:36:37 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224]) by mx1.freebsd.org (Postfix) with SMTP id AFB538FC0A for ; Sat, 9 Oct 2010 06:36:36 +0000 (UTC) Received: from [98.139.52.193] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 09 Oct 2010 06:23:11 -0000 Received: from [74.6.228.51] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 09 Oct 2010 06:23:11 -0000 Received: from [127.0.0.1] by smtp110.mail.ac4.yahoo.com with NNFMP; 09 Oct 2010 06:23:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1286605391; bh=KB9SOfg9c5nnpI/kV4ebrFjbrtMrJSFECt87D/MSQQY=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:References:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=JH3mUJuSNnqeJRRM4PjdHZfL529X9aheFhyHvtV2xpgFopDFpB7vYsS7uNQhCv6yuD1bHWZ/wpsacb61h5M6Y70/RGlWM95J6m293iUcXu7MwYUXaewRNZe/G/m1ni9B9n+e1s5DSxPVJDDSPzy9sBw9OhPlv1ViL3h+FH1cqXc= X-Yahoo-Newman-Id: 4744.5741.bm@smtp110.mail.ac4.yahoo.com Received: from china (beezarliu@124.207.251.123 with login) by smtp110.mail.ac4.yahoo.com with SMTP; 08 Oct 2010 23:23:09 -0700 PDT X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: qH_Kk04VM1n1rcfeiDlozwbJ3_2T_zUyMw_brrPM_1O_6jC DKeA_l0kBT99RIdZpEUBBHzBkBoIRAoNxkW9pza69KDJA.Ili_Ext8Dn9HDy Ao0NrX3XHyEslOMGdiQfK5n8vjAmzPzGozXt8LeBLkLgsOexzrzEB3uYZBec ybCmyPtN5HrV8i2QFBLylEbiG6WF4Yn1HBsrgwxvsSAkG7k.PhX51yXLY8NP MbB8SpXYeHFU6eQUNuY0Yf_0ddIncc4k0p47b X-Yahoo-Newman-Property: ymail-3 Date: Sat, 9 Oct 2010 14:23:05 +0800 From: "beezarliu" To: "Li, Qing" , "zeus.panchenko@gmail.com" , "freebsd-net@freebsd.org" References: <201008262259.QAA25138@lariat.net>, <20100827062454.GB7160@relay.ibs.dn.ua>, Message-ID: <201010091422577347034@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 X-Mailman-Approved-At: Sat, 09 Oct 2010 11:03:31 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: RE: RADIX_MPATH usage information X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 06:36:37 -0000 DQpIb3cgYWJvdXQgdGhlIGRvY3VtZW50YXRpb24/DQpJIGVuam95ZWQgb25lIG9mIHlvdXIgYXJ0 aWNsZSBhYm91dCByb3V0aW5nIGFyY2hpdGVjdHVyZSBpbiBGcmVlQlNEOCwgDQpzbyBJJ20gbG9v a2luZyBmb3J3YXJkIHRvIHRoaXMgb25lLg0KDQpUaGFua3MNCjIwMTAtMTAtMDkgDQoNCg0KDQpi ZWV6YXJsaXUgDQoNCg0KDQq3orz+yMujuiBMaSwgUWluZyANCreiy83Ksbzko7ogMjAxMC0wOC0y OCAgMDA6MDE6MDYgDQrK1bz+yMujuiB6ZXVzLnBhbmNoZW5rb0BnbWFpbC5jb207IGZyZWVic2Qt bmV0QGZyZWVic2Qub3JnIA0Ks63LzaO6IA0K1vfM4qO6IFJFOiBSQURJWF9NUEFUSCB1c2FnZSBp bmZvcm1hdGlvbiANCiANClRoZXJlIGFyZSBhIGNvdXBsZSBvZiBpdGVtcyBJIG5lZWQgdG8gdGFr ZSBjYXJlIG9mDQppbiB0aGlzIGFyZWEsIGluY2x1ZGluZyB0aGUgZG9jdW1lbnRhdGlvbiwgc28g SSB3aWxsIGdldA0KaXQgZG9uZSB0aGlzIHdlZWtlbmQuDQoNCi0tUWluZw0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItZnJlZWJzZC1uZXRAZnJlZWJzZC5v cmcgW21haWx0bzpvd25lci1mcmVlYnNkLQ0KPiBuZXRAZnJlZWJzZC5vcmddIE9uIEJlaGFsZiBP ZiBaZXVzIFYgUGFuY2hlbmtvDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjYsIDIwMTAgMTE6 MjUgUE0NCj4gVG86IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnDQo+IFN1YmplY3Q6IFJlOiBSQURJ WF9NUEFUSCB1c2FnZSBpbmZvcm1hdGlvbg0KPiANCj4gKzENCj4gDQo+IC0tDQo+IFpldXMgVi4g UGFuY2hlbmtvDQo+IElUIERwdC4sIElCUyBsdGQgICAgICAgICAgICAgICAgR01UKzIgKEVFVCkN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZnJl ZWJzZC1uZXRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0dHA6Ly9saXN0cy5mcmVlYnNk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtbmV0DQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5k IGFueSBtYWlsIHRvICJmcmVlYnNkLW5ldC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpmcmVlYnNkLW5ldEBm cmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCmh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ZyZWVic2QtbmV0DQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAi ZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 12:33:16 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1DC106564A; Sat, 9 Oct 2010 12:33:16 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34B448FC17; Sat, 9 Oct 2010 12:33:15 +0000 (UTC) Received: by vws1 with SMTP id 1so433112vws.13 for ; Sat, 09 Oct 2010 05:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=f2a4S8fS4ZKds98prAndc+M57tzM5/fUeC+WZfSZ8+0=; b=q8hz2JDEhAjgn1LpdvVm9xKvfBWB8ZtRELsEAHGVRH9ASxuoi0TUGibBWQVtYYzhqh XD/c8huUPjMFbfiY4dLixPYqdJ0S/+fVXW6peuUlc23Kmwt6XaTmWEyxK2hPwid1PtB7 k38E4IrpEapSHS5DLUBTSBri3tnCmqDt4+Kd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w5xu1BGFycEjnEHX08KFue84jyE1paAVl7KVMZaFij9GKwVn1dagtn30BAHSzOIP7m +whVKaCt7uJRDXt/uvyHEb4lcrrndRUI8UbnrJDCj4XngJknJa4tvGNZZTAJ/qRMXkZg 3GDjHowRoU6wT+BNOswbezVuaBjhybTJDQ9gI= MIME-Version: 1.0 Received: by 10.220.182.3 with SMTP id ca3mr1107322vcb.273.1286627594532; Sat, 09 Oct 2010 05:33:14 -0700 (PDT) Received: by 10.220.180.135 with HTTP; Sat, 9 Oct 2010 05:33:14 -0700 (PDT) In-Reply-To: <20101009061352.GB88618@FreeBSD.org> References: <4763016D.7060100@janh.de> <20101006100335.GA26843@FreeBSD.org> <20101007094918.GA15399@FreeBSD.org> <20101009061352.GB88618@FreeBSD.org> Date: Sat, 9 Oct 2010 12:33:14 +0000 Message-ID: From: Paul B Mahol To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 12:33:16 -0000 On 10/9/10, Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 06:07:31PM +0000, Paul B Mahol wrote: >> Just to clear this up, iwi(4) can not support injection (see >> iwi_raw_xmit()) >> unless you manage to hack firmware ... > > Can you perhaps comment on this thread: > > http://ubuntuforums.org/showthread.php?t=242556 > > At a glance it looks like guys use dummy interface for packet injection, > and I don't see they patch firmware in any way. If it's not a hoax, I > wonder if similar techniques can be used under FreeBSD. That patch allows only data injection so it is near to useless. From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 16:12:06 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEC0E10656AA for ; Sat, 9 Oct 2010 16:12:06 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 524A18FC12 for ; Sat, 9 Oct 2010 16:12:06 +0000 (UTC) Received: (qmail invoked by alias); 09 Oct 2010 16:12:04 -0000 Received: from 77.49.101.48.dsl.dyn.forthnet.gr (EHLO moby.local) [77.49.101.48] by mail.gmx.com (mp-eu002) with SMTP; 09 Oct 2010 18:12:04 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1/OrYoVQ7fO+QTVdtvC5D8068hzM5Te2EyKuqDOSb IAiWw5smyBZndb Message-ID: <4CB0944D.7060806@gmx.com> Date: Sat, 09 Oct 2010 19:11:57 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.23 (X11/20100313) MIME-Version: 1.0 To: Paul B Mahol References: <4CA0F4CE.7020905@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: FreeBSD Net Subject: Re: VIMAGE + NDIS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 16:12:06 -0000 Paul B Mahol wrote: > On 9/27/10, Julian Elischer wrote: >> anyone here have NDIS experience? >> >> On 9/27/10 10:51 AM, Nikos Vassiliadis wrote: >>> Julian Elischer wrote: >>>>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at >>>>> /usr/src/sys/net/rtsock.c:1374 >>>>> 1374 if (V_loif) >>>>> (kgdb) list >>>>> 1369 } >>>>> 1370 *(unsigned short *)(tag + 1) = sa->sa_family; >>>>> 1371 m_tag_prepend(m, tag); >>>>> 1372 } >>>>> 1373 #ifdef VIMAGE >>>>> 1374 if (V_loif) >>>>> 1375 m->m_pkthdr.rcvif = V_loif; >>>>> 1376 else { >>>>> 1377 m_freem(m); >>>>> 1378 return; >>>>> (kgdb) >>>>> >>>> ok so probably there is a code-path to this point that does not first >>>> set up the current-vnet pointer before doing this. >>>> what you need to do is to produce a stack-trace so we can see how >>>> it got here, >>>> and then we can figure out where on that path we should set the >>>> pointer. >>> Here it is: >>> (kgdb) #0 doadump () at pcpu.h:231 >>> #1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808, >>> dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548 >>> #2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0, >>> dopager=1) >>> at /usr/src/sys/ddb/db_command.c:445 >>> #3 0xc04d4e0a in db_command_loop () at >>> /usr/src/sys/ddb/db_command.c:498 >>> #4 0xc04d6d0d in db_trap (type=12, code=0) at >>> /usr/src/sys/ddb/db_main.c:229 >>> #5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948) >>> at /usr/src/sys/kern/subr_kdb.c:535 >>> #6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24) >>> at /usr/src/sys/i386/i386/trap.c:929 >>> #7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24) >>> at /usr/src/sys/i386/i386/trap.c:851 >>> #8 0xc0c0bad5 in trap (frame=0xeef1d948) at >>> /usr/src/sys/i386/i386/trap.c:533 >>> #9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) >>> at /usr/src/sys/net/rtsock.c:1374 >>> #11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at >>> /usr/src/sys/net/rtsock.c:1168 >>> #12 0xc76704a1 in ?? () >>> #13 0xc6c3d400 in ?? () >>> #14 0xeef1daa8 in ?? () >>> #15 0xeef1daf4 in ?? () >>> #16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200) >>> at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105 >>> #17 0xc766d8a1 in ?? () >>> #18 0xc76b9200 in ?? () >>> #19 0xc76c0000 in ?? () >>> #20 0xc76f1000 in ?? () >>> #21 0xeef1dacc in ?? () >>> #22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () >>> from /boot/modules/bcmwl5_sys.ko >>> #23 0x006c0000 in ?? () >>> #24 0xeef1dbb4 in ?? () >>> #25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () >>> from /boot/modules/bcmwl5_sys.ko >>> #26 0xc76c0000 in ?? () >>> #27 0xc76c0000 in ?? () >>> #28 0xc7340800 in ?? () >>> #29 0xc086adcc in hardclock_cpu (usermode=7077888) >>> at /usr/src/sys/kern/kern_clock.c:447 >> >> whoa! >> hardclock interrupted itself? >> >>> #30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () >>> from /boot/modules/bcmwl5_sys.ko >>> #31 0x006c0000 in ?? () >>> #32 0xeef1dbb4 in ?? () >>> #33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () >>> from /boot/modules/bcmwl5_sys.ko >>> #34 0xc76c0000 in ?? () >>> #35 0xc76c0000 in ?? () >>> #36 0xc7340800 in ?? () >> hmmm maybe we need to get ndis to put in a wrapper at this point that >> is called form hardclock and sets the value before going further >> >> I'd have to look at the code to see what happens here.. >> >> *wonders who has their fingers in this code*.. >> >>> #37 0xc086adcc in hardclock_cpu (usermode=-949223424) >>> at /usr/src/sys/kern/kern_clock.c:447 >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) >>> >>> >>> and the panic, in case it helps: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 1; apic id = 01 >>> fault virtual address = 0x18 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0xc0978200 >>> stack pointer = 0x28:0xeef1d988 >>> frame pointer = 0x28:0xeef1d9a0 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 1404 (Windows Workitem 3) >>> panic: from debugger >>> cpuid = 1 >>> KDB: stack backtrace: >>> Physical memory: 2916 MB >>> Dumping 113 MB: 98 82 66 50 34 18 2 >>> >>> Thanks, Nikos >>> > > Please give more background information of this case. > Personally I never tested VIMAGE. Sorry for the delayed response, It is easily producible. Build a kernel with VIMAGE, associate with an AP, run dhclient and then change the SSID to something random. If there is something I can do to help you debug this problem, please don't hesitate to ask. Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 16:55:29 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2F02106567A; Sat, 9 Oct 2010 16:55:29 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5C48FC12; Sat, 9 Oct 2010 16:55:28 +0000 (UTC) Received: by vws1 with SMTP id 1so514520vws.13 for ; Sat, 09 Oct 2010 09:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LJb94KJnkgYvd6MGOn9BQfiJhFmHUghtzPQSBdaZFqs=; b=bi1ghff5mbm++0eJWY0Hd5neXE9svfisK3IUbJvPZlXsWwMsoBFWnNrO5JXVwsEGGS 4aQBKsntm4yZ2HDGBXrqHtNpKzwzIYY0kuyh8BpTnVFK52cw0Za+0ppMnxZ6+x6Ubouy tOPMx2gIDqFC0tpWSXH0kfO6xr8SO8tvZccHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SsPXMxwYTe9gmRQRJH4W89PBFgZNT3sjUuMIcIPGhazAeH6Dw80R4L35xagIbMoZie /J7FFLQA5/lpQsxmjNppQm4v05uEX4LT//xfFLffFKBlgJUMmLFG5wZJ96+P3427/ES+ hhPNfzfuII+qEldRCAg64BS+2VFN4F35aW3YM= MIME-Version: 1.0 Received: by 10.220.179.11 with SMTP id bo11mr323159vcb.87.1286643328238; Sat, 09 Oct 2010 09:55:28 -0700 (PDT) Received: by 10.220.180.135 with HTTP; Sat, 9 Oct 2010 09:55:28 -0700 (PDT) In-Reply-To: <4CB0944D.7060806@gmx.com> References: <4CA0F4CE.7020905@freebsd.org> <4CB0944D.7060806@gmx.com> Date: Sat, 9 Oct 2010 16:55:28 +0000 Message-ID: From: Paul B Mahol To: Nikos Vassiliadis Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Re: VIMAGE + NDIS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 16:55:29 -0000 On 10/9/10, Nikos Vassiliadis wrote: > Paul B Mahol wrote: >> On 9/27/10, Julian Elischer wrote: >>> anyone here have NDIS experience? >>> >>> On 9/27/10 10:51 AM, Nikos Vassiliadis wrote: >>>> Julian Elischer wrote: >>>>>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at >>>>>> /usr/src/sys/net/rtsock.c:1374 >>>>>> 1374 if (V_loif) >>>>>> (kgdb) list >>>>>> 1369 } >>>>>> 1370 *(unsigned short *)(tag + 1) = sa->sa_family; >>>>>> 1371 m_tag_prepend(m, tag); >>>>>> 1372 } >>>>>> 1373 #ifdef VIMAGE >>>>>> 1374 if (V_loif) >>>>>> 1375 m->m_pkthdr.rcvif = V_loif; >>>>>> 1376 else { >>>>>> 1377 m_freem(m); >>>>>> 1378 return; >>>>>> (kgdb) >>>>>> >>>>> ok so probably there is a code-path to this point that does not first >>>>> set up the current-vnet pointer before doing this. >>>>> what you need to do is to produce a stack-trace so we can see how >>>>> it got here, >>>>> and then we can figure out where on that path we should set the >>>>> pointer. >>>> Here it is: >>>> (kgdb) #0 doadump () at pcpu.h:231 >>>> #1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808, >>>> dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548 >>>> #2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0, >>>> dopager=1) >>>> at /usr/src/sys/ddb/db_command.c:445 >>>> #3 0xc04d4e0a in db_command_loop () at >>>> /usr/src/sys/ddb/db_command.c:498 >>>> #4 0xc04d6d0d in db_trap (type=12, code=0) at >>>> /usr/src/sys/ddb/db_main.c:229 >>>> #5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948) >>>> at /usr/src/sys/kern/subr_kdb.c:535 >>>> #6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24) >>>> at /usr/src/sys/i386/i386/trap.c:929 >>>> #7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24) >>>> at /usr/src/sys/i386/i386/trap.c:851 >>>> #8 0xc0c0bad5 in trap (frame=0xeef1d948) at >>>> /usr/src/sys/i386/i386/trap.c:533 >>>> #9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >>>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) >>>> at /usr/src/sys/net/rtsock.c:1374 >>>> #11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at >>>> /usr/src/sys/net/rtsock.c:1168 >>>> #12 0xc76704a1 in ?? () >>>> #13 0xc6c3d400 in ?? () >>>> #14 0xeef1daa8 in ?? () >>>> #15 0xeef1daf4 in ?? () >>>> #16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200) >>>> at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105 >>>> #17 0xc766d8a1 in ?? () >>>> #18 0xc76b9200 in ?? () >>>> #19 0xc76c0000 in ?? () >>>> #20 0xc76f1000 in ?? () >>>> #21 0xeef1dacc in ?? () >>>> #22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () >>>> from /boot/modules/bcmwl5_sys.ko >>>> #23 0x006c0000 in ?? () >>>> #24 0xeef1dbb4 in ?? () >>>> #25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () >>>> from /boot/modules/bcmwl5_sys.ko >>>> #26 0xc76c0000 in ?? () >>>> #27 0xc76c0000 in ?? () >>>> #28 0xc7340800 in ?? () >>>> #29 0xc086adcc in hardclock_cpu (usermode=7077888) >>>> at /usr/src/sys/kern/kern_clock.c:447 >>> >>> whoa! >>> hardclock interrupted itself? >>> >>>> #30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () >>>> from /boot/modules/bcmwl5_sys.ko >>>> #31 0x006c0000 in ?? () >>>> #32 0xeef1dbb4 in ?? () >>>> #33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () >>>> from /boot/modules/bcmwl5_sys.ko >>>> #34 0xc76c0000 in ?? () >>>> #35 0xc76c0000 in ?? () >>>> #36 0xc7340800 in ?? () >>> hmmm maybe we need to get ndis to put in a wrapper at this point that >>> is called form hardclock and sets the value before going further >>> >>> I'd have to look at the code to see what happens here.. >>> >>> *wonders who has their fingers in this code*.. >>> >>>> #37 0xc086adcc in hardclock_cpu (usermode=-949223424) >>>> at /usr/src/sys/kern/kern_clock.c:447 >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>> >>>> >>>> and the panic, in case it helps: >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 1; apic id = 01 >>>> fault virtual address = 0x18 >>>> fault code = supervisor read, page not present >>>> instruction pointer = 0x20:0xc0978200 >>>> stack pointer = 0x28:0xeef1d988 >>>> frame pointer = 0x28:0xeef1d9a0 >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, def32 1, gran 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current process = 1404 (Windows Workitem 3) >>>> panic: from debugger >>>> cpuid = 1 >>>> KDB: stack backtrace: >>>> Physical memory: 2916 MB >>>> Dumping 113 MB: 98 82 66 50 34 18 2 >>>> >>>> Thanks, Nikos >>>> >> >> Please give more background information of this case. >> Personally I never tested VIMAGE. > > Sorry for the delayed response, > > It is easily producible. Build a kernel with VIMAGE, associate > with an AP, run dhclient and then change the SSID to something > random. > > If there is something I can do to help you debug this problem, > please don't hesitate to ask. First remove rt_ifmsg() call from if_ndis.c rebuild & load if_ndis module and tell me if it still happens. From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 18:49:31 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A5FE106566B; Sat, 9 Oct 2010 18:49:31 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3B18FC18; Sat, 9 Oct 2010 18:49:30 +0000 (UTC) Received: by fxm12 with SMTP id 12so136431fxm.13 for ; Sat, 09 Oct 2010 11:49:27 -0700 (PDT) Received: by 10.223.98.193 with SMTP id r1mr660428fan.144.1286650167641; Sat, 09 Oct 2010 11:49:27 -0700 (PDT) Received: from julie.lab.techwires.net ([178.2.204.101]) by mx.google.com with ESMTPS id m8sm2058268faj.11.2010.10.09.11.49.24 (version=SSLv3 cipher=RC4-MD5); Sat, 09 Oct 2010 11:49:25 -0700 (PDT) From: Bernhard Schmidt To: Alexey Dokuchaev Date: Sat, 9 Oct 2010 20:46:41 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> In-Reply-To: <20101009060239.GA88618@FreeBSD.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_RiLsMwW/r8wTxKE" Message-Id: <201010092046.41551.bschmidt@techwires.net> Cc: Paul B Mahol , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 18:49:31 -0000 --Boundary-00=_RiLsMwW/r8wTxKE Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 07:44:50PM +0200, Bernhard Schmidt wrote: > > On Friday 08 October 2010 19:36:13 Bernhard Schmidt wrote: > > > After having another cup of coffee it's pretty obvious what's wrong. > > > The only difference between what I did and your scenario is, that I > > > didn't use > > > ifconfig iwi0 mediaopt monitor > > > but > > > ifconfig iwi0 monitor > > I haven't look in the source yet, but what is the difference between > "mediaopt monitor" and "monitor"? The first is SIOCSIFMEDIA the other SIOCGIFFLAGS. The later probably only worked by accident.. > > > instead.. anyways.. > > > > > > Attached patched should behave better now. > > > > Sorry.. correct one this time. > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > does not work after that (and "list scan" returns no results) even if I > put adapter back to normal (from promisc and monitor modes) with > ifconfig(8). kldunloading and loading module again fixes the issue. Due to enqueueing the scan command in an infinite loop (yeah.. scanning returns every frame, that's monitor mode for that device.. *sigh*) we might increment a queue index but never actually dequeueing the command. On 'down' we clear the command queue but not the indicies resulting in the cur index not pointing to a filled entry. Attached patch should fix that. On a side note, you should never be required to run 'ifconfig dev scan', because after 'ifconfig dev up' the device is always in SCAN state (at least in station mode). Using 'ifconfig dev list scan' is sufficient enough. The 'scan' command is usally used to trigger a background scan while not being in SCAN state and those tend to get suspended pretty often (eg. when packets need to be sent), this is what you see as a hang. > Injection test "aireplay-ng -9 iwi0" still fails, but as I've been told > this is firmware issue (i.e. not possible with iwi(4)), which is also > inline with dmesg: > > kernel: iwi0: firmware error > kernel: iwi0: iwi_cmd: cmd 6 not sent, busy > kernel: iwi0: device configuration failed > > Googling shows that people patch Linux drivers to support injection, but > I do not know if any of that information is applicable to FreeBSD. It might be possible with lots of ugly hacks to get that device sending some kind of frames, 'injecting' those frames via net80211 shouldn't be that hard. At least the code is there according to comments in ieee80211_output.c. I do not consider this worth the effort though, if someone wants to work on that, let me know. > Apart from that, machine seems stable, and monitor mode is fixed. Thanks > a lot! You're welcome :) -- Bernhard --Boundary-00=_RiLsMwW/r8wTxKE Content-Type: text/x-patch; charset="ISO-8859-1"; name="iwi_fix_queue_idex.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iwi_fix_queue_idex.diff" Index: sys/dev/iwi/if_iwi.c =================================================================== --- sys/dev/iwi/if_iwi.c (revision 213584) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -3267,6 +3298,7 @@ iwi_stop(void *priv) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); memset(sc->sc_cmd, 0, sizeof(sc->sc_cmd)); + sc->sc_cmd_cur = sc->sc_cmd_next = 0; sc->sc_tx_timer = 0; sc->sc_rfkill_timer = 0; sc->sc_state_timer = 0; --Boundary-00=_RiLsMwW/r8wTxKE-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 23:30:46 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C2261065674 for ; Sat, 9 Oct 2010 23:30:46 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 651558FC16 for ; Sat, 9 Oct 2010 23:30:45 +0000 (UTC) Received: (qmail invoked by alias); 09 Oct 2010 23:30:43 -0000 Received: from 77.49.101.48.dsl.dyn.forthnet.gr (EHLO moby.local) [77.49.101.48] by mail.gmx.com (mp-eu003) with SMTP; 10 Oct 2010 01:30:43 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1+qsBY/nmuq+C4Ji6wtAo1SpZAJAhAvlB5UR3Xmr3 bspuojQYEz1FD/ Message-ID: <4CB0FB1D.60605@gmx.com> Date: Sun, 10 Oct 2010 02:30:37 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.23 (X11/20100313) MIME-Version: 1.0 To: Paul B Mahol References: <4CA0F4CE.7020905@freebsd.org> <4CB0944D.7060806@gmx.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: FreeBSD Net Subject: Re: VIMAGE + NDIS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 23:30:46 -0000 Paul B Mahol wrote: > First remove rt_ifmsg() call from if_ndis.c rebuild & load if_ndis > module and tell me if it still happens. No, it doesn't panic anymore. Thanks a lot for your help! Nikos