Hello,
I am trying to capture packets that are exchanged between an AP and a
smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
traffic from a laptop PC towards the smartphone using iperf.
The problem is that I can see _only_ the control frames like RTS/CTS,
Block ACK, while the data packets are not captured. I uploaded the
Wireshark capture files at [1] (located inside the folders whose name
starts with 5Ghz).
If I use the 2.4 frequency, all the frames are captured. I also
uploaded the Wireshark packet traces for 2.4Ghz at [1] (located inside
the folders whose name starts with 2.4 Ghz).
Is this a known bug or am I doing something wrong?
Additional details:
Wi-Fi card: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
Wireless N 7260, REV=0x144
Firmware version: iwlwifi 0000:04:00.0: loaded firmware version
25.228.9.0 op_mode iwlmvm
Traffic encryption: WPA & WPA2 Personal
Setting up the card in wireless mode:
ip link set dev wlan0 down
iw wlan0 set type monitor
ip link set dev wlan0 up
iw wlan0 set freq 5240
[1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
Thank you, Doru
PiBPbiBUdWUsIEFwciA1LCAyMDE2IGF0IDQ6MzQgUE0sIEdydW1iYWNoLCBFbW1hbnVlbA0KPiA8
ZW1tYW51ZWwuZ3J1bWJhY2hAaW50ZWwuY29tPiB3cm90ZToNCj4gPiBPbiBUdWUsIDIwMTYtMDQt
MDUgYXQgMTY6MjUgKzAzMDAsIEd1Y2VhIERvcnUgd3JvdGU6DQo+ID4+IE9uIFR1ZSwgQXByIDUs
IDIwMTYgYXQgMTowMCBQTSwgR3J1bWJhY2gsIEVtbWFudWVsDQo+ID4+IDxlbW1hbnVlbC5ncnVt
YmFjaEBpbnRlbC5jb20+IHdyb3RlOg0KPiA+PiA+ID4NCj4gPj4gPiA+IEhlbGxvLA0KPiA+PiA+
ID4NCj4gPj4gPiA+IEkgYW0gdHJ5aW5nIHRvIGNhcHR1cmUgcGFja2V0cyB0aGF0IGFyZSBleGNo
YW5nZWQgYmV0d2VlbiBhbiBBUA0KPiA+PiA+ID4gYW5kIGEgc21hcnRwaG9uZSBvbiB0aGUgNUdo
eiBmcmVxdWVuY3kuIEZvciBnZW5lcmF0aW5nIHRyYWZmaWMsIEkNCj4gPj4gPiA+IHVwbG9hZCBV
RFAgdHJhZmZpYyBmcm9tIGEgbGFwdG9wIFBDIHRvd2FyZHMgdGhlIHNtYXJ0cGhvbmUgdXNpbmcN
Cj4gPj4gPiA+IGlwZXJmLg0KPiA+PiA+ID4NCj4gPj4gPiA+IFRoZSBwcm9ibGVtIGlzIHRoYXQg
SSBjYW4gc2VlIF9vbmx5XyB0aGUgY29udHJvbCBmcmFtZXMgbGlrZQ0KPiA+PiA+ID4gUlRTL0NU
UywgQmxvY2sgQUNLLCB3aGlsZSB0aGUgZGF0YSBwYWNrZXRzIGFyZSBub3QgY2FwdHVyZWQuIEkN
Cj4gPj4gPiA+IHVwbG9hZGVkIHRoZSBXaXJlc2hhcmsgY2FwdHVyZSBmaWxlcyBhdCBbMV0gKGxv
Y2F0ZWQgaW5zaWRlIHRoZQ0KPiA+PiA+ID4gZm9sZGVycyB3aG9zZSBuYW1lIHN0YXJ0cyB3aXRo
IDVHaHopLg0KPiA+PiA+DQo+ID4+ID4gTW9zdCBsaWtlbHkgdGhlIHBhY2tldHMgb24gQSBiYW5k
IGhhdmUgYSBWSFQgcHJlYW1ibGUgYW5kIHlvdXIgU0tVDQo+ID4+ID4gaXMgMTFOIG9ubHkuDQo+
ID4+DQo+ID4+IE15IGNhcmQsIEludGVsIDcyNjAgWzFdICBzdXBwb3J0cyA4MDIuMTEgYWMuIFNv
IGl0IHNob3VsZCBhbHNvDQo+ID4+IHN1cHBvcnQgVkhULCByaWdodD8gSXMgdGhlcmUgYW55IGlu
dGVyZmFjZSBpbiB1c2VyLXNwYWNlIGZvciBjaGVja2luZw0KPiA+PiBhZnRlciBWSFQ/DQo+ID4N
Cj4gPiA3MjYwIGhhcyBzZXZlcmFsIGZsYXZvcnMuIFRoZSBvbmUgeW91IGhhdmUgZG9lc24ndCBz
dXBwb3J0IFZIVDoNCj4gPj4gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IERldGVjdGVkIEludGVsKFIp
IER1YWwgQmFuZCBXaXJlbGVzcyBOIDcyNjANCj4gPg0KPiA+IER1YWwgQmFuZCBtZWFucyB5b3Ug
aGF2ZSBzdXBwb3J0IGZvciA1LjJHSHosIGJ1dCBXaXJlbGVzcyBOLCBtZWFucyBubw0KPiA+IFZI
VC4NCj4gDQo+IE9uZSBvZiBteSBjb2xsZWFndWVzIGhhZCBhbiBJbnRlbCA3MjYwIEFDIGNhcmQg
c28gSSByZXBlYXRlZCB0aGUNCj4gZXhwZXJpbWVudHM6DQo+IC0gaWYgSSBzZXQgdGhlIGNoYW5u
ZWwgd2lkdGggdG8gMjBNaHogZnJvbSB0aGUgQVAgYW5kIHRoZSBtb25pdG9yIGludGVyZmFjZQ0K
PiB1c2luZyB0aGUgY29tbWFuZCBpdyB3bGFuMCBzZXQgZnJlcSA1MjQwIEhUMjArIEkgY2FuIHNl
ZSBkYXRhIGZyYW1lcyBhbmQNCj4gdGhlIEJsb2NrIEFDS3MgZm9yIHRoZXNlIGZyYW1lczsNCj4g
LSBpZiBJIHNldCB0aGUgY2hhbm5lbCB3aWR0aCB0byA0ME1oeiBmcm9tIHRoZSBBUCBhbmQgdGhl
IG1vbml0b3IgaW50ZXJmYWNlDQo+IHVzaW5nIHRoZSBjb21tYW5kIGl3IHdsYW4wIHNldCBmcmVx
IDUyNDAgSFQ0MC0gSSBjYW4gc2VlIGRhdGEgZnJhbWVzIGFuZA0KPiB0aGUgQmxvY2sgQUNLcyBm
b3IgdGhlc2UgZnJhbWVzOw0KPiAtIElmIEkgc2V0IHRoZSBjaGFubmVsIHdpZHRoIHRvIDgwTWh6
IGZyb20gdGhlIEFQIEkgZG9uJ3QgaG93IHRvIHNldCB1cCB0aGUNCj4gbW9uaXRvciBpbnRlcmZh
Y2UuIEkgdHJpZWQgd2l0aCBpdyB3bGFuMCBzZXQgZnJlcSA1MjQwIEhUNDArIGJ1dCBpdCB0ZWxs
cyBtZQ0KPiB0aGF0IHRoZSBhcmd1bWVudCBpcyBpbnZhbGlkLg0KPiANCj4gSXMgdGhlIGl3bHdp
ZmkgZHJpdmVyIGNhcGFibGUgb2YgY2FwdHVyaW5nIGRhdGEgZnJhbWVzIHdoZW4gdGhlIGNoYW5u
ZWwNCj4gYm9uZGluZyBpcyBzZXQgdG8gODBNaHo/DQoNCmRldiA8ZGV2bmFtZT4gc2V0IGZyZXEg
PGNvbnRyb2wgZnJlcT4gWzIwfDQwfDgwfDgwKzgwfDE2MF0gWzxjZW50ZXIgZnJlcSAxPl0gWzxj
ZW50ZXIgZnJlcSAyPl0NCg0KWW91IGNhbiB0YWtlIGNlbnRlcl9mcmVxMSBmcm9tIHRoZSBvdXRw
dXQgb2YgaXcgZGV2IG9uIGEgZGV2aWNlIHRoYXQgaXMgYXNzb2NpYXRlZCB0byB0aGUgc2FtZSBB
UC4NCg==
On Wed, Apr 6, 2016 at 12:39 AM, Reinoud Koornstra
<[email protected]> wrote:
> On Tue, Apr 5, 2016 at 7:25 AM, Gucea Doru <[email protected]> wrote:
>> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>> <[email protected]> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I am trying to capture packets that are exchanged between an AP and a
>>>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>>>> traffic from a laptop PC towards the smartphone using iperf.
>>>>
>>>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>>>> ACK, while the data packets are not captured. I uploaded the Wireshark
>>>> capture files at [1] (located inside the folders whose name starts with 5Ghz).
>>>
>>> Most likely the packets on A band have a VHT preamble and your SKU is 11N only.
>>
>> My card, Intel 7260 [1] supports 802.11 ac. So it should also support
>> VHT, right? Is there any interface in user-space for checking after
>> VHT?
>>
>> However, I noticed a "failure" message in dmesg:
>> [ 4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
>> [ 4.030570] iwlwifi 0000:04:00.0: irq 37 for MSI/MSI-X
>> [ 4.030760] iwlwifi 0000:04:00.0: Direct firmware load for
>> iwlwifi-7260-10.ucode failed with error -2
>> [ 4.035509] iwlwifi 0000:04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> [ 4.454772] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
>> Wireless N 7260, REV=0x144
>> [ 4.454825] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>> [ 4.455055] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>> [ 15.049933] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>> [ 15.050269] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>
> The ucode failure isn't a problem, you'll likely find that another
> firmware does load.
> I've got also a 7620, but mine does support 11ac, so mine does support VHT.
>
> [ 9.820637] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7260, REV=0x144
>
> I also got a firmware load failure, but that's ok
>
> [ 8.399101] iwlwifi 0000:04:00.0: Direct firmware load for
> iwlwifi-7260-17.ucode failed with error -2
>
> Cause here it does load the one it needs:
>
> [ 9.110486] iwlwifi 0000:04:00.0: loaded firmware version
> 16.242414.0 op_mode iwlmvm
>
> I did fetch recent firmware by git to be up to date.
> I also added some instrumentation to get to see the unsupported splx
> structure and in my case it's just because of the package.count isn't
> what it should be.
> This isn't a problem as well really.
>
> Mar 14 00:32:36 router-dev kernel: [ 8.273274] iwlwifi
> 0000:04:00.0: Unsupported splx structure
> Mar 14 00:32:36 router-dev kernel: [ 8.273276] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->type is 0x04
> Mar 14 00:32:36 router-dev kernel: [ 8.273277] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->package.count is 4
> Mar 14 00:32:36 router-dev kernel: [ 8.273277] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->package.elements[0].type is 0x01
> Mar 14 00:32:36 router-dev kernel: [ 8.273278] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->package.elements[0].integer.value is 0
> Mar 14 00:32:36 router-dev kernel: [ 8.273279] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->type is 0x04
> Mar 14 00:32:36 router-dev kernel: [ 8.273280] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->package.count is 3
> Mar 14 00:32:36 router-dev kernel: [ 8.273281] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->package.elements[0].type is 0x01
> Mar 14 00:32:36 router-dev kernel: [ 8.273281] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->package.elements[1].type is 0x01
> Mar 14 00:32:36 router-dev kernel: [ 8.273282] iwlwifi
> 0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: WiFi power is not limited,
> domain_type->integer.value is 0
>
> I compiled wpa_supplicant and it connects without trouble to several
> access points.
> I mostly do it this way, because I maintain the mtk driver I use in
> the access point here so I get to see extensive info from both sides
> when things go pearshape. :)
>
Thanks a lot for your support: as Emmanuel pointed out the problem
comes from my Wi-Fi flavour card.
>>
>> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
>> assumption is that the card can't enter into the 802.11 ac mode, it
>> just stays into 802.11n.
>>
>> doru@doru-N551JK:~$ iwconfig wlan0
>> wlan0 IEEE 802.11abgn ESSID:"5_mptcp"
>> Mode:Managed Frequency:5.24 GHz Access Point: C4:6E:1F:4B:10:A2
>> Bit Rate=150 Mb/s Tx-Power=22 dBm
>> Retry short limit:7 RTS thr:off Fragment thr:off
>> Power Management:on
>> Link Quality=70/70 Signal level=-36 dBm
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:22 Missed beacon:0
>>
>>
>> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth-brief.html
>>
>>> Another option is that the traffic uses LDPC encoding and this device doesn't support it.
>>>
>>>
>>>>
>>>> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
>>>> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
>>>> name starts with 2.4 Ghz).
>>>>
>>>> Is this a known bug or am I doing something wrong?
>>>>
>>>> Additional details:
>>>> Wi-Fi card: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless N 7260,
>>>> REV=0x144 Firmware version: iwlwifi 0000:04:00.0: loaded firmware version
>>>> 25.228.9.0 op_mode iwlmvm
>>>> Traffic encryption: WPA & WPA2 Personal
>>>> Setting up the card in wireless mode:
>>>> ip link set dev wlan0 down
>>>> iw wlan0 set type monitor
>>>> ip link set dev wlan0 up
>>>> iw wlan0 set freq 5240
>>>>
>>>> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>>>>
>>>> Thank you, Doru
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 5, 2016 at 4:34 PM, Grumbach, Emmanuel
<[email protected]> wrote:
> On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
>> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>> <[email protected]> wrote:
>> > >
>> > > Hello,
>> > >
>> > > I am trying to capture packets that are exchanged between an AP
>> > > and a
>> > > smartphone on the 5Ghz frequency. For generating traffic, I
>> > > upload UDP
>> > > traffic from a laptop PC towards the smartphone using iperf.
>> > >
>> > > The problem is that I can see _only_ the control frames like
>> > > RTS/CTS, Block
>> > > ACK, while the data packets are not captured. I uploaded the
>> > > Wireshark
>> > > capture files at [1] (located inside the folders whose name
>> > > starts with 5Ghz).
>> >
>> > Most likely the packets on A band have a VHT preamble and your SKU
>> > is 11N only.
>>
>> My card, Intel 7260 [1] supports 802.11 ac. So it should also
>> support
>> VHT, right? Is there any interface in user-space for checking after
>> VHT?
>
> 7260 has several flavors. The one you have doesn't support VHT:
>> iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless N 7260
>
> Dual Band means you have support for 5.2GHz, but Wireless N, means no
> VHT.
One of my colleagues had an Intel 7260 AC card so I repeated the experiments:
- if I set the channel width to 20Mhz from the AP and the monitor
interface using the command iw wlan0 set freq 5240 HT20+ I can see
data frames and the Block ACKs for these frames;
- if I set the channel width to 40Mhz from the AP and the monitor
interface using the command iw wlan0 set freq 5240 HT40- I can see
data frames and the Block ACKs for these frames;
- If I set the channel width to 80Mhz from the AP I don't how to set
up the monitor interface. I tried with iw wlan0 set freq 5240 HT40+
but it tells me that the argument is invalid.
Is the iwlwifi driver capable of capturing data frames when the
channel bonding is set to 80Mhz?
>
>>
>> However, I noticed a "failure" message in dmesg:
>> [ 4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
>> [ 4.030570] iwlwifi 0000:04:00.0: irq 37 for MSI/MSI-X
>> [ 4.030760] iwlwifi 0000:04:00.0: Direct firmware load for
>> iwlwifi-7260-10.ucode failed with error -2
>> [ 4.035509] iwlwifi 0000:04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> [ 4.454772] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
>> Wireless N 7260, REV=0x144
>> [ 4.454825] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>> [ 4.455055] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>> [ 15.049933] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>> [ 15.050269] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
>>
>> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
>> assumption is that the card can't enter into the 802.11 ac mode, it
>> just stays into 802.11n.
>>
>> doru@doru-N551JK:~$ iwconfig wlan0
>> wlan0 IEEE 802.11abgn ESSID:"5_mptcp"
>> Mode:Managed Frequency:5.24 GHz Access Point:
>> C4:6E:1F:4B:10:A2
>> Bit Rate=150 Mb/s Tx-Power=22 dBm
>> Retry short limit:7 RTS thr:off Fragment thr:off
>> Power Management:on
>> Link Quality=70/70 Signal level=-36 dBm
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:22 Missed beacon:0
>>
>>
>> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-ban
>> d-wireless-ac-7260-bluetooth-brief.html
>>
>> > Another option is that the traffic uses LDPC encoding and this
>> > device doesn't support it.
>> >
>> >
>> > >
>> > > If I use the 2.4 frequency, all the frames are captured. I also
>> > > uploaded the
>> > > Wireshark packet traces for 2.4Ghz at [1] (located inside the
>> > > folders whose
>> > > name starts with 2.4 Ghz).
>> > >
>> > > Is this a known bug or am I doing something wrong?
>> > >
>> > > Additional details:
>> > > Wi-Fi card: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
>> > > Wireless N 7260,
>> > > REV=0x144 Firmware version: iwlwifi 0000:04:00.0: loaded firmware
>> > > version
>> > > 25.228.9.0 op_mode iwlmvm
>> > > Traffic encryption: WPA & WPA2 Personal
>> > > Setting up the card in wireless mode:
>> > > ip link set dev wlan0 down
>> > > iw wlan0 set type monitor
>> > > ip link set dev wlan0 up
>> > > iw wlan0 set freq 5240
>> > >
>> > > [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>> > >
>> > > Thank you, Doru
PiBPbiBTdW4sIEFwciAxMCwgMjAxNiBhdCAxOjI4IFBNLCBHcnVtYmFjaCwgRW1tYW51ZWwNCj4g
PGVtbWFudWVsLmdydW1iYWNoQGludGVsLmNvbT4gd3JvdGU6DQo+ID4+ID4gT24gVHVlLCAyMDE2
LTA0LTA1IGF0IDE2OjI1ICswMzAwLCBHdWNlYSBEb3J1IHdyb3RlOg0KPiA+PiBJcyB0aGUgaXds
d2lmaSBkcml2ZXIgY2FwYWJsZSBvZiBjYXB0dXJpbmcgZGF0YSBmcmFtZXMgd2hlbiB0aGUNCj4g
Pj4gY2hhbm5lbCBib25kaW5nIGlzIHNldCB0byA4ME1oej8NCj4gPg0KPiA+IGRldiA8ZGV2bmFt
ZT4gc2V0IGZyZXEgPGNvbnRyb2wgZnJlcT4gWzIwfDQwfDgwfDgwKzgwfDE2MF0gWzxjZW50ZXIN
Cj4gPiBmcmVxIDE+XSBbPGNlbnRlciBmcmVxIDI+XQ0KPiA+DQo+ID4gWW91IGNhbiB0YWtlIGNl
bnRlcl9mcmVxMSBmcm9tIHRoZSBvdXRwdXQgb2YgaXcgZGV2IG9uIGEgZGV2aWNlIHRoYXQgaXMN
Cj4gYXNzb2NpYXRlZCB0byB0aGUgc2FtZSBBUC4NCj4gDQo+IFRoYW5rcyBhIGxvdCwgRW1tYW51
ZWwuIE15IGl3IGJpbmFyeSB0aGF0IGNhbWUgZGVmYXVsdCB3aXRoIG15IFVidW50dQ0KPiBkaXN0
cmlidXRpb24gd2FzIHZlcnkgb2xkICgzLjQpIGFuZCBpdCBkaWRuJ3QgaGF2ZSBzdXBwb3J0IGZv
ciBjaGFubmVsIGJvbmRpbmcNCj4gbGFyZ2VyIHRoYW4gNDBNaHouDQo+IEkgY29tcGlsZWQgdGhl
IGxhdGVzdCBpdyB2ZXJzaW9uIGZyb20gc291cmNlcyB0aGVuIEkgdG9vayB0aGUNCj4gY2VudGVy
X2ZyZXExIGZyb20gdGhlIGJlYWNvbiBhZHZlcnRpc2VkIGJ5IHRoZSBBUC4gVGhhdCdzIGJlY2F1
c2UgdGhlIGl3DQo+IGRldiBvbiBhIGRldmljZSBhc3NvY2lhdGVkIHRvIHRoZSBzYW1lIEFQIGdh
dmUgbWUgdGhlIGNvbnRyb2wgZnJlcXVlbmN5Lg0KPiBBZnRlciB0aGF0LCBJIHdhcyBhYmxlIHRv
IGNhcHR1cmUgdGhlIGRhdGEgZnJhbWVzLg0KPiANCj4gT25lIG1vcmUgcXVlc3Rpb24gdGhhdCBJ
IHByb21pc2UgdG8gYmUgdGhlIGxhc3Qgb25lOg0KPiAtIEkgYW0gdHJ5aW5nIHRvIGNhcHR1cmUg
dGhlIFdpLUZpIERpcmVjdCB0cmFmZmljIGJldHdlZW4gdHdvDQo+IHNtYXJ0cGhvbmVzOiBpdyBz
aG93cyBtZSB0aGF0IHRoZSBwMnAgaW50ZXJmYWNlIGZyb20gb25lIG9mIHRoZQ0KPiBzbWFydHBo
b25lcyB1c2VzIDIuNEdoeiwgY2hhbm5lbCAxIHNvIEkgc2V0IHRoZSBtb25pdG9yIGludGVyZmFj
ZSBvbiAyLjQsDQo+IGNoYW5uZWwgMS4gVGhlIHByb2JsZW0gaXMgdGhhdCwgYWdhaW4sIEkgY2Fu
J3Qgc2VlIHRoZSBkYXRhIGZyYW1lcy4gSW5zdGVhZCwgSQ0KPiBjYW4gc2VlIHRoZSBBc3NvY2lh
dGlvbi9BdXRoZW50aWNhdGlvbiBSZXF1ZXN0LCBSVFMvQ1RTLCBCbG9jayBBQ0sgKEkNCj4gYXR0
YWNoZWQgdGhlIFdpcmVzaGFyayBjYXB0dXJlIGF0IFsxXSkuDQo+IA0KDQouLi4uIC4uLi4gLi4u
LiAuLi4xID0gSFQgTERQQyBjb2RpbmcgY2FwYWJpbGl0eTogVHJhbnNtaXR0ZXIgc3VwcG9ydHMg
cmVjZWl2aW5nIExEUEMgY29kZWQgcGFja2V0cw0KDQpUaGlzIG1lYW5zIHRoYXQgYm90aCBzaWRl
cyB1c2UgYSBjb2RpbmcgYWxnbyB0aGF0IDcyNjAgZG9lc24ndCB1bmRlcnN0YW5kLiA3MjYwIHRh
bGtzIFZpdGVyYmkuDQpUaGUgb25seSB3YXkgdG8gZ28gaGVyZSBpcyB0byBnZXQgYSA3MjY1IG1v
ZHVsZSAob3IgbGF0ZXIpIGluc3RlYWQuDQoNCj4gQW5hbHl6aW5nIHRoZSBjYXB0dXJlLCBJIG5v
dGljZWQgdGhhdCB0aGUgSFQgY2FwYWJpbGl0aWVzIGFkdmVydGlzZWQgaW4gdGhlDQo+IGJlYWNv
biBmcmFtZXMgaW5kaWNhdGVzIDgwMi4xMW4gRDEuMTAuIERvZXMgdGhpcyB0cmlnZ2VyIGFueSBp
bmRpY2F0aW9uIGZvcg0KPiB5b3Ugb24gaG93IHRvIHNldHVwIHRoZSBtb25pdG9yIGludGVyZmFj
ZT8NCj4gDQo+IFsxXQ0KPiBodHRwczovL2RyaXZlLmdvb2dsZS5jb20vZmlsZS9kLzBCNVNCSDA4
UFVfQ2hObGxhVkhSaWVuQlNWbEUvdmlldz91c3ANCj4gPXNoYXJpbmcNCj4gDQo+IFJlZ2FyZHMs
DQo+IERvcnUNCg==
On Tue, Apr 5, 2016 at 7:25 AM, Gucea Doru <[email protected]> wrote:
> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
> <[email protected]> wrote:
>>>
>>> Hello,
>>>
>>> I am trying to capture packets that are exchanged between an AP and a
>>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>>> traffic from a laptop PC towards the smartphone using iperf.
>>>
>>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>>> ACK, while the data packets are not captured. I uploaded the Wireshark
>>> capture files at [1] (located inside the folders whose name starts with 5Ghz).
>>
>> Most likely the packets on A band have a VHT preamble and your SKU is 11N only.
>
> My card, Intel 7260 [1] supports 802.11 ac. So it should also support
> VHT, right? Is there any interface in user-space for checking after
> VHT?
>
> However, I noticed a "failure" message in dmesg:
> [ 4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
> [ 4.030570] iwlwifi 0000:04:00.0: irq 37 for MSI/MSI-X
> [ 4.030760] iwlwifi 0000:04:00.0: Direct firmware load for
> iwlwifi-7260-10.ucode failed with error -2
> [ 4.035509] iwlwifi 0000:04:00.0: loaded firmware version
> 25.228.9.0 op_mode iwlmvm
> [ 4.454772] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
> Wireless N 7260, REV=0x144
> [ 4.454825] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
> [ 4.455055] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
> [ 15.049933] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
> [ 15.050269] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
The ucode failure isn't a problem, you'll likely find that another
firmware does load.
I've got also a 7620, but mine does support 11ac, so mine does support VHT.
[ 9.820637] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144
I also got a firmware load failure, but that's ok
[ 8.399101] iwlwifi 0000:04:00.0: Direct firmware load for
iwlwifi-7260-17.ucode failed with error -2
Cause here it does load the one it needs:
[ 9.110486] iwlwifi 0000:04:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm
I did fetch recent firmware by git to be up to date.
I also added some instrumentation to get to see the unsupported splx
structure and in my case it's just because of the package.count isn't
what it should be.
This isn't a problem as well really.
Mar 14 00:32:36 router-dev kernel: [ 8.273274] iwlwifi
0000:04:00.0: Unsupported splx structure
Mar 14 00:32:36 router-dev kernel: [ 8.273276] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->type is 0x04
Mar 14 00:32:36 router-dev kernel: [ 8.273277] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->package.count is 4
Mar 14 00:32:36 router-dev kernel: [ 8.273277] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->package.elements[0].type is 0x01
Mar 14 00:32:36 router-dev kernel: [ 8.273278] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->package.elements[0].integer.value is 0
Mar 14 00:32:36 router-dev kernel: [ 8.273279] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->type is 0x04
Mar 14 00:32:36 router-dev kernel: [ 8.273280] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->package.count is 3
Mar 14 00:32:36 router-dev kernel: [ 8.273281] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->package.elements[0].type is 0x01
Mar 14 00:32:36 router-dev kernel: [ 8.273281] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->package.elements[1].type is 0x01
Mar 14 00:32:36 router-dev kernel: [ 8.273282] iwlwifi
0000:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: WiFi power is not limited,
domain_type->integer.value is 0
I compiled wpa_supplicant and it connects without trouble to several
access points.
I mostly do it this way, because I maintain the mtk driver I use in
the access point here so I get to see extensive info from both sides
when things go pearshape. :)
>
> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
> assumption is that the card can't enter into the 802.11 ac mode, it
> just stays into 802.11n.
>
> doru@doru-N551JK:~$ iwconfig wlan0
> wlan0 IEEE 802.11abgn ESSID:"5_mptcp"
> Mode:Managed Frequency:5.24 GHz Access Point: C4:6E:1F:4B:10:A2
> Bit Rate=150 Mb/s Tx-Power=22 dBm
> Retry short limit:7 RTS thr:off Fragment thr:off
> Power Management:on
> Link Quality=70/70 Signal level=-36 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:22 Missed beacon:0
>
>
> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth-brief.html
>
>> Another option is that the traffic uses LDPC encoding and this device doesn't support it.
>>
>>
>>>
>>> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
>>> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
>>> name starts with 2.4 Ghz).
>>>
>>> Is this a known bug or am I doing something wrong?
>>>
>>> Additional details:
>>> Wi-Fi card: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless N 7260,
>>> REV=0x144 Firmware version: iwlwifi 0000:04:00.0: loaded firmware version
>>> 25.228.9.0 op_mode iwlmvm
>>> Traffic encryption: WPA & WPA2 Personal
>>> Setting up the card in wireless mode:
>>> ip link set dev wlan0 down
>>> iw wlan0 set type monitor
>>> ip link set dev wlan0 up
>>> iw wlan0 set freq 5240
>>>
>>> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>>>
>>> Thank you, Doru
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
<[email protected]> wrote:
>>
>> Hello,
>>
>> I am trying to capture packets that are exchanged between an AP and a
>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>> traffic from a laptop PC towards the smartphone using iperf.
>>
>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>> ACK, while the data packets are not captured. I uploaded the Wireshark
>> capture files at [1] (located inside the folders whose name starts with 5Ghz).
>
> Most likely the packets on A band have a VHT preamble and your SKU is 11N only.
My card, Intel 7260 [1] supports 802.11 ac. So it should also support
VHT, right? Is there any interface in user-space for checking after
VHT?
However, I noticed a "failure" message in dmesg:
[ 4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
[ 4.030570] iwlwifi 0000:04:00.0: irq 37 for MSI/MSI-X
[ 4.030760] iwlwifi 0000:04:00.0: Direct firmware load for
iwlwifi-7260-10.ucode failed with error -2
[ 4.035509] iwlwifi 0000:04:00.0: loaded firmware version
25.228.9.0 op_mode iwlmvm
[ 4.454772] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
Wireless N 7260, REV=0x144
[ 4.454825] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
[ 4.455055] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
[ 15.049933] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
[ 15.050269] iwlwifi 0000:04:00.0: L1 Disabled - LTR Enabled
Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
assumption is that the card can't enter into the 802.11 ac mode, it
just stays into 802.11n.
doru@doru-N551JK:~$ iwconfig wlan0
wlan0 IEEE 802.11abgn ESSID:"5_mptcp"
Mode:Managed Frequency:5.24 GHz Access Point: C4:6E:1F:4B:10:A2
Bit Rate=150 Mb/s Tx-Power=22 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=70/70 Signal level=-36 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:22 Missed beacon:0
[1] http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth-brief.html
> Another option is that the traffic uses LDPC encoding and this device doesn't support it.
>
>
>>
>> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
>> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
>> name starts with 2.4 Ghz).
>>
>> Is this a known bug or am I doing something wrong?
>>
>> Additional details:
>> Wi-Fi card: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless N 7260,
>> REV=0x144 Firmware version: iwlwifi 0000:04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> Traffic encryption: WPA & WPA2 Personal
>> Setting up the card in wireless mode:
>> ip link set dev wlan0 down
>> iw wlan0 set type monitor
>> ip link set dev wlan0 up
>> iw wlan0 set freq 5240
>>
>> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>>
>> Thank you, Doru
PiANCj4gSGVsbG8sDQo+IA0KPiBJIGFtIHRyeWluZyB0byBjYXB0dXJlIHBhY2tldHMgdGhhdCBh
cmUgZXhjaGFuZ2VkIGJldHdlZW4gYW4gQVAgYW5kIGENCj4gc21hcnRwaG9uZSBvbiB0aGUgNUdo
eiBmcmVxdWVuY3kuIEZvciBnZW5lcmF0aW5nIHRyYWZmaWMsIEkgdXBsb2FkIFVEUA0KPiB0cmFm
ZmljIGZyb20gYSBsYXB0b3AgUEMgdG93YXJkcyB0aGUgc21hcnRwaG9uZSB1c2luZyBpcGVyZi4N
Cj4gDQo+IFRoZSBwcm9ibGVtIGlzIHRoYXQgSSBjYW4gc2VlIF9vbmx5XyB0aGUgY29udHJvbCBm
cmFtZXMgbGlrZSBSVFMvQ1RTLCBCbG9jaw0KPiBBQ0ssIHdoaWxlIHRoZSBkYXRhIHBhY2tldHMg
YXJlIG5vdCBjYXB0dXJlZC4gSSB1cGxvYWRlZCB0aGUgV2lyZXNoYXJrDQo+IGNhcHR1cmUgZmls
ZXMgYXQgWzFdIChsb2NhdGVkIGluc2lkZSB0aGUgZm9sZGVycyB3aG9zZSBuYW1lIHN0YXJ0cyB3
aXRoIDVHaHopLg0KDQpNb3N0IGxpa2VseSB0aGUgcGFja2V0cyBvbiBBIGJhbmQgaGF2ZSBhIFZI
VCBwcmVhbWJsZSBhbmQgeW91ciBTS1UgaXMgMTFOIG9ubHkuDQpBbm90aGVyIG9wdGlvbiBpcyB0
aGF0IHRoZSB0cmFmZmljIHVzZXMgTERQQyBlbmNvZGluZyBhbmQgdGhpcyBkZXZpY2UgZG9lc24n
dCBzdXBwb3J0IGl0Lg0KDQoNCj4gDQo+IElmIEkgdXNlIHRoZSAyLjQgZnJlcXVlbmN5LCBhbGwg
dGhlIGZyYW1lcyBhcmUgY2FwdHVyZWQuIEkgYWxzbyB1cGxvYWRlZCB0aGUNCj4gV2lyZXNoYXJr
IHBhY2tldCB0cmFjZXMgZm9yIDIuNEdoeiBhdCBbMV0gKGxvY2F0ZWQgaW5zaWRlIHRoZSBmb2xk
ZXJzIHdob3NlDQo+IG5hbWUgc3RhcnRzIHdpdGggMi40IEdoeikuDQo+IA0KPiBJcyB0aGlzIGEg
a25vd24gYnVnIG9yIGFtIEkgZG9pbmcgc29tZXRoaW5nIHdyb25nPw0KPiANCj4gQWRkaXRpb25h
bCBkZXRhaWxzOg0KPiBXaS1GaSBjYXJkOiAgaXdsd2lmaSAwMDAwOjA0OjAwLjA6IERldGVjdGVk
IEludGVsKFIpIER1YWwgQmFuZCBXaXJlbGVzcyBOIDcyNjAsDQo+IFJFVj0weDE0NCBGaXJtd2Fy
ZSB2ZXJzaW9uOiBpd2x3aWZpIDAwMDA6MDQ6MDAuMDogbG9hZGVkIGZpcm13YXJlIHZlcnNpb24N
Cj4gMjUuMjI4LjkuMCBvcF9tb2RlIGl3bG12bQ0KPiBUcmFmZmljIGVuY3J5cHRpb246IFdQQSAm
IFdQQTIgUGVyc29uYWwNCj4gU2V0dGluZyB1cCB0aGUgY2FyZCBpbiB3aXJlbGVzcyBtb2RlOg0K
PiBpcCBsaW5rIHNldCBkZXYgd2xhbjAgZG93bg0KPiBpdyB3bGFuMCBzZXQgdHlwZSBtb25pdG9y
DQo+IGlwIGxpbmsgc2V0IGRldiB3bGFuMCB1cA0KPiBpdyB3bGFuMCBzZXQgZnJlcSA1MjQwDQo+
IA0KPiBbMV0gaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL29wZW4/aWQ9MEI1U0JIMDhQVV9DaGVr
OXJPSFkwVmt4RlJVRQ0KPiANCj4gVGhhbmsgeW91LCBEb3J1DQo=
T24gVHVlLCAyMDE2LTA0LTA1IGF0IDE2OjI1ICswMzAwLCBHdWNlYSBEb3J1IHdyb3RlOg0KPiBP
biBUdWUsIEFwciA1LCAyMDE2IGF0IDE6MDAgUE0sIEdydW1iYWNoLCBFbW1hbnVlbA0KPiA8ZW1t
YW51ZWwuZ3J1bWJhY2hAaW50ZWwuY29tPiB3cm90ZToNCj4gPiA+IA0KPiA+ID4gSGVsbG8sDQo+
ID4gPiANCj4gPiA+IEkgYW0gdHJ5aW5nIHRvIGNhcHR1cmUgcGFja2V0cyB0aGF0IGFyZSBleGNo
YW5nZWQgYmV0d2VlbiBhbiBBUA0KPiA+ID4gYW5kIGENCj4gPiA+IHNtYXJ0cGhvbmUgb24gdGhl
IDVHaHogZnJlcXVlbmN5LiBGb3IgZ2VuZXJhdGluZyB0cmFmZmljLCBJDQo+ID4gPiB1cGxvYWQg
VURQDQo+ID4gPiB0cmFmZmljIGZyb20gYSBsYXB0b3AgUEMgdG93YXJkcyB0aGUgc21hcnRwaG9u
ZSB1c2luZyBpcGVyZi4NCj4gPiA+IA0KPiA+ID4gVGhlIHByb2JsZW0gaXMgdGhhdCBJIGNhbiBz
ZWUgX29ubHlfIHRoZSBjb250cm9sIGZyYW1lcyBsaWtlDQo+ID4gPiBSVFMvQ1RTLCBCbG9jaw0K
PiA+ID4gQUNLLCB3aGlsZSB0aGUgZGF0YSBwYWNrZXRzIGFyZSBub3QgY2FwdHVyZWQuIEkgdXBs
b2FkZWQgdGhlDQo+ID4gPiBXaXJlc2hhcmsNCj4gPiA+IGNhcHR1cmUgZmlsZXMgYXQgWzFdIChs
b2NhdGVkIGluc2lkZSB0aGUgZm9sZGVycyB3aG9zZSBuYW1lDQo+ID4gPiBzdGFydHMgd2l0aCA1
R2h6KS4NCj4gPiANCj4gPiBNb3N0IGxpa2VseSB0aGUgcGFja2V0cyBvbiBBIGJhbmQgaGF2ZSBh
IFZIVCBwcmVhbWJsZSBhbmQgeW91ciBTS1UNCj4gPiBpcyAxMU4gb25seS4NCj4gDQo+IE15IGNh
cmQsIEludGVsIDcyNjAgWzFdICBzdXBwb3J0cyA4MDIuMTEgYWMuIFNvIGl0IHNob3VsZCBhbHNv
DQo+IHN1cHBvcnQNCj4gVkhULCByaWdodD8gSXMgdGhlcmUgYW55IGludGVyZmFjZSBpbiB1c2Vy
LXNwYWNlIGZvciBjaGVja2luZyBhZnRlcg0KPiBWSFQ/DQoNCjcyNjAgaGFzIHNldmVyYWwgZmxh
dm9ycy4gVGhlIG9uZSB5b3UgaGF2ZSBkb2Vzbid0IHN1cHBvcnQgVkhUOg0KPiBpd2x3aWZpIDAw
MDA6MDQ6MDAuMDogRGV0ZWN0ZWQgSW50ZWwoUikgRHVhbCBCYW5kIFdpcmVsZXNzIE4gNzI2MA0K
DQpEdWFsIEJhbmQgbWVhbnMgeW91IGhhdmUgc3VwcG9ydCBmb3IgNS4yR0h6LCBidXQgV2lyZWxl
c3MgTiwgbWVhbnMgbm8NClZIVC4NCg0KPiANCj4gSG93ZXZlciwgSSBub3RpY2VkIGEgImZhaWx1
cmUiIG1lc3NhZ2UgaW4gZG1lc2c6DQo+IFsgICAgNC4wMzA0MjhdIEludGVsKFIpIFdpcmVsZXNz
IFdpRmkgZHJpdmVyIGZvciBMaW51eCwgaW4tdHJlZToNCj4gWyAgICA0LjAzMDU3MF0gaXdsd2lm
aSAwMDAwOjA0OjAwLjA6IGlycSAzNyBmb3IgTVNJL01TSS1YDQo+IFsgICAgNC4wMzA3NjBdIGl3
bHdpZmkgMDAwMDowNDowMC4wOiBEaXJlY3QgZmlybXdhcmUgbG9hZCBmb3INCj4gaXdsd2lmaS03
MjYwLTEwLnVjb2RlIGZhaWxlZCB3aXRoIGVycm9yIC0yDQo+IFsgICAgNC4wMzU1MDldIGl3bHdp
ZmkgMDAwMDowNDowMC4wOiBsb2FkZWQgZmlybXdhcmUgdmVyc2lvbg0KPiAyNS4yMjguOS4wIG9w
X21vZGUgaXdsbXZtDQo+IFsgICAgNC40NTQ3NzJdIGl3bHdpZmkgMDAwMDowNDowMC4wOiBEZXRl
Y3RlZCBJbnRlbChSKSBEdWFsIEJhbmQNCj4gV2lyZWxlc3MgTiA3MjYwLCBSRVY9MHgxNDQNCj4g
WyAgICA0LjQ1NDgyNV0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEwxIERpc2FibGVkIC0gTFRSIEVu
YWJsZWQNCj4gWyAgICA0LjQ1NTA1NV0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEwxIERpc2FibGVk
IC0gTFRSIEVuYWJsZWQNCj4gWyAgIDE1LjA0OTkzM10gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEwx
IERpc2FibGVkIC0gTFRSIEVuYWJsZWQNCj4gWyAgIDE1LjA1MDI2OV0gaXdsd2lmaSAwMDAwOjA0
OjAwLjA6IEwxIERpc2FibGVkIC0gTFRSIEVuYWJsZWQNCj4gDQo+IEFsc28sIHRoZSBtYXhpbXVt
IGJpdCByYXRlIHJlcG9ydGVkIGJ5IGl3Y29uZmlnIGlzIDE1MCBNYi9zLCBzbyBteQ0KPiBhc3N1
bXB0aW9uIGlzIHRoYXQgdGhlIGNhcmQgY2FuJ3QgZW50ZXIgaW50byB0aGUgODAyLjExIGFjIG1v
ZGUsIGl0DQo+IGp1c3Qgc3RheXMgaW50byA4MDIuMTFuLg0KPiANCj4gZG9ydUBkb3J1LU41NTFK
Szp+JCBpd2NvbmZpZyB3bGFuMA0KPiB3bGFuMCAgICAgSUVFRSA4MDIuMTFhYmduICBFU1NJRDoi
NV9tcHRjcCINCj4gICAgICAgICAgIE1vZGU6TWFuYWdlZCAgRnJlcXVlbmN5OjUuMjQgR0h6ICBB
Y2Nlc3MgUG9pbnQ6DQo+IEM0OjZFOjFGOjRCOjEwOkEyDQo+ICAgICAgICAgICBCaXQgUmF0ZT0x
NTAgTWIvcyAgIFR4LVBvd2VyPTIyIGRCbQ0KPiAgICAgICAgICAgUmV0cnkgc2hvcnQgbGltaXQ6
NyAgIFJUUyB0aHI6b2ZmICAgRnJhZ21lbnQgdGhyOm9mZg0KPiAgICAgICAgICAgUG93ZXIgTWFu
YWdlbWVudDpvbg0KPiAgICAgICAgICAgTGluayBRdWFsaXR5PTcwLzcwICBTaWduYWwgbGV2ZWw9
LTM2IGRCbQ0KPiAgICAgICAgICAgUnggaW52YWxpZCBud2lkOjAgIFJ4IGludmFsaWQgY3J5cHQ6
MCAgUnggaW52YWxpZCBmcmFnOjANCj4gICAgICAgICAgIFR4IGV4Y2Vzc2l2ZSByZXRyaWVzOjAg
IEludmFsaWQgbWlzYzoyMiAgIE1pc3NlZCBiZWFjb246MA0KPiANCj4gDQo+IFsxXSBodHRwOi8v
d3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi93aXJlbGVzcy1wcm9kdWN0cy9kdWFsLWJh
bg0KPiBkLXdpcmVsZXNzLWFjLTcyNjAtYmx1ZXRvb3RoLWJyaWVmLmh0bWwNCj4gDQo+ID4gQW5v
dGhlciBvcHRpb24gaXMgdGhhdCB0aGUgdHJhZmZpYyB1c2VzIExEUEMgZW5jb2RpbmcgYW5kIHRo
aXMNCj4gPiBkZXZpY2UgZG9lc24ndCBzdXBwb3J0IGl0Lg0KPiA+IA0KPiA+IA0KPiA+ID4gDQo+
ID4gPiBJZiBJIHVzZSB0aGUgMi40IGZyZXF1ZW5jeSwgYWxsIHRoZSBmcmFtZXMgYXJlIGNhcHR1
cmVkLiBJIGFsc28NCj4gPiA+IHVwbG9hZGVkIHRoZQ0KPiA+ID4gV2lyZXNoYXJrIHBhY2tldCB0
cmFjZXMgZm9yIDIuNEdoeiBhdCBbMV0gKGxvY2F0ZWQgaW5zaWRlIHRoZQ0KPiA+ID4gZm9sZGVy
cyB3aG9zZQ0KPiA+ID4gbmFtZSBzdGFydHMgd2l0aCAyLjQgR2h6KS4NCj4gPiA+IA0KPiA+ID4g
SXMgdGhpcyBhIGtub3duIGJ1ZyBvciBhbSBJIGRvaW5nIHNvbWV0aGluZyB3cm9uZz8NCj4gPiA+
IA0KPiA+ID4gQWRkaXRpb25hbCBkZXRhaWxzOg0KPiA+ID4gV2ktRmkgY2FyZDogIGl3bHdpZmkg
MDAwMDowNDowMC4wOiBEZXRlY3RlZCBJbnRlbChSKSBEdWFsIEJhbmQNCj4gPiA+IFdpcmVsZXNz
IE4gNzI2MCwNCj4gPiA+IFJFVj0weDE0NCBGaXJtd2FyZSB2ZXJzaW9uOiBpd2x3aWZpIDAwMDA6
MDQ6MDAuMDogbG9hZGVkIGZpcm13YXJlDQo+ID4gPiB2ZXJzaW9uDQo+ID4gPiAyNS4yMjguOS4w
IG9wX21vZGUgaXdsbXZtDQo+ID4gPiBUcmFmZmljIGVuY3J5cHRpb246IFdQQSAmIFdQQTIgUGVy
c29uYWwNCj4gPiA+IFNldHRpbmcgdXAgdGhlIGNhcmQgaW4gd2lyZWxlc3MgbW9kZToNCj4gPiA+
IGlwIGxpbmsgc2V0IGRldiB3bGFuMCBkb3duDQo+ID4gPiBpdyB3bGFuMCBzZXQgdHlwZSBtb25p
dG9yDQo+ID4gPiBpcCBsaW5rIHNldCBkZXYgd2xhbjAgdXANCj4gPiA+IGl3IHdsYW4wIHNldCBm
cmVxIDUyNDANCj4gPiA+IA0KPiA+ID4gWzFdIGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9vcGVu
P2lkPTBCNVNCSDA4UFVfQ2hlazlyT0hZMFZreEZSVUUNCj4gPiA+IA0KPiA+ID4gVGhhbmsgeW91
LCBEb3J1
On Sun, Apr 10, 2016 at 1:28 PM, Grumbach, Emmanuel
<[email protected]> wrote:
>> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
>> Is the iwlwifi driver capable of capturing data frames when the channel
>> bonding is set to 80Mhz?
>
> dev <devname> set freq <control freq> [20|40|80|80+80|160] [<center freq 1>] [<center freq 2>]
>
> You can take center_freq1 from the output of iw dev on a device that is associated to the same AP.
Thanks a lot, Emmanuel. My iw binary that came default with my Ubuntu
distribution was very old (3.4) and it didn't have support for channel
bonding larger than 40Mhz.
I compiled the latest iw version from sources then I took the
center_freq1 from the beacon advertised by the AP. That's because the
iw dev on a device associated to the same AP gave me the control
frequency. After that, I was able to capture the data frames.
One more question that I promise to be the last one:
- I am trying to capture the Wi-Fi Direct traffic between two
smartphones: iw shows me that the p2p interface from one of the
smartphones uses 2.4Ghz, channel 1 so I set the monitor interface on
2.4, channel 1. The problem is that, again, I can't see the data
frames. Instead, I can see the Association/Authentication Request,
RTS/CTS, Block ACK (I attached the Wireshark capture at [1]).
Analyzing the capture, I noticed that the HT capabilities advertised
in the beacon frames indicates 802.11n D1.10. Does this trigger any
indication for you on how to setup the monitor interface?
[1] https://drive.google.com/file/d/0B5SBH08PU_ChNllaVHRienBSVlE/view?usp=sharing
Regards,
Doru