Re: [802.11s] mesh_forward() and (re)-encapsulating frames
On Tue, Jul 9, 2013 at 1:33 AM, Adrian Chadd adr...@freebsd.org wrote: On 8 July 2013 16:00, Monthadar Al Jaberi montha...@gmail.com wrote: * What's supposed to happen to the mesh sequence number? Mesh sequence number should be decreased with 1. Decreased or increased by one? I can see the mesh TTL being decremented by one. You are correct about TTL, my mistake. but mesh sequence number should be the same when forwarded. This is to avoid loops, so each meshSTA that receives this will remember the seq. no. and discard it if it receives it a again. * What's supposed to happen to the QoS header sequence number? (ie, the sequence number space between the two peers) This is as if the frame is being sent originally from source mesh. As any other frame. The mesh header comes _after_ the QoS header, right? So there's both? Look at this picture http://tr.docdat.com/pars_docs/refs/29/28671/28671_html_m4e2b3a71.png. I am not tottally fimilar with QoS, but I think you can discard it too, and only queue frame on correct AC queue. Mesh control header is in the frame playload and it should not be discarded. * What's supposed to happen for encryption? is it end-to-end encryption, or hop-by-hop encryption? I havn't worked with encryption, others could have better knowldge. But to my knowldge it is hop-by-hop. Right. That's a bit sucky from a security perspective, but sure. It makes it much easier to do hardware encryption and such. Can I just get away with extending ieee80211_encap() to take a meshcntl header and if I provide it, just use that instead of calculating the contents in ieee80211_encap()? I think that'll be good enough to get around the data path requirements and we can get back on track getting this stuff ready for 802.11n and encryption. That is good enough, but how do you intend to save the mesh ctrl header to be associated with correct frame when it is in powersave? That's the real question, isn't it? Same with AMSDU/fast-frames support, etc. Mesh ctrl header is part the frame payload, so why not keep it there? That way you only decap the 802.11 header. The header could be either 3 or 4 address frames. But lets get something done first, and your solution is good enough for now :) Well, the evil adrian here thinks we could just decap the 802.11 bit and store it as a frame that has mesh + 802.3. But then we'll have to special case things again, and I'm not really interested in having three cases in the code (802.3, 802.11, 802.11s.) It'll make things difficult to juggle. That's why I'm thinking we can just store the mesh information in an mbuf tag and reuse it when we need to. But what I really need to understand is all of the crazy logic and use-cases for the meshgate stuff. I don't have a clear picture of it in my head - admittedly I haven't sat down and _done_ the hard work to get a clear picture in my head. But I'll get there. Thus far: * When it's time to transmit it in ath(4) (ie, software queued in the driver, for A-MPDU or otherwise) then it's 802.11 + 802.11s + 802.3. That's easy, I don't have to care about it. * If it's coming in from if_transmit (ie, someone's queued an ethernet frame) then it'll be encapsulated as per normal. I don't have to care; that case is already taken care of. * If it's coming in from the receive path and we're retransmitting - it's already an 802.11 + 802.11s + 802.3 frame. We absolutely need to re-encapsulate the 802.11 bit before we queue it (because that's needed for the encryption handling, aggregation, etc.) We (at least now) won't have to deal with getting an 802.11s + 802.3 only frame this way. So, if we assume we _always_ get an 802.11+802.11s+802.3 frame, we can just do this: + re-encapsulate the 802.11 part + then if we need to do ampdu/amsdu/powersave staging, stage it as an 802.11 frame, rather than an 802.3 frame. .. but, the fast-frames code assumes it's getting two un-encapsulated 802.3 frames to assemble. And I think the amsdu support I'm going to write will assume the same thing. So the inefficient-but-sane thing to do may be this: + store the mesh control header as an mbuf tag - it's not that big, so I don't mind + strip the 802.11 bits + store the frame as an 802.3 frame - this then gets queued in the staging / powersave queues as per normal + then, when we pass it again through ieee80211_encap() to send it out, we restore the mesh control header and push it out. HOWEVER - this is why things are hairy - if we're going to encapsulate a frame for say, AMSDU or fast-frames support, we need to ensure that all the frames actually end up going to the same meshnode destination, as we only get one 802.11 header here. (ie, the AMSDU/FF support stores multiple 802.3 frames, not multiple 802.11 frames.) So we have to be careful when aggregating things. I don't know the right thing to do there except to be really paranoid and don't aggregate if
Not work ATH (AR9285) after update
Hello, i'm horrible news, after update my notebook not nave wi-fi :( full update system, build and install world and kernel. # uname -a FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253562: Tue Jul 23 14:44:07 MSK 2013 root@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 # grep ATH /usr/src/sys/amd64/conf/W_BOOK options ATH_ENABLE_11N options ATH_DEBUG options ATH_DIAGAPI ath0@pci0:3:0:0:class=0x028000 card=0x1a891a3b chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9285 Wireless Network Adapter (PCI-Express)' class = network # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:25:d3:7b:94:87 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8c43UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:25:d3:7b:94:87 inet6 fe80::225:d3ff:fe7b:9487%wlan0 prefixlen 64 scopeid 0x4 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid channel 8 (2447 MHz 11g) regdomain 33411 country RU indoor ecm authmode WPA1+WPA2/802.11i privacy MIXED deftxkey UNDEF txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming MANUAL # ifconfig wlan0 list scan SSID/MESH IDBSSID CHAN RATE S:N INT CAPS APT-SPB2b8:a3:86:4a:75:6a6 54M -92:-96 100 EP HTCAP WPA RSN WME WPS THD1 74:ea:3a:d1:37:46 10 54M -85:-96 100 EP RSN HTCAP WME Balt1 00:90:4c:c1:00:001 54M -90:-96 100 EP RSN TP-LINK_904D2A 64:70:02:90:4d:2a 11 54M -94:-96 100 EPS RSN HTCAP WME ATH WPS /var/log/messages ... Jul 23 15:34:24 x220 wpa_supplicant[669]: wlan0: CTRL-EVENT-TERMINATING Jul 23 15:34:24 x220 kernel: wlan0: Ethernet address: 00:25:d3:7b:94:87 Jul 23 15:34:24 x220 devd: Executing '/etc/pccard_ether wlan0 start' Jul 23 15:34:24 x220 wpa_supplicant[2563]: Successfully initialized wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2571]: Successfully initialized wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2571]: ctrl_iface exists and seems to be in use - cannot override it Jul 23 15:34:24 x220 wpa_supplicant[2571]: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore Jul 23 15:34:24 x220 wpa_supplicant[2571]: Failed to initialize control interface '/var/run/wpa_supplicant'. You may have another wpa_supplicant process already running or the file was left by an unclean termination of wpa_supplicant in which case you will need to manually remove this file before starting wpa_supplicant again. Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jul 23 15:34:24 x220 root: /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:24 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:25 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:25 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:26 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: warning, recursive reset path! Jul 23 15:34:26 x220 kernel: ath0: ath_reset: concurrent reset! Danger! Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt 0; bailing Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt 0; bailing Jul 23 15:34:26 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:27 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, recursive reset path! ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Not work ATH (AR9285) after update
On Tue, Jul 23, 2013 at 5:13 PM, Adrian Chadd adr...@freebsd.org wrote: .. are two copies of wpa_supplicant running? -adrian On 23 July 2013 06:09, Andrey Fesenko f0and...@gmail.com wrote: Hello, i'm horrible news, after update my notebook not nave wi-fi :( full update system, build and install world and kernel. # uname -a FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253562: Tue Jul 23 14:44:07 MSK 2013 root@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 # grep ATH /usr/src/sys/amd64/conf/W_BOOK options ATH_ENABLE_11N options ATH_DEBUG options ATH_DIAGAPI ath0@pci0:3:0:0:class=0x028000 card=0x1a891a3b chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9285 Wireless Network Adapter (PCI-Express)' class = network # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:25:d3:7b:94:87 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8c43UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:25:d3:7b:94:87 inet6 fe80::225:d3ff:fe7b:9487%wlan0 prefixlen 64 scopeid 0x4 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid channel 8 (2447 MHz 11g) regdomain 33411 country RU indoor ecm authmode WPA1+WPA2/802.11i privacy MIXED deftxkey UNDEF txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming MANUAL # ifconfig wlan0 list scan SSID/MESH IDBSSID CHAN RATE S:N INT CAPS APT-SPB2b8:a3:86:4a:75:6a6 54M -92:-96 100 EP HTCAP WPA RSN WME WPS THD1 74:ea:3a:d1:37:46 10 54M -85:-96 100 EP RSN HTCAP WME Balt1 00:90:4c:c1:00:001 54M -90:-96 100 EP RSN TP-LINK_904D2A 64:70:02:90:4d:2a 11 54M -94:-96 100 EPS RSN HTCAP WME ATH WPS /var/log/messages ... Jul 23 15:34:24 x220 wpa_supplicant[669]: wlan0: CTRL-EVENT-TERMINATING Jul 23 15:34:24 x220 kernel: wlan0: Ethernet address: 00:25:d3:7b:94:87 Jul 23 15:34:24 x220 devd: Executing '/etc/pccard_ether wlan0 start' Jul 23 15:34:24 x220 wpa_supplicant[2563]: Successfully initialized wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2571]: Successfully initialized wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2571]: ctrl_iface exists and seems to be in use - cannot override it Jul 23 15:34:24 x220 wpa_supplicant[2571]: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore Jul 23 15:34:24 x220 wpa_supplicant[2571]: Failed to initialize control interface '/var/run/wpa_supplicant'. You may have another wpa_supplicant process already running or the file was left by an unclean termination of wpa_supplicant in which case you will need to manually remove this file before starting wpa_supplicant again. Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jul 23 15:34:24 x220 root: /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:24 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:25 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:25 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:26 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: warning, recursive reset path! Jul 23 15:34:26 x220 kernel: ath0: ath_reset: concurrent reset! Danger! Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt 0; bailing Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt 0; bailing Jul 23 15:34:26 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:27 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, recursive reset path! Not, root@x220:~ # ps -A | grep wpa 671 - Ss 0:00.73 /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_suppl Start, or
Re: wifi hostap Atheros AR938x
On Tue, Jul 23, 2013 at 10:22 AM, Adrian Chadd adr...@freebsd.org wrote: I don't think so. The handbook chapter(s) on wireless need updating. :( Would you mind giving me an example of how to setup 802.11n correctly on both the hostap side and the client side? assume both cards are Ath 9300 devices.. id like to do security on wifi, but I cant figure out if I am required to have hosthapd for that.. or if I can do it all from rc.conf.. I guess im not exactly clear on What hostapd is , and if it is a requirement in WIFI.. -- Sam Fourman Jr. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
IWN Review split 1
Hello there, As discuss this morning on Efnet, here is the first small patch for IWN. This one add an hint value for early debugging IWN. Early debug feature will start printing information from attach function and further. After attachment, debug verbosity is controlled by sysctl value. Cedric hint_debug.patch Description: Binary data ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: My WLI-UC-GNM up crash
I manually make up, is compiling the kernel -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ 2013/7/24 XiaoQI Ge g...@7axu.com: patch /root/if_run_2013_01_19_radiotap_fix_only.diff appears to be invalid ] /usr/src/sys/dev/usb/wlan # patch /root/if_run_2013_01_19_radiotap_fix_only.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- if_run.c.fix1_vnet 2013-06-14 10:12:49.786774072 +0200 |+++ if_run.c.fix2_vnet_plus_radiotap 2013-06-14 10:15:34.890774314 +0200 -- File to patch: 2013/7/23 Daan Vreeken d...@vitsch.nl: cd /usr/src/sys/dev/usb/wlan -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
