- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We would like to bring-up monitor mode on CYW43455 (Murata 1MW) module.
We tried using wl command to enable monitor mode as below but not successful
wl monitor 1
Also tried using iw commands to create Monitor mode interface but it returns below error
#ip link set IFACE down
#iw IFACE set monitor control
#command failed: Operation not supported (-95)
When we checked the discussion on below link it says "There is no limitation on the firmware side as such for entering monitor mode."
https://community.cypress.com/message/177118#177118
Let us know do we need to use specific Drivers/Firmware to enable this feature.
Please share us necessary steps to bring-up monitor mode
Let us know if any more details are required.
Below are the S/W version details:
Loading modules backported from Linux version v4.14.52-manda-RTM-0-g897c6ceBackport generated by backports.git v4.14-rc2-1-70-g694b78fbrcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006usbcore: registered new interface driver brcmfmacbrcmfmac: brcmf_c_preinit_dcmds: Murata Customized Version: imx-rocko-manda_r1.0;brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 21 2018 04:08:34 version 7.45.173 (r707987 CY) FWID 01-d2799ea2
1.21 RC0.0wl0: Sep 21 2018 04:08:34 version 7.45.173 (r707987 CY) FWID 01-d2799ea2
vendorid 0x14e4deviceid 0x43abradiorev 0x58030bchipnum 0x4345chiprev 0x6chippackage 0x2corerev 54.0boardid 0x6e4boardvendor 0x14e4boardrev P201driverrev 7.45.173.0ucoderev 0x0bus 0x0phytype 0xbphyrev 20.0anarev 0x0nvramrev 498373
Below is the output of iw phy phy0 info
Wiphy phy0
max # scan SSIDs: 10
max scan IEs length: 2048 bytes
max # sched scan SSIDs: 16
max # match sets: 16
max # scan plans: 1
max scan plan interval: 508
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports roaming.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CMAC (00-0f-ac:6)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
* P2P-device
Band 1:
Capabilities: 0x1022
HT20/HT40
Static SM Power Save
RX HT20 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (20.0 dBm)
Band 2:
Capabilities: 0x1062
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7
VHT Capabilities (0x00001020):
Max MPDU length: 3895
Supported Channel Width: neither 160 nor 80+80
short GI (80 MHz)
SU Beamformee
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: not supported
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: not supported
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5170 MHz [34] (20.0 dBm)
* 5180 MHz [36] (20.0 dBm)
* 5190 MHz [38] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5210 MHz [42] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5230 MHz [46] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm)
* 5280 MHz [56] (20.0 dBm)
* 5300 MHz [60] (20.0 dBm)
* 5320 MHz [64] (20.0 dBm)
* 5500 MHz [100] (20.0 dBm)
* 5520 MHz [104] (20.0 dBm)
* 5540 MHz [108] (20.0 dBm)
* 5560 MHz [112] (20.0 dBm)
* 5580 MHz [116] (20.0 dBm)
* 5600 MHz [120] (20.0 dBm)
* 5620 MHz [124] (20.0 dBm)
* 5640 MHz [128] (20.0 dBm)
* 5660 MHz [132] (20.0 dBm)
* 5680 MHz [136] (20.0 dBm)
* 5700 MHz [140] (20.0 dBm)
* 5720 MHz [144] (20.0 dBm)
* 5745 MHz [149] (20.0 dBm)
* 5765 MHz [153] (20.0 dBm)
* 5785 MHz [157] (20.0 dBm)
* 5805 MHz [161] (20.0 dBm)
* 5825 MHz [165] (20.0 dBm)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* set_bss
* join_ibss
* set_pmksa
* del_pmksa
* flush_pmksa
* remain_on_channel
* frame
* set_wiphy_netns
* set_channel
* start_sched_scan
* start_p2p_device
* connect
* disconnect
* crit_protocol_start
* crit_protocol_stop
* update_connect_params
Supported TX frame types:
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* managed: 0x40 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
WoWLAN support:
* wake up on disconnect
* wake up on magic packet
* wake up on pattern match, up to 8 patterns of 1-128 bytes,
maximum packet offset 1500 bytes
software interface modes (can always be added):
valid interface combinations:
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
total <= 3, #channels <= 2
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
total <= 4, #channels <= 1
Device supports scan flush.
ip link
set
wlan0 down
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do confirm that you are following the sequence below:
wl mpc 0
wl up
wl monitor 1
ifconfig <monitor_mode_interface> up
Use the monitor_mode_interface in wireshark.
Regards,
Vinayak
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
Are there any patches available to support Monitor Mode on CYW43455 module ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know if there's support for monitor mode on fw side, but the supplied brcmfmac driver doesn't handle it.
vnak could you tell us something about it?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do confirm that you are following the sequence below:
wl mpc 0
wl up
wl monitor 1
ifconfig <monitor_mode_interface> up
Use the monitor_mode_interface in wireshark.
Regards,
Vinayak
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, thank you or your reply.
Unfortunately I'm using this chipset on a different platform (RPi 3B+), and I don't have wl (I'm using fw+driver from your latest release).
As far as I can understand it'is just a matter of handling ioctl cmds 107/108, rigth?
Is there a simple way to do it on my platform or I have to implement it by myself in brcmfmac?
Thank you
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Yes, the implementation of monitor mode in brcmfmac for the ioctls isi currently not present. You could try moving ahead to implement this in the driver, but that would be a hassle. Better way would be to use the compiled wl utility for you platform(arm64 compiled wl utility). Please contact our local FAE/sales for more details on getting compiled wl utility
Regards,
Vinayak
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank You Vinayak for your response.
We have tried the steps shared by you and we are able to capture the packets using tcpdump on linux. but not able to parse the radio header.
We would like to fetch channel,data rate and signal level information from the radio header.
Looks like first 25bytes of the packet is related to broadcom specific radio header and from 26th octet 802.11 MAC Header is started.
Needed help in parsing this broadcom specific radio header.
Sample header:
11:24:06.929119 00:00:24:d0:0c:00 (oui Unknown) > 00:00:00:00:04:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 257
0x0000: 0100 0000 d100 0000 f3e7 7e65 0000 0000 ..........~e....
0x0010: bdff ffff 0000 0000 0100 0000 0200 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 1400 0000 ................
0x0030: 0000
Below are the steps followed.
Monitor Mode Bring-up:
wl mpc 0
wl up
wl monitor 1
ifconfig wlan0 up
Setting Channel:
wl channel 36
Capturing packets:
tcpdump -iwlan0
Attached tcpdump output for Channel36 and Channel44
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the late reply.
Frame received in monitor mode contains 802.11 header and starts with d11 header(internal headers recieved from the firmware).
The driver handles the conversion of d11rxhdr to radiotap header conversion.
We will have to look into the driver to see where that parsing is happening.
Regards