From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 12 00:43:49 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36EF1106566B; Sun, 12 Feb 2012 00:43:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 950378FC0A; Sun, 12 Feb 2012 00:43:48 +0000 (UTC) Received: by werm13 with SMTP id m13so4236397wer.13 for ; Sat, 11 Feb 2012 16:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ayoJkV9FvaN6ggmnWo2s8Ew4MAPXMQTKJ/+o/jF7ftM=; b=tx65xIXMuz7Izgsm0lkDpOn+S4o/ZbNk9chGI/N8NTZu2hd8zIR3V32e5/O0jPiH3q OqnlePai9Sgw3ztRSsX/USmQKcauVcKEjFgwB2XUbdeO6QLcwBDnLGJnevOwJsAE6R9t o851Fbm9kXVsRXKAm96+YYX2ssnOWxracp9Kw= MIME-Version: 1.0 Received: by 10.216.135.76 with SMTP id t54mr4431206wei.14.1329007427511; Sat, 11 Feb 2012 16:43:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sat, 11 Feb 2012 16:43:47 -0800 (PST) In-Reply-To: <4f36df71.2139440a.10ce.fffffb81@mx.google.com> References: <4F36DAB0.2020803@gmail.com> <4f36df71.2139440a.10ce.fffffb81@mx.google.com> Date: Sat, 11 Feb 2012 16:43:47 -0800 X-Google-Sender-Auth: q9EKJw7bc0IkjuvtPYlpSBa8VZg Message-ID: From: Adrian Chadd To: "Sevan / Venture37" , Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: wi driver X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 00:43:49 -0000 Is this FreeBSD-9.0 RELEASE? Which interface are you marking as up? wi0? or wlan0? Can you please supply me with a complete dmesg? Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 12 01:00:23 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B3211065677; Sun, 12 Feb 2012 01:00:23 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF4BE8FC08; Sun, 12 Feb 2012 01:00:22 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so1449843wgb.1 for ; Sat, 11 Feb 2012 17:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WaaeHYabtMZX0rYVlgV0f8HxK8qmuGot3mvs3W1UhE0=; b=mQi2keRQfPjEsZf0K1jHlGbhtzgXJMDM2Vb3mSm1oqVRf1orrJCxfWhx3dKPdNA8vn PxechJOyDnffsalG2qRvN8LQwkwHCdLzpvcxNxoDNLh5cVwNcaNQAh4qY3TjI8hNd9Sd bpuFqfAuHeP0jXXHAUGQEHXrcFOuewUYg2D9A= Received: by 10.180.101.101 with SMTP id ff5mr10847846wib.14.1329008421622; Sat, 11 Feb 2012 17:00:21 -0800 (PST) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id er8sm29915581wib.9.2012.02.11.17.00.18 (version=SSLv3 cipher=OTHER); Sat, 11 Feb 2012 17:00:20 -0800 (PST) Message-ID: <4F370F21.3030300@gmail.com> Date: Sun, 12 Feb 2012 01:00:17 +0000 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Adrian Chadd References: <4F36DAB0.2020803@gmail.com> <4f36df71.2139440a.10ce.fffffb81@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-wireless@freebsd.org" Subject: Re: wi driver X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 01:00:23 -0000 On 12/02/2012 00:43, Adrian Chadd wrote: > Is this FreeBSD-9.0 RELEASE? > > Which interface are you marking as up? wi0? or wlan0? wi0 > Can you please supply me with a complete dmesg? Sure, mac addresses have been snipped btw Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #1: Sat Feb 11 15:10:22 GMT 2012 xxx:/usr/obj/usr/src/sys/THINKPAD amd64 CPU: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (1596.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8155246592 (7777 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110527/tbfadt-556) ACPI Warning: Optional field Gpe1Block has zero address or length: 0x000000000000102C/0x0 (20110527/tbfadt-586) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard CPU0: local APIC error 0x40 acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf8000000-0xf80fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory acpi_video0: on vgapci0 vgapci1: mem 0xf8100000-0xf81fffff at device 2.1 on pci0 em0: port 0x1840-0x185f mem 0xf8200000-0xf821ffff,0xf8225000-0xf8225fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:1d:72: uhci0: port 0x1860-0x187f irq 20 at device 26.0 on pci0 usbus0: on uhci0 uhci1: port 0x1880-0x189f irq 21 at device 26.1 on pci0 usbus1: on uhci1 ehci0: mem 0xf8426c00-0xf8426fff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 hdac0: mem 0xf8220000-0xf8223fff irq 17 at device 27.0 on pci0 pcib1: irq 20 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci3: on pcib2 pci3: at device 0.0 (no driver attached) uhci2: port 0x18a0-0x18bf irq 16 at device 29.0 on pci0 usbus3: on uhci2 uhci3: port 0x18c0-0x18df irq 17 at device 29.1 on pci0 usbus4: on uhci3 ehci1: mem 0xf8427000-0xf84273ff irq 19 at device 29.7 on pci0 usbus5: EHCI version 1.0 usbus5: on ehci1 pcib3: at device 30.0 on pci0 pci5: on pcib3 cbb0: mem 0xd7eff000-0xd7efffff irq 16 at device 0.0 on pci5 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xd7efe800-0xd7efefff irq 17 at device 0.1 on pci5 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1d:72:ff: fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1d:72: fwe0: Ethernet address: 02:1d:72: fwip0: on firewire0 fwip0: Firewire address: 00:1d:72:ff:9 @ 0xfffe00000000, S400, maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x51c4000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode pci5: at device 0.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18e0-0x18ef at device 31.1 on pci0 ata0: on atapci0 ahci0: port 0x1c30-0x1c37,0x1c24-0x1c27,0x1c28-0x1c2f,0x1c20-0x1c23,0x1c00-0x1c1f mem 0xf8426000-0xf84267ff irq 16 at device 31.2 on pci0 ahci0: AHCI v1.10 with 3 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pci0: at device 31.3 (no driver attached) acpi_dock0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 orm0: at iomem 0xc0000-0xcffff,0xe0000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hdac0: HDA Codec #0: Analog Devices AD1984 hdac0: HDA Codec #1: Conexant (Unknown) pcm0: at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! GEOM: ada0s2: geometry does not match label (255h,63s != 16h,63s). GEOM: ada0s2: invalid disklabel. Root mount waiting for: cbb0 usbus5 usbus2 wi0: at port 0x4000-0x403f irq 16 function 0 config 1 on pccard0 uhub2: 4 ports with 4 removable, self powered uhub5: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ada0s3a [rw]... ugen0.2: at usbus0 From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 12 05:33:46 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E5E106566B for ; Sun, 12 Feb 2012 05:33:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4218FC08 for ; Sun, 12 Feb 2012 05:33:46 +0000 (UTC) Received: by werm13 with SMTP id m13so4334768wer.13 for ; Sat, 11 Feb 2012 21:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=BafZEcKWL0HLFq4300qHaJaFdu/GNRul00Jvfaftl7E=; b=vjpcf3Lh6TJLzLdZ3EAF4PGRbQSdZfQ8vetMTHmkmQ7BoGBSl/K8o1wsdTDh7MKZlb J00I/TKfUfvjeDO8ANOoXxdcuxKwrVpCUQ252eFrjggkg+quzDoYg4+kK8eNrixCneeo Amg48TSFKtqQdulNmtT8polOColeeHbNAVtSY= MIME-Version: 1.0 Received: by 10.216.135.76 with SMTP id t54mr4629834wei.14.1329024825509; Sat, 11 Feb 2012 21:33:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sat, 11 Feb 2012 21:33:45 -0800 (PST) Date: Sat, 11 Feb 2012 21:33:45 -0800 X-Google-Sender-Auth: dQ3S6mkiIlj95rCS3Fc6Rnh4zMA Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=00504502d75d9f48de04b8bdb4b5 Subject: [ath] patch: lock vap->iv_bss before using it in a few places X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 05:33:46 -0000 --00504502d75d9f48de04b8bdb4b5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, This quick patch mirrors what was done in r212127 - it enforces locking of whatever the vap->iv_bss node is before using it. I'd appreciate some testing and feedback before I commit it. I'm going to try and reproduce breaking it in sta/hostap mode but I won't be able to until I'm back in the lab next week. Thanks, Adrian --00504502d75d9f48de04b8bdb4b5 Content-Type: application/octet-stream; name="if_ath_net80211_lock.diff" Content-Disposition: attachment; filename="if_ath_net80211_lock.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gyjn1fcp0 SW5kZXg6IHN5cy9kZXYvYXRoL2lmX2F0aC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvYXRoL2lm X2F0aC5jCShyZXZpc2lvbiAyMzE1NDEpCisrKyBzeXMvZGV2L2F0aC9pZl9hdGguYwkod29ya2lu ZyBjb3B5KQpAQCAtMTY2OSw2ICsxNjY5LDcgQEAKIAkJc3RydWN0IGF0aF9zb2Z0YyAqc2MgPSBp ZnAtPmlmX3NvZnRjOwogCQl1X2ludDY0X3QgbGFzdHJ4ID0gc2MtPnNjX2xhc3RyeDsKIAkJdV9p bnQ2NF90IHRzZiA9IGF0aF9oYWxfZ2V0dHNmNjQoc2MtPnNjX2FoKTsKKwkJLyogWFhYIHNob3Vs ZCB0YWtlIGEgbG9ja2VkIHJlZiB0byBpdl9ic3MgKi8KIAkJdV9pbnQgYm1pc3N0aW1lb3V0ID0K IAkJCXZhcC0+aXZfYm1pc3N0aHJlc2hvbGQgKiB2YXAtPml2X2Jzcy0+bmlfaW50dmFsICogMTAy NDsKIApAQCAtMzI0NSw3ICszMjQ2LDcgQEAKIAogCWlmICh2YXAgPT0gTlVMTCkKIAkJdmFwID0g VEFJTFFfRklSU1QoJmljLT5pY192YXBzKTsJLyogWFhYICovCi0JbmkgPSB2YXAtPml2X2JzczsK KwluaSA9IGllZWU4MDIxMV9yZWZfbm9kZSh2YXAtPml2X2Jzcyk7CiAKIAkvKiBleHRyYWN0IHRz dGFtcCBmcm9tIGxhc3QgYmVhY29uIGFuZCBjb252ZXJ0IHRvIFRVICovCiAJbmV4dHRidHQgPSBU U0ZfVE9fVFUoTEVfUkVBRF80KG5pLT5uaV90c3RhbXAuZGF0YSArIDQpLApAQCAtMzQxNSw2ICsz NDE2LDcgQEAKIAkJCWF0aF9iZWFjb25fc3RhcnRfYWRob2Moc2MsIHZhcCk7CiAJfQogCXNjLT5z Y19zeW5jYmVhY29uID0gMDsKKwlpZWVlODAyMTFfZnJlZV9ub2RlKG5pKTsKICN1bmRlZiBGVURH RQogI3VuZGVmIFRTRl9UT19UVQogfQpAQCAtMzg1Myw2ICszODU1LDcgQEAKIAlzd2l0Y2ggKHN1 YnR5cGUpIHsKIAljYXNlIElFRUU4MDIxMV9GQzBfU1VCVFlQRV9CRUFDT046CiAJCS8qIHVwZGF0 ZSByc3NpIHN0YXRpc3RpY3MgZm9yIHVzZSBieSB0aGUgaGFsICovCisJCS8qIFhYWCB1bmxvY2tl ZCBjaGVjayBhZ2FpbnN0IHZhcC0+aXZfYnNzPyAqLwogCQlBVEhfUlNTSV9MUEYoc2MtPnNjX2hh bHN0YXRzLm5zX2F2Z2Jyc3NpLCByc3NpKTsKIAkJaWYgKHNjLT5zY19zeW5jYmVhY29uICYmCiAJ CSAgICBuaSA9PSB2YXAtPml2X2JzcyAmJiB2YXAtPml2X3N0YXRlID09IElFRUU4MDIxMV9TX1JV TikgewpAQCAtNTcyMSw3ICs1NzI0LDcgQEAKIAkJdGFza3F1ZXVlX3VuYmxvY2soc2MtPnNjX3Rx KTsKIAl9CiAKLQluaSA9IHZhcC0+aXZfYnNzOworCW5pID0gaWVlZTgwMjExX3JlZl9ub2RlKHZh cC0+aXZfYnNzKTsKIAlyZmlsdCA9IGF0aF9jYWxjcnhmaWx0ZXIoc2MpOwogCXN0YW1vZGUgPSAo dmFwLT5pdl9vcG1vZGUgPT0gSUVFRTgwMjExX01fU1RBIHx8CiAJCSAgIHZhcC0+aXZfb3Btb2Rl ID09IElFRUU4MDIxMV9NX0FIREVNTyB8fApAQCAtNTc1Miw3ICs1NzU1LDggQEAKIAogCWlmIChu c3RhdGUgPT0gSUVFRTgwMjExX1NfUlVOKSB7CiAJCS8qIE5COiBjb2xsZWN0IGJzcyBub2RlIGFn YWluLCBpdCBtYXkgaGF2ZSBjaGFuZ2VkICovCi0JCW5pID0gdmFwLT5pdl9ic3M7CisJCWllZWU4 MDIxMV9mcmVlX25vZGUobmkpOworCQluaSA9IGllZWU4MDIxMV9yZWZfbm9kZSh2YXAtPml2X2Jz cyk7CiAKIAkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NUQVRFLAogCQkgICAgIiVzKFJVTik6IGl2 X2ZsYWdzIDB4JTA4eCBiaW50dmwgJWQgYnNzaWQgJXMgIgpAQCAtNTg3NSw2ICs1ODc5LDcgQEAK ICNlbmRpZgogCX0KIGJhZDoKKwlpZWVlODAyMTFfZnJlZV9ub2RlKG5pKTsKIAlyZXR1cm4gZXJy b3I7CiB9CiAKQEAgLTU4OTMsNiArNTg5OCw3IEBACiAJc3RydWN0IGF0aF9zb2Z0YyAqc2MgPSB2 YXAtPml2X2ljLT5pY19pZnAtPmlmX3NvZnRjOwogCWllZWU4MDIxMV9rZXlpeCBrZXlpeCwgcnhr ZXlpeDsKIAorCS8qIFhYWCBzaG91bGQgdGFrZSBhIGxvY2tlZCByZWYgdG8gdmFwLT5pdl9ic3Mg Ki8KIAlpZiAoIWF0aF9rZXlfYWxsb2ModmFwLCAmbmktPm5pX3VjYXN0a2V5LCAma2V5aXgsICZy eGtleWl4KSkgewogCQkvKgogCQkgKiBLZXkgY2FjaGUgaXMgZnVsbDsgd2UnbGwgZmFsbCBiYWNr IHRvIGRvaW5nCkBAIC02NDQ4LDYgKzY0NTQsNyBAQAogCQkJcmV0dXJuOwogCQl9CiAJfQorCS8q IFhYWCBzaG91bGQgdGFrZSBhIGxvY2tlZCByZWYgdG8gaXZfYnNzICovCiAJdHAgPSB2YXAtPml2 X2Jzcy0+bmlfdHhwYXJtczsKIAkvKgogCSAqIENhbGN1bGF0ZSB0aGUgZ3VhcmQgdGltZSBmb3Ig ZWFjaCBzbG90LiAgVGhpcyBpcyB0aGUKQEAgLTY2OTcsNiArNjcwNCw3IEBACiAJCSAqIFJlY29y ZCBsb2NhbCBUU0YgZm9yIG91ciBsYXN0IHNlbmQgZm9yIHVzZQogCQkgKiBpbiBhcmJpdHJhdGlu ZyBzbG90IGNvbGxpc2lvbnMuCiAJCSAqLworCQkvKiBYWFggc2hvdWxkIHRha2UgYSBsb2NrZWQg cmVmIHRvIGl2X2JzcyAqLwogCQl2YXAtPml2X2Jzcy0+bmlfdHN0YW1wLnRzZiA9IGF0aF9oYWxf Z2V0dHNmNjQoYWgpOwogCX0KIH0K --00504502d75d9f48de04b8bdb4b5-- From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 12 23:24:26 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4F951065674; Sun, 12 Feb 2012 23:24:26 +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 77F568FC17; Sun, 12 Feb 2012 23:24:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1CNOQsK090729; Sun, 12 Feb 2012 23:24:26 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1CNOQf1090725; Sun, 12 Feb 2012 23:24:26 GMT (envelope-from adrian) Date: Sun, 12 Feb 2012 23:24:26 GMT Message-Id: <201202122324.q1CNOQf1090725@freefall.freebsd.org> To: kwm@FreeBSD.org, adrian@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/163312: [panic] [ath driver] kernel panic: page fault with ath0 taskq X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 23:24:26 -0000 Synopsis: [panic] [ath driver] kernel panic: page fault with ath0 taskq State-Changed-From-To: open->patched State-Changed-By: adrian State-Changed-When: Sun Feb 12 23:23:12 UTC 2012 State-Changed-Why: The patch in the PR should be fine - the RX antenna should be validated before being used. This should be backported to 9.x and 8.x. Although it _should_ only be occuring when in 11n mode (since RX antenna may not be updated for non-final RX aggregate frames) it may be occuring elsewhere. http://www.freebsd.org/cgi/query-pr.cgi?pr=163312 From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 13 00:14:16 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDAAD106564A; Mon, 13 Feb 2012 00:14:16 +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 9FD0B8FC08; Mon, 13 Feb 2012 00:14:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1D0EGXd042624; Mon, 13 Feb 2012 00:14:16 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1D0EG89042620; Mon, 13 Feb 2012 00:14:16 GMT (envelope-from adrian) Date: Mon, 13 Feb 2012 00:14:16 GMT Message-Id: <201202130014.q1D0EG89042620@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/165060: [ath] vap->iv_bss race conditions causing crashes inside ath_beacon_alloc and similar X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:14:16 -0000 Synopsis: [ath] vap->iv_bss race conditions causing crashes inside ath_beacon_alloc and similar Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Feb 13 00:14:06 UTC 2012 Responsible-Changed-Why: Assign http://www.freebsd.org/cgi/query-pr.cgi?pr=165060 From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 13 00:30:14 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69DB0106564A for ; Mon, 13 Feb 2012 00:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5489A8FC16 for ; Mon, 13 Feb 2012 00:30:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1D0UETH052329 for ; Mon, 13 Feb 2012 00:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1D0UEKi052326; Mon, 13 Feb 2012 00:30:14 GMT (envelope-from gnats) Date: Mon, 13 Feb 2012 00:30:14 GMT Message-Id: <201202130030.q1D0UEKi052326@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165060: commit references a PR X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:30:14 -0000 The following reply was made to PR kern/165060; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165060: commit references a PR Date: Mon, 13 Feb 2012 00:28:55 +0000 (UTC) Author: adrian Date: Mon Feb 13 00:28:41 2012 New Revision: 231571 URL: http://svn.freebsd.org/changeset/base/231571 Log: Attempt to address some potential vap->iv_bss race conditions. There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060 Modified: head/sys/dev/ath/if_ath.c Modified: head/sys/dev/ath/if_ath.c ============================================================================== --- head/sys/dev/ath/if_ath.c Sun Feb 12 23:48:39 2012 (r231570) +++ head/sys/dev/ath/if_ath.c Mon Feb 13 00:28:41 2012 (r231571) @@ -1669,6 +1669,7 @@ ath_bmiss_vap(struct ieee80211vap *vap) struct ath_softc *sc = ifp->if_softc; u_int64_t lastrx = sc->sc_lastrx; u_int64_t tsf = ath_hal_gettsf64(sc->sc_ah); + /* XXX should take a locked ref to iv_bss */ u_int bmisstimeout = vap->iv_bmissthreshold * vap->iv_bss->ni_intval * 1024; @@ -3245,7 +3246,7 @@ ath_beacon_config(struct ath_softc *sc, if (vap == NULL) vap = TAILQ_FIRST(&ic->ic_vaps); /* XXX */ - ni = vap->iv_bss; + ni = ieee80211_ref_node(vap->iv_bss); /* extract tstamp from last beacon and convert to TU */ nexttbtt = TSF_TO_TU(LE_READ_4(ni->ni_tstamp.data + 4), @@ -3415,6 +3416,7 @@ ath_beacon_config(struct ath_softc *sc, ath_beacon_start_adhoc(sc, vap); } sc->sc_syncbeacon = 0; + ieee80211_free_node(ni); #undef FUDGE #undef TSF_TO_TU } @@ -3853,6 +3855,7 @@ ath_recv_mgmt(struct ieee80211_node *ni, switch (subtype) { case IEEE80211_FC0_SUBTYPE_BEACON: /* update rssi statistics for use by the hal */ + /* XXX unlocked check against vap->iv_bss? */ ATH_RSSI_LPF(sc->sc_halstats.ns_avgbrssi, rssi); if (sc->sc_syncbeacon && ni == vap->iv_bss && vap->iv_state == IEEE80211_S_RUN) { @@ -5721,7 +5724,7 @@ ath_newstate(struct ieee80211vap *vap, e taskqueue_unblock(sc->sc_tq); } - ni = vap->iv_bss; + ni = ieee80211_ref_node(vap->iv_bss); rfilt = ath_calcrxfilter(sc); stamode = (vap->iv_opmode == IEEE80211_M_STA || vap->iv_opmode == IEEE80211_M_AHDEMO || @@ -5752,7 +5755,8 @@ ath_newstate(struct ieee80211vap *vap, e if (nstate == IEEE80211_S_RUN) { /* NB: collect bss node again, it may have changed */ - ni = vap->iv_bss; + ieee80211_free_node(ni); + ni = ieee80211_ref_node(vap->iv_bss); DPRINTF(sc, ATH_DEBUG_STATE, "%s(RUN): iv_flags 0x%08x bintvl %d bssid %s " @@ -5875,6 +5879,7 @@ ath_newstate(struct ieee80211vap *vap, e #endif } bad: + ieee80211_free_node(ni); return error; } @@ -5893,6 +5898,7 @@ ath_setup_stationkey(struct ieee80211_no struct ath_softc *sc = vap->iv_ic->ic_ifp->if_softc; ieee80211_keyix keyix, rxkeyix; + /* XXX should take a locked ref to vap->iv_bss */ if (!ath_key_alloc(vap, &ni->ni_ucastkey, &keyix, &rxkeyix)) { /* * Key cache is full; we'll fall back to doing @@ -6448,6 +6454,7 @@ ath_tdma_config(struct ath_softc *sc, st return; } } + /* XXX should take a locked ref to iv_bss */ tp = vap->iv_bss->ni_txparms; /* * Calculate the guard time for each slot. This is the @@ -6697,6 +6704,7 @@ ath_tdma_beacon_send(struct ath_softc *s * Record local TSF for our last send for use * in arbitrating slot collisions. */ + /* XXX should take a locked ref to iv_bss */ vap->iv_bss->ni_tstamp.tsf = ath_hal_gettsf64(ah); } } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 13 11:08:16 2012 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EFD0106564A for ; Mon, 13 Feb 2012 11:08:16 +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 7C5998FC12 for ; Mon, 13 Feb 2012 11:08:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1DB8Gg3091083 for ; Mon, 13 Feb 2012 11:08:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1DB8Fpj091080 for freebsd-wireless@FreeBSD.org; Mon, 13 Feb 2012 11:08:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Feb 2012 11:08:15 GMT Message-Id: <201202131108.q1DB8Fpj091080@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 11:08:16 -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/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/164721 wireless [ath] ath device timeouts o kern/164499 wireless [wi] [patch] if_wi needs fix for big endian architectu o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 wireless [ath] wireless networking stops functioning o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne p bin/137484 wireless [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/136943 wireless [wpi] [lor] wpi0_com_lock / wpi0 o kern/136836 wireless [ath] atheros card stops functioning after about 12 ho o kern/132722 wireless [ath] Wifi ath0 associates fine with AP, but DHCP or I o bin/131549 wireless ifconfig(8) can't clear 'monitor' mode on the wireless o kern/126475 wireless [ath] [panic] ath pcmcia card inevitably panics under o kern/125721 wireless [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 wireless [ath] [panic] ath(4) related panic o kern/125501 wireless [ath] atheros cardbus driver hangs o kern/125332 wireless [ath] [panic] crash under any non-tiny networking unde o kern/124767 wireless [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 wireless [ieee80211] net80211 discards power-save queue packets o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 69 problems total. From owner-freebsd-wireless@FreeBSD.ORG Tue Feb 14 08:19:41 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCB561065672 for ; Tue, 14 Feb 2012 08:19:41 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7FA8FC16 for ; Tue, 14 Feb 2012 08:19:41 +0000 (UTC) Received: by iaeo4 with SMTP id o4so6864965iae.13 for ; Tue, 14 Feb 2012 00:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=XTQtBtP7YtDqXhuwJRGtub/bh5/IHta68RBPLn+ruXw=; b=JhXW6ni7OGZfFF3aNcnYqhvKv1koqlwBWIWz52N4FEt58J93UYO39NUMWsPP0NKsvC FkTbUx5QNC6dv+UOHds2hdnC0bpwtyQu73oWLuUS1wt0A9LONWOaEEXWdv2C8tCOvfwb 7PSuceje9bbKEzdRLkm9qMW1AqGIgQjaiI9QM= MIME-Version: 1.0 Received: by 10.42.80.3 with SMTP id t3mr26124285ick.49.1329207581013; Tue, 14 Feb 2012 00:19:41 -0800 (PST) Received: by 10.50.213.74 with HTTP; Tue, 14 Feb 2012 00:19:40 -0800 (PST) Date: Tue, 14 Feb 2012 09:19:40 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Fragment number of first fragment != 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 08:19:41 -0000 Hi, I found that in FreeBSD current the first fragment will have a fragment number = 1 in function ieee80211_fragment. But according to 802.11-2007, 9.4 Fragmentation page 279: "...The fragments shall be sent in order of lowest fragment number to highest fragment number, where the fragment number value starts at zero, ..." This also holds on the 802.11-2011 draft 12: "The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by one for each successive fragment of that MSDU or MMPDU." I checked Linux 3.3-rc3 code and there I see them having a check on rx side if (frag == 0) { /* This is the first fragment of a new frame. */ and on tx side they put: fragnum = 0; On Madwifi 0.9.4 in function ieee80211_encap: fragnum = 0; So should we change our fragno to be 0? br, -- Monthadar Al Jaberi From owner-freebsd-wireless@FreeBSD.ORG Tue Feb 14 08:26:22 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B9A106564A for ; Tue, 14 Feb 2012 08:26:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 193048FC0A for ; Tue, 14 Feb 2012 08:26:21 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so6230959wib.13 for ; Tue, 14 Feb 2012 00:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aGrv+PL/VgTf58BjxmdKRYB12mylT44uKfE/juaZYo8=; b=TfUkS/mkm7YMoPdzQjwapCtC39YSPEXBL6BfTcbDq17rDfAGvvI6qO7nQb37ptZLMN ZMI3m2i+LrJ5ZhkqFQXEZ7eiIS6Xe/TAEZ9seRltbOHSiwoIZJrQTF+BOPNjSa0Gzp75 0Vbwg177fnzvOJTFwSeyF5dcBNqQcRkB8cCxM= MIME-Version: 1.0 Received: by 10.180.78.6 with SMTP id x6mr1981504wiw.18.1329207981054; Tue, 14 Feb 2012 00:26:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Tue, 14 Feb 2012 00:26:21 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 00:26:21 -0800 X-Google-Sender-Auth: asoIcm1Zw0cqphnhRyjIBOBuBXQ Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Fragment number of first fragment != 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 08:26:22 -0000 Lemme check into this a little more.. adrian On 14 February 2012 00:19, Monthadar Al Jaberi wrote: > Hi, > > I found that in FreeBSD current the first fragment will have a > fragment number = 1 in function ieee80211_fragment. > > But according to 802.11-2007, 9.4 Fragmentation page 279: > "...The fragments shall be sent in order of lowest fragment number to > highest fragment > number, where the fragment number value starts at zero, ..." > > This also holds on the 802.11-2011 draft 12: > "The fragment number is set to 0 in the first or only fragment of an > MSDU or MMPDU and is > incremented by one for each successive fragment of that MSDU or MMPDU." > > I checked Linux 3.3-rc3 code and there I see them having a check on rx side > if (frag == 0) { /* This is the first fragment of a new frame. */ > and on tx side they put: > fragnum = 0; > > On Madwifi 0.9.4 in function ieee80211_encap: > fragnum = 0; > > So should we change our fragno to be 0? > > br, > > -- > Monthadar Al Jaberi > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Tue Feb 14 16:03:20 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85D9F1065740 for ; Tue, 14 Feb 2012 16:03:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lpp01m020-f182.google.com (mail-lpp01m020-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0288D8FC1E for ; Tue, 14 Feb 2012 16:03:19 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so4688797lbb.13 for ; Tue, 14 Feb 2012 08:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4X+Bk6HPnwplzxEdfQuy5b3Snk5nMpDK+LWSo350AF4=; b=niiIsrfSuS866nuGzwVgB2wtCUIcaufTTYTXw6YPqGdLNUvI88+mrz2hdTMB18SIsn E9JxkH1e96QsKgDNGs1OJ7XMQu5QdzdXdVplSAk5jIC3tzrij7D1IkQNU9A6dUUk7e1j YQ0WgcEbTrttbmvAt9Pb0Lc8Molk/KvLTLgkQ= MIME-Version: 1.0 Received: by 10.152.125.20 with SMTP id mm20mr14562389lab.6.1329235398702; Tue, 14 Feb 2012 08:03:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.112.87.35 with HTTP; Tue, 14 Feb 2012 08:03:18 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 08:03:18 -0800 X-Google-Sender-Auth: R_qqgYSwWScon42SFEEGH1wbbtk Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Fragment number of first fragment != 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:03:20 -0000 .. I think the answer is "yes". Please create a PR with what you've put in this email and a patch to fix it. I'll commit that fix today :0 adrian On 14 February 2012 00:26, Adrian Chadd wrote: > Lemme check into this a little more.. > > > adrian > > On 14 February 2012 00:19, Monthadar Al Jaberi wrote: >> Hi, >> >> I found that in FreeBSD current the first fragment will have a >> fragment number = 1 in function ieee80211_fragment. >> >> But according to 802.11-2007, 9.4 Fragmentation page 279: >> "...The fragments shall be sent in order of lowest fragment number to >> highest fragment >> number, where the fragment number value starts at zero, ..." >> >> This also holds on the 802.11-2011 draft 12: >> "The fragment number is set to 0 in the first or only fragment of an >> MSDU or MMPDU and is >> incremented by one for each successive fragment of that MSDU or MMPDU." >> >> I checked Linux 3.3-rc3 code and there I see them having a check on rx side >> if (frag == 0) { /* This is the first fragment of a new frame. */ >> and on tx side they put: >> fragnum = 0; >> >> On Madwifi 0.9.4 in function ieee80211_encap: >> fragnum = 0; >> >> So should we change our fragno to be 0? >> >> br, >> >> -- >> Monthadar Al Jaberi >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Tue Feb 14 18:43:34 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFCD9106566C; Tue, 14 Feb 2012 18:43:34 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8948FC18; Tue, 14 Feb 2012 18:43:34 +0000 (UTC) Received: by yhfs35 with SMTP id s35so258189yhf.13 for ; Tue, 14 Feb 2012 10:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eySPI+c3Uieyrw4njliKOZMgHpQ83z80sb+DnvTYnT0=; b=sN48aI6r1QNIuuibJWQmTEf6eg9rJMHw3KJGNMx9Af+zrfTenSY6QS/g+B9yV2UNXf unIpPhGjNBKh8dKJy0aYzVps+k+qPWMk6Fi4gUI+7UCyPpVWwbgKjQUhfTIbpeYXmjbl 6x3/GbhI67SMoVmnAhxcGBxFqaLsK1TJygfYs= MIME-Version: 1.0 Received: by 10.50.85.231 with SMTP id k7mr6278535igz.25.1329245013652; Tue, 14 Feb 2012 10:43:33 -0800 (PST) Received: by 10.50.213.74 with HTTP; Tue, 14 Feb 2012 10:43:33 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 19:43:33 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Fragment number of first fragment != 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:43:35 -0000 done; http://www.freebsd.org/cgi/query-pr.cgi?pr=165146 br On Tue, Feb 14, 2012 at 5:03 PM, Adrian Chadd wrote: > .. I think the answer is "yes". > > Please create a PR with what you've put in this email and a patch to fix it. > > I'll commit that fix today :0 > > > adrian > > On 14 February 2012 00:26, Adrian Chadd wrote: >> Lemme check into this a little more.. >> >> >> adrian >> >> On 14 February 2012 00:19, Monthadar Al Jaberi wrote: >>> Hi, >>> >>> I found that in FreeBSD current the first fragment will have a >>> fragment number = 1 in function ieee80211_fragment. >>> >>> But according to 802.11-2007, 9.4 Fragmentation page 279: >>> "...The fragments shall be sent in order of lowest fragment number to >>> highest fragment >>> number, where the fragment number value starts at zero, ..." >>> >>> This also holds on the 802.11-2011 draft 12: >>> "The fragment number is set to 0 in the first or only fragment of an >>> MSDU or MMPDU and is >>> incremented by one for each successive fragment of that MSDU or MMPDU." >>> >>> I checked Linux 3.3-rc3 code and there I see them having a check on rx side >>> if (frag == 0) { /* This is the first fragment of a new frame. */ >>> and on tx side they put: >>> fragnum = 0; >>> >>> On Madwifi 0.9.4 in function ieee80211_encap: >>> fragnum = 0; >>> >>> So should we change our fragno to be 0? >>> >>> br, >>> >>> -- >>> Monthadar Al Jaberi >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" -- Monthadar Al Jaberi From owner-freebsd-wireless@FreeBSD.ORG Tue Feb 14 22:14:58 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 682341065679; Tue, 14 Feb 2012 22:14:58 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 194E98FC14; Tue, 14 Feb 2012 22:14:57 +0000 (UTC) Received: by iaeo4 with SMTP id o4so626472iae.13 for ; Tue, 14 Feb 2012 14:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=/JRZ5BWixvzeaSqk9vCOebrnHQnepS8uf555KSdOeoc=; b=NA+1Gpi8XbysMssV3HVvZgawhS9B0UcN+ZCgcF3Jr8cYECzyW3Rbxka/aoi/TQ5y9x n8sVGMvoSvoejp8ww/ZhC9gwqmE2NVRhCqfX7IBU8zODS5II9dYTE4SzXVYChVj4xSZ3 pVBx9KsTDkbpXreHZaw/0iPnxmsn/KnQXQ6Z4= MIME-Version: 1.0 Received: by 10.42.80.3 with SMTP id t3mr30727684ick.49.1329257697585; Tue, 14 Feb 2012 14:14:57 -0800 (PST) Received: by 10.50.213.74 with HTTP; Tue, 14 Feb 2012 14:14:57 -0800 (PST) Date: Tue, 14 Feb 2012 23:14:57 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=20cf3011da15e12aee04b8f3ec09 Cc: Rui Paulo , Bernhard Schmidt Subject: Fragment and 11s inconsistency X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:14:58 -0000 --20cf3011da15e12aee04b8f3ec09 Content-Type: text/plain; charset=ISO-8859-1 Hi, I cant verify this yet, but isn't there something wrong in current FreeBSD? lets say an 11s data frame need to be fragmented in ieee80211_encap: if (addqos) hdrsize = sizeof(struct ieee80211_qosframe); else hdrsize = sizeof(struct ieee80211_frame); ... if (vap->iv_opmode == IEEE80211_M_MBSS) { ... if (!IEEE80211_IS_MULTICAST(eh.ether_dhost)) hdrsize += IEEE80211_ADDR_LEN; /* unicast are 4-addr */ meshhdrsize = sizeof(struct ieee80211_meshcntl); } ... if (__predict_true((m->m_flags & M_FF) == 0)) { /* * Normal frame. */ m = ieee80211_mbuf_adjust(vap, hdrspace + meshhdrsize, key, m); } M_PREPEND(m, hdrspace + meshhdrsize, M_DONTWAIT); if (txfrag && !ieee80211_fragment(vap, m, hdrsize, key != NULL ? key->wk_cipher->ic_header : 0, vap->iv_fragthreshold)) goto bad; This means we send meshcontrol only in first segment, because we never add meshhdrsize to hdrsize... but in mesh_input switch (type) { case IEEE80211_FC0_TYPE_DATA: ... meshdrlen = sizeof(struct ieee80211_meshcntl) + (mc->mc_flags & 3) * IEEE80211_ADDR_LEN; hdrspace += meshdrlen; ... /* * Potentially forward packet. See table s36 (p140) * for the rules. XXX tap fwd'd packets not for us? */ if (dir == IEEE80211_FC1_DIR_FROMDS || !mesh_isucastforme(vap, wh, mc)) { mesh_forward(vap, m, mc); ... if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { m = ieee80211_defrag(ni, m, hdrspace); if (m == NULL) { This seems wrong to me, how can we potentially forward before defragin the frame? this will fail cause sub-frag have no mesh control as code shows above. shouldnt the defrag code be moved above? I am attaching a patch that both moves the defrag, validates that mesh control is present and makes 11s data frames QoS and set Mesh control bit present to 1 as the amendment specifies. br, -- Monthadar Al Jaberi --20cf3011da15e12aee04b8f3ec09 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Disposition: attachment; filename="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynhniow0 RnJvbSA4MmFhNTg2OWNlMTQwNTg4Mjc0YzgwMjFhNWQ0MDQyMDI1ZDFmMWFhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNb250aGFkYXIgQWwgSmFiZXJpIDxtb250aGFkYXJAZ21haWwu Y29tPgpEYXRlOiBUdWUsIDE0IEZlYiAyMDEyIDE2OjQ3OjQzICswMTAwClN1YmplY3Q6IFtQQVRD SF0gTWFrZSBtZXNoIGRhdGEgZnJhbWVzIHRvIGJlIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKS4K CiogSW50cm9kdWNlIG5ldyBmbGFnIGZvciBRb1MgY29udHJvbCBmaWVsZDsKKiBDaGFuZ2UgaW4g bWVzaF9pbnB1dCB0byB2YWxpZGF0ZSB0aGF0IFFvUyBpcyBzZXQgYW5kIE1lc2ggQ29udHJvbCBm aWVsZAppcyBwcmVzZW50LCBhbHNvIGJvdGggYnl0ZXMgb2YgdGhlIFFvUyBhcmUgcmVhZDsKKiBN b3ZlZCBkZWZyYWdtZW50YXRpb24gaW4gbWVzaF9pbnB1dCBiZWZvcmUgd2UgdHJ5IHRvIGZvcndh cmQgcGFja2V0IGFzCmluZmVycmVkIGZyb20gYW1lbmRtZW50IHNwZWMsIGJlY2F1c2UgTWVzaCBD b250cm9sIGZpZWxkIG9ubHkgcHJlc2VudCBpbiBmaXJzdApmcmFnbWVudDsKKiBDaGFuZ2VkIGlu IGllZWU4MDIxMV9lbmNhcCB0byBzZXQgUW9TIHN1YnR5cGUgYW5kIE1lc2ggQ29udHJvbCBmaWVs ZCBwcmVzZW50OwotLS0KIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTEuaCAgICAgICAgfCAgICA3ICsr Kwogc3lzL25ldDgwMjExL2llZWU4MDIxMV9tZXNoLmMgICB8ICAgODMgKysrKysrKysrKysrKysr KysrKysrKysrKysrLS0tLS0tLS0tLS0tCiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX291dHB1dC5j IHwgICAxMyArKysrKy0KIDMgZmlsZXMgY2hhbmdlZCwgNzUgaW5zZXJ0aW9ucygrKSwgMjggZGVs ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4MDIxMS5oIGIvc3lzL25l dDgwMjExL2llZWU4MDIxMS5oCmluZGV4IDAyOGFmZWMuLjI5YmZhM2MgMTAwNjQ0Ci0tLSBhL3N5 cy9uZXQ4MDIxMS9pZWVlODAyMTEuaAorKysgYi9zeXMvbmV0ODAyMTEvaWVlZTgwMjExLmgKQEAg LTE5OSw2ICsxOTksMTMgQEAgc3RydWN0IGllZWU4MDIxMV9xb3NmcmFtZV9hZGRyNCB7CiAjZGVm aW5lCUlFRUU4MDIxMV9RT1NfRU9TUAkJCTB4MTAJLyogRW5kT2ZTZXJ2aWNlIFBlcmlvZCovCiAj ZGVmaW5lCUlFRUU4MDIxMV9RT1NfRU9TUF9TCQkJNAogI2RlZmluZQlJRUVFODAyMTFfUU9TX1RJ RAkJCTB4MGYKKy8qIHFvc1sxXSBieXRlIHVzZWQgZm9yIGFsbCBmcmFtZXMgc2VudCBieSBtZXNo IFNUQXMgaW4gYSBtZXNoIEJTUyAqLworI2RlZmluZSBJRUVFODAyMTFfUU9TX01DCQkJMHgxMAkv KiBNZXNoIGNvbnRyb2wgKi8KKy8qIE1lc2ggcG93ZXIgc2F2ZSBsZXZlbCovCisjZGVmaW5lIElF RUU4MDIxMV9RT1NfTUVTSF9QU0wJCQkweDIwCisvKiBNZXNoIFJlY2VpdmVyIFNlcnZpY2UgUGVy aW9kIEluaXRpYXRlZCAqLworI2RlZmluZSBJRUVFODAyMTFfUU9TX1JTUEkJCQkweDQwCisvKiBi aXRzIDExIHRvIDE1IHJlc2VydmVkICovCiAKIC8qIGRvZXMgZnJhbWUgaGF2ZSBRb1Mgc2VxdWVu Y2UgY29udHJvbCBkYXRhICovCiAjZGVmaW5lCUlFRUU4MDIxMV9RT1NfSEFTX1NFUSh3aCkgXApk aWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4MDIxMV9tZXNoLmMgYi9zeXMvbmV0ODAyMTEv aWVlZTgwMjExX21lc2guYwppbmRleCBiOTJmNjk1Li5hMjAzNjA0IDEwMDY0NAotLS0gYS9zeXMv bmV0ODAyMTEvaWVlZTgwMjExX21lc2guYworKysgYi9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX21l c2guYwpAQCAtMTA0Nyw5ICsxMDQ3LDkgQEAgbWVzaF9pbnB1dChzdHJ1Y3QgaWVlZTgwMjExX25v ZGUgKm5pLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGludCBuZikKIAlzdHJ1Y3QgaWVlZTgw MjExX2ZyYW1lICp3aDsKIAljb25zdCBzdHJ1Y3QgaWVlZTgwMjExX21lc2hjbnRsICptYzsKIAlp bnQgaGRyc3BhY2UsIG1lc2hkcmxlbiwgbmVlZF90YXA7Ci0JdWludDhfdCBkaXIsIHR5cGUsIHN1 YnR5cGUsIHFvczsKKwl1aW50OF90IGRpciwgdHlwZSwgc3VidHlwZTsKIAl1aW50MzJfdCBzZXE7 Ci0JdWludDhfdCAqYWRkcjsKKwl1aW50OF90ICphZGRyLCBxb3NbMl07CiAJaWVlZTgwMjExX3Nl cSByeHNlcTsKIAogCUtBU1NFUlQobmkgIT0gTlVMTCwgKCJudWxsIG5vZGUiKSk7CkBAIC0xMTQ2 LDggKzExNDYsNjIgQEAgbWVzaF9pbnB1dChzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1 Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGludCBuZikKIAkJCXZhcC0+aXZfc3RhdHMuaXNfcnhfd3Jv bmdkaXIrKzsKIAkJCWdvdG8gZXJyOwogCQl9Ci0JCS8qIHB1bGwgdXAgZW5vdWdoIHRvIGdldCB0 byB0aGUgbWVzaCBjb250cm9sICovCisKKwkJLyogQWxsIE1lc2ggZGF0YSBmcmFtZXMgYXJlIFFv UyBzdWJ0eXBlICovCisJCWlmICghSEFTX1NFUSh0eXBlKSkgeworCQkJSUVFRTgwMjExX0RJU0NB UkQodmFwLCBJRUVFODAyMTFfTVNHX0lOUFVULAorCQkJICAgIHdoLCAiZGF0YSIsICJpbmNvcnJl Y3Qgc3VidHlwZSAweCV4Iiwgc3VidHlwZSk7CisJCQl2YXAtPml2X3N0YXRzLmlzX3J4X2JhZHN1 YnR5cGUrKzsKKwkJCWdvdG8gZXJyOworCQl9CisKKwkJLyoKKwkJICogTmV4dCB1cCwgYW55IGZy YWdtZW50YXRpb24uCisJCSAqIFhYWDogd2UgZGVmcmFnIGJlZm9yZSB3ZSBldmVuIHRyeSB0byBm b3J3YXJkLAorCQkgKiBNZXNoIENvbnRyb2wgZmllbGQgaXMgbm90IHByZXNlbnQgaW4gc3ViLXNl cXVlbnQKKwkJICogZnJhZ21lbnRlZCBmcmFtZXMuIFRoaXMgaXMgaW4gY29uc3RyYXN0IHRvIERy YWYgNC4wLgorCQkgKi8KIAkJaGRyc3BhY2UgPSBpZWVlODAyMTFfaGRyc3BhY2UoaWMsIHdoKTsK KwkJaWYgKCFJRUVFODAyMTFfSVNfTVVMVElDQVNUKHdoLT5pX2FkZHIxKSkgeworCQkJbSA9IGll ZWU4MDIxMV9kZWZyYWcobmksIG0sIGhkcnNwYWNlKTsKKwkJCWlmIChtID09IE5VTEwpIHsKKwkJ CQkvKiBGcmFnbWVudCBkcm9wcGVkIG9yIGZyYW1lIG5vdCBjb21wbGV0ZSB5ZXQgKi8KKwkJCQln b3RvIG91dDsKKwkJCX0KKwkJfQorCQl3aCA9IG10b2QobSwgc3RydWN0IGllZWU4MDIxMV9mcmFt ZSAqKTsgLyogTkI6IGFmdGVyIGRlZnJhZyAqLworCisJCS8qCisJCSAqIE5vdyB3ZSBoYXZlIGEg Y29tcGxldGUgTWVzaCBEYXRhIGZyYW1lLgorCQkgKi8KKworCQkvKgorCQkgKiBPbmx5IGdyb3Vw IGFkZHJlc3NlZCBNZXNoIGRhdGEgZnJhbWVzIGFyZSAzIGFkZHJlc3MKKwkJICogcW9zIGZyYW1l cyBhbW9uZyB0aGUgZGlmZmVyZW50IE1lc2ggRGF0YSBmcmFtZXMgYXMKKwkJICogc3BlY2lmaWVk IGluIGFtZW5kbWVudC4KKwkJICovCisJCSoodWludDE2X3QgKilxb3MgPSAqKHVpbnQxNl90ICop CisJCSAgICAoKChJRUVFODAyMTFfSVNfTVVMVElDQVNUKHdoLT5pX2FkZHIxKSAmJgorCQkgICAg ZGlyID09IElFRUU4MDIxMV9GQzFfRElSX0ZST01EUykpID8KKwkJICAgICgoc3RydWN0IGllZWU4 MDIxMV9xb3NmcmFtZSAqKXdoKS0+aV9xb3MgOgorCQkgICAgKChzdHJ1Y3QgaWVlZTgwMjExX3Fv c2ZyYW1lX2FkZHI0ICopd2gpLT5pX3Fvcyk7CisKKwkJLyoKKwkJICogTkI6IFRoZSBtZXNoIFNU QSBzZXRzIHRoZSBNZXNoIENvbnRyb2wgUHJlc2VudAorCQkgKiBzdWJmaWVsZCB0byAxIGluIHRo ZSBNZXNoIERhdGEgZnJhbWUgY29udGFpbmluZworCQkgKiBhbiB1bmZyYWdtZW50ZWQgTVNEVSwg YW4gQS1NU0RVLCBvciB0aGUgZmlyc3QKKwkJICogZnJhZ21lbnQgb2YgYW4gTVNEVS4KKwkJICog QWZ0ZXIgZGVmcmFnIGl0IHNob3VsZCBhbHdheXMgYmUgcHJlc2VudC4KKwkJICovCisJCWlmICgh KHFvc1sxXSAmIElFRUU4MDIxMV9RT1NfTUMpKSB7CisJCQlJRUVFODAyMTFfRElTQ0FSRF9NQUMo dmFwLCBJRUVFODAyMTFfTVNHX01FU0gsCisJCQkgICAgbmktPm5pX21hY2FkZHIsIE5VTEwsCisJ CQkgICAgIiVzIiwgIk1lc2ggY29udHJvbCBmaWVsZCBub3QgcHJlc2VudCIpOworCQkJdmFwLT5p dl9zdGF0cy5pc19yeF9lbGVtX21pc3NpbmcrKzsgLyogWFhYOiBraW5kYSAqLworCQkJZ290byBl cnI7CisJCX0KKworCQkvKiBwdWxsIHVwIGVub3VnaCB0byBnZXQgdG8gdGhlIG1lc2ggY29udHJv bCAqLwogCQlpZiAobS0+bV9sZW4gPCBoZHJzcGFjZSArIHNpemVvZihzdHJ1Y3QgaWVlZTgwMjEx X21lc2hjbnRsKSAmJgogCQkgICAgKG0gPSBtX3B1bGx1cChtLCBoZHJzcGFjZSArCiAJCSAgICAg ICAgc2l6ZW9mKHN0cnVjdCBpZWVlODAyMTFfbWVzaGNudGwpKSkgPT0gTlVMTCkgewpAQCAtMTE5 NSwyNyArMTI0OSw2IEBAIG1lc2hfaW5wdXQoc3RydWN0IGllZWU4MDIxMV9ub2RlICpuaSwgc3Ry dWN0IG1idWYgKm0sIGludCByc3NpLCBpbnQgbmYpCiAJCQkvKiBOQjogZmFsbCB0aHJ1IHRvIGRl bGl2ZXIgbWNhc3QgZnJhbWVzIGxvY2FsbHkgKi8KIAkJfQogCi0JCS8qCi0JCSAqIFNhdmUgUW9T IGJpdHMgZm9yIHVzZSBiZWxvdy0tYmVmb3JlIHdlIHN0cmlwIHRoZSBoZWFkZXIuCi0JCSAqLwot CQlpZiAoc3VidHlwZSA9PSBJRUVFODAyMTFfRkMwX1NVQlRZUEVfUU9TKSB7Ci0JCQlxb3MgPSAo ZGlyID09IElFRUU4MDIxMV9GQzFfRElSX0RTVE9EUykgPwotCQkJICAgICgoc3RydWN0IGllZWU4 MDIxMV9xb3NmcmFtZV9hZGRyNCAqKXdoKS0+aV9xb3NbMF0gOgotCQkJICAgICgoc3RydWN0IGll ZWU4MDIxMV9xb3NmcmFtZSAqKXdoKS0+aV9xb3NbMF07Ci0JCX0gZWxzZQotCQkJcW9zID0gMDsK LQkJLyoKLQkJICogTmV4dCB1cCwgYW55IGZyYWdtZW50YXRpb24uCi0JCSAqLwotCQlpZiAoIUlF RUU4MDIxMV9JU19NVUxUSUNBU1Qod2gtPmlfYWRkcjEpKSB7Ci0JCQltID0gaWVlZTgwMjExX2Rl ZnJhZyhuaSwgbSwgaGRyc3BhY2UpOwotCQkJaWYgKG0gPT0gTlVMTCkgewotCQkJCS8qIEZyYWdt ZW50IGRyb3BwZWQgb3IgZnJhbWUgbm90IGNvbXBsZXRlIHlldCAqLwotCQkJCWdvdG8gb3V0Owot CQkJfQotCQl9Ci0JCXdoID0gTlVMTDsJCS8qIG5vIGxvbmdlciB2YWxpZCwgY2F0Y2ggYW55IHVz ZXMgKi8KLQogCQlpZiAoaWVlZTgwMjExX3JhZGlvdGFwX2FjdGl2ZV92YXAodmFwKSkKIAkJCWll ZWU4MDIxMV9yYWRpb3RhcF9yeCh2YXAsIG0pOwogCQluZWVkX3RhcCA9IDA7CkBAIC0xMjM2LDcg KzEyNjksNyBAQCBtZXNoX2lucHV0KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBt YnVmICptLCBpbnQgcnNzaSwgaW50IG5mKQogCQkJSUVFRTgwMjExX05PREVfU1RBVChuaSwgcnhf ZGVjYXApOwogCQkJZ290byBlcnI7CiAJCX0KLQkJaWYgKHFvcyAmIElFRUU4MDIxMV9RT1NfQU1T RFUpIHsKKwkJaWYgKHFvc1swXSAmIElFRUU4MDIxMV9RT1NfQU1TRFUpIHsKIAkJCW0gPSBpZWVl ODAyMTFfZGVjYXBfYW1zZHUobmksIG0pOwogCQkJaWYgKG0gPT0gTlVMTCkKIAkJCQlyZXR1cm4g SUVFRTgwMjExX0ZDMF9UWVBFX0RBVEE7CmRpZmYgLS1naXQgYS9zeXMvbmV0ODAyMTEvaWVlZTgw MjExX291dHB1dC5jIGIvc3lzL25ldDgwMjExL2llZWU4MDIxMV9vdXRwdXQuYwppbmRleCBmNjE3 N2Q5Li44YjJiNTAxIDEwMDY0NAotLS0gYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX291dHB1dC5j CisrKyBiL3N5cy9uZXQ4MDIxMS9pZWVlODAyMTFfb3V0cHV0LmMKQEAgLTEwNjksOSArMTA2OSwx MSBAQCBpZWVlODAyMTFfZW5jYXAoc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwLCBzdHJ1Y3QgaWVl ZTgwMjExX25vZGUgKm5pLAogCSAqIGFwJ3MgcmVxdWlyZSBhbGwgZGF0YSBmcmFtZXMgdG8gYmUg UW9TLWVuY2Fwc3VsYXRlZAogCSAqIG9uY2UgbmVnb3RpYXRlZCBpbiB3aGljaCBjYXNlIHdlJ2xs IG5lZWQgdG8gbWFrZSB0aGlzCiAJICogY29uZmlndXJhYmxlLgorCSAqIE5COiBtZXNoIGRhdGEg ZnJhbWVzIGFyZSBRb1MuCiAJICovCi0JYWRkcW9zID0gKG5pLT5uaV9mbGFncyAmIChJRUVFODAy MTFfTk9ERV9RT1N8SUVFRTgwMjExX05PREVfSFQpKSAmJgotCQkgKG0tPm1fZmxhZ3MgJiBNX0VB UE9MKSA9PSAwOworCWFkZHFvcyA9ICgobmktPm5pX2ZsYWdzICYgKElFRUU4MDIxMV9OT0RFX1FP U3xJRUVFODAyMTFfTk9ERV9IVCkpIHx8CisJICAgICh2YXAtPml2X29wbW9kZSA9PSBJRUVFODAy MTFfTV9NQlNTKSkgJiYKKwkgICAgKG0tPm1fZmxhZ3MgJiBNX0VBUE9MKSA9PSAwOwogCWlmIChh ZGRxb3MpCiAJCWhkcnNpemUgPSBzaXplb2Yoc3RydWN0IGllZWU4MDIxMV9xb3NmcmFtZSk7CiAJ ZWxzZQpAQCAtMTI3Nyw3ICsxMjc5LDEyIEBAIGllZWU4MDIxMV9lbmNhcChzdHJ1Y3QgaWVlZTgw MjExdmFwICp2YXAsIHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksCiAJCXFvc1swXSA9IHRpZCAm IElFRUU4MDIxMV9RT1NfVElEOwogCQlpZiAoaWMtPmljX3dtZS53bWVfd21lQ2hhblBhcmFtcy5j YXBfd21lUGFyYW1zW2FjXS53bWVwX25vYWNrUG9saWN5KQogCQkJcW9zWzBdIHw9IElFRUU4MDIx MV9RT1NfQUNLUE9MSUNZX05PQUNLOwotCQlxb3NbMV0gPSAwOworI2lmZGVmIElFRUU4MDIxMV9T VVBQT1JUX01FU0gKKwkJaWYgKHZhcC0+aXZfb3Btb2RlID09IElFRUU4MDIxMV9NX01CU1MpIHsK KwkJCXFvc1sxXSB8PSBJRUVFODAyMTFfUU9TX01DOworCQl9IGVsc2UKKyNlbmRpZgorCQkJcW9z WzFdID0gMDsKIAkJd2gtPmlfZmNbMF0gfD0gSUVFRTgwMjExX0ZDMF9TVUJUWVBFX1FPUzsKIAog CQlpZiAoKG0tPm1fZmxhZ3MgJiBNX0FNUERVX01QRFUpID09IDApIHsKLS0gCjEuNy40LjEKCg== --20cf3011da15e12aee04b8f3ec09-- From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 04:50:03 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81078106564A; Wed, 15 Feb 2012 04:50:03 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from felyko.com (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6638FC1D; Wed, 15 Feb 2012 04:50:03 +0000 (UTC) Received: from [10.0.1.3] (c-50-131-226-51.hsd1.ca.comcast.net [50.131.226.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id E7E803981E; Tue, 14 Feb 2012 20:50:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rui Paulo In-Reply-To: Date: Tue, 14 Feb 2012 20:50:02 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3F2E258F-1F82-48D7-AAAD-546BCB03EDE2@freebsd.org> References: To: Monthadar Al Jaberi X-Mailer: Apple Mail (2.1257) Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Fragment and 11s inconsistency X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 04:50:03 -0000 On 2012/02/14, at 14:14, Monthadar Al Jaberi wrote: > Hi, > > I cant verify this yet, but isn't there something wrong in current FreeBSD? > > lets say an 11s data frame need to be fragmented in ieee80211_encap: > if (addqos) > hdrsize = sizeof(struct ieee80211_qosframe); > else > hdrsize = sizeof(struct ieee80211_frame); > ... > if (vap->iv_opmode == IEEE80211_M_MBSS) { > ... > if (!IEEE80211_IS_MULTICAST(eh.ether_dhost)) > hdrsize += IEEE80211_ADDR_LEN; /* unicast are 4-addr */ > meshhdrsize = sizeof(struct ieee80211_meshcntl); > } > ... > if (__predict_true((m->m_flags & M_FF) == 0)) { > /* > * Normal frame. > */ > m = ieee80211_mbuf_adjust(vap, hdrspace + meshhdrsize, key, m); > } > M_PREPEND(m, hdrspace + meshhdrsize, M_DONTWAIT); > if (txfrag && !ieee80211_fragment(vap, m, hdrsize, > key != NULL ? key->wk_cipher->ic_header : 0, vap->iv_fragthreshold)) > goto bad; > > This means we send meshcontrol only in first segment, because we never > add meshhdrsize to hdrsize... Yes, this is a bug. Thanks for finding it. > but in mesh_input > switch (type) { > case IEEE80211_FC0_TYPE_DATA: > ... > meshdrlen = sizeof(struct ieee80211_meshcntl) + > (mc->mc_flags & 3) * IEEE80211_ADDR_LEN; > hdrspace += meshdrlen; > ... > /* > * Potentially forward packet. See table s36 (p140) > * for the rules. XXX tap fwd'd packets not for us? > */ > if (dir == IEEE80211_FC1_DIR_FROMDS || > !mesh_isucastforme(vap, wh, mc)) { > mesh_forward(vap, m, mc); > ... > if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { > m = ieee80211_defrag(ni, m, hdrspace); > if (m == NULL) { > > This seems wrong to me, how can we potentially forward before defragin > the frame? this will fail cause sub-frag have no mesh control as code > shows above. > > shouldnt the defrag code be moved above? Yes, another bug. > I am attaching a patch that both moves the defrag, validates that mesh > control is present and makes 11s data frames QoS and set Mesh control > bit present to 1 as the amendment specifies. There are some typos in your patch ("This is in constrast to Draf 4.0."). Can you please rewrite this code: + *(uint16_t *)qos = *(uint16_t *) + (((IEEE80211_IS_MULTICAST(wh->i_addr1) && + dir == IEEE80211_FC1_DIR_FROMDS)) ? + ((struct ieee80211_qosframe *)wh)->i_qos : + ((struct ieee80211_qosframe_addr4 *)wh)->i_qos); In ieee80211_encap(), why didn't you add meshhdrsize to ieee80211_fragment()? Would be nice to test this before committing. Thanks, -- Rui Paulo From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 05:55:43 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 316A0106566B for ; Wed, 15 Feb 2012 05:55:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0EFD8FC0A for ; Wed, 15 Feb 2012 05:55:42 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so441453wib.13 for ; Tue, 14 Feb 2012 21:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RGKkopdM/3QBdPu2iZZ5gyu1A+oPIJgywkRBj7mPwDo=; b=K4pjLmd0O1vXD672fDoV9+KZWtH5tNtVl6i9B9r9BhQV7/vn4Js6MyTMG85zmpMgS4 yU14dKRkdRMT0alwLKkWT1Q9G8XXUftn1DG6u6pD088j1O67byTig49lfgRjL26bOP/+ b/Zrrt2kZCZoNtmG4tmcBiftkj5Wxh20m81nM= MIME-Version: 1.0 Received: by 10.216.137.210 with SMTP id y60mr2110580wei.14.1329285341633; Tue, 14 Feb 2012 21:55:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Tue, 14 Feb 2012 21:55:41 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 21:55:41 -0800 X-Google-Sender-Auth: 8T8xcHUvkR9ZOPOgvhRbCO7qwCA Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Fragment number of first fragment != 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:55:43 -0000 Oddly, I can't get any fragments to transmit: * ieee80211_fragment() fragments the frame (correctly or not, I'm not paying attention); * the fragments are chained together via m->m_nextpkt; * but the first call to IFQ_DEQUEUE() in ath_start() removes the m->m_nextpkt reference, completely destroying the fragment chain; * .. and then ath_txfrag_setup() finds it has no fragments to operate on, as m0->m_nextpkt is NULL; * .. so the mbuf is dropped on the floor. I'm also not yet convinced that we're not leaking the fragment mbufs. IFQ_DEQUEUE() has been used in ath_start() since sam introduced vap functionality in 2008 or 2009. The _IF_DEQUEUE() macro behaviour (of clearing m->m_nextpkt) So, how exactly again are we supposed to handle net80211 fragments correctly? :-) Confused, Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 06:13:26 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 713EF106564A; Wed, 15 Feb 2012 06:13:26 +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 42E8A8FC18; Wed, 15 Feb 2012 06:13:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1F6DQR9052917; Wed, 15 Feb 2012 06:13:26 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1F6DQlj052913; Wed, 15 Feb 2012 06:13:26 GMT (envelope-from adrian) Date: Wed, 15 Feb 2012 06:13:26 GMT Message-Id: <201202150613.q1F6DQlj052913@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/165146: [net80211] Net802.11 Fragment number is assigned 1 (should be 0) when fragmenting a frame X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:13:26 -0000 Old Synopsis: Net802.11 Fragment number is assigned 1 (should be 0) when fragmenting a frame New Synopsis: [net80211] Net802.11 Fragment number is assigned 1 (should be 0) when fragmenting a frame Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed Feb 15 06:13:12 UTC 2012 Responsible-Changed-Why: Punt http://www.freebsd.org/cgi/query-pr.cgi?pr=165146 From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 06:13:39 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD1A510656D1; Wed, 15 Feb 2012 06:13:39 +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 800718FC15; Wed, 15 Feb 2012 06:13:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1F6DdPh053362; Wed, 15 Feb 2012 06:13:39 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1F6Ddux053356; Wed, 15 Feb 2012 06:13:39 GMT (envelope-from adrian) Date: Wed, 15 Feb 2012 06:13:39 GMT Message-Id: <201202150613.q1F6Ddux053356@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/165149: [ath] [net80211] Ping with data length more than iv_fragthreshold X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:13:39 -0000 Old Synopsis: [ath][net80211] Ping with data length more than iv_fragthreshold New Synopsis: [ath] [net80211] Ping with data length more than iv_fragthreshold Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed Feb 15 06:13:29 UTC 2012 Responsible-Changed-Why: Punt http://www.freebsd.org/cgi/query-pr.cgi?pr=165149 From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 06:20:12 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99FB11065670 for ; Wed, 15 Feb 2012 06:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 840988FC0A for ; Wed, 15 Feb 2012 06:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1F6KCIR055016 for ; Wed, 15 Feb 2012 06:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1F6KCLi055015; Wed, 15 Feb 2012 06:20:12 GMT (envelope-from gnats) Date: Wed, 15 Feb 2012 06:20:12 GMT Message-Id: <201202150620.q1F6KCLi055015@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Adrian Chadd Cc: Subject: Re: kern/165149: [ath] [net80211] Ping with data length more than iv_fragthreshold X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Chadd List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:20:12 -0000 The following reply was made to PR kern/165149; it has been noted by GNATS. From: Adrian Chadd To: bug-followup@FreeBSD.org, monthadar@gmail.com Cc: Subject: Re: kern/165149: [ath] [net80211] Ping with data length more than iv_fragthreshold Date: Tue, 14 Feb 2012 22:16:31 -0800 The problem is .. well, annoying: * ieee80211_fragment() creates a fragment list by chaining mbufs together using m->m_nextpkt; * IFQ_DEQUEUE() (well, _IF_DEQUEUE()) clears m->m_nextpkt when the mbuf is being returned; * ath_start() uses IFQ_DEQUEUE() to dequeue a frame; * .. since it notes its a fragment, it punts it to ath_txfrag_setup(); * .. and ath_txfrag_setup(), finding m->m_nextpkt to be NULL, bails out with an error (since the fragment list is empty.) * ath_start() tosses the initial frame, and nothing is sent. Now it looks like the rest of the frames in the list are also unceremoniously ignored (since m->m_nextpkt is completely blanked out); which is likely the mbuf leak you noticed. Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 06:32:02 2012 Return-Path: Delivered-To: wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 245831065674; Wed, 15 Feb 2012 06:32:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78DBA8FC14; Wed, 15 Feb 2012 06:32:01 +0000 (UTC) Received: by werm13 with SMTP id m13so654809wer.13 for ; Tue, 14 Feb 2012 22:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2v42PmpFfBruhRT2S6JzKRoW1FEy2sip2wyVLL6X0Wg=; b=bsPFiYeN6u+1GH1wckz2kyJb362P0LsgtqGJ2qkUFh4UJ+y5vXnLHEWbSn01isv7AI c2JbhW9EOLsVtH9eOfb7OKI7B66wpSK+NN7JaFzBjqCX7LCUFjowPphqr+QpB7xAG4Xo qQBvpnFEsR39mF9Z06TIWJknvdjnetSZp0vMQ= MIME-Version: 1.0 Received: by 10.180.96.8 with SMTP id do8mr6286057wib.21.1329286141168; Tue, 14 Feb 2012 22:09:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Tue, 14 Feb 2012 22:09:01 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 22:09:01 -0800 X-Google-Sender-Auth: wSnxM8GiGDbTOvf8o5Bdyouxsb0 Message-ID: From: Adrian Chadd To: Jakob Pedersen Content-Type: text/plain; charset=ISO-8859-1 Cc: mobile@freebsd.org, wireless@freebsd.org Subject: Re: Problems with RaLink rt61pci/rt2561 wifi card X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:32:02 -0000 Hi, It sounds like it could be: * low TX power from your device; * Really bad RX gain settings somehow; * other fruity radio related stuff. The trouble is going to be diagnosing it. What I do in these instances is use a known-good setup (i have a bunch of laptops with AR9280's in them for this reason) to use in monitor mode - I can then get a rough estimate of TX power by just sniffing the frames your device is sending. That'd hopefully identify whether it's a TX or an RX problem. If the device works in monitor mode, you could try that: tcpdump -ni wlan0 -y IEEE802_11_RADIO Connect, then walk away from the AP. See if the RX RSSI fields in the tcpdump drop suddenly. If you get a few metres away and you're still receiving things strong, it may be a TX issue. If you suddenly stop hearing anything, it's likely an RX issue. Good luck! Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 08:26:12 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D596106566C; Wed, 15 Feb 2012 08:26:12 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14AC68FC0C; Wed, 15 Feb 2012 08:26:11 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1450322iae.13 for ; Wed, 15 Feb 2012 00:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YxQfUdTCiuNS/b4Cqvz2sULwiJ0wly8E0/NyIOObxQk=; b=nQNoknz3V5y3CN74YAnnlNFRKEM+MvV5Oh0yWMFU5XsjMz77vuDh8KLy/Ogqz20gAg 9myOySjEErx3pwpB7OxCfIJtBaEZEY0p2xieDz8uv/vBD3wcJx8p7VYh/2ghuyCOOqjW +IFQCGAcKHTKU0FgiOrr5P52u1PoPeVxS02k0= MIME-Version: 1.0 Received: by 10.43.48.65 with SMTP id uv1mr19072677icb.57.1329294371622; Wed, 15 Feb 2012 00:26:11 -0800 (PST) Received: by 10.50.213.74 with HTTP; Wed, 15 Feb 2012 00:26:11 -0800 (PST) In-Reply-To: <3F2E258F-1F82-48D7-AAAD-546BCB03EDE2@freebsd.org> References: <3F2E258F-1F82-48D7-AAAD-546BCB03EDE2@freebsd.org> Date: Wed, 15 Feb 2012 09:26:11 +0100 Message-ID: From: Monthadar Al Jaberi To: Rui Paulo Content-Type: multipart/mixed; boundary=bcaec529a061d2903404b8fc76ec Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Fragment and 11s inconsistency X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 08:26:12 -0000 --bcaec529a061d2903404b8fc76ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 5:50 AM, Rui Paulo wrote: > On 2012/02/14, at 14:14, Monthadar Al Jaberi wrote: > >> Hi, >> >> I cant verify this yet, but isn't there something wrong in current FreeB= SD? >> >> lets say an 11s data frame need to be fragmented in ieee80211_encap: >> if (addqos) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize =3D sizeof(struct ieee80211_qosframe= ); >> else >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize =3D sizeof(struct ieee80211_frame); >> ... >> if (vap->iv_opmode =3D=3D IEEE80211_M_MBSS) { >> ... >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!IEEE80211_IS_MULTICAST(eh.ether_dhost)) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize +=3D IEEE80211_ADDR_= LEN; =A0/* unicast are 4-addr */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 meshhdrsize =3D sizeof(struct ieee80211_mesh= cntl); >> } >> ... >> if (__predict_true((m->m_flags & M_FF) =3D=3D 0)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Normal frame. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D ieee80211_mbuf_adjust(vap, hdrspace + = meshhdrsize, key, m); >> } >> M_PREPEND(m, hdrspace + meshhdrsize, M_DONTWAIT); >> if (txfrag && !ieee80211_fragment(vap, m, hdrsize, >> =A0 =A0 =A0 =A0 =A0 key !=3D NULL ? key->wk_cipher->ic_header : 0, vap->= iv_fragthreshold)) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad; >> >> This means we send meshcontrol only in first segment, because we never >> add meshhdrsize to hdrsize... > > Yes, this is a bug. Thanks for finding it. > >> but in mesh_input >> switch (type) { >> =A0 =A0 =A0 case IEEE80211_FC0_TYPE_DATA: >> ... >> meshdrlen =3D sizeof(struct ieee80211_meshcntl) + >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (mc->mc_flags & 3) * IEEE80211_ADDR_= LEN; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrspace +=3D meshdrlen; >> ... >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Potentially forward packet. =A0See tabl= e s36 (p140) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* for the rules. =A0XXX tap fwd'd packets= not for us? >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS || >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !mesh_isucastforme(vap, wh, mc)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mesh_forward(vap, m, mc); >> ... >> if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D ieee80211_defrag(ni, m= , hdrspace); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (m =3D=3D NULL) { >> >> This seems wrong to me, how can we potentially forward before defragin >> the frame? this will fail cause sub-frag have no mesh control as code >> shows above. >> >> shouldnt the defrag code be moved above? > > Yes, another bug. > >> I am attaching a patch that both moves the defrag, validates that mesh >> control is present and makes 11s data frames QoS and set Mesh control >> bit present to 1 as the amendment specifies. > > There are some typos in your patch ("This is in constrast to Draf 4.0."). > > Can you please rewrite this code: > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(uint16_t *)qos =3D *(uint16_t *) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (((IEEE80211_IS_MULTICAST(wh->i_add= r1) && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dir =3D=3D IEEE80211_FC1_DIR_FROMDS= )) ? > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((struct ieee80211_qosframe *)wh)->= i_qos : > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((struct ieee80211_qosframe_addr4 *= )wh)->i_qos); > > In ieee80211_encap(), why didn't you add meshhdrsize to ieee80211_fragmen= t()? Because the mesh control is not part of the header, it is in the frame body and should only be present in the first fragment of a frame. So I think this is correct. > > Would be nice to test this =A0before committing. Yes, Adrian and Bernhard are looking into the fragment code between net80211 and ath. It seems the code is broken. I am reattaching the patch thanks for your comments. > > Thanks, > -- > Rui Paulo > --=20 Monthadar Al Jaberi --bcaec529a061d2903404b8fc76ec Content-Type: text/x-patch; charset=US-ASCII; name="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Disposition: attachment; filename="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gyo3jbm30 RnJvbSBjMGZlYjE3ODI1YTg2MGIxMTdiNWU3NzZiYWU5ZGRhYjNmZWRmNWI5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNb250aGFkYXIgQWwgSmFiZXJpIDxtb250aGFkYXJAZ21haWwu Y29tPgpEYXRlOiBUdWUsIDE0IEZlYiAyMDEyIDE2OjQ3OjQzICswMTAwClN1YmplY3Q6IFtQQVRD SF0gTWFrZSBtZXNoIGRhdGEgZnJhbWVzIHRvIGJlIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKS4K CiogSW50cm9kdWNlIG5ldyBmbGFnIGZvciBRb1MgY29udHJvbCBmaWVsZDsKKiBDaGFuZ2UgaW4g bWVzaF9pbnB1dCB0byB2YWxpZGF0ZSB0aGF0IFFvUyBpcyBzZXQgYW5kIE1lc2ggQ29udHJvbCBm aWVsZAppcyBwcmVzZW50LCBhbHNvIGJvdGggYnl0ZXMgb2YgdGhlIFFvUyBhcmUgcmVhZDsKKiBN b3ZlZCBkZWZyYWdtZW50YXRpb24gaW4gbWVzaF9pbnB1dCBiZWZvcmUgd2UgdHJ5IHRvIGZvcndh cmQgcGFja2V0IGFzCmluZmVycmVkIGZyb20gYW1lbmRtZW50IHNwZWMsIGJlY2F1c2UgTWVzaCBD b250cm9sIGZpZWxkIG9ubHkgcHJlc2VudCBpbiBmaXJzdApmcmFnbWVudDsKKiBDaGFuZ2VkIGlu IGllZWU4MDIxMV9lbmNhcCB0byBzZXQgUW9TIHN1YnR5cGUgYW5kIE1lc2ggQ29udHJvbCBmaWVs ZCBwcmVzZW50OwotLS0KIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTEuaCAgICAgICAgfCAgICA3ICsr Kwogc3lzL25ldDgwMjExL2llZWU4MDIxMV9tZXNoLmMgICB8ICAgODUgKysrKysrKysrKysrKysr KysrKysrKysrKysrLS0tLS0tLS0tLS0KIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfb3V0cHV0LmMg fCAgIDEzICsrKysrLQogMyBmaWxlcyBjaGFuZ2VkLCA3NyBpbnNlcnRpb25zKCspLCAyOCBkZWxl dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExLmggYi9zeXMvbmV0 ODAyMTEvaWVlZTgwMjExLmgKaW5kZXggMDI4YWZlYy4uMjliZmEzYyAxMDA2NDQKLS0tIGEvc3lz L25ldDgwMjExL2llZWU4MDIxMS5oCisrKyBiL3N5cy9uZXQ4MDIxMS9pZWVlODAyMTEuaApAQCAt MTk5LDYgKzE5OSwxMyBAQCBzdHJ1Y3QgaWVlZTgwMjExX3Fvc2ZyYW1lX2FkZHI0IHsKICNkZWZp bmUJSUVFRTgwMjExX1FPU19FT1NQCQkJMHgxMAkvKiBFbmRPZlNlcnZpY2UgUGVyaW9kKi8KICNk ZWZpbmUJSUVFRTgwMjExX1FPU19FT1NQX1MJCQk0CiAjZGVmaW5lCUlFRUU4MDIxMV9RT1NfVElE CQkJMHgwZgorLyogcW9zWzFdIGJ5dGUgdXNlZCBmb3IgYWxsIGZyYW1lcyBzZW50IGJ5IG1lc2gg U1RBcyBpbiBhIG1lc2ggQlNTICovCisjZGVmaW5lIElFRUU4MDIxMV9RT1NfTUMJCQkweDEwCS8q IE1lc2ggY29udHJvbCAqLworLyogTWVzaCBwb3dlciBzYXZlIGxldmVsKi8KKyNkZWZpbmUgSUVF RTgwMjExX1FPU19NRVNIX1BTTAkJCTB4MjAKKy8qIE1lc2ggUmVjZWl2ZXIgU2VydmljZSBQZXJp b2QgSW5pdGlhdGVkICovCisjZGVmaW5lIElFRUU4MDIxMV9RT1NfUlNQSQkJCTB4NDAKKy8qIGJp dHMgMTEgdG8gMTUgcmVzZXJ2ZWQgKi8KIAogLyogZG9lcyBmcmFtZSBoYXZlIFFvUyBzZXF1ZW5j ZSBjb250cm9sIGRhdGEgKi8KICNkZWZpbmUJSUVFRTgwMjExX1FPU19IQVNfU0VRKHdoKSBcCmRp ZmYgLS1naXQgYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYyBiL3N5cy9uZXQ4MDIxMS9p ZWVlODAyMTFfbWVzaC5jCmluZGV4IGI5MmY2OTUuLmU0N2Q5MWEgMTAwNjQ0Ci0tLSBhL3N5cy9u ZXQ4MDIxMS9pZWVlODAyMTFfbWVzaC5jCisrKyBiL3N5cy9uZXQ4MDIxMS9pZWVlODAyMTFfbWVz aC5jCkBAIC0xMDQ3LDkgKzEwNDcsOSBAQCBtZXNoX2lucHV0KHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksIHN0cnVjdCBtYnVmICptLCBpbnQgcnNzaSwgaW50IG5mKQogCXN0cnVjdCBpZWVlODAy MTFfZnJhbWUgKndoOwogCWNvbnN0IHN0cnVjdCBpZWVlODAyMTFfbWVzaGNudGwgKm1jOwogCWlu dCBoZHJzcGFjZSwgbWVzaGRybGVuLCBuZWVkX3RhcDsKLQl1aW50OF90IGRpciwgdHlwZSwgc3Vi dHlwZSwgcW9zOworCXVpbnQ4X3QgZGlyLCB0eXBlLCBzdWJ0eXBlOwogCXVpbnQzMl90IHNlcTsK LQl1aW50OF90ICphZGRyOworCXVpbnQ4X3QgKmFkZHIsIHFvc1syXTsKIAlpZWVlODAyMTFfc2Vx IHJ4c2VxOwogCiAJS0FTU0VSVChuaSAhPSBOVUxMLCAoIm51bGwgbm9kZSIpKTsKQEAgLTExNDYs OCArMTE0Niw2NCBAQCBtZXNoX2lucHV0KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVj dCBtYnVmICptLCBpbnQgcnNzaSwgaW50IG5mKQogCQkJdmFwLT5pdl9zdGF0cy5pc19yeF93cm9u Z2RpcisrOwogCQkJZ290byBlcnI7CiAJCX0KLQkJLyogcHVsbCB1cCBlbm91Z2ggdG8gZ2V0IHRv IHRoZSBtZXNoIGNvbnRyb2wgKi8KKworCQkvKiBBbGwgTWVzaCBkYXRhIGZyYW1lcyBhcmUgUW9T IHN1YnR5cGUgKi8KKwkJaWYgKCFIQVNfU0VRKHR5cGUpKSB7CisJCQlJRUVFODAyMTFfRElTQ0FS RCh2YXAsIElFRUU4MDIxMV9NU0dfSU5QVVQsCisJCQkgICAgd2gsICJkYXRhIiwgImluY29ycmVj dCBzdWJ0eXBlIDB4JXgiLCBzdWJ0eXBlKTsKKwkJCXZhcC0+aXZfc3RhdHMuaXNfcnhfYmFkc3Vi dHlwZSsrOworCQkJZ290byBlcnI7CisJCX0KKworCQkvKgorCQkgKiBOZXh0IHVwLCBhbnkgZnJh Z21lbnRhdGlvbi4KKwkJICogWFhYOiB3ZSBkZWZyYWcgYmVmb3JlIHdlIGV2ZW4gdHJ5IHRvIGZv cndhcmQsCisJCSAqIE1lc2ggQ29udHJvbCBmaWVsZCBpcyBub3QgcHJlc2VudCBpbiBzdWItc2Vx dWVudAorCQkgKiBmcmFnbWVudGVkIGZyYW1lcy4gVGhpcyBpcyBpbiBjb250cmFzdCB0byBEcmFm IDQuMC4KKwkJICovCiAJCWhkcnNwYWNlID0gaWVlZTgwMjExX2hkcnNwYWNlKGljLCB3aCk7CisJ CWlmICghSUVFRTgwMjExX0lTX01VTFRJQ0FTVCh3aC0+aV9hZGRyMSkpIHsKKwkJCW0gPSBpZWVl ODAyMTFfZGVmcmFnKG5pLCBtLCBoZHJzcGFjZSk7CisJCQlpZiAobSA9PSBOVUxMKSB7CisJCQkJ LyogRnJhZ21lbnQgZHJvcHBlZCBvciBmcmFtZSBub3QgY29tcGxldGUgeWV0ICovCisJCQkJZ290 byBvdXQ7CisJCQl9CisJCX0KKwkJd2ggPSBtdG9kKG0sIHN0cnVjdCBpZWVlODAyMTFfZnJhbWUg Kik7IC8qIE5COiBhZnRlciBkZWZyYWcgKi8KKworCQkvKgorCQkgKiBOb3cgd2UgaGF2ZSBhIGNv bXBsZXRlIE1lc2ggRGF0YSBmcmFtZS4KKwkJICovCisKKwkJLyoKKwkJICogT25seSBncm91cCBh ZGRyZXNzZWQgTWVzaCBkYXRhIGZyYW1lcyBhcmUgMyBhZGRyZXNzCisJCSAqIHFvcyBmcmFtZXMg YW1vbmcgdGhlIGRpZmZlcmVudCBNZXNoIERhdGEgZnJhbWVzIGFzCisJCSAqIHNwZWNpZmllZCBp biBhbWVuZG1lbnQuCisJCSAqLworCQlpZiAoSUVFRTgwMjExX0lTX01VTFRJQ0FTVCh3aC0+aV9h ZGRyMSkgJiYKKwkJICAgIGRpciA9PSBJRUVFODAyMTFfRkMxX0RJUl9GUk9NRFMpCisJCQkqKHVp bnQxNl90ICopcW9zID0gKih1aW50MTZfdCAqKQorCQkJICAgICgoc3RydWN0IGllZWU4MDIxMV9x b3NmcmFtZSAqKXdoKS0+aV9xb3M7CisJCWVsc2UKKwkJCSoodWludDE2X3QgKilxb3MgPSAqKHVp bnQxNl90ICopCisJCQkgICAgKHN0cnVjdCBpZWVlODAyMTFfcW9zZnJhbWVfYWRkcjQgKil3aCkt PmlfcW9zOworCisJCS8qCisJCSAqIE5COiBUaGUgbWVzaCBTVEEgc2V0cyB0aGUgTWVzaCBDb250 cm9sIFByZXNlbnQKKwkJICogc3ViZmllbGQgdG8gMSBpbiB0aGUgTWVzaCBEYXRhIGZyYW1lIGNv bnRhaW5pbmcKKwkJICogYW4gdW5mcmFnbWVudGVkIE1TRFUsIGFuIEEtTVNEVSwgb3IgdGhlIGZp cnN0CisJCSAqIGZyYWdtZW50IG9mIGFuIE1TRFUuCisJCSAqIEFmdGVyIGRlZnJhZyBpdCBzaG91 bGQgYWx3YXlzIGJlIHByZXNlbnQuCisJCSAqLworCQlpZiAoIShxb3NbMV0gJiBJRUVFODAyMTFf UU9TX01DKSkgeworCQkJSUVFRTgwMjExX0RJU0NBUkRfTUFDKHZhcCwgSUVFRTgwMjExX01TR19N RVNILAorCQkJICAgIG5pLT5uaV9tYWNhZGRyLCBOVUxMLAorCQkJICAgICIlcyIsICJNZXNoIGNv bnRyb2wgZmllbGQgbm90IHByZXNlbnQiKTsKKwkJCXZhcC0+aXZfc3RhdHMuaXNfcnhfZWxlbV9t aXNzaW5nKys7IC8qIFhYWDoga2luZGEgKi8KKwkJCWdvdG8gZXJyOworCQl9CisKKwkJLyogcHVs bCB1cCBlbm91Z2ggdG8gZ2V0IHRvIHRoZSBtZXNoIGNvbnRyb2wgKi8KIAkJaWYgKG0tPm1fbGVu IDwgaGRyc3BhY2UgKyBzaXplb2Yoc3RydWN0IGllZWU4MDIxMV9tZXNoY250bCkgJiYKIAkJICAg IChtID0gbV9wdWxsdXAobSwgaGRyc3BhY2UgKwogCQkgICAgICAgIHNpemVvZihzdHJ1Y3QgaWVl ZTgwMjExX21lc2hjbnRsKSkpID09IE5VTEwpIHsKQEAgLTExOTUsMjcgKzEyNTEsNiBAQCBtZXNo X2lucHV0KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBtYnVmICptLCBpbnQgcnNz aSwgaW50IG5mKQogCQkJLyogTkI6IGZhbGwgdGhydSB0byBkZWxpdmVyIG1jYXN0IGZyYW1lcyBs b2NhbGx5ICovCiAJCX0KIAotCQkvKgotCQkgKiBTYXZlIFFvUyBiaXRzIGZvciB1c2UgYmVsb3ct LWJlZm9yZSB3ZSBzdHJpcCB0aGUgaGVhZGVyLgotCQkgKi8KLQkJaWYgKHN1YnR5cGUgPT0gSUVF RTgwMjExX0ZDMF9TVUJUWVBFX1FPUykgewotCQkJcW9zID0gKGRpciA9PSBJRUVFODAyMTFfRkMx X0RJUl9EU1RPRFMpID8KLQkJCSAgICAoKHN0cnVjdCBpZWVlODAyMTFfcW9zZnJhbWVfYWRkcjQg Kil3aCktPmlfcW9zWzBdIDoKLQkJCSAgICAoKHN0cnVjdCBpZWVlODAyMTFfcW9zZnJhbWUgKil3 aCktPmlfcW9zWzBdOwotCQl9IGVsc2UKLQkJCXFvcyA9IDA7Ci0JCS8qCi0JCSAqIE5leHQgdXAs IGFueSBmcmFnbWVudGF0aW9uLgotCQkgKi8KLQkJaWYgKCFJRUVFODAyMTFfSVNfTVVMVElDQVNU KHdoLT5pX2FkZHIxKSkgewotCQkJbSA9IGllZWU4MDIxMV9kZWZyYWcobmksIG0sIGhkcnNwYWNl KTsKLQkJCWlmIChtID09IE5VTEwpIHsKLQkJCQkvKiBGcmFnbWVudCBkcm9wcGVkIG9yIGZyYW1l IG5vdCBjb21wbGV0ZSB5ZXQgKi8KLQkJCQlnb3RvIG91dDsKLQkJCX0KLQkJfQotCQl3aCA9IE5V TEw7CQkvKiBubyBsb25nZXIgdmFsaWQsIGNhdGNoIGFueSB1c2VzICovCi0KIAkJaWYgKGllZWU4 MDIxMV9yYWRpb3RhcF9hY3RpdmVfdmFwKHZhcCkpCiAJCQlpZWVlODAyMTFfcmFkaW90YXBfcngo dmFwLCBtKTsKIAkJbmVlZF90YXAgPSAwOwpAQCAtMTIzNiw3ICsxMjcxLDcgQEAgbWVzaF9pbnB1 dChzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGlu dCBuZikKIAkJCUlFRUU4MDIxMV9OT0RFX1NUQVQobmksIHJ4X2RlY2FwKTsKIAkJCWdvdG8gZXJy OwogCQl9Ci0JCWlmIChxb3MgJiBJRUVFODAyMTFfUU9TX0FNU0RVKSB7CisJCWlmIChxb3NbMF0g JiBJRUVFODAyMTFfUU9TX0FNU0RVKSB7CiAJCQltID0gaWVlZTgwMjExX2RlY2FwX2Ftc2R1KG5p LCBtKTsKIAkJCWlmIChtID09IE5VTEwpCiAJCQkJcmV0dXJuIElFRUU4MDIxMV9GQzBfVFlQRV9E QVRBOwpkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4MDIxMV9vdXRwdXQuYyBiL3N5cy9u ZXQ4MDIxMS9pZWVlODAyMTFfb3V0cHV0LmMKaW5kZXggZjYxNzdkOS4uOGIyYjUwMSAxMDA2NDQK LS0tIGEvc3lzL25ldDgwMjExL2llZWU4MDIxMV9vdXRwdXQuYworKysgYi9zeXMvbmV0ODAyMTEv aWVlZTgwMjExX291dHB1dC5jCkBAIC0xMDY5LDkgKzEwNjksMTEgQEAgaWVlZTgwMjExX2VuY2Fw KHN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCwgc3RydWN0IGllZWU4MDIxMV9ub2RlICpuaSwKIAkg KiBhcCdzIHJlcXVpcmUgYWxsIGRhdGEgZnJhbWVzIHRvIGJlIFFvUy1lbmNhcHN1bGF0ZWQKIAkg KiBvbmNlIG5lZ290aWF0ZWQgaW4gd2hpY2ggY2FzZSB3ZSdsbCBuZWVkIHRvIG1ha2UgdGhpcwog CSAqIGNvbmZpZ3VyYWJsZS4KKwkgKiBOQjogbWVzaCBkYXRhIGZyYW1lcyBhcmUgUW9TLgogCSAq LwotCWFkZHFvcyA9IChuaS0+bmlfZmxhZ3MgJiAoSUVFRTgwMjExX05PREVfUU9TfElFRUU4MDIx MV9OT0RFX0hUKSkgJiYKLQkJIChtLT5tX2ZsYWdzICYgTV9FQVBPTCkgPT0gMDsKKwlhZGRxb3Mg PSAoKG5pLT5uaV9mbGFncyAmIChJRUVFODAyMTFfTk9ERV9RT1N8SUVFRTgwMjExX05PREVfSFQp KSB8fAorCSAgICAodmFwLT5pdl9vcG1vZGUgPT0gSUVFRTgwMjExX01fTUJTUykpICYmCisJICAg IChtLT5tX2ZsYWdzICYgTV9FQVBPTCkgPT0gMDsKIAlpZiAoYWRkcW9zKQogCQloZHJzaXplID0g c2l6ZW9mKHN0cnVjdCBpZWVlODAyMTFfcW9zZnJhbWUpOwogCWVsc2UKQEAgLTEyNzcsNyArMTI3 OSwxMiBAQCBpZWVlODAyMTFfZW5jYXAoc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwLCBzdHJ1Y3Qg aWVlZTgwMjExX25vZGUgKm5pLAogCQlxb3NbMF0gPSB0aWQgJiBJRUVFODAyMTFfUU9TX1RJRDsK IAkJaWYgKGljLT5pY193bWUud21lX3dtZUNoYW5QYXJhbXMuY2FwX3dtZVBhcmFtc1thY10ud21l cF9ub2Fja1BvbGljeSkKIAkJCXFvc1swXSB8PSBJRUVFODAyMTFfUU9TX0FDS1BPTElDWV9OT0FD SzsKLQkJcW9zWzFdID0gMDsKKyNpZmRlZiBJRUVFODAyMTFfU1VQUE9SVF9NRVNICisJCWlmICh2 YXAtPml2X29wbW9kZSA9PSBJRUVFODAyMTFfTV9NQlNTKSB7CisJCQlxb3NbMV0gfD0gSUVFRTgw MjExX1FPU19NQzsKKwkJfSBlbHNlCisjZW5kaWYKKwkJCXFvc1sxXSA9IDA7CiAJCXdoLT5pX2Zj WzBdIHw9IElFRUU4MDIxMV9GQzBfU1VCVFlQRV9RT1M7CiAKIAkJaWYgKChtLT5tX2ZsYWdzICYg TV9BTVBEVV9NUERVKSA9PSAwKSB7Ci0tIAoxLjcuNC4xCgo= --bcaec529a061d2903404b8fc76ec-- From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 09:26:52 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DF29106566B; Wed, 15 Feb 2012 09:26:52 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A70D08FC0A; Wed, 15 Feb 2012 09:26:51 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1541612iae.13 for ; Wed, 15 Feb 2012 01:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZOuB41aAqyhr0DAh4ZlNmShiWY1HYdUzeJ1ml6pUh3k=; b=owDj+H7vPgUwUc4sSk/5tx4YArdGVGSUK8AQHJppq2D+zN83tczqIyNbx6/PcSGCGP B3VhdA1dbIFrf4QILN6iifEEXYF+8EoZBQwbtB/sAvbftmQgT73OOPZdMfvVkpAvfsEC 95qXfT5wCxb2VFKD7o0w3pTRsFA3tnJZhB9/0= MIME-Version: 1.0 Received: by 10.50.189.137 with SMTP id gi9mr40292648igc.29.1329298011105; Wed, 15 Feb 2012 01:26:51 -0800 (PST) Received: by 10.50.213.74 with HTTP; Wed, 15 Feb 2012 01:26:51 -0800 (PST) In-Reply-To: References: <3F2E258F-1F82-48D7-AAAD-546BCB03EDE2@freebsd.org> Date: Wed, 15 Feb 2012 10:26:51 +0100 Message-ID: From: Monthadar Al Jaberi To: Rui Paulo Content-Type: multipart/mixed; boundary=14dae9340dd3c0a7c304b8fd4ffa Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Fragment and 11s inconsistency X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 09:26:52 -0000 --14dae9340dd3c0a7c304b8fd4ffa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 9:26 AM, Monthadar Al Jaberi wrote: > On Wed, Feb 15, 2012 at 5:50 AM, Rui Paulo wrote: >> On 2012/02/14, at 14:14, Monthadar Al Jaberi wrote: >> >>> Hi, >>> >>> I cant verify this yet, but isn't there something wrong in current Free= BSD? >>> >>> lets say an 11s data frame need to be fragmented in ieee80211_encap: >>> if (addqos) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize =3D sizeof(struct ieee80211_qosfram= e); >>> else >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize =3D sizeof(struct ieee80211_frame); >>> ... >>> if (vap->iv_opmode =3D=3D IEEE80211_M_MBSS) { >>> ... >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!IEEE80211_IS_MULTICAST(eh.ether_dhost)= ) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize +=3D IEEE80211_ADDR= _LEN; =A0/* unicast are 4-addr */ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 meshhdrsize =3D sizeof(struct ieee80211_mes= hcntl); >>> } >>> ... >>> if (__predict_true((m->m_flags & M_FF) =3D=3D 0)) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Normal frame. >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D ieee80211_mbuf_adjust(vap, hdrspace += meshhdrsize, key, m); >>> } >>> M_PREPEND(m, hdrspace + meshhdrsize, M_DONTWAIT); >>> if (txfrag && !ieee80211_fragment(vap, m, hdrsize, >>> =A0 =A0 =A0 =A0 =A0 key !=3D NULL ? key->wk_cipher->ic_header : 0, vap-= >iv_fragthreshold)) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad; >>> >>> This means we send meshcontrol only in first segment, because we never >>> add meshhdrsize to hdrsize... >> >> Yes, this is a bug. Thanks for finding it. >> >>> but in mesh_input >>> switch (type) { >>> =A0 =A0 =A0 case IEEE80211_FC0_TYPE_DATA: >>> ... >>> meshdrlen =3D sizeof(struct ieee80211_meshcntl) + >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (mc->mc_flags & 3) * IEEE80211_ADDR= _LEN; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrspace +=3D meshdrlen; >>> ... >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Potentially forward packet. =A0See tab= le s36 (p140) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* for the rules. =A0XXX tap fwd'd packet= s not for us? >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS || >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !mesh_isucastforme(vap, wh, mc)) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mesh_forward(vap, m, mc); >>> ... >>> if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D ieee80211_defrag(ni, = m, hdrspace); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (m =3D=3D NULL) { >>> >>> This seems wrong to me, how can we potentially forward before defragin >>> the frame? this will fail cause sub-frag have no mesh control as code >>> shows above. >>> >>> shouldnt the defrag code be moved above? >> >> Yes, another bug. >> >>> I am attaching a patch that both moves the defrag, validates that mesh >>> control is present and makes 11s data frames QoS and set Mesh control >>> bit present to 1 as the amendment specifies. >> >> There are some typos in your patch ("This is in constrast to Draf 4.0.")= . >> >> Can you please rewrite this code: >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(uint16_t *)qos =3D *(uint16_t *) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (((IEEE80211_IS_MULTICAST(wh->i_ad= dr1) && >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dir =3D=3D IEEE80211_FC1_DIR_FROMD= S)) ? >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((struct ieee80211_qosframe *)wh)-= >i_qos : >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((struct ieee80211_qosframe_addr4 = *)wh)->i_qos); >> >> In ieee80211_encap(), why didn't you add meshhdrsize to ieee80211_fragme= nt()? > > Because the mesh control is not part of the header, it is in the frame > body and should only be present in the first fragment of a frame. So I > think this is correct. > Attaching patch again; this time Mesh Control field is set to not present for frags 1+. >> >> Would be nice to test this =A0before committing. > > Yes, Adrian and Bernhard are looking into the fragment code between > net80211 and ath. It seems the code is broken. > > I am reattaching the patch thanks for your comments. > >> >> Thanks, >> -- >> Rui Paulo >> > > > > -- > Monthadar Al Jaberi br --=20 Monthadar Al Jaberi --14dae9340dd3c0a7c304b8fd4ffa Content-Type: text/x-patch; charset=US-ASCII; name="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Disposition: attachment; filename="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gyo5qggy1 RnJvbSA3YWM0YTFmZjA5MzRlOTI3MTM3MmE2NjlkOGU4MzJlNzk0ZDgxMDdlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNb250aGFkYXIgQWwgSmFiZXJpIDxtb250aGFkYXJAZ21haWwu Y29tPgpEYXRlOiBUdWUsIDE0IEZlYiAyMDEyIDE2OjQ3OjQzICswMTAwClN1YmplY3Q6IFtQQVRD SF0gTWFrZSBtZXNoIGRhdGEgZnJhbWVzIHRvIGJlIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKS4K CiogSW50cm9kdWNlIG5ldyBmbGFnIGZvciBRb1MgY29udHJvbCBmaWVsZDsKKiBDaGFuZ2UgaW4g bWVzaF9pbnB1dCB0byB2YWxpZGF0ZSB0aGF0IFFvUyBpcyBzZXQgYW5kIE1lc2ggQ29udHJvbCBm aWVsZAppcyBwcmVzZW50LCBhbHNvIGJvdGggYnl0ZXMgb2YgdGhlIFFvUyBhcmUgcmVhZDsKKiBN b3ZlZCBkZWZyYWdtZW50YXRpb24gaW4gbWVzaF9pbnB1dCBiZWZvcmUgd2UgdHJ5IHRvIGZvcndh cmQgcGFja2V0IGFzCmluZmVycmVkIGZyb20gYW1lbmRtZW50IHNwZWMsIGJlY2F1c2UgTWVzaCBD b250cm9sIGZpZWxkIG9ubHkgcHJlc2VudCBpbiBmaXJzdApmcmFnbWVudDsKKiBDaGFuZ2VkIGlu IGllZWU4MDIxMV9lbmNhcCB0byBzZXQgUW9TIHN1YnR5cGUgYW5kIE1lc2ggQ29udHJvbCBmaWVs ZCBwcmVzZW50LApvbmx5IGZpcnN0IGZyYWdtZW50IGhhdmUgTWVzaCBDb250cm9sIGZpZWxkIHBy ZXNlbnQgYml0IGVxdWFsIHRvIDE7Ci0tLQogc3lzL25ldDgwMjExL2llZWU4MDIxMS5oICAgICAg ICB8ICAgIDcgKysrCiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYyAgIHwgICA4NSArKysr KysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLQogc3lzL25ldDgwMjExL2llZWU4MDIx MV9vdXRwdXQuYyB8ICAgMjQgKysrKysrKysrKy0KIDMgZmlsZXMgY2hhbmdlZCwgODggaW5zZXJ0 aW9ucygrKSwgMjggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4 MDIxMS5oIGIvc3lzL25ldDgwMjExL2llZWU4MDIxMS5oCmluZGV4IDAyOGFmZWMuLjI5YmZhM2Mg MTAwNjQ0Ci0tLSBhL3N5cy9uZXQ4MDIxMS9pZWVlODAyMTEuaAorKysgYi9zeXMvbmV0ODAyMTEv aWVlZTgwMjExLmgKQEAgLTE5OSw2ICsxOTksMTMgQEAgc3RydWN0IGllZWU4MDIxMV9xb3NmcmFt ZV9hZGRyNCB7CiAjZGVmaW5lCUlFRUU4MDIxMV9RT1NfRU9TUAkJCTB4MTAJLyogRW5kT2ZTZXJ2 aWNlIFBlcmlvZCovCiAjZGVmaW5lCUlFRUU4MDIxMV9RT1NfRU9TUF9TCQkJNAogI2RlZmluZQlJ RUVFODAyMTFfUU9TX1RJRAkJCTB4MGYKKy8qIHFvc1sxXSBieXRlIHVzZWQgZm9yIGFsbCBmcmFt ZXMgc2VudCBieSBtZXNoIFNUQXMgaW4gYSBtZXNoIEJTUyAqLworI2RlZmluZSBJRUVFODAyMTFf UU9TX01DCQkJMHgxMAkvKiBNZXNoIGNvbnRyb2wgKi8KKy8qIE1lc2ggcG93ZXIgc2F2ZSBsZXZl bCovCisjZGVmaW5lIElFRUU4MDIxMV9RT1NfTUVTSF9QU0wJCQkweDIwCisvKiBNZXNoIFJlY2Vp dmVyIFNlcnZpY2UgUGVyaW9kIEluaXRpYXRlZCAqLworI2RlZmluZSBJRUVFODAyMTFfUU9TX1JT UEkJCQkweDQwCisvKiBiaXRzIDExIHRvIDE1IHJlc2VydmVkICovCiAKIC8qIGRvZXMgZnJhbWUg aGF2ZSBRb1Mgc2VxdWVuY2UgY29udHJvbCBkYXRhICovCiAjZGVmaW5lCUlFRUU4MDIxMV9RT1Nf SEFTX1NFUSh3aCkgXApkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4MDIxMV9tZXNoLmMg Yi9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYwppbmRleCBiOTJmNjk1Li5kNzFiMDhlIDEw MDY0NAotLS0gYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYworKysgYi9zeXMvbmV0ODAy MTEvaWVlZTgwMjExX21lc2guYwpAQCAtMTA0Nyw5ICsxMDQ3LDkgQEAgbWVzaF9pbnB1dChzdHJ1 Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGludCBuZikK IAlzdHJ1Y3QgaWVlZTgwMjExX2ZyYW1lICp3aDsKIAljb25zdCBzdHJ1Y3QgaWVlZTgwMjExX21l c2hjbnRsICptYzsKIAlpbnQgaGRyc3BhY2UsIG1lc2hkcmxlbiwgbmVlZF90YXA7Ci0JdWludDhf dCBkaXIsIHR5cGUsIHN1YnR5cGUsIHFvczsKKwl1aW50OF90IGRpciwgdHlwZSwgc3VidHlwZTsK IAl1aW50MzJfdCBzZXE7Ci0JdWludDhfdCAqYWRkcjsKKwl1aW50OF90ICphZGRyLCBxb3NbMl07 CiAJaWVlZTgwMjExX3NlcSByeHNlcTsKIAogCUtBU1NFUlQobmkgIT0gTlVMTCwgKCJudWxsIG5v ZGUiKSk7CkBAIC0xMTQ2LDggKzExNDYsNjQgQEAgbWVzaF9pbnB1dChzdHJ1Y3QgaWVlZTgwMjEx X25vZGUgKm5pLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGludCBuZikKIAkJCXZhcC0+aXZf c3RhdHMuaXNfcnhfd3JvbmdkaXIrKzsKIAkJCWdvdG8gZXJyOwogCQl9Ci0JCS8qIHB1bGwgdXAg ZW5vdWdoIHRvIGdldCB0byB0aGUgbWVzaCBjb250cm9sICovCisKKwkJLyogQWxsIE1lc2ggZGF0 YSBmcmFtZXMgYXJlIFFvUyBzdWJ0eXBlICovCisJCWlmICghSEFTX1NFUSh0eXBlKSkgeworCQkJ SUVFRTgwMjExX0RJU0NBUkQodmFwLCBJRUVFODAyMTFfTVNHX0lOUFVULAorCQkJICAgIHdoLCAi ZGF0YSIsICJpbmNvcnJlY3Qgc3VidHlwZSAweCV4Iiwgc3VidHlwZSk7CisJCQl2YXAtPml2X3N0 YXRzLmlzX3J4X2JhZHN1YnR5cGUrKzsKKwkJCWdvdG8gZXJyOworCQl9CisKKwkJLyoKKwkJICog TmV4dCB1cCwgYW55IGZyYWdtZW50YXRpb24uCisJCSAqIFhYWDogd2UgZGVmcmFnIGJlZm9yZSB3 ZSBldmVuIHRyeSB0byBmb3J3YXJkLAorCQkgKiBNZXNoIENvbnRyb2wgZmllbGQgaXMgbm90IHBy ZXNlbnQgaW4gc3ViLXNlcXVlbnQKKwkJICogZnJhZ21lbnRlZCBmcmFtZXMuIFRoaXMgaXMgaW4g Y29udHJhc3QgdG8gRHJhZnQgNC4wLgorCQkgKi8KIAkJaGRyc3BhY2UgPSBpZWVlODAyMTFfaGRy c3BhY2UoaWMsIHdoKTsKKwkJaWYgKCFJRUVFODAyMTFfSVNfTVVMVElDQVNUKHdoLT5pX2FkZHIx KSkgeworCQkJbSA9IGllZWU4MDIxMV9kZWZyYWcobmksIG0sIGhkcnNwYWNlKTsKKwkJCWlmICht ID09IE5VTEwpIHsKKwkJCQkvKiBGcmFnbWVudCBkcm9wcGVkIG9yIGZyYW1lIG5vdCBjb21wbGV0 ZSB5ZXQgKi8KKwkJCQlnb3RvIG91dDsKKwkJCX0KKwkJfQorCQl3aCA9IG10b2QobSwgc3RydWN0 IGllZWU4MDIxMV9mcmFtZSAqKTsgLyogTkI6IGFmdGVyIGRlZnJhZyAqLworCisJCS8qCisJCSAq IE5vdyB3ZSBoYXZlIGEgY29tcGxldGUgTWVzaCBEYXRhIGZyYW1lLgorCQkgKi8KKworCQkvKgor CQkgKiBPbmx5IGdyb3VwIGFkZHJlc3NlZCBNZXNoIGRhdGEgZnJhbWVzIGFyZSAzIGFkZHJlc3MK KwkJICogcW9zIGZyYW1lcyBhbW9uZyB0aGUgZGlmZmVyZW50IE1lc2ggRGF0YSBmcmFtZXMgYXMK KwkJICogc3BlY2lmaWVkIGluIGFtZW5kbWVudC4KKwkJICovCisJCWlmIChJRUVFODAyMTFfSVNf TVVMVElDQVNUKHdoLT5pX2FkZHIxKSAmJgorCQkgICAgZGlyID09IElFRUU4MDIxMV9GQzFfRElS X0ZST01EUykKKwkJCSoodWludDE2X3QgKilxb3MgPSAqKHVpbnQxNl90ICopCisJCQkgICAgKChz dHJ1Y3QgaWVlZTgwMjExX3Fvc2ZyYW1lICopd2gpLT5pX3FvczsKKwkJZWxzZQorCQkJKih1aW50 MTZfdCAqKXFvcyA9ICoodWludDE2X3QgKikKKwkJCSAgICAoKHN0cnVjdCBpZWVlODAyMTFfcW9z ZnJhbWVfYWRkcjQgKil3aCktPmlfcW9zOworCisJCS8qCisJCSAqIE5COiBUaGUgbWVzaCBTVEEg c2V0cyB0aGUgTWVzaCBDb250cm9sIFByZXNlbnQKKwkJICogc3ViZmllbGQgdG8gMSBpbiB0aGUg TWVzaCBEYXRhIGZyYW1lIGNvbnRhaW5pbmcKKwkJICogYW4gdW5mcmFnbWVudGVkIE1TRFUsIGFu IEEtTVNEVSwgb3IgdGhlIGZpcnN0CisJCSAqIGZyYWdtZW50IG9mIGFuIE1TRFUuCisJCSAqIEFm dGVyIGRlZnJhZyBpdCBzaG91bGQgYWx3YXlzIGJlIHByZXNlbnQuCisJCSAqLworCQlpZiAoIShx b3NbMV0gJiBJRUVFODAyMTFfUU9TX01DKSkgeworCQkJSUVFRTgwMjExX0RJU0NBUkRfTUFDKHZh cCwgSUVFRTgwMjExX01TR19NRVNILAorCQkJICAgIG5pLT5uaV9tYWNhZGRyLCBOVUxMLAorCQkJ ICAgICIlcyIsICJNZXNoIGNvbnRyb2wgZmllbGQgbm90IHByZXNlbnQiKTsKKwkJCXZhcC0+aXZf c3RhdHMuaXNfcnhfZWxlbV9taXNzaW5nKys7IC8qIFhYWDoga2luZGEgKi8KKwkJCWdvdG8gZXJy OworCQl9CisKKwkJLyogcHVsbCB1cCBlbm91Z2ggdG8gZ2V0IHRvIHRoZSBtZXNoIGNvbnRyb2wg Ki8KIAkJaWYgKG0tPm1fbGVuIDwgaGRyc3BhY2UgKyBzaXplb2Yoc3RydWN0IGllZWU4MDIxMV9t ZXNoY250bCkgJiYKIAkJICAgIChtID0gbV9wdWxsdXAobSwgaGRyc3BhY2UgKwogCQkgICAgICAg IHNpemVvZihzdHJ1Y3QgaWVlZTgwMjExX21lc2hjbnRsKSkpID09IE5VTEwpIHsKQEAgLTExOTUs MjcgKzEyNTEsNiBAQCBtZXNoX2lucHV0KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVj dCBtYnVmICptLCBpbnQgcnNzaSwgaW50IG5mKQogCQkJLyogTkI6IGZhbGwgdGhydSB0byBkZWxp dmVyIG1jYXN0IGZyYW1lcyBsb2NhbGx5ICovCiAJCX0KIAotCQkvKgotCQkgKiBTYXZlIFFvUyBi aXRzIGZvciB1c2UgYmVsb3ctLWJlZm9yZSB3ZSBzdHJpcCB0aGUgaGVhZGVyLgotCQkgKi8KLQkJ aWYgKHN1YnR5cGUgPT0gSUVFRTgwMjExX0ZDMF9TVUJUWVBFX1FPUykgewotCQkJcW9zID0gKGRp ciA9PSBJRUVFODAyMTFfRkMxX0RJUl9EU1RPRFMpID8KLQkJCSAgICAoKHN0cnVjdCBpZWVlODAy MTFfcW9zZnJhbWVfYWRkcjQgKil3aCktPmlfcW9zWzBdIDoKLQkJCSAgICAoKHN0cnVjdCBpZWVl ODAyMTFfcW9zZnJhbWUgKil3aCktPmlfcW9zWzBdOwotCQl9IGVsc2UKLQkJCXFvcyA9IDA7Ci0J CS8qCi0JCSAqIE5leHQgdXAsIGFueSBmcmFnbWVudGF0aW9uLgotCQkgKi8KLQkJaWYgKCFJRUVF ODAyMTFfSVNfTVVMVElDQVNUKHdoLT5pX2FkZHIxKSkgewotCQkJbSA9IGllZWU4MDIxMV9kZWZy YWcobmksIG0sIGhkcnNwYWNlKTsKLQkJCWlmIChtID09IE5VTEwpIHsKLQkJCQkvKiBGcmFnbWVu dCBkcm9wcGVkIG9yIGZyYW1lIG5vdCBjb21wbGV0ZSB5ZXQgKi8KLQkJCQlnb3RvIG91dDsKLQkJ CX0KLQkJfQotCQl3aCA9IE5VTEw7CQkvKiBubyBsb25nZXIgdmFsaWQsIGNhdGNoIGFueSB1c2Vz ICovCi0KIAkJaWYgKGllZWU4MDIxMV9yYWRpb3RhcF9hY3RpdmVfdmFwKHZhcCkpCiAJCQlpZWVl ODAyMTFfcmFkaW90YXBfcngodmFwLCBtKTsKIAkJbmVlZF90YXAgPSAwOwpAQCAtMTIzNiw3ICsx MjcxLDcgQEAgbWVzaF9pbnB1dChzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgbWJ1 ZiAqbSwgaW50IHJzc2ksIGludCBuZikKIAkJCUlFRUU4MDIxMV9OT0RFX1NUQVQobmksIHJ4X2Rl Y2FwKTsKIAkJCWdvdG8gZXJyOwogCQl9Ci0JCWlmIChxb3MgJiBJRUVFODAyMTFfUU9TX0FNU0RV KSB7CisJCWlmIChxb3NbMF0gJiBJRUVFODAyMTFfUU9TX0FNU0RVKSB7CiAJCQltID0gaWVlZTgw MjExX2RlY2FwX2Ftc2R1KG5pLCBtKTsKIAkJCWlmIChtID09IE5VTEwpCiAJCQkJcmV0dXJuIElF RUU4MDIxMV9GQzBfVFlQRV9EQVRBOwpkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4MDIx MV9vdXRwdXQuYyBiL3N5cy9uZXQ4MDIxMS9pZWVlODAyMTFfb3V0cHV0LmMKaW5kZXggZjYxNzdk OS4uMWJkOTQ1MiAxMDA2NDQKLS0tIGEvc3lzL25ldDgwMjExL2llZWU4MDIxMV9vdXRwdXQuYwor KysgYi9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX291dHB1dC5jCkBAIC0xMDY5LDkgKzEwNjksMTEg QEAgaWVlZTgwMjExX2VuY2FwKHN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCwgc3RydWN0IGllZWU4 MDIxMV9ub2RlICpuaSwKIAkgKiBhcCdzIHJlcXVpcmUgYWxsIGRhdGEgZnJhbWVzIHRvIGJlIFFv Uy1lbmNhcHN1bGF0ZWQKIAkgKiBvbmNlIG5lZ290aWF0ZWQgaW4gd2hpY2ggY2FzZSB3ZSdsbCBu ZWVkIHRvIG1ha2UgdGhpcwogCSAqIGNvbmZpZ3VyYWJsZS4KKwkgKiBOQjogbWVzaCBkYXRhIGZy YW1lcyBhcmUgUW9TLgogCSAqLwotCWFkZHFvcyA9IChuaS0+bmlfZmxhZ3MgJiAoSUVFRTgwMjEx X05PREVfUU9TfElFRUU4MDIxMV9OT0RFX0hUKSkgJiYKLQkJIChtLT5tX2ZsYWdzICYgTV9FQVBP TCkgPT0gMDsKKwlhZGRxb3MgPSAoKG5pLT5uaV9mbGFncyAmIChJRUVFODAyMTFfTk9ERV9RT1N8 SUVFRTgwMjExX05PREVfSFQpKSB8fAorCSAgICAodmFwLT5pdl9vcG1vZGUgPT0gSUVFRTgwMjEx X01fTUJTUykpICYmCisJICAgIChtLT5tX2ZsYWdzICYgTV9FQVBPTCkgPT0gMDsKIAlpZiAoYWRk cW9zKQogCQloZHJzaXplID0gc2l6ZW9mKHN0cnVjdCBpZWVlODAyMTFfcW9zZnJhbWUpOwogCWVs c2UKQEAgLTEyNzcsNyArMTI3OSwxMiBAQCBpZWVlODAyMTFfZW5jYXAoc3RydWN0IGllZWU4MDIx MXZhcCAqdmFwLCBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLAogCQlxb3NbMF0gPSB0aWQgJiBJ RUVFODAyMTFfUU9TX1RJRDsKIAkJaWYgKGljLT5pY193bWUud21lX3dtZUNoYW5QYXJhbXMuY2Fw X3dtZVBhcmFtc1thY10ud21lcF9ub2Fja1BvbGljeSkKIAkJCXFvc1swXSB8PSBJRUVFODAyMTFf UU9TX0FDS1BPTElDWV9OT0FDSzsKLQkJcW9zWzFdID0gMDsKKyNpZmRlZiBJRUVFODAyMTFfU1VQ UE9SVF9NRVNICisJCWlmICh2YXAtPml2X29wbW9kZSA9PSBJRUVFODAyMTFfTV9NQlNTKSB7CisJ CQlxb3NbMV0gfD0gSUVFRTgwMjExX1FPU19NQzsKKwkJfSBlbHNlCisjZW5kaWYKKwkJCXFvc1sx XSA9IDA7CiAJCXdoLT5pX2ZjWzBdIHw9IElFRUU4MDIxMV9GQzBfU1VCVFlQRV9RT1M7CiAKIAkJ aWYgKChtLT5tX2ZsYWdzICYgTV9BTVBEVV9NUERVKSA9PSAwKSB7CkBAIC0xNDAyLDkgKzE0MDks MjAgQEAgaWVlZTgwMjExX2ZyYWdtZW50KHN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCwgc3RydWN0 IG1idWYgKm0wLAogCQkgKiB3ZSBtYXJrIHRoZSBmaXJzdCBmcmFnbWVudCB3aXRoIHRoZSBNT1JF X0ZSQUcgYml0CiAJCSAqIGl0IGF1dG9tYXRpY2FsbHkgaXMgcHJvcGFnYXRlZCB0byBlYWNoIGZy YWdtZW50OyB3ZQogCQkgKiBuZWVkIG9ubHkgY2xlYXIgaXQgb24gdGhlIGxhc3QgZnJhZ21lbnQg KGRvbmUgYmVsb3cpLgorCQkgKiBOQjogZnJhZyAxKyBkb250IGhhdmUgTWVzaCBDb250cm9sIGZp ZWxkIHByZXNlbnQuCiAJCSAqLwogCQl3aGYgPSBtdG9kKG0sIHN0cnVjdCBpZWVlODAyMTFfZnJh bWUgKik7CiAJCW1lbWNweSh3aGYsIHdoLCBoZHJzaXplKTsKKyNpZmRlZiBJRUVFODAyMTFfU1VQ UE9SVF9NRVNICisJCWlmICh2YXAtPml2X29wbW9kZSA9PSBJRUVFODAyMTFfTV9NQlNTKSB7CisJ CQlpZiAoSUVFRTgwMjExX0lTX0RTVE9EUyh3aCkpCisJCQkJKChzdHJ1Y3QgaWVlZTgwMjExX3Fv c2ZyYW1lX2FkZHI0ICopCisJCQkJICAgIHdoZiktPmlfcW9zWzFdICY9IH5JRUVFODAyMTFfUU9T X01DOworCQkJZWxzZQorCQkJCSgoc3RydWN0IGllZWU4MDIxMV9xb3NmcmFtZSAqKQorCQkJCSAg ICB3aGYpLT5pX3Fvc1sxXSAmPSB+SUVFRTgwMjExX1FPU19NQzsKKwkJfQorI2VuZGlmCiAJCSoo dWludDE2X3QgKikmd2hmLT5pX3NlcVswXSB8PSBodG9sZTE2KAogCQkJKGZyYWdubyAmIElFRUU4 MDIxMV9TRVFfRlJBR19NQVNLKSA8PAogCQkJCUlFRUU4MDIxMV9TRVFfRlJBR19TSElGVCk7Ci0t IAoxLjcuNC4xCgo= --14dae9340dd3c0a7c304b8fd4ffa-- From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 09:46:36 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96283106566B; Wed, 15 Feb 2012 09:46:36 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 394098FC20; Wed, 15 Feb 2012 09:46:36 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1571359iae.13 for ; Wed, 15 Feb 2012 01:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0wsmZQ72XqhJy4DOrAldRv+pNksiqiDqyPcQQM4jLCo=; b=lXdDANhCJJMz406RwwtD7tGR1QWNHNdxwE2vcJKHKMg/M94uSseRHp40/fBymFjjut 06EGHG/aPZOvbPaRHaMorV1emq7iPmJN5MjPDfHoIV6SwKWtvmT7h3luveHVgThJQVu1 jQZaw3aacfvR7JrEFskVA5y0O+Z/P/cxLvUrk= MIME-Version: 1.0 Received: by 10.50.87.136 with SMTP id ay8mr23047319igb.25.1329299195917; Wed, 15 Feb 2012 01:46:35 -0800 (PST) Received: by 10.50.213.74 with HTTP; Wed, 15 Feb 2012 01:46:35 -0800 (PST) In-Reply-To: References: <3F2E258F-1F82-48D7-AAAD-546BCB03EDE2@freebsd.org> Date: Wed, 15 Feb 2012 10:46:35 +0100 Message-ID: From: Monthadar Al Jaberi To: Rui Paulo Content-Type: multipart/mixed; boundary=e89a8f3ba7075f750604b8fd96af Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Fragment and 11s inconsistency X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 09:46:36 -0000 --e89a8f3ba7075f750604b8fd96af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry for the noise, I found out that I had an error when reading out the QoS control field, it is corrected now and I updated the comment. I tested the code without fragmentation and it should work fine now. On Wed, Feb 15, 2012 at 10:26 AM, Monthadar Al Jaberi wrote: > On Wed, Feb 15, 2012 at 9:26 AM, Monthadar Al Jaberi > wrote: >> On Wed, Feb 15, 2012 at 5:50 AM, Rui Paulo wrote: >>> On 2012/02/14, at 14:14, Monthadar Al Jaberi wrote: >>> >>>> Hi, >>>> >>>> I cant verify this yet, but isn't there something wrong in current Fre= eBSD? >>>> >>>> lets say an 11s data frame need to be fragmented in ieee80211_encap: >>>> if (addqos) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize =3D sizeof(struct ieee80211_qosfra= me); >>>> else >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize =3D sizeof(struct ieee80211_frame)= ; >>>> ... >>>> if (vap->iv_opmode =3D=3D IEEE80211_M_MBSS) { >>>> ... >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!IEEE80211_IS_MULTICAST(eh.ether_dhost= )) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrsize +=3D IEEE80211_ADD= R_LEN; =A0/* unicast are 4-addr */ >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 meshhdrsize =3D sizeof(struct ieee80211_me= shcntl); >>>> } >>>> ... >>>> if (__predict_true((m->m_flags & M_FF) =3D=3D 0)) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Normal frame. >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D ieee80211_mbuf_adjust(vap, hdrspace = + meshhdrsize, key, m); >>>> } >>>> M_PREPEND(m, hdrspace + meshhdrsize, M_DONTWAIT); >>>> if (txfrag && !ieee80211_fragment(vap, m, hdrsize, >>>> =A0 =A0 =A0 =A0 =A0 key !=3D NULL ? key->wk_cipher->ic_header : 0, vap= ->iv_fragthreshold)) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad; >>>> >>>> This means we send meshcontrol only in first segment, because we never >>>> add meshhdrsize to hdrsize... >>> >>> Yes, this is a bug. Thanks for finding it. >>> >>>> but in mesh_input >>>> switch (type) { >>>> =A0 =A0 =A0 case IEEE80211_FC0_TYPE_DATA: >>>> ... >>>> meshdrlen =3D sizeof(struct ieee80211_meshcntl) + >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (mc->mc_flags & 3) * IEEE80211_ADD= R_LEN; >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdrspace +=3D meshdrlen; >>>> ... >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Potentially forward packet. =A0See ta= ble s36 (p140) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* for the rules. =A0XXX tap fwd'd packe= ts not for us? >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS || >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !mesh_isucastforme(vap, wh, mc)) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mesh_forward(vap, m, mc); >>>> ... >>>> if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D ieee80211_defrag(ni,= m, hdrspace); >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (m =3D=3D NULL) { >>>> >>>> This seems wrong to me, how can we potentially forward before defragin >>>> the frame? this will fail cause sub-frag have no mesh control as code >>>> shows above. >>>> >>>> shouldnt the defrag code be moved above? >>> >>> Yes, another bug. >>> >>>> I am attaching a patch that both moves the defrag, validates that mesh >>>> control is present and makes 11s data frames QoS and set Mesh control >>>> bit present to 1 as the amendment specifies. >>> >>> There are some typos in your patch ("This is in constrast to Draf 4.0."= ). >>> >>> Can you please rewrite this code: >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(uint16_t *)qos =3D *(uint16_t *) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (((IEEE80211_IS_MULTICAST(wh->i_a= ddr1) && >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dir =3D=3D IEEE80211_FC1_DIR_FROM= DS)) ? >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((struct ieee80211_qosframe *)wh)= ->i_qos : >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((struct ieee80211_qosframe_addr4= *)wh)->i_qos); >>> >>> In ieee80211_encap(), why didn't you add meshhdrsize to ieee80211_fragm= ent()? >> >> Because the mesh control is not part of the header, it is in the frame >> body and should only be present in the first fragment of a frame. So I >> think this is correct. >> > > Attaching patch again; this time Mesh Control field is set to not > present for frags 1+. > >>> >>> Would be nice to test this =A0before committing. >> >> Yes, Adrian and Bernhard are looking into the fragment code between >> net80211 and ath. It seems the code is broken. >> >> I am reattaching the patch thanks for your comments. >> >>> >>> Thanks, >>> -- >>> Rui Paulo >>> >> >> >> >> -- >> Monthadar Al Jaberi > > br > > -- > Monthadar Al Jaberi --=20 Monthadar Al Jaberi --e89a8f3ba7075f750604b8fd96af Content-Type: text/x-patch; charset=US-ASCII; name="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Disposition: attachment; filename="0001-Make-mesh-data-frames-to-be-quality-of-service-QoS.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gyo6fv821 RnJvbSAzYzI0OGM5NjE1MDk3NTBkMTU0YWM0NGUwM2Y2ODA4Yzc4YzdhOGNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNb250aGFkYXIgQWwgSmFiZXJpIDxtb250aGFkYXJAZ21haWwu Y29tPgpEYXRlOiBUdWUsIDE0IEZlYiAyMDEyIDE2OjQ3OjQzICswMTAwClN1YmplY3Q6IFtQQVRD SF0gTWFrZSBtZXNoIGRhdGEgZnJhbWVzIHRvIGJlIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKS4K CiogSW50cm9kdWNlIG5ldyBmbGFnIGZvciBRb1MgY29udHJvbCBmaWVsZDsKKiBDaGFuZ2UgaW4g bWVzaF9pbnB1dCB0byB2YWxpZGF0ZSB0aGF0IFFvUyBpcyBzZXQgYW5kIE1lc2ggQ29udHJvbCBm aWVsZAppcyBwcmVzZW50LCBhbHNvIGJvdGggYnl0ZXMgb2YgdGhlIFFvUyBhcmUgcmVhZDsKKiBN b3ZlZCBkZWZyYWdtZW50YXRpb24gaW4gbWVzaF9pbnB1dCBiZWZvcmUgd2UgdHJ5IHRvIGZvcndh cmQgcGFja2V0IGFzCmluZmVycmVkIGZyb20gYW1lbmRtZW50IHNwZWMsIGJlY2F1c2UgTWVzaCBD b250cm9sIGZpZWxkIG9ubHkgcHJlc2VudCBpbiBmaXJzdApmcmFnbWVudDsKKiBDaGFuZ2VkIGlu IGllZWU4MDIxMV9lbmNhcCB0byBzZXQgUW9TIHN1YnR5cGUgYW5kIE1lc2ggQ29udHJvbCBmaWVs ZCBwcmVzZW50LApvbmx5IGZpcnN0IGZyYWdtZW50IGhhdmUgTWVzaCBDb250cm9sIGZpZWxkIHBy ZXNlbnQgYml0IGVxdWFsIHRvIDE7Ci0tLQogc3lzL25ldDgwMjExL2llZWU4MDIxMS5oICAgICAg ICB8ICAgIDcgKysrCiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYyAgIHwgICA4NSArKysr KysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLQogc3lzL25ldDgwMjExL2llZWU4MDIx MV9vdXRwdXQuYyB8ICAgMjQgKysrKysrKysrKy0KIDMgZmlsZXMgY2hhbmdlZCwgODggaW5zZXJ0 aW9ucygrKSwgMjggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4 MDIxMS5oIGIvc3lzL25ldDgwMjExL2llZWU4MDIxMS5oCmluZGV4IDAyOGFmZWMuLjI5YmZhM2Mg MTAwNjQ0Ci0tLSBhL3N5cy9uZXQ4MDIxMS9pZWVlODAyMTEuaAorKysgYi9zeXMvbmV0ODAyMTEv aWVlZTgwMjExLmgKQEAgLTE5OSw2ICsxOTksMTMgQEAgc3RydWN0IGllZWU4MDIxMV9xb3NmcmFt ZV9hZGRyNCB7CiAjZGVmaW5lCUlFRUU4MDIxMV9RT1NfRU9TUAkJCTB4MTAJLyogRW5kT2ZTZXJ2 aWNlIFBlcmlvZCovCiAjZGVmaW5lCUlFRUU4MDIxMV9RT1NfRU9TUF9TCQkJNAogI2RlZmluZQlJ RUVFODAyMTFfUU9TX1RJRAkJCTB4MGYKKy8qIHFvc1sxXSBieXRlIHVzZWQgZm9yIGFsbCBmcmFt ZXMgc2VudCBieSBtZXNoIFNUQXMgaW4gYSBtZXNoIEJTUyAqLworI2RlZmluZSBJRUVFODAyMTFf UU9TX01DCQkJMHgxMAkvKiBNZXNoIGNvbnRyb2wgKi8KKy8qIE1lc2ggcG93ZXIgc2F2ZSBsZXZl bCovCisjZGVmaW5lIElFRUU4MDIxMV9RT1NfTUVTSF9QU0wJCQkweDIwCisvKiBNZXNoIFJlY2Vp dmVyIFNlcnZpY2UgUGVyaW9kIEluaXRpYXRlZCAqLworI2RlZmluZSBJRUVFODAyMTFfUU9TX1JT UEkJCQkweDQwCisvKiBiaXRzIDExIHRvIDE1IHJlc2VydmVkICovCiAKIC8qIGRvZXMgZnJhbWUg aGF2ZSBRb1Mgc2VxdWVuY2UgY29udHJvbCBkYXRhICovCiAjZGVmaW5lCUlFRUU4MDIxMV9RT1Nf SEFTX1NFUSh3aCkgXApkaWZmIC0tZ2l0IGEvc3lzL25ldDgwMjExL2llZWU4MDIxMV9tZXNoLmMg Yi9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYwppbmRleCBiOTJmNjk1Li44YjFhNmRiIDEw MDY0NAotLS0gYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX21lc2guYworKysgYi9zeXMvbmV0ODAy MTEvaWVlZTgwMjExX21lc2guYwpAQCAtMTA0Nyw5ICsxMDQ3LDkgQEAgbWVzaF9pbnB1dChzdHJ1 Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGludCBuZikK IAlzdHJ1Y3QgaWVlZTgwMjExX2ZyYW1lICp3aDsKIAljb25zdCBzdHJ1Y3QgaWVlZTgwMjExX21l c2hjbnRsICptYzsKIAlpbnQgaGRyc3BhY2UsIG1lc2hkcmxlbiwgbmVlZF90YXA7Ci0JdWludDhf dCBkaXIsIHR5cGUsIHN1YnR5cGUsIHFvczsKKwl1aW50OF90IGRpciwgdHlwZSwgc3VidHlwZTsK IAl1aW50MzJfdCBzZXE7Ci0JdWludDhfdCAqYWRkcjsKKwl1aW50OF90ICphZGRyLCBxb3NbMl07 CiAJaWVlZTgwMjExX3NlcSByeHNlcTsKIAogCUtBU1NFUlQobmkgIT0gTlVMTCwgKCJudWxsIG5v ZGUiKSk7CkBAIC0xMTQ2LDggKzExNDYsNjQgQEAgbWVzaF9pbnB1dChzdHJ1Y3QgaWVlZTgwMjEx X25vZGUgKm5pLCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IHJzc2ksIGludCBuZikKIAkJCXZhcC0+aXZf c3RhdHMuaXNfcnhfd3JvbmdkaXIrKzsKIAkJCWdvdG8gZXJyOwogCQl9Ci0JCS8qIHB1bGwgdXAg ZW5vdWdoIHRvIGdldCB0byB0aGUgbWVzaCBjb250cm9sICovCisKKwkJLyogQWxsIE1lc2ggZGF0 YSBmcmFtZXMgYXJlIFFvUyBzdWJ0eXBlICovCisJCWlmICghSEFTX1NFUSh0eXBlKSkgeworCQkJ SUVFRTgwMjExX0RJU0NBUkQodmFwLCBJRUVFODAyMTFfTVNHX0lOUFVULAorCQkJICAgIHdoLCAi ZGF0YSIsICJpbmNvcnJlY3Qgc3VidHlwZSAweCV4Iiwgc3VidHlwZSk7CisJCQl2YXAtPml2X3N0 YXRzLmlzX3J4X2JhZHN1YnR5cGUrKzsKKwkJCWdvdG8gZXJyOworCQl9CisKKwkJLyoKKwkJICog TmV4dCB1cCwgYW55IGZyYWdtZW50YXRpb24uCisJCSAqIFhYWDogd2UgZGVmcmFnIGJlZm9yZSB3 ZSBldmVuIHRyeSB0byBmb3J3YXJkLAorCQkgKiBNZXNoIENvbnRyb2wgZmllbGQgaXMgbm90IHBy ZXNlbnQgaW4gc3ViLXNlcXVlbnQKKwkJICogZnJhZ21lbnRlZCBmcmFtZXMuIFRoaXMgaXMgaW4g Y29udHJhc3QgdG8gRHJhZnQgNC4wLgorCQkgKi8KIAkJaGRyc3BhY2UgPSBpZWVlODAyMTFfaGRy c3BhY2UoaWMsIHdoKTsKKwkJaWYgKCFJRUVFODAyMTFfSVNfTVVMVElDQVNUKHdoLT5pX2FkZHIx KSkgeworCQkJbSA9IGllZWU4MDIxMV9kZWZyYWcobmksIG0sIGhkcnNwYWNlKTsKKwkJCWlmICht ID09IE5VTEwpIHsKKwkJCQkvKiBGcmFnbWVudCBkcm9wcGVkIG9yIGZyYW1lIG5vdCBjb21wbGV0 ZSB5ZXQgKi8KKwkJCQlnb3RvIG91dDsKKwkJCX0KKwkJfQorCQl3aCA9IG10b2QobSwgc3RydWN0 IGllZWU4MDIxMV9mcmFtZSAqKTsgLyogTkI6IGFmdGVyIGRlZnJhZyAqLworCisJCS8qCisJCSAq IE5vdyB3ZSBoYXZlIGEgY29tcGxldGUgTWVzaCBEYXRhIGZyYW1lLgorCQkgKi8KKworCQkvKgor CQkgKiBPbmx5IGZyb21EU3RvRFMgZGF0YSBmcmFtZXMgdXNlIDQgYWRkcmVzcyBxb3MgZnJhbWVz CisJCSAqIGFzIHNwZWNpZmllZCBpbiBhbWVuZG1lbnQuIE90aGVyd2lzZSBhZGRyNCBpcyBsb2Nh dGVkCisJCSAqIGluIHRoZSBNZXNoIENvbnRyb2wgZmllbGQgYW5kIGEgMyBhZGRyZXNzIHFvcyBm cmFtZQorCQkgKiBpcyB1c2VkLgorCQkgKi8KKwkJaWYgKElFRUU4MDIxMV9JU19EU1RPRFMod2gp KQorCQkJKih1aW50MTZfdCAqKXFvcyA9ICoodWludDE2X3QgKikKKwkJCSAgICAoKHN0cnVjdCBp ZWVlODAyMTFfcW9zZnJhbWVfYWRkcjQgKil3aCktPmlfcW9zOworCQllbHNlCisJCQkqKHVpbnQx Nl90ICopcW9zID0gKih1aW50MTZfdCAqKQorCQkJICAgICgoc3RydWN0IGllZWU4MDIxMV9xb3Nm cmFtZSAqKXdoKS0+aV9xb3M7CisKKwkJLyoKKwkJICogTkI6IFRoZSBtZXNoIFNUQSBzZXRzIHRo ZSBNZXNoIENvbnRyb2wgUHJlc2VudAorCQkgKiBzdWJmaWVsZCB0byAxIGluIHRoZSBNZXNoIERh dGEgZnJhbWUgY29udGFpbmluZworCQkgKiBhbiB1bmZyYWdtZW50ZWQgTVNEVSwgYW4gQS1NU0RV LCBvciB0aGUgZmlyc3QKKwkJICogZnJhZ21lbnQgb2YgYW4gTVNEVS4KKwkJICogQWZ0ZXIgZGVm cmFnIGl0IHNob3VsZCBhbHdheXMgYmUgcHJlc2VudC4KKwkJICovCisJCWlmICghKHFvc1sxXSAm IElFRUU4MDIxMV9RT1NfTUMpKSB7CisJCQlJRUVFODAyMTFfRElTQ0FSRF9NQUModmFwLCBJRUVF ODAyMTFfTVNHX01FU0gsCisJCQkgICAgbmktPm5pX21hY2FkZHIsIE5VTEwsCisJCQkgICAgIiVz IiwgIk1lc2ggY29udHJvbCBmaWVsZCBub3QgcHJlc2VudCIpOworCQkJdmFwLT5pdl9zdGF0cy5p c19yeF9lbGVtX21pc3NpbmcrKzsgLyogWFhYOiBraW5kYSAqLworCQkJZ290byBlcnI7CisJCX0K KworCQkvKiBwdWxsIHVwIGVub3VnaCB0byBnZXQgdG8gdGhlIG1lc2ggY29udHJvbCAqLwogCQlp ZiAobS0+bV9sZW4gPCBoZHJzcGFjZSArIHNpemVvZihzdHJ1Y3QgaWVlZTgwMjExX21lc2hjbnRs KSAmJgogCQkgICAgKG0gPSBtX3B1bGx1cChtLCBoZHJzcGFjZSArCiAJCSAgICAgICAgc2l6ZW9m KHN0cnVjdCBpZWVlODAyMTFfbWVzaGNudGwpKSkgPT0gTlVMTCkgewpAQCAtMTE5NSwyNyArMTI1 MSw2IEBAIG1lc2hfaW5wdXQoc3RydWN0IGllZWU4MDIxMV9ub2RlICpuaSwgc3RydWN0IG1idWYg Km0sIGludCByc3NpLCBpbnQgbmYpCiAJCQkvKiBOQjogZmFsbCB0aHJ1IHRvIGRlbGl2ZXIgbWNh c3QgZnJhbWVzIGxvY2FsbHkgKi8KIAkJfQogCi0JCS8qCi0JCSAqIFNhdmUgUW9TIGJpdHMgZm9y IHVzZSBiZWxvdy0tYmVmb3JlIHdlIHN0cmlwIHRoZSBoZWFkZXIuCi0JCSAqLwotCQlpZiAoc3Vi dHlwZSA9PSBJRUVFODAyMTFfRkMwX1NVQlRZUEVfUU9TKSB7Ci0JCQlxb3MgPSAoZGlyID09IElF RUU4MDIxMV9GQzFfRElSX0RTVE9EUykgPwotCQkJICAgICgoc3RydWN0IGllZWU4MDIxMV9xb3Nm cmFtZV9hZGRyNCAqKXdoKS0+aV9xb3NbMF0gOgotCQkJICAgICgoc3RydWN0IGllZWU4MDIxMV9x b3NmcmFtZSAqKXdoKS0+aV9xb3NbMF07Ci0JCX0gZWxzZQotCQkJcW9zID0gMDsKLQkJLyoKLQkJ ICogTmV4dCB1cCwgYW55IGZyYWdtZW50YXRpb24uCi0JCSAqLwotCQlpZiAoIUlFRUU4MDIxMV9J U19NVUxUSUNBU1Qod2gtPmlfYWRkcjEpKSB7Ci0JCQltID0gaWVlZTgwMjExX2RlZnJhZyhuaSwg bSwgaGRyc3BhY2UpOwotCQkJaWYgKG0gPT0gTlVMTCkgewotCQkJCS8qIEZyYWdtZW50IGRyb3Bw ZWQgb3IgZnJhbWUgbm90IGNvbXBsZXRlIHlldCAqLwotCQkJCWdvdG8gb3V0OwotCQkJfQotCQl9 Ci0JCXdoID0gTlVMTDsJCS8qIG5vIGxvbmdlciB2YWxpZCwgY2F0Y2ggYW55IHVzZXMgKi8KLQog CQlpZiAoaWVlZTgwMjExX3JhZGlvdGFwX2FjdGl2ZV92YXAodmFwKSkKIAkJCWllZWU4MDIxMV9y YWRpb3RhcF9yeCh2YXAsIG0pOwogCQluZWVkX3RhcCA9IDA7CkBAIC0xMjM2LDcgKzEyNzEsNyBA QCBtZXNoX2lucHV0KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBtYnVmICptLCBp bnQgcnNzaSwgaW50IG5mKQogCQkJSUVFRTgwMjExX05PREVfU1RBVChuaSwgcnhfZGVjYXApOwog CQkJZ290byBlcnI7CiAJCX0KLQkJaWYgKHFvcyAmIElFRUU4MDIxMV9RT1NfQU1TRFUpIHsKKwkJ aWYgKHFvc1swXSAmIElFRUU4MDIxMV9RT1NfQU1TRFUpIHsKIAkJCW0gPSBpZWVlODAyMTFfZGVj YXBfYW1zZHUobmksIG0pOwogCQkJaWYgKG0gPT0gTlVMTCkKIAkJCQlyZXR1cm4gSUVFRTgwMjEx X0ZDMF9UWVBFX0RBVEE7CmRpZmYgLS1naXQgYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX291dHB1 dC5jIGIvc3lzL25ldDgwMjExL2llZWU4MDIxMV9vdXRwdXQuYwppbmRleCBmNjE3N2Q5Li4xYmQ5 NDUyIDEwMDY0NAotLS0gYS9zeXMvbmV0ODAyMTEvaWVlZTgwMjExX291dHB1dC5jCisrKyBiL3N5 cy9uZXQ4MDIxMS9pZWVlODAyMTFfb3V0cHV0LmMKQEAgLTEwNjksOSArMTA2OSwxMSBAQCBpZWVl ODAyMTFfZW5jYXAoc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwLCBzdHJ1Y3QgaWVlZTgwMjExX25v ZGUgKm5pLAogCSAqIGFwJ3MgcmVxdWlyZSBhbGwgZGF0YSBmcmFtZXMgdG8gYmUgUW9TLWVuY2Fw c3VsYXRlZAogCSAqIG9uY2UgbmVnb3RpYXRlZCBpbiB3aGljaCBjYXNlIHdlJ2xsIG5lZWQgdG8g bWFrZSB0aGlzCiAJICogY29uZmlndXJhYmxlLgorCSAqIE5COiBtZXNoIGRhdGEgZnJhbWVzIGFy ZSBRb1MuCiAJICovCi0JYWRkcW9zID0gKG5pLT5uaV9mbGFncyAmIChJRUVFODAyMTFfTk9ERV9R T1N8SUVFRTgwMjExX05PREVfSFQpKSAmJgotCQkgKG0tPm1fZmxhZ3MgJiBNX0VBUE9MKSA9PSAw OworCWFkZHFvcyA9ICgobmktPm5pX2ZsYWdzICYgKElFRUU4MDIxMV9OT0RFX1FPU3xJRUVFODAy MTFfTk9ERV9IVCkpIHx8CisJICAgICh2YXAtPml2X29wbW9kZSA9PSBJRUVFODAyMTFfTV9NQlNT KSkgJiYKKwkgICAgKG0tPm1fZmxhZ3MgJiBNX0VBUE9MKSA9PSAwOwogCWlmIChhZGRxb3MpCiAJ CWhkcnNpemUgPSBzaXplb2Yoc3RydWN0IGllZWU4MDIxMV9xb3NmcmFtZSk7CiAJZWxzZQpAQCAt MTI3Nyw3ICsxMjc5LDEyIEBAIGllZWU4MDIxMV9lbmNhcChzdHJ1Y3QgaWVlZTgwMjExdmFwICp2 YXAsIHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksCiAJCXFvc1swXSA9IHRpZCAmIElFRUU4MDIx MV9RT1NfVElEOwogCQlpZiAoaWMtPmljX3dtZS53bWVfd21lQ2hhblBhcmFtcy5jYXBfd21lUGFy YW1zW2FjXS53bWVwX25vYWNrUG9saWN5KQogCQkJcW9zWzBdIHw9IElFRUU4MDIxMV9RT1NfQUNL UE9MSUNZX05PQUNLOwotCQlxb3NbMV0gPSAwOworI2lmZGVmIElFRUU4MDIxMV9TVVBQT1JUX01F U0gKKwkJaWYgKHZhcC0+aXZfb3Btb2RlID09IElFRUU4MDIxMV9NX01CU1MpIHsKKwkJCXFvc1sx XSB8PSBJRUVFODAyMTFfUU9TX01DOworCQl9IGVsc2UKKyNlbmRpZgorCQkJcW9zWzFdID0gMDsK IAkJd2gtPmlfZmNbMF0gfD0gSUVFRTgwMjExX0ZDMF9TVUJUWVBFX1FPUzsKIAogCQlpZiAoKG0t Pm1fZmxhZ3MgJiBNX0FNUERVX01QRFUpID09IDApIHsKQEAgLTE0MDIsOSArMTQwOSwyMCBAQCBp ZWVlODAyMTFfZnJhZ21lbnQoc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwLCBzdHJ1Y3QgbWJ1ZiAq bTAsCiAJCSAqIHdlIG1hcmsgdGhlIGZpcnN0IGZyYWdtZW50IHdpdGggdGhlIE1PUkVfRlJBRyBi aXQKIAkJICogaXQgYXV0b21hdGljYWxseSBpcyBwcm9wYWdhdGVkIHRvIGVhY2ggZnJhZ21lbnQ7 IHdlCiAJCSAqIG5lZWQgb25seSBjbGVhciBpdCBvbiB0aGUgbGFzdCBmcmFnbWVudCAoZG9uZSBi ZWxvdykuCisJCSAqIE5COiBmcmFnIDErIGRvbnQgaGF2ZSBNZXNoIENvbnRyb2wgZmllbGQgcHJl c2VudC4KIAkJICovCiAJCXdoZiA9IG10b2QobSwgc3RydWN0IGllZWU4MDIxMV9mcmFtZSAqKTsK IAkJbWVtY3B5KHdoZiwgd2gsIGhkcnNpemUpOworI2lmZGVmIElFRUU4MDIxMV9TVVBQT1JUX01F U0gKKwkJaWYgKHZhcC0+aXZfb3Btb2RlID09IElFRUU4MDIxMV9NX01CU1MpIHsKKwkJCWlmIChJ RUVFODAyMTFfSVNfRFNUT0RTKHdoKSkKKwkJCQkoKHN0cnVjdCBpZWVlODAyMTFfcW9zZnJhbWVf YWRkcjQgKikKKwkJCQkgICAgd2hmKS0+aV9xb3NbMV0gJj0gfklFRUU4MDIxMV9RT1NfTUM7CisJ CQllbHNlCisJCQkJKChzdHJ1Y3QgaWVlZTgwMjExX3Fvc2ZyYW1lICopCisJCQkJICAgIHdoZikt PmlfcW9zWzFdICY9IH5JRUVFODAyMTFfUU9TX01DOworCQl9CisjZW5kaWYKIAkJKih1aW50MTZf dCAqKSZ3aGYtPmlfc2VxWzBdIHw9IGh0b2xlMTYoCiAJCQkoZnJhZ25vICYgSUVFRTgwMjExX1NF UV9GUkFHX01BU0spIDw8CiAJCQkJSUVFRTgwMjExX1NFUV9GUkFHX1NISUZUKTsKLS0gCjEuNy40 LjEKCg== --e89a8f3ba7075f750604b8fd96af-- From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 14:56:20 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3659106566C for ; Thu, 16 Feb 2012 14:56:20 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9200F8FC12 for ; Thu, 16 Feb 2012 14:56:20 +0000 (UTC) Received: by iaeo4 with SMTP id o4so3976390iae.13 for ; Thu, 16 Feb 2012 06:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=HaKNa9yoRqiMTAk4nRqy9xFNxD9EZlEjB3wu2Scs0SI=; b=ctQmZ27wMKb2Z6ZzvSqVWv48dLuF/x3FODecQppQJMwc72kJONV9mVhM8Wqz7SI0SP XeGmP9Mq3Zr6ARqDkvZeDv7oZqLghIG3Yy2ZBw3ecrihcC2hw3h0ZkbVcsA3+mSXtLl4 DsKA5i/0GjO3zdEz3g3tXetcr3IqZORU/wuyE= MIME-Version: 1.0 Received: by 10.42.80.3 with SMTP id t3mr2566099ick.49.1329404180004; Thu, 16 Feb 2012 06:56:20 -0800 (PST) Received: by 10.50.213.74 with HTTP; Thu, 16 Feb 2012 06:56:19 -0800 (PST) Date: Thu, 16 Feb 2012 15:56:19 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Add a module dependency on wlan for wtap X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:56:20 -0000 Hi, This patch makes wtap depend on wlan. Commit message: Add a module dependency on wlan. diff --git a/sys/dev/wtap/if_wtap_module.c b/sys/dev/wtap/if_wtap_module.c index d0108af..064cf98 100644 --- a/sys/dev/wtap/if_wtap_module.c +++ b/sys/dev/wtap/if_wtap_module.c @@ -184,3 +184,4 @@ static moduledata_t wtap_conf = { }; DECLARE_MODULE(wtap, wtap_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); +MODULE_DEPEND(wtap, wlan, 1, 1, 1); /* 802.11 media layer */ -- Monthadar Al Jaberi From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 15:18:15 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01BC6106566B for ; Thu, 16 Feb 2012 15:18:15 +0000 (UTC) (envelope-from jake@mischler.com) Received: from teaspoon.mischlersflorist.com (rrcs-72-45-221-198.nys.biz.rr.com [72.45.221.198]) by mx1.freebsd.org (Postfix) with ESMTP id ABA3A8FC16 for ; Thu, 16 Feb 2012 15:18:14 +0000 (UTC) Received: from [192.168.163.29] ([192.168.163.29]) by teaspoon.mischlersflorist.com (8.14.5/8.14.4) with ESMTP id q1GFIDqJ035826; Thu, 16 Feb 2012 10:18:13 -0500 (EST) (envelope-from jake@mischler.com) From: Dave Mischler To: Adrian Chadd Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Feb 2012 10:18:12 -0500 Message-ID: <1329405492.9116.6.camel@firkin.mischler.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jake@mischler.com List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:18:15 -0000 > Can you please compile up athstats (/usr/src/tools/tools/ath/athstats) > and make sure your kernel has the following options: > > options ATH_DEBUG > options AH_DEBUG > options ATH_DIAGAPI > > Then run scan for a while and use athstats to see what (if any) is > being received. As soon as I configured the interface I started getting this in the log. I assume that this means that an expected interrupt is not happening. Remember, the PCI mapping wasn't getting configured under 8.2; could something else the BIOS normally configures also be missing? Feb 16 14:12:54 halfpint kernel: wlan0: Ethernet address: 00:24:2c:5d:ed:55 Feb 16 14:13:06 halfpint kernel: ar5212StopDmaReceive: dma failed to stop in 10ms Feb 16 14:13:06 halfpint kernel: AR_CR=0x00000024 Feb 16 14:13:06 halfpint kernel: AR_DIAG_SW=0x00000020 Feb 16 14:13:06 halfpint kernel: ar5212StopDmaReceive: dma failed to stop in 10ms Feb 16 14:13:06 halfpint kernel: AR_CR=0x00000024 Feb 16 14:13:06 halfpint kernel: AR_DIAG_SW=0x00000020 Feb 16 14:13:07 halfpint kernel: ar5212StopDmaReceive: dma failed to stop in 10ms Feb 16 14:13:07 halfpint kernel: AR_CR=0x00000024 Feb 16 14:13:07 halfpint kernel: AR_DIAG_SW=0x00000020 From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 16:27:03 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7447C106564A for ; Thu, 16 Feb 2012 16:27:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id EADE78FC0C for ; Thu, 16 Feb 2012 16:27:02 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2049192wgb.31 for ; Thu, 16 Feb 2012 08:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I4BmKhQP2kzYbvfU/EZVFFDK38GIWVOnuApu5sifbMs=; b=WvkkEz0SmjUC7wvSz3Tu+57Vu/E2OYSuyhMn58Oem4WVU3FwarJX6EEz271Q2bO5yJ nRCRb1578kmEmQoF5IiERJRxofvVpMNQ7eXSa4RYjcIatvgmhIDuCMM7lEgBK0xj9c6x zEA91zSgxcbyS4gxKvHh/OzphVk4cnF9JGR8k= MIME-Version: 1.0 Received: by 10.216.131.215 with SMTP id m65mr1455991wei.54.1329409622011; Thu, 16 Feb 2012 08:27:02 -0800 (PST) Received: by 10.216.154.199 with HTTP; Thu, 16 Feb 2012 08:27:01 -0800 (PST) In-Reply-To: <1329405492.9116.6.camel@firkin.mischler.com> References: <1329405492.9116.6.camel@firkin.mischler.com> Date: Thu, 16 Feb 2012 08:27:01 -0800 Message-ID: From: Adrian Chadd To: jake@mischler.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:27:03 -0000 Hi, That means the RX DMA is getting "stuck" somehow. It normally doesn't matter, it happens in some instances anyway, so in itself it isn't a problem. It's doing that for each channel change. Just give me the output of "athstats -i ath0" after you've left it running for a minute or so. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 16:48:20 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FBF106577B for ; Thu, 16 Feb 2012 16:48:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7862E8FC16 for ; Thu, 16 Feb 2012 16:48:19 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2064469wgb.31 for ; Thu, 16 Feb 2012 08:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dnb91KVe5O4XcYVbJC4yLBT/RKPh7Z48JnBkPrpzkxY=; b=oY4jdSMdZR8TGp/ctepvfQwL0cXl93/n8PsLtfFDzJ7TowkwRhfqSLYYhBr1ocEn3D DLoITr6l6jpqC4jsNdqtAAD7Vv1mX7xwvG7+OUfTm3dySpKRmjiFT5BmoItbZXQ58TZG 2YySu9ArIQUYXHxKUNHqJzcn7jx9uiFfA/rNI= MIME-Version: 1.0 Received: by 10.216.138.36 with SMTP id z36mr1559473wei.22.1329410898415; Thu, 16 Feb 2012 08:48:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Thu, 16 Feb 2012 08:48:18 -0800 (PST) In-Reply-To: References: Date: Thu, 16 Feb 2012 08:48:18 -0800 X-Google-Sender-Auth: bV9tnhWz0Bv-QL_xiyrsHPs5Cgg Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org Subject: Re: Add a module dependency on wlan for wtap X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:48:20 -0000 Committed in r231828. Thanks! adrian On 16 February 2012 06:56, Monthadar Al Jaberi wrote: > Hi, > > This patch makes wtap depend on wlan. > > Commit message: Add a module dependency on wlan. > > diff --git a/sys/dev/wtap/if_wtap_module.c b/sys/dev/wtap/if_wtap_module.= c > index d0108af..064cf98 100644 > --- a/sys/dev/wtap/if_wtap_module.c > +++ b/sys/dev/wtap/if_wtap_module.c > @@ -184,3 +184,4 @@ static moduledata_t wtap_conf =3D { > =A0}; > > =A0DECLARE_MODULE(wtap, wtap_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > +MODULE_DEPEND(wtap, wlan, 1, 1, 1); =A0 =A0 =A0 =A0 =A0 =A0/* 802.11 med= ia layer */ > > > -- > Monthadar Al Jaberi > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.or= g" From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 16:58:42 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BFAF106564A for ; Thu, 16 Feb 2012 16:58:42 +0000 (UTC) (envelope-from jake@mischler.com) Received: from teaspoon.mischlersflorist.com (rrcs-72-45-221-198.nys.biz.rr.com [72.45.221.198]) by mx1.freebsd.org (Postfix) with ESMTP id AD4008FC15 for ; Thu, 16 Feb 2012 16:58:41 +0000 (UTC) Received: from [192.168.163.29] ([192.168.163.29]) by teaspoon.mischlersflorist.com (8.14.5/8.14.4) with ESMTP id q1GGwdBj041845; Thu, 16 Feb 2012 11:58:40 -0500 (EST) (envelope-from jake@mischler.com) From: Dave Mischler To: Adrian Chadd Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Feb 2012 11:58:39 -0500 Message-ID: <1329411519.10173.2.camel@firkin.mischler.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jake@mischler.com List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:58:42 -0000 > output of "athstats -i ath0" after you've left it > running for a minute or so much more than a minute: 740 data frames transmit 1M current transmit rate -0/+0 TDMA slot adjust (usecs, smoothed) -96 rx noise floor 740 tx frames through raw api 741 ANI enabled OFDM weak signal detect 741 ANI disabled CCK weak signal threshold Antenna profile: From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 17:20:29 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48B8C1065757 for ; Thu, 16 Feb 2012 17:20:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CE9628FC08 for ; Thu, 16 Feb 2012 17:20:28 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2087102wgb.31 for ; Thu, 16 Feb 2012 09:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SH5HTtmUf0PSodJD3PMfdPPQ6nVtoxOkWGaq5sXc2F4=; b=EXSMSE1+t/S3gcYGZQNl4/qgPCALPT3RieF75lHjRgJEQjKprJzUfIHL3hFuYmfCnK jvjqomtYmxJ/xtVVEze+9EyKUhu0EqtoQvczlTZRXJHyNbix8wW6NhER0spO0oRSEZ/+ uh/1mle9ehxH0+iEiOY6jrovBwZBiRxXrMuwY= MIME-Version: 1.0 Received: by 10.216.134.37 with SMTP id r37mr1588384wei.38.1329412827719; Thu, 16 Feb 2012 09:20:27 -0800 (PST) Received: by 10.216.154.199 with HTTP; Thu, 16 Feb 2012 09:20:27 -0800 (PST) In-Reply-To: <1329411519.10173.2.camel@firkin.mischler.com> References: <1329411519.10173.2.camel@firkin.mischler.com> Date: Thu, 16 Feb 2012 09:20:27 -0800 Message-ID: From: Adrian Chadd To: jake@mischler.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:20:29 -0000 .. wait a sec, that's _all_ it showed you? Did you run this with a kernel w/ all the debug/diagnostic options compiled= in? Adrian On 16 February 2012 08:58, Dave Mischler wrote: > >> output of "athstats -i ath0" after you've left it >> running for a minute or so > > much more than a minute: > > 740 =A0 =A0 =A0 =A0 =A0data frames transmit > 1M =A0 =A0 =A0 =A0 =A0 current transmit rate > -0/+0 =A0 =A0 =A0 =A0TDMA slot adjust (usecs, smoothed) > -96 =A0 =A0 =A0 =A0 =A0rx noise floor > 740 =A0 =A0 =A0 =A0 =A0tx frames through raw api > 741 =A0 =A0 =A0 =A0 =A0ANI enabled OFDM weak signal detect > 741 =A0 =A0 =A0 =A0 =A0ANI disabled CCK weak signal threshold > Antenna profile: > > From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 17:52:29 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFB941065677 for ; Thu, 16 Feb 2012 17:52:29 +0000 (UTC) (envelope-from jake@mischler.com) Received: from teaspoon.mischlersflorist.com (rrcs-72-45-221-198.nys.biz.rr.com [72.45.221.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2008FC16 for ; Thu, 16 Feb 2012 17:52:28 +0000 (UTC) Received: from [192.168.163.29] ([192.168.163.29]) by teaspoon.mischlersflorist.com (8.14.5/8.14.4) with ESMTP id q1GHqRhd045060; Thu, 16 Feb 2012 12:52:28 -0500 (EST) (envelope-from jake@mischler.com) From: Dave Mischler To: Adrian Chadd Content-Type: multipart/mixed; boundary="=-0aX44wfQnNIqMIIZwX00" Date: Thu, 16 Feb 2012 12:52:27 -0500 Message-ID: <1329414747.10173.10.camel@firkin.mischler.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jake@mischler.com List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:52:29 -0000 --=-0aX44wfQnNIqMIIZwX00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > .. wait a sec, that's _all_ it showed you? > > Did you run this with a kernel w/ all the debug/diagnostic options compiled= > in? I believe so. I included options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI I attached my kernel config file in case you want to see it. I also attached the output of sysctl dev.ath.0 in case that proves interesting. --=-0aX44wfQnNIqMIIZwX00 Content-Disposition: attachment; filename="HALFPINT" Content-Type: text/plain; name="HALFPINT"; charset="us-ascii" Content-Transfer-Encoding: 7bit # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.562 2012/01/31 19:38:18 jimharris Exp $ cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options MAC # TrustedBSD MAC Framework #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use this instead: options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device eisa device pci # Floppy drives device fdc # ATA controllers device ahci # AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA device siis # SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device esp # AMD Am53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 device isci # Intel C600 SAS controller # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) device ses # Enclosure Services (SES and SAF-TE) device ctl # CAM Target Layer # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID device tws # LSI 3ware 9750 SATA+SAS 6Gb/s RAID controller # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da device puc # Multi I/O cards and multi-channel UARTs # PCI Ethernet NICs. device bxe # Broadcom BCM57710/BCM57711/BCM57711E 10Gb Ethernet device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit Family device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device ti # Alteon Networks Tigon I/II gigabit Ethernet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device ae # Attansic/Atheros L2 FastEthernet device age # Attansic/Atheros L1 Gigabit Ethernet device alc # Atheros AR8131/AR8132 Ethernet device ale # Atheros AR8121/AR8113/AR8114 Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sge # Silicon Integrated Systems SiS190/191 device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device vte # DM&P Vortex86 RDC R6040 Fast Ethernet device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros NIC's device ath_pci # Atheros pci/cardbus glue device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath #device bwi # Broadcom BCM430x/BCM431x wireless NICs. #device bwn # Broadcom BCM43xx wireless NICs. device ipw # Intel 2100 wireless NICs. device iwi # Intel 2200BG/2225BG/2915ABG wireless NICs. device iwn # Intel 4965/1000/5000/6000 wireless NICs. device malo # Marvell Libertas wireless NICs. device mwl # Marvell 88W8363 802.11n wireless NICs. device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. device wpi # Intel 3945ABG wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices (needs netgraph) device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player # USB Serial devices device u3g # USB-based 3G modems (Option, Huawei, Sierra) device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet device udav # Davicom DM9601E USB # USB Wireless device rum # Ralink Technology RT2501USB wireless NICs device run # Ralink Technology RT2700/RT2800/RT3000 NICs. device uath # Atheros AR5523 wireless NICs device upgt # Conexant/Intersil PrismGT wireless NICs. device ural # Ralink Technology RT2500USB wireless NICs device urtw # Realtek RTL8187B/L wireless NICs device zyd # ZyDAS zd1211/zd1211b wireless NICs # FireWire support device firewire # FireWire bus code # sbp(4) works for some systems but causes boot failure on others #device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons # Sound support device sound # Generic sound driver (required) device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_uaudio # USB Audio device snd_via8233 # VIA VT8233x Audio # MMC/SD device mmc # MMC/SD bus device mmcsd # MMC/SD memory card device sdhci # Generic PCI SD Host Controller --=-0aX44wfQnNIqMIIZwX00 Content-Disposition: attachment; filename="sysctl.dev.ath0" Content-Type: text/plain; name="sysctl.dev.ath0"; charset="us-ascii" Content-Transfer-Encoding: 7bit dev.ath.0.%desc: Atheros 5424/2424 dev.ath.0.%driver: ath dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.RP02.PXS2 dev.ath.0.%pnpinfo: vendor=0x168c device=0x001c subvendor=0x105b subdevice=0xe00d class=0x020000 dev.ath.0.%parent: pci3 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.sample_stats: 0 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 101 dev.ath.0.debug: 0 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.hardled: 0 dev.ath.0.led_net_pin: -1 dev.ath.0.led_pwr_pin: -1 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 1 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.rfsilent: 1 dev.ath.0.rfkill: 1 dev.ath.0.txagg: 0 dev.ath.0.forcebstuck: 0 dev.ath.0.intmit: 1 dev.ath.0.monpass: 24 dev.ath.0.hwq_limit: 2 dev.ath.0.tid_hwq_lo: 2 dev.ath.0.tid_hwq_hi: 4 dev.ath.0.clear_stats: 0 dev.ath.0.stats.ast_watchdog: 0 dev.ath.0.stats.ast_hardware: 0 dev.ath.0.stats.ast_bmiss: 0 dev.ath.0.stats.ast_bmiss_phantom: 0 dev.ath.0.stats.ast_bstuck: 0 dev.ath.0.stats.ast_rxorn: 0 dev.ath.0.stats.ast_rxeol: 0 dev.ath.0.stats.ast_txurn: 0 dev.ath.0.stats.ast_mib: 0 dev.ath.0.stats.ast_intrcoal: 0 dev.ath.0.stats.ast_tx_packets: 1228 dev.ath.0.stats.ast_tx_mgmt: 0 dev.ath.0.stats.ast_tx_discard: 0 dev.ath.0.stats.ast_tx_qstop: 0 dev.ath.0.stats.ast_tx_encap: 0 dev.ath.0.stats.ast_tx_nonode: 0 dev.ath.0.stats.ast_tx_nombuf: 0 dev.ath.0.stats.ast_tx_nomcl: 0 dev.ath.0.stats.ast_tx_linear: 0 dev.ath.0.stats.ast_tx_nodata: 0 dev.ath.0.stats.ast_tx_busdma: 0 dev.ath.0.stats.ast_tx_xretries: 0 dev.ath.0.stats.ast_tx_fifoerr: 0 dev.ath.0.stats.ast_tx_filtered: 0 dev.ath.0.stats.ast_tx_shortretry: 0 dev.ath.0.stats.ast_tx_longretry: 0 dev.ath.0.stats.ast_tx_badrate: 0 dev.ath.0.stats.ast_tx_noack: 0 dev.ath.0.stats.ast_tx_rts: 0 dev.ath.0.stats.ast_tx_cts: 0 dev.ath.0.stats.ast_tx_shortpre: 0 dev.ath.0.stats.ast_tx_altrate: 0 dev.ath.0.stats.ast_tx_protect: 0 dev.ath.0.stats.ast_tx_ctsburst: 0 dev.ath.0.stats.ast_tx_ctsext: 0 dev.ath.0.stats.ast_rx_nombuf: 0 dev.ath.0.stats.ast_rx_busdma: 0 dev.ath.0.stats.ast_rx_orn: 0 dev.ath.0.stats.ast_rx_crcerr: 0 dev.ath.0.stats.ast_rx_fifoerr: 0 dev.ath.0.stats.ast_rx_badcrypt: 0 dev.ath.0.stats.ast_rx_badmic: 0 dev.ath.0.stats.ast_rx_phyerr: 0 dev.ath.0.stats.ast_rx_tooshort: 0 dev.ath.0.stats.ast_rx_toobig: 0 dev.ath.0.stats.ast_rx_packets: 0 dev.ath.0.stats.ast_rx_mgt: 0 dev.ath.0.stats.ast_rx_ctl: 0 dev.ath.0.stats.ast_be_xmit: 0 dev.ath.0.stats.ast_be_nombuf: 0 dev.ath.0.stats.ast_per_cal: 0 dev.ath.0.stats.ast_per_calfail: 0 dev.ath.0.stats.ast_per_rfgain: 0 dev.ath.0.stats.ast_rate_calls: 0 dev.ath.0.stats.ast_rate_raise: 0 dev.ath.0.stats.ast_rate_drop: 0 dev.ath.0.stats.ast_ant_defswitch: 0 dev.ath.0.stats.ast_ant_txswitch: 0 dev.ath.0.stats.ast_cabq_xmit: 0 dev.ath.0.stats.ast_cabq_busy: 0 dev.ath.0.stats.ast_tx_raw: 5053 dev.ath.0.stats.ast_ff_txok: 0 dev.ath.0.stats.ast_ff_txerr: 0 dev.ath.0.stats.ast_ff_rx: 0 dev.ath.0.stats.ast_ff_flush: 0 dev.ath.0.stats.ast_tx_qfull: 0 dev.ath.0.stats.ast_tx_nobuf: 0 dev.ath.0.stats.ast_tdma_update: 0 dev.ath.0.stats.ast_tdma_timers: 0 dev.ath.0.stats.ast_tdma_tsf: 0 dev.ath.0.stats.ast_tdma_ack: 0 dev.ath.0.stats.ast_tx_raw_fail: 0 dev.ath.0.stats.ast_tx_nofrag: 0 dev.ath.0.stats.ast_be_missed: 0 dev.ath.0.stats.ast_ani_cal: 0 dev.ath.0.stats.ast_rx_agg: 0 dev.ath.0.stats.ast_rx_halfgi: 0 dev.ath.0.stats.ast_rx_2040: 0 dev.ath.0.stats.ast_rx_pre_crc_err: 0 dev.ath.0.stats.ast_rx_post_crc_err: 0 dev.ath.0.stats.ast_rx_decrypt_busy_err: 0 dev.ath.0.stats.ast_rx_hi_rx_chain: 0 dev.ath.0.stats.ast_tx_htprotect: 0 dev.ath.0.stats.ast_rx_hitqueueend: 0 dev.ath.0.stats.ast_tx_timeout: 0 dev.ath.0.stats.ast_tx_cst: 0 dev.ath.0.stats.ast_tx_xtxop: 0 dev.ath.0.stats.ast_tx_timerexpired: 0 dev.ath.0.stats.ast_tx_desccfgerr: 0 dev.ath.0.stats.ast_tx_swretries: 0 dev.ath.0.stats.ast_tx_swretrymax: 0 dev.ath.0.stats.ast_tx_data_underrun: 0 dev.ath.0.stats.ast_tx_delim_underrun: 0 dev.ath.0.stats.ast_tx_aggr_failall: 0 dev.ath.0.stats.ast_tx_aggr_ok: 0 dev.ath.0.stats.ast_tx_aggr_fail: 0 dev.ath.0.stats.ast_rx_intr: 0 dev.ath.0.stats.ast_tx_intr: 0 dev.ath.0.stats.rx_phy_err.0: 0 dev.ath.0.stats.rx_phy_err.1: 0 dev.ath.0.stats.rx_phy_err.2: 0 dev.ath.0.stats.rx_phy_err.3: 0 dev.ath.0.stats.rx_phy_err.4: 0 dev.ath.0.stats.rx_phy_err.5: 0 dev.ath.0.stats.rx_phy_err.6: 0 dev.ath.0.stats.rx_phy_err.7: 0 dev.ath.0.stats.rx_phy_err.8: 0 dev.ath.0.stats.rx_phy_err.9: 0 dev.ath.0.stats.rx_phy_err.10: 0 dev.ath.0.stats.rx_phy_err.11: 0 dev.ath.0.stats.rx_phy_err.12: 0 dev.ath.0.stats.rx_phy_err.13: 0 dev.ath.0.stats.rx_phy_err.14: 0 dev.ath.0.stats.rx_phy_err.15: 0 dev.ath.0.stats.rx_phy_err.16: 0 dev.ath.0.stats.rx_phy_err.17: 0 dev.ath.0.stats.rx_phy_err.18: 0 dev.ath.0.stats.rx_phy_err.19: 0 dev.ath.0.stats.rx_phy_err.20: 0 dev.ath.0.stats.rx_phy_err.21: 0 dev.ath.0.stats.rx_phy_err.22: 0 dev.ath.0.stats.rx_phy_err.23: 0 dev.ath.0.stats.rx_phy_err.24: 0 dev.ath.0.stats.rx_phy_err.25: 0 dev.ath.0.stats.rx_phy_err.26: 0 dev.ath.0.stats.rx_phy_err.27: 0 dev.ath.0.stats.rx_phy_err.28: 0 dev.ath.0.stats.rx_phy_err.29: 0 dev.ath.0.stats.rx_phy_err.30: 0 dev.ath.0.stats.rx_phy_err.31: 0 dev.ath.0.stats.rx_phy_err.32: 0 dev.ath.0.stats.rx_phy_err.33: 0 dev.ath.0.stats.rx_phy_err.34: 0 dev.ath.0.stats.rx_phy_err.35: 0 dev.ath.0.stats.rx_phy_err.36: 0 dev.ath.0.stats.rx_phy_err.37: 0 dev.ath.0.stats.rx_phy_err.38: 0 dev.ath.0.stats.rx_phy_err.39: 0 dev.ath.0.stats.rx_phy_err.40: 0 dev.ath.0.stats.rx_phy_err.41: 0 dev.ath.0.stats.rx_phy_err.42: 0 dev.ath.0.stats.rx_phy_err.43: 0 dev.ath.0.stats.rx_phy_err.44: 0 dev.ath.0.stats.rx_phy_err.45: 0 dev.ath.0.stats.rx_phy_err.46: 0 dev.ath.0.stats.rx_phy_err.47: 0 dev.ath.0.stats.rx_phy_err.48: 0 dev.ath.0.stats.rx_phy_err.49: 0 dev.ath.0.stats.rx_phy_err.50: 0 dev.ath.0.stats.rx_phy_err.51: 0 dev.ath.0.stats.rx_phy_err.52: 0 dev.ath.0.stats.rx_phy_err.53: 0 dev.ath.0.stats.rx_phy_err.54: 0 dev.ath.0.stats.rx_phy_err.55: 0 dev.ath.0.stats.rx_phy_err.56: 0 dev.ath.0.stats.rx_phy_err.57: 0 dev.ath.0.stats.rx_phy_err.58: 0 dev.ath.0.stats.rx_phy_err.59: 0 dev.ath.0.stats.rx_phy_err.60: 0 dev.ath.0.stats.rx_phy_err.61: 0 dev.ath.0.stats.rx_phy_err.62: 0 dev.ath.0.stats.rx_phy_err.63: 0 dev.ath.0.hal.debug: 0 dev.ath.0.hal.ar5416_biasadj: 0 dev.ath.0.hal.dma_brt: 2 dev.ath.0.hal.sw_brt: 10 dev.ath.0.hal.swba_backoff: 0 dev.ath.0.hal.force_full_reset: 0 dev.ath.0.hal.serialise_reg_war: 0 dev.ath.0.wake: 0 --=-0aX44wfQnNIqMIIZwX00-- From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 19:01:25 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEB8D106566C for ; Thu, 16 Feb 2012 19:01:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7356D8FC17 for ; Thu, 16 Feb 2012 19:01:25 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2148209wgb.31 for ; Thu, 16 Feb 2012 11:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1b7CR0zWlfO59BG2J8qpW9vzqHLeTv5ZVvGKH5oeyE4=; b=JeJ1N3wwBKyUAzQjcph7inARTwMlqYl72Zi6jSQDkC+xreKbmoFdpeeTRi85thvo8K eXC5E5XNCcwRk5Vl6MIwaCTfKJZCOIswnxqZpGtFVMhwsZ9J76Tq3v+7EYXQVWY7mfRE E9BRhoqd5diuGzVvS+DC80Bi4G/jDq+ygkUQ4= MIME-Version: 1.0 Received: by 10.216.134.87 with SMTP id r65mr1814595wei.46.1329418884328; Thu, 16 Feb 2012 11:01:24 -0800 (PST) Received: by 10.216.154.199 with HTTP; Thu, 16 Feb 2012 11:01:24 -0800 (PST) In-Reply-To: <1329414747.10173.10.camel@firkin.mischler.com> References: <1329414747.10173.10.camel@firkin.mischler.com> Date: Thu, 16 Feb 2012 11:01:24 -0800 Message-ID: From: Adrian Chadd To: jake@mischler.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:01:25 -0000 .. that's odd. There's nothing to indicate it's ever received anything. Can you please submit a PR for this? Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 16 20:49:16 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9785A106566C for ; Thu, 16 Feb 2012 20:49:16 +0000 (UTC) (envelope-from jake@mischler.com) Received: from teaspoon.mischlersflorist.com (rrcs-72-45-221-198.nys.biz.rr.com [72.45.221.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDA78FC0A for ; Thu, 16 Feb 2012 20:49:15 +0000 (UTC) Received: from [192.168.163.29] ([192.168.163.29]) by teaspoon.mischlersflorist.com (8.14.5/8.14.4) with ESMTP id q1GKnEvr055646; Thu, 16 Feb 2012 15:49:14 -0500 (EST) (envelope-from jake@mischler.com) From: Dave Mischler To: Adrian Chadd Content-Type: text/plain Date: Thu, 16 Feb 2012 15:49:14 -0500 Message-ID: <1329425354.10757.1.camel@firkin.mischler.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jake@mischler.com List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:49:16 -0000 kern/165212 From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 02:47:41 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1DA5106564A for ; Fri, 17 Feb 2012 02:47:41 +0000 (UTC) (envelope-from jake@mischler.com) Received: from teaspoon.mischlersflorist.com (rrcs-72-45-221-198.nys.biz.rr.com [72.45.221.198]) by mx1.freebsd.org (Postfix) with ESMTP id 893408FC08 for ; Fri, 17 Feb 2012 02:47:41 +0000 (UTC) Received: from [192.168.254.253] ([192.168.254.253]) by teaspoon.mischlersflorist.com (8.14.5/8.14.4) with ESMTP id q1H2ldV2077092; Thu, 16 Feb 2012 21:47:39 -0500 (EST) (envelope-from jake@mischler.com) From: Dave Mischler To: Adrian Chadd Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Feb 2012 21:47:38 -0500 Message-ID: <1329446858.92200.2.camel@barrel.mischler.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jake@mischler.com List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:47:42 -0000 Does this problem intersect, or maybe match completely? kern/98162: [request] AcerHK driver port needed for enabling WiFi on Acer's laptops From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 06:58:54 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8032D1065675 for ; Fri, 17 Feb 2012 06:58:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14DD48FC12 for ; Fri, 17 Feb 2012 06:58:53 +0000 (UTC) Received: by werm13 with SMTP id m13so2609557wer.13 for ; Thu, 16 Feb 2012 22:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v8L3kQN3d4TS/1yWIpRE/yPqKemZI4b1lkfxWF2IbN0=; b=RzFafjRCRDpPbaf1lqLWGSUZfgutPOFTM+nE5LvibBs34yT2pL5YukBThtlh+yZl/i KK91IiOBuRD/zH7Ux0HoptbjknAV6cWR0OrYD3spAQXL0P3j94ljtgZ9ICYbKFZs7F+F ek4wLHQxRX6PwRxtA6wUj9HZES/+KpxS1AM+Q= MIME-Version: 1.0 Received: by 10.180.95.105 with SMTP id dj9mr1481778wib.18.1329461933029; Thu, 16 Feb 2012 22:58:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Thu, 16 Feb 2012 22:58:52 -0800 (PST) In-Reply-To: <1328727803.90839.15.camel@firkin.mischler.com> References: <1328727803.90839.15.camel@firkin.mischler.com> Date: Thu, 16 Feb 2012 22:58:52 -0800 X-Google-Sender-Auth: Fqtf9vcpBZoFOX7G9lCghSgIw-Q Message-ID: From: Adrian Chadd To: jake@mischler.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: No WiFi on Acer Aspire One 751h X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 06:58:54 -0000 I've found an AR5BHB63 here (and I have AR9285's here); I'll try this out for you tomorrow in my eeepc. Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 07:23:45 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40BA31065672; Fri, 17 Feb 2012 07:23:45 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 180218FC13; Fri, 17 Feb 2012 07:23:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1H7NiE4066551; Fri, 17 Feb 2012 07:23:44 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1H7NiHd066547; Fri, 17 Feb 2012 07:23:44 GMT (envelope-from adrian) Date: Fri, 17 Feb 2012 07:23:44 GMT Message-Id: <201202170723.q1H7NiHd066547@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/165220: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 07:23:45 -0000 Synopsis: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Feb 17 07:23:32 UTC 2012 Responsible-Changed-Why: Change http://www.freebsd.org/cgi/query-pr.cgi?pr=165220 From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 07:26:46 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A0231065670 for ; Fri, 17 Feb 2012 07:26:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A57498FC1B for ; Fri, 17 Feb 2012 07:26:45 +0000 (UTC) Received: by werm13 with SMTP id m13so2624375wer.13 for ; Thu, 16 Feb 2012 23:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=PPwA0ir0WzofFFm91RD6ia7sfPE3V/MldA4KqXQ4LBs=; b=CSN2noqzo+U2FpxAOOmImdTZ8ywQIyRFl/yzoe0IMQwO9p9dORBLDiNQlhJ3Icb97W YkGTiWgELw8wK2+s52RsnEU3LorOtxQujjaudQ9Tvb5x0bqcfrv1LvDmeCWdJS8RqZH9 c9cLx1dJVfQycZANEUWPx1JeAlVokTyn+yYyA= MIME-Version: 1.0 Received: by 10.180.96.8 with SMTP id do8mr1612618wib.21.1329463604538; Thu, 16 Feb 2012 23:26:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Thu, 16 Feb 2012 23:26:44 -0800 (PST) Date: Thu, 16 Feb 2012 23:26:44 -0800 X-Google-Sender-Auth: R_J9Z-PYtsfsGJ3TdM0uH8bUxIw Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ath fixes in -HEAD: squish (most) of the ath_rx_tasklet warnings X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 07:26:46 -0000 Hi, I've just rejiggled the reset/channel change path to (mostly) properly drain and pause the ath taskqueue when doing a reset/channel change. This has quietened most of the overlapping RX completions during reset - they seemed to have been occuring because an RX interrupt was coming in or had just come in before a reset. Please test the latest -HEAD and let me know if there are any issues. Thanks! Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 08:42:51 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9AA106566C for ; Fri, 17 Feb 2012 08:42:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 209028FC17 for ; Fri, 17 Feb 2012 08:42:50 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2157200wib.13 for ; Fri, 17 Feb 2012 00:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=nUugMZTmgIGGfmXAcxugGd35iER8lByWxCYjvkGpqcU=; b=qw8lPLUBD4Sa8dImcR4jwxHXw8jtr8/HrCbYyFY/296eg1sqD9SZZ6M4XzMdbFmhyX oiscWQ0SRAPVaRjc3uyy6zuRPS7KP/kAX5i5Y30meo1Dnjp2WeAl64LOQBQY0Eh7OUcf AOpr9x830Z7P4cdXJw1cxEaJSsh8QqzKxidt0= MIME-Version: 1.0 Received: by 10.180.95.105 with SMTP id dj9mr2002938wib.18.1329468169997; Fri, 17 Feb 2012 00:42:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Fri, 17 Feb 2012 00:42:49 -0800 (PST) Date: Fri, 17 Feb 2012 00:42:49 -0800 X-Google-Sender-Auth: JEz1vyo9WfiVkC8Cb1oWWG68rX4 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: athstats in -HEAD now works again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:42:51 -0000 Hi, I've unbroken athstats in -HEAD. It turns out statfoo was coded up assuming <= 127 statistics would be available and I had added a few too many stats to it. Things work fine now! So back to debugging y'all can go. From Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 18:23:34 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCAB1065675; Fri, 17 Feb 2012 18:23:34 +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 6A8648FC1B; Fri, 17 Feb 2012 18:23:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1HINY6X018132; Fri, 17 Feb 2012 18:23:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1HINY90018128; Fri, 17 Feb 2012 18:23:34 GMT (envelope-from linimon) Date: Fri, 17 Feb 2012 18:23:34 GMT Message-Id: <201202171823.q1HINY90018128@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165021: [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:23:34 -0000 Synopsis: [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 17 18:23:14 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=165021 From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 17 20:26:14 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423D11065670; Fri, 17 Feb 2012 20:26:14 +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 15F838FC0C; Fri, 17 Feb 2012 20:26:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1HKQDci029347; Fri, 17 Feb 2012 20:26:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1HKQD33029343; Fri, 17 Feb 2012 20:26:13 GMT (envelope-from linimon) Date: Fri, 17 Feb 2012 20:26:13 GMT Message-Id: <201202172026.q1HKQD33029343@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165214: [ieee80211] Kernel panic in ieee80211_output.c:2505 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:26:14 -0000 Old Synopsis: Kernel panic in ieee80211_output.c:2505 New Synopsis: [ieee80211] Kernel panic in ieee80211_output.c:2505 Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 17 20:25:58 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165214 From owner-freebsd-wireless@FreeBSD.ORG Sat Feb 18 09:30:27 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 728E7106564A for ; Sat, 18 Feb 2012 09:30:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 06E358FC12 for ; Sat, 18 Feb 2012 09:30:26 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3110875wib.13 for ; Sat, 18 Feb 2012 01:30:26 -0800 (PST) Received-SPF: pass (google.com: domain of adrian.chadd@gmail.com designates 10.180.93.4 as permitted sender) client-ip=10.180.93.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adrian.chadd@gmail.com designates 10.180.93.4 as permitted sender) smtp.mail=adrian.chadd@gmail.com; dkim=pass header.i=adrian.chadd@gmail.com Received: from mr.google.com ([10.180.93.4]) by 10.180.93.4 with SMTP id cq4mr2556246wib.21.1329557426014 (num_hops = 1); Sat, 18 Feb 2012 01:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Hk9qx2dTL5BEdLyvHaT6QYJ+PP2pZLIrruc8a7njRr0=; b=TOI5TWuC37r63MHoD2twYty0+ssCpOhlX/PaMl1hYQHxjRx1/xiVs1Ad/KnuvGFO0C z2F0UuO5WZCjDIDCAyiisZVQbkExhmByKqg2/GXHdVArOHaj2TtD9pzje3t0oKlQgVHp 6p0GInnYeP4JZS3H/LDdcii4ulzzfwDsKQPig= MIME-Version: 1.0 Received: by 10.180.93.4 with SMTP id cq4mr2174420wib.21.1329557425968; Sat, 18 Feb 2012 01:30:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Sat, 18 Feb 2012 01:30:25 -0800 (PST) Date: Sat, 18 Feb 2012 01:30:25 -0800 X-Google-Sender-Auth: iDwGnv6_ZY1E_3ZcDH2qK1s7Yh8 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ath/net80211 in -HEAD: please test! X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 09:30:27 -0000 Hi all, I'd really appreciate it if -HEAD ath/net80211 could get some testing (complete with lock/witness debugging enabled). I've made a few changes: * tried to close the vap->iv_bss races that may be occuring, for reasons I'll contiune trying to trace down; * Fixed RX interrupts overlapping with reset/channel change; * Added a lock assert in ath_newstate() to ensure the lock is still held throughout the call and after the call to the vap newstate function. I'm going to do some more locking work in the next few days to try and capture if/where the locking and refcounting violations are occuring. On the plus side, I don't have any odd net80211 panics in the lab any longer (thanks to all of the test/blocking traffic around me!) but on the minus side, I'm not at all convinced I've conclusively nailed the issues. So I'd really appreciate it if people would test this out in both station and access point. (And ibss/mesh, if you're that way inclined.) Yes, I know TDMA is still broken - it's on my near term TODO list, after more 11n fixes. I'll try to test things as best I can but you all can break things in weird/wonderful ways. I'd appreciate it. Really. Appreciate. :-) Thanks! Adrian