Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP8266/Embedded devices unable to connect to 2.4Ghz Radio #278

Open
iganeshk opened this issue Mar 3, 2018 · 176 comments
Open

ESP8266/Embedded devices unable to connect to 2.4Ghz Radio #278

iganeshk opened this issue Mar 3, 2018 · 176 comments

Comments

@iganeshk
Copy link

iganeshk commented Mar 3, 2018

I am trying to setup the wireless camera over 2.4ghz access point on 3200ACM running openwrt r6302/r6365 using the latest driver on 3200ACM with all the possible encryption and channels but it just fails after authentication and hence dhcp is unable to detect and allocate an IP to it. Here are the logs that I observed on various settings.

Fri Mar  2 14:07:05 2018 daemon.info hostapd: wlan1: STA 88:83:5d:XX:XX:XX IEEE 802.11: associated (aid 4)
Fri Mar  2 14:07:06 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 88:83:5d:XX:XX:XX
Fri Mar  2 14:07:06 2018 daemon.info hostapd: wlan1: STA 88:83:5d:XX:XX:XX WPA: pairwise key handshake completed (RSN)
Fri Mar  2 14:07:17 2018 daemon.info hostapd: wlan1: STA 88:83:5d:XX:XX:XX IEEE 802.11: authenticated
Fri Mar  2 14:07:51 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 88:83:5d:XX:XX:XX
Fri Mar  2 14:07:51 2018 kern.debug kernel: [43300.431211] ieee80211 phy1: staid 4 deleted
Sat Mar  3 02:53:37 2018 kern.debug kernel: [43405.708782] ieee80211 phy1: staid 4 deleted
Sat Mar  3 02:53:40 2018 daemon.info hostapd: wlan1: STA 88:83:5d:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Sat Mar  3 02:53:41 2018 daemon.notice hostapd: handle_auth_cb: STA 88:83:5d:xx:xx:xx not found
Sat Mar  3 02:53:41 2018 daemon.notice hostapd: handle_auth_cb: STA 88:83:5d:xx:xx:xx not found
Sat Mar  3 02:53:41 2018 daemon.notice hostapd: handle_auth_cb: STA 88:83:5d:xx:xx:xx not found
Sat Mar  3 02:53:43 2018 daemon.info hostapd: wlan1: STA 88:83:5d:xx:xx:xx IEEE 802.11: associated (aid 4)
Sat Mar  3 02:53:43 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 02:53:44 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 02:53:45 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx

After allocating static ip:

Fri Mar  2 14:10:22 2018 daemon.info hostapd: wlan1-1: STA 88:83:5d:XX:XX:XX IEEE 802.11: associated (aid 1)
Fri Mar  2 14:10:23 2018 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED 88:83:5d:XX:XX:XX
Fri Mar  2 14:10:23 2018 daemon.info hostapd: wlan1-1: STA 88:83:5d:XX:XX:XX WPA: pairwise key handshake completed (WPA)
Fri Mar  2 14:10:23 2018 daemon.info hostapd: wlan1-1: STA 88:83:5d:XX:XX:XX WPA: group key handshake completed (WPA)
Fri Mar  2 14:10:27 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:30 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:33 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:37 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:40 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:43 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:43 2018 daemon.info hostapd: wlan1-1: STA 88:83:5d:XX:XX:XX IEEE 802.11: authenticated
Fri Mar  2 14:10:48 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:51 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:54 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:10:59 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:11:02 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:11:05 2018 daemon.warn dnsmasq-dhcp[3775]: DHCP packet received on wlan1-1 which has no address
Fri Mar  2 14:11:08 2018 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED 88:83:5d:XX:XX:XX

At first I though it was an issue with dnsmasq, but then I was able to connect the camera with radio2 over 2.4ghz.

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 3, 2018

  1. AP-STA-POSSIBLE-PSK-MISMATCH?
  2. If static ip is used, why DHCP packets still sent out? BTW, wlan1-1 is used for multi-BSSID? Can you give your setting for the router?

@iganeshk
Copy link
Author

iganeshk commented Mar 3, 2018

Log 1: Openwrt r6302 (davidc502 build), Kernel 4.9.82, WPA2-PSK-CCMP [10.3.4.0-20180226]
Log 3: Openwrt r6302 (davidc502 build), Kernel 4.9.82, multi-wlan1 bssid to test various encryption (WPA/WPA2-PSK-CCMP/TKIP)
Log 2: Openwrt r6365 (snapshot), Kernel 4.14.23 (WPA-PSK-CCMP) (switched regular snapshot to use on radio2, since disabled on david's build)

Wireless config:

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '36'
	option hwmode '11a'
	option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
	option htmode 'VHT80'
	option disabled '1'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11g'
	option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
	option country 'US'
	option legacy_rates '1'
	option htmode 'HT20'
	option txpower '30'
	option channel '2'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid '2_4_SSID'
	option key 'SECURE_PASS'
	option wmm '0'
	option encryption 'psk2'

5Ghz disabled (different router), 2.4ghz opened for IoT devices (Espressif)

wlan2 (wpa2-psk-ccmp) log:

Sat Mar  3 12:02:22 2018 daemon.info hostapd: wlan2: STA 88:83:5d:xx:xx:xx IEEE 802.11: associated
Sat Mar  3 12:02:24 2018 daemon.notice hostapd: wlan2: AP-STA-CONNECTED 88:83:5d:xx:xx:xx
Sat Mar  3 12:02:24 2018 daemon.info hostapd: wlan2: STA 88:83:5d:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sat Mar  3 12:02:25 2018 daemon.info dnsmasq-dhcp[3369]: DHCPDISCOVER(br-lan) 88:83:5d:xx:xx:xx
Sat Mar  3 12:02:25 2018 daemon.info dnsmasq-dhcp[3369]: DHCPOFFER(br-lan) 192.168.1.200 88:83:5d:xx:xx:xx
Sat Mar  3 12:02:25 2018 daemon.info dnsmasq-dhcp[3369]: DHCPREQUEST(br-lan) 192.168.1.200 88:83:5d:xx:xx:xx
Sat Mar  3 12:02:25 2018 daemon.info dnsmasq-dhcp[3369]: DHCPACK(br-lan) 192.168.1.200 88:83:5d:xx:xx:xx Hikam-0505

@iganeshk
Copy link
Author

iganeshk commented Mar 3, 2018

radio2 went out shortly (12hrs), is it because it's used for DFS scan?

Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.604192] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x16c/0x248
Sat Mar  3 16:49:49 2018 kern.info kernel: [42473.612497] NETDEV WATCHDOG: wlan2 (mwifiex_sdio): transmit queue 1 timed out
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.619665] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc rfcomm nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack mwifiex_sdio mwifiex iptable_mangle iptable_filter ip_tables hidp hci_uart crc_ccitt btusb btmrvl_sdio btmrvl btintel bnep bluetooth hid evdev input_core mwlwifi mac80211 cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables ecdh_generic kpp ecb cmac gpio_button_hotplug
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.687105] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.23 #0
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.693137] Hardware name: Marvell Armada 380/385 (Device Tree)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.699097] [<c010f3d0>] (unwind_backtrace) from [<c010b134>] (show_stack+0x10/0x14)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.706880] [<c010b134>] (show_stack) from [<c060e4c4>] (dump_stack+0x8c/0xa0)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.714137] [<c060e4c4>] (dump_stack) from [<c0121e1c>] (__warn+0xe4/0x100)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.721130] [<c0121e1c>] (__warn) from [<c0121e70>] (warn_slowpath_fmt+0x38/0x48)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.728646] [<c0121e70>] (warn_slowpath_fmt) from [<c053b518>] (dev_watchdog+0x16c/0x248)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.736864] [<c053b518>] (dev_watchdog) from [<c016f340>] (call_timer_fn+0x24/0x98)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.744556] [<c016f340>] (call_timer_fn) from [<c016f510>] (run_timer_softirq+0x15c/0x1e8)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.752857] [<c016f510>] (run_timer_softirq) from [<c01015f0>] (__do_softirq+0xd0/0x21c)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.760986] [<c01015f0>] (__do_softirq) from [<c01265f4>] (irq_exit+0xb0/0xd8)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.768245] [<c01265f4>] (irq_exit) from [<c015d388>] (__handle_domain_irq+0x9c/0xac)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.776111] [<c015d388>] (__handle_domain_irq) from [<c0101438>] (gic_handle_irq+0x58/0x98)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.784499] [<c0101438>] (gic_handle_irq) from [<c010bdcc>] (__irq_svc+0x6c/0x90)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.792013] Exception stack(0xdf465f80 to 0xdf465fc8)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.797087] 5f80: 00000001 00000000 00000000 c0114b60 df464000 c0946410 df465fd8 00000000
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.805301] 5fa0: 00000000 414fc091 00000000 00000000 df465fc8 df465fd0 c01082fc c0108300
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.813513] 5fc0: 60000013 ffffffff
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.817017] [<c010bdcc>] (__irq_svc) from [<c0108300>] (arch_cpu_idle+0x34/0x38)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.824452] [<c0108300>] (arch_cpu_idle) from [<c01540f4>] (do_idle+0xd0/0x188)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.831795] [<c01540f4>] (do_idle) from [<c0154408>] (cpu_startup_entry+0x18/0x1c)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.839398] [<c0154408>] (cpu_startup_entry) from [<001017cc>] (0x1017cc)
Sat Mar  3 16:49:49 2018 kern.warn kernel: [42473.846223] ---[ end trace 13e6eee65b64e4a8 ]---
Sat Mar  3 16:49:49 2018 kern.info kernel: [42473.850868] mwifiex_sdio mmc0:0001:1: 4215929 : Tx timeout(#1), bss_type-num = 1-0
Sat Mar  3 16:49:49 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:49:52 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:49:54 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:49:55 2018 kern.info kernel: [42479.681635] mwifiex_sdio mmc0:0001:1: 4216512 : Tx timeout(#2), bss_type-num = 1-0
Sat Mar  3 16:49:57 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:49:59 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:03 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:05 2018 kern.info kernel: [42489.605060] mwifiex_sdio mmc0:0001:1: 4217504 : Tx timeout(#3), bss_type-num = 1-0
Sat Mar  3 16:50:06 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:09 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:11 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:14 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:15 2018 kern.info kernel: [42499.608485] mwifiex_sdio mmc0:0001:1: 4218504 : Tx timeout(#4), bss_type-num = 1-0
Sat Mar  3 16:50:16 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:19 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:23 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:25 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: associated
Sat Mar  3 16:50:25 2018 kern.info kernel: [42509.621922] mwifiex_sdio mmc0:0001:1: 4219505 : Tx timeout(#5), bss_type-num = 1-0
Sat Mar  3 16:50:26 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:28 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:28 2018 daemon.notice hostapd: wlan2: AP-STA-DISCONNECTED dc:4f:22:84:c1:b5
Sat Mar  3 16:50:28 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: disassociated
Sat Mar  3 16:50:30 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: associated
Sat Mar  3 16:50:31 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:33 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:33 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: disassociated
Sat Mar  3 16:50:35 2018 kern.info kernel: [42519.615359] mwifiex_sdio mmc0:0001:1: 4220504 : Tx timeout(#6), bss_type-num = 1-0
Sat Mar  3 16:50:35 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: associated
Sat Mar  3 16:50:36 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:38 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:38 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: disassociated
Sat Mar  3 16:50:40 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: associated
Sat Mar  3 16:50:41 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: disassociated
Sat Mar  3 16:50:43 2018 daemon.info hostapd: wlan2: STA dc:4f:22:c3:c4:8f IEEE 802.11: associated
Sat Mar  3 16:50:43 2018 daemon.info hostapd: wlan2: STA dc:4f:22:84:c1:b5 IEEE 802.11: disassociated
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.618796] mwifiex_sdio mmc0:0001:1: 4221504 : Tx timeout(#7), bss_type-num = 1-0
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.626403] mwifiex_sdio mmc0:0001:1: tx_timeout_cnt exceeds threshold.	Triggering card reset!
Sat Mar  3 16:50:45 2018 kern.err kernel: [42529.740722] mwifiex_sdio mmc0:0001:1: EVENT: BT coex wlan param update
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.747805] mwifiex_sdio mmc0:0001:1: info: shutdown mwifiex...
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.753848] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.758223] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.762605] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.766978] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.771355] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.775731] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.780109] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.784483] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.788859] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.793233] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.797606] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.801983] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.806357] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.810734] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.warn kernel: [42529.815108] mwifiex: Have pending ack frames!
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.819669] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.825619] mwifiex_sdio mmc0:0001:1: Failed to delete mgmt IEs!
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.831663] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.837609] mwifiex_sdio mmc0:0001:1: Failed to stop the BSS
Sat Mar  3 16:50:45 2018 daemon.notice netifd: Network device 'wlan2' link is down
Sat Mar  3 16:50:45 2018 kern.info kernel: [42529.843651] br-lan: port 2(wlan2) entered disabled state
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.009044] device wlan2 left promiscuous mode
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.013511] br-lan: port 2(wlan2) entered disabled state
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.019016] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.024968] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.030925] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
Sat Mar  3 16:50:45 2018 daemon.notice hostapd: wlan2: AP-STA-DISCONNECTED dc:ef:ca:73:1e:7d
Sat Mar  3 16:50:45 2018 daemon.notice hostapd: wlan2: AP-STA-DISCONNECTED dc:4f:22:c0:f5:13
Sat Mar  3 16:50:45 2018 daemon.notice hostapd: wlan2: INTERFACE-DISABLED
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.253627] mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW dnld
Sat Mar  3 16:50:45 2018 kern.info kernel: [42530.260664] mwifiex_sdio mmc0:0001:1: WLAN FW is active
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.502536] mwifiex_sdio mmc0:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0xa9, act = 0x0
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.511371] mwifiex_sdio mmc0:0001:1: num_data_h2c_failure = 0
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.517240] mwifiex_sdio mmc0:0001:1: num_cmd_h2c_failure = 0
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.523015] mwifiex_sdio mmc0:0001:1: is_cmd_timedout = 1
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.528437] mwifiex_sdio mmc0:0001:1: num_tx_timeout = 0
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.533777] mwifiex_sdio mmc0:0001:1: last_cmd_index = 0
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.539111] mwifiex_sdio mmc0:0001:1: last_cmd_id: a9 00 28 00 28 00 28 00 b2 00
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.546542] mwifiex_sdio mmc0:0001:1: last_cmd_act: 00 00 93 00 93 00 93 00 00 00
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.554065] mwifiex_sdio mmc0:0001:1: last_cmd_resp_index = 4
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.559835] mwifiex_sdio mmc0:0001:1: last_cmd_resp_id: b5 80 28 80 28 80 28 80 b2 80
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.567703] mwifiex_sdio mmc0:0001:1: last_event_index = 1
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.573215] mwifiex_sdio mmc0:0001:1: last_event: 43 00 76 00 2c 00 2d 00 2c 00
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.580559] mwifiex_sdio mmc0:0001:1: data_sent=1 cmd_sent=1
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.586245] mwifiex_sdio mmc0:0001:1: ps_mode=0 ps_state=0
Sat Mar  3 16:50:56 2018 kern.info kernel: [42540.591899] mwifiex_sdio mmc0:0001:1: info: _mwifiex_fw_dpc: unregister device

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

  1. Radio 2 is not mwlwifi.
  2. Can you use the same version to test DHCP and static IP? Please get the log for me.
  3. Don't use WEP or TKIP.

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

Log 1 repeats for DHCP and static IP. If I create a secondary radio on wlan1, I get Log 3. Logread doesn't output anything else, its just keep repeating.

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

On a single session, after making several changes to the AP(2.4)'s settings, the rest of the devices doesn't seem to get discovered as well. Here are 2 other ESP device's log:

Sun Mar  4 00:13:37 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:13:37 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: disassociated
Sun Mar  4 00:13:37 2018 kern.debug kernel: [69110.826839] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:13:38 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Mar  4 00:13:40 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:13:40 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:13:40 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 00:13:40 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:13:40 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:13:59 2018 kern.debug kernel: [69132.918797] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:14:03 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:14:03 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:14:03 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 00:14:06 2018 kern.debug kernel: [69140.408993] ieee80211 phy1: staid 1 deleted
Sun Mar  4 00:14:06 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Mar  4 00:14:06 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:14:06 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 00:14:15 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:14:15 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:14:15 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:14:22 2018 kern.debug kernel: [69156.009745] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:14:22 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:14:22 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:14:22 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 00:14:38 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:14:42 2018 authpriv.info dropbear[23493]: Child connection from 192.168.1.151:54099
Sun Mar  4 00:14:48 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:14:48 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: disassociated
Sun Mar  4 00:14:48 2018 kern.debug kernel: [69181.811196] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:14:49 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Mar  4 00:14:51 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:14:51 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:14:51 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 00:15:05 2018 kern.debug kernel: [69199.324638] ieee80211 phy1: staid 1 deleted
Sun Mar  4 00:15:05 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Mar  4 00:15:05 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:15:05 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 00:15:07 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:15:07 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:15:25 2018 kern.debug kernel: [69219.207861] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:15:25 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:15:25 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:15:25 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)

after successful handshake, does mwlwifi notify about the new device to DHCP?

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

Second update: Disabling encryption allows all the three devices to login (discovered by DHCP).

Sun Mar  4 00:32:15 2018 daemon.err hostapd: Using interface wlan1 with hwaddr 60:38:e0:xx:xx:xx and ssid "BSSID_NAME"
Sun Mar  4 00:32:15 2018 kern.debug kernel: [70228.922074] ieee80211 phy1: change: 0x100
Sun Mar  4 00:32:15 2018 kern.debug kernel: [70228.935141] ieee80211 phy1: change: 0x42
Sun Mar  4 00:32:15 2018 kern.info kernel: [70229.105066] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Sun Mar  4 00:32:15 2018 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->ENABLED
Sun Mar  4 00:32:15 2018 daemon.notice hostapd: wlan1: AP-ENABLED
Sun Mar  4 00:32:15 2018 daemon.notice netifd: Network device 'wlan1' link is up
Sun Mar  4 00:32:16 2018 daemon.notice hostapd: Station dc:4f:22:xx:xx:xx trying to disassociate, but it is not associated
Sun Mar  4 00:32:16 2018 daemon.notice hostapd: Station dc:4f:22:xx:xx:xx trying to disassociate, but it is not associated
Sun Mar  4 00:32:16 2018 daemon.notice hostapd: Station dc:4f:22:xx:xx:xx trying to disassociate, but it is not associated
Sun Mar  4 00:32:16 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Mar  4 00:32:16 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 2)
Sun Mar  4 00:32:16 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.235 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPREQUEST(br-lan) 192.168.1.235 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPACK(br-lan) 192.168.1.235 dc:4f:22:xx:xx:xx ESP_C0F513
Sun Mar  4 00:32:16 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:32:16 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPREQUEST(br-lan) 192.168.1.235 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:16 2018 daemon.info dnsmasq-dhcp[30747]: DHCPACK(br-lan) 192.168.1.235 dc:4f:22:xx:xx:xx ESP_C0F513
Sun Mar  4 00:32:16 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:32:16 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:18 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:18 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:19 2018 kern.debug kernel: [70233.755306] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:32:19 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:32:19 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:19 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:19 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.249 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:19 2018 daemon.info dnsmasq-dhcp[30747]: DHCPREQUEST(br-lan) 192.168.1.249 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:19 2018 daemon.info dnsmasq-dhcp[30747]: DHCPACK(br-lan) 192.168.1.249 dc:4f:22:xx:xx:xx ESP_84C1B5
Sun Mar  4 00:32:22 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:22 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:22 2018 daemon.info dnsmasq-dhcp[30747]: DHCPREQUEST(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:22 2018 daemon.info dnsmasq-dhcp[30747]: DHCPACK(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx ESP_C3C48F
Sun Mar  4 00:32:27 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:32:27 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:32:55 2018 kern.debug kernel: [70269.223629] ieee80211 phy1: staid 1 deleted
Sun Mar  4 00:32:55 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Mar  4 00:32:55 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:55 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:55 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:57 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:32:57 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:01 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:01 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:01 2018 daemon.info dnsmasq-dhcp[30747]: DHCPREQUEST(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:01 2018 daemon.info dnsmasq-dhcp[30747]: DHCPACK(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx ESP_C3C48F
Sun Mar  4 00:33:02 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 00:33:21 2018 kern.debug kernel: [70295.140470] ieee80211 phy1: staid 3 deleted
Sun Mar  4 00:33:21 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 00:33:21 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:21 2018 daemon.info dnsmasq-dhcp[30747]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:21 2018 daemon.info dnsmasq-dhcp[30747]: DHCPOFFER(br-lan) 192.168.1.249 dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:21 2018 daemon.info dnsmasq-dhcp[30747]: DHCPREQUEST(br-lan) 192.168.1.249 dc:4f:22:xx:xx:xx
Sun Mar  4 00:33:21 2018 daemon.info dnsmasq-dhcp[30747]: DHCPACK(br-lan) 192.168.1.249 dc:4f:22:xx:xx:xx ESP_84C1B5

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

Please don't disable WMM.

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

And use CCMP only.

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

I was trying to find out if any of those were conflicting with this issue, apparently they do not. I have set the wlan to AES only (not auto nor TKIP)

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

  1. Don't disable WMM and use CCMP only.
  2. Only test with problem client.
  3. Get log for DHCP and static IP. The logs should be different and you should check ping for static IP if connection is established.

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

This is DHCP, how about static IP?

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

BTW, aid 2 and 3 are the same kind of client?

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

I've allocated static ip for all the 3 clients. They're all same kind of client (3) and one camera which is offline.

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

In this image

I believe the clients have IP on them only because I had them on static list. There is no ip on the hostname if the client does not have a static ip

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

Removing them from static list, the log (after rebooting router):

Sun Mar  4 04:07:41 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:07:41 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:07:50 2018 authpriv.info dropbear[3371]: Child connection from 192.168.1.151:57119
Sun Mar  4 04:08:07 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:08:07 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: disassociated
Sun Mar  4 04:08:07 2018 kern.debug kernel: [  105.684705] ieee80211 phy1: staid 3 deleted
Sun Mar  4 04:08:08 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Mar  4 04:08:10 2018 kern.debug kernel: [  107.923936] ieee80211 phy1: staid 2 deleted
Sun Mar  4 04:08:10 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 2)
Sun Mar  4 04:08:10 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:08:10 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:08:13 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 04:08:13 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:08:13 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:08:16 2018 daemon.err uhttpd[1810]: luci: accepted login on / for root from 192.168.1.1
Sun Mar  4 04:08:26 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:08:26 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:08:26 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:08:26 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:08:44 2018 kern.debug kernel: [  141.932637] ieee80211 phy1: staid 2 deleted
Sun Mar  4 04:08:44 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 2)
Sun Mar  4 04:08:44 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:08:44 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:08:44 2018 kern.debug kernel: [  142.629431] ieee80211 phy1: staid 3 deleted
Sun Mar  4 04:08:48 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 04:08:48 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:08:48 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:09:22 2018 kern.debug kernel: [  180.723186] ieee80211 phy1: staid 3 deleted
Sun Mar  4 04:09:22 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 04:09:23 2018 kern.debug kernel: [  181.044324] ieee80211 phy1: staid 2 deleted
Sun Mar  4 04:09:23 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 2)
Sun Mar  4 04:09:23 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:09:23 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:09:26 2018 kern.debug kernel: [  184.838938] ieee80211 phy1: staid 3 deleted
Sun Mar  4 04:09:26 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 04:09:28 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:09:28 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:09:34 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:09:34 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:09:34 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:09:34 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:09:34 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:09:34 2018 kern.debug kernel: [  191.989466] ieee80211 phy1: staid 3 deleted
Sun Mar  4 04:09:34 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Sun Mar  4 04:10:06 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 3)
Sun Mar  4 04:10:06 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:10:06 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 04:10:07 2018 kern.debug kernel: [  225.251038] ieee80211 phy1: staid 2 deleted
Sun Mar  4 04:10:07 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 2)
Sun Mar  4 04:10:07 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 04:10:07 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 4, 2018

  1. For static IP, it means you set IP to the client, so the client won't ask IP from DHCP server. After connection, if ping is all right, we can make sure data encryption is all right.
  2. Can you just use one client to do the test?

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

  1. The terminal screenshot in my previous post had devices allocated with static ip and that is when I get "DHCP packet received from wlan1 which has no address"

  2. Setup for only ESP device with static ip and log after a reboot.
    cat /etc/config/dhcp

config dnsmasq
    option domainneeded '1'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'
    option nonwildcard '1'
    option localservice '1'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    list dhcp_option '6,8.8.8.8,8.8.4.4'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'
    option loglevel '4'

config host
    option name 'DESKTOP-XX'
    option dns '1'
    option mac 'xx:xx:xx:xx:xx'
    option ip '192.168.1.199'
    option leasetime 'infinite'

config host
    option name 'VelopNode1'
    option dns '1'
    option mac '58:ef:xx:xx:xx:xx'
    option ip '192.168.1.151'
    option leasetime 'infinite'

config host
    option name 'Hikam-0505'
    option dns '1'
    option mac '88:83:5d:xx:xx:xx'
    option ip '192.168.1.200'
    option leasetime 'infinite'

config host
    option name 'ESP_C0F513'
    option dns '1'
    option mac 'dc:4f:22:xx:xx:xx'
    option ip '192.168.1.235'
    option leasetime 'infinite'

cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '36'
	option hwmode '11a'
	option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
	option htmode 'VHT80'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11g'
	option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
	option country 'US'
	option channel '11'
	option txpower '29'
	option htmode 'HT20'
	option legacy_rates '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'SSID'
	option key 'PASSWORD'
	option encryption 'psk2+ccmp'

Log:

Sun Mar  4 12:45:37 2018 daemon.err uhttpd[1810]: luci: accepted login on /admin/network/wireless for root from 192.168.1.1
Sun Mar  4 12:45:48 2018 daemon.notice netifd: radio1 (11006): command failed: Not supported (-95)
Sun Mar  4 12:45:48 2018 daemon.err hostapd: Configuration file: /var/run/hostapd-phy1.conf
Sun Mar  4 12:45:48 2018 kern.debug kernel: [  546.593951] ieee80211 phy1: change: 0xffffffff
Sun Mar  4 12:45:48 2018 kern.info kernel: [  546.683234] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
Sun Mar  4 12:45:48 2018 kern.info kernel: [  546.690075] br-lan: port 2(wlan1) entered blocking state
Sun Mar  4 12:45:48 2018 kern.info kernel: [  546.695453] br-lan: port 2(wlan1) entered disabled state
Sun Mar  4 12:45:48 2018 kern.info kernel: [  546.700905] device wlan1 entered promiscuous mode
Sun Mar  4 12:45:48 2018 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Sun Mar  4 12:45:48 2018 daemon.err hostapd: Using interface wlan1 with hwaddr 60:38:e0:xx:xx:xx and ssid "SSID"
Sun Mar  4 12:45:49 2018 kern.debug kernel: [  546.756698] ieee80211 phy1: change: 0x100
Sun Mar  4 12:45:49 2018 kern.debug kernel: [  546.769749] ieee80211 phy1: change: 0x42
Sun Mar  4 12:45:49 2018 kern.info kernel: [  546.937221] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Sun Mar  4 12:45:49 2018 kern.info kernel: [  546.943666] br-lan: port 2(wlan1) entered blocking state
Sun Mar  4 12:45:49 2018 kern.info kernel: [  546.949012] br-lan: port 2(wlan1) entered forwarding state
Sun Mar  4 12:45:49 2018 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->ENABLED
Sun Mar  4 12:45:49 2018 daemon.notice hostapd: wlan1: AP-ENABLED
Sun Mar  4 12:45:49 2018 kern.debug kernel: [  547.027698] ieee80211 phy1: change: 0x20
Sun Mar  4 12:45:49 2018 daemon.notice netifd: Network device 'wlan1' link is up
Sun Mar  4 12:45:53 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Mar  4 12:45:54 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Sun Mar  4 12:45:54 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Mar  4 12:46:26 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated

Ping: (no response, not even timeout)

root@XXXXX:~# ping 192.168.1.235
PING 192.168.1.235 (192.168.1.235): 56 data bytes

@ghost
Copy link

ghost commented Mar 4, 2018

@iganeshk
Copy link
Author

iganeshk commented Mar 4, 2018

@rs-se the problem is these are ESP8285 based devices and configuring static ip is not possible because they run proprietary firmware. I am not sure about the camera's wifi module but all these devices can be configured from their respective apps to join 2.4Ghz networks.

As of now the devices connect without issues to the radio2 on 3200acm (which is not mwlwifi, dhcp discovers it) and my velop mesh nodes.

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 5, 2018

  1. So this issue is related to ESP8285?
  2. Can you let me know version of mwlwifi and firmware.
  3. Please use monitor mode to check if DHCP packets can be received. You can use open to check it first, then check via security.
    Thanks.

@iganeshk
Copy link
Author

iganeshk commented Mar 5, 2018

  1. I don't think so because these are able to join other networks.
kmod-mwlwifi - 4.14.23+2018-02-26-51350a3e-1
mwlwifi-firmware-88w8964 - 2018-02-26-51350a3e-1

phy0

driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.4.0-20180226
firmware version: 0x09030205
power table loaded from dts: no
firmware region code: 0x10
mac address: 60:38:e0:xx:xx:xx
2g: disable
5g: enable
antenna: 4 4
irq number: 50
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000000
radio: disable
iobase0: e0e00000
iobase1: e1080000
tx limit: 1024
rx limit: 16384

phy1:

driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.4.0-20180226
firmware version: 0x09030205
power table loaded from dts: no
firmware region code: 0x10
mac address: 60:38:e0:xx:xx:xx
2g: enable
5g: disable
antenna: 4 4
irq number: 51
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000000
radio: disable
iobase0: e1200000
iobase1: e1480000
tx limit: 1024
rx limit: 16384
  1. I did not get you, how do I capture DHCP packets in monitor mode again?

PS: I was going through this issue #242, I see similar issue with authentication.

@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 6, 2018

  1. I just want to make sure the client is ESP8285.
  2. Using following commands to create monitor interface:
    iw wlan0/wlan1 interface add mon0 type monitor
    ifconfig mon0 up
  3. The way to dump dhcp packets:
    tcpdump -vvvi mon0 -n port 67 and port 68
  4. The way to dump icmp packets:
    tcpdump -vvvi mon0 icmp

Please use open to test and get log:

  1. Prepare mon0 to dump dhcp packets and then connect client to AP.
  2. Prepare mon0 to dump icmp packets, try to ping AP from client after connection is established.

Run the same test under security mode and get log.

@iganeshk
Copy link
Author

iganeshk commented Mar 6, 2018

Had one ESP client running, right after enabling wlan1 and setting up the monitor mode it connected! I tried turned on all the clients as of now and DHCP allocated the static ip. Had the clients connected over wlan2 for the previous 18hrs. This is bizarre.

Will continue to monitor them and report with monitor logs if it occurs.

@iganeshk iganeshk closed this as completed Mar 6, 2018
@iganeshk
Copy link
Author

iganeshk commented Mar 6, 2018

Apologies, due to my absent mindedness, I forgot to look at the encryption being disabled. So I followed your steps to get mon0 up and monitoring tcpdump.

Mon Mar  5 23:55:53 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 2)
Mon Mar  5 23:55:53 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
Mon Mar  5 23:55:53 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Mon Mar  5 23:56:17 2018 daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
Mon Mar  5 23:56:52 2018 kern.debug kernel: [111031.348942] ieee80211 phy1: staid 2 deleted
root@HOST:~# tcpdump -vvvi mon0 icmp
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
root@HOST:~# tcpdump -vvvi mon0 -n port 67 and port 68
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes

I do not happen to see any connection/dhcp packet on the tcpdumps. Tried pinging the client with static ip allocated, but no response.

@iganeshk iganeshk reopened this Mar 6, 2018
@yuhhaurlin
Copy link
Collaborator

yuhhaurlin commented Mar 6, 2018

Please use open mode to do the test first:

  1. Set AP to open mode.
  2. Issue "tcpdump -vvvi mon0 -n port 67 and port 68" and connect client to AP (get the log from tcpdump).
  3. Stop tcpdump (ctrl-C).
  4. Issue "tcpdump -vvvi mon0 icmp"
  5. Ping from cilent and get log from tcpdump).

Since open mode is all right according to your description, tcpdump should get DHCP and Ping packets.

Run the same test for security mode, I want to know if DHCP packets can be received by the router.

Finally, run the test for security mode but set static IP to client.

@iganeshk
Copy link
Author

iganeshk commented Mar 6, 2018

Here you go:

root@openwrt:~# iw wlan1 interface add mon0 type monitor
root@openwrt:~# ifconfig mon0 up
root@openwrt:~# iw wlan1 info
Interface wlan1
    ifindex 7343
    wdev 0x1000007ab
    addr 60:38:e0:xx:xx:xx
    ssid SSID
    type AP
    wiphy 1
    channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
    txpower 30.00 dBm
root@openwrt:~# uci show wireless.radio1
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.hwmode='11g'
wireless.radio1.path='soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
wireless.radio1.country='US'
wireless.radio1.channel='11'
wireless.radio1.htmode='HT20'
wireless.radio1.legacy_rates='1'
wireless.radio1.txpower='30'
root@openwrt:~# uci show wireless.default_radio1
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.ssid='SSID'
wireless.default_radio1.key='PASSWORD'
wireless.default_radio1.mode='ap'
wireless.default_radio1.encryption='psk2'

# changing encryption to nothing

root@openwrt:~# uci set wireless.default_radio1.encryption=''
root@openwrt:~# uci commit wireless; wifi
root@openwrt:~# iw wlan1 interface add mon0 type monitor
root@openwrt:~# ifconfig mon0 up
root@openwrt:~# tcpdump -vvvi mon0 -n port 67 and port 68
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
tcpdump: pcap_loop: The interface went down
0 packets captured
2 packets received by filter
0 packets dropped by kernel

# bringing mon0 up again after commit

root@openwrt:~# tcpdump -vvvi mon0 -n port 67 and port 68
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
09:51:27.370789 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 255, id 9992, offset 0, flags [none], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from dc:4f:22:xx:xx:xx, length 308, xid 0xc4daac6a, Flags [none] (0x0000)
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        MSZ Option 57, length 2: 1500
        Hostname Option 12, length 10: "ESP_C3C48F"
        Parameter-Request Option 55, length 12: 
          Subnet-Mask, Default-Gateway, BR, Domain-Name-Server
          Domain-Name, Netbios-Name-Server, Netbios-Node, Netbios-Scope
          Router-Discovery, Static-Route, Classless-Static-Route, Vendor-Option
        END Option 255, length 0
        PAD Option 0, length 0, occurs 34
09:51:27.371232 6.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 17190, offset 0, flags [none], proto UDP (17), length 329)
    192.168.1.1.67 > 192.168.1.223.68: [udp sum ok] BOOTP/DHCP, Reply, length 301, xid 0xc4daac6a, Flags [none] (0x0000)
      Your-IP 192.168.1.223
      Server-IP 192.168.1.1
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 192.168.1.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 192.168.1.255
        Default-Gateway Option 3, length 4: 192.168.1.1
        Domain-Name Option 15, length 3: "lan"
        Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
        END Option 255, length 0
09:51:29.163009 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 255, id 9993, offset 0, flags [none], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from dc:4f:22:xx:xx:xx, length 308, xid 0xc4daac6a, Flags [none] (0x0000)
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        MSZ Option 57, length 2: 1500
        Hostname Option 12, length 10: "ESP_C3C48F"
        Parameter-Request Option 55, length 12: 
          Subnet-Mask, Default-Gateway, BR, Domain-Name-Server
          Domain-Name, Netbios-Name-Server, Netbios-Node, Netbios-Scope
          Router-Discovery, Static-Route, Classless-Static-Route, Vendor-Option
        END Option 255, length 0
        PAD Option 0, length 0, occurs 34
09:51:29.163511 [bit 15] IP (tos 0xc0, ttl 64, id 17265, offset 0, flags [none], proto UDP (17), length 329)
    192.168.1.1.67 > 192.168.1.223.68: [udp sum ok] BOOTP/DHCP, Reply, length 301, xid 0xc4daac6a, Flags [none] (0x0000)
      Your-IP 192.168.1.223
      Server-IP 192.168.1.1
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 192.168.1.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 192.168.1.255
        Default-Gateway Option 3, length 4: 192.168.1.1
        Domain-Name Option 15, length 3: "lan"
        Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
        END Option 255, length 0
09:51:33.151352 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 255, id 9994, offset 0, flags [none], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from dc:4f:22:xx:xx:xx, length 308, xid 0xc4daac6a, Flags [none] (0x0000)
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        MSZ Option 57, length 2: 1500
        Hostname Option 12, length 10: "ESP_C3C48F"
        Parameter-Request Option 55, length 12: 
          Subnet-Mask, Default-Gateway, BR, Domain-Name-Server
          Domain-Name, Netbios-Name-Server, Netbios-Node, Netbios-Scope
          Router-Discovery, Static-Route, Classless-Static-Route, Vendor-Option
        END Option 255, length 0
        PAD Option 0, length 0, occurs 34
09:51:33.151817 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 17502, offset 0, flags [none], proto UDP (17), length 329)
    192.168.1.1.67 > 192.168.1.223.68: [udp sum ok] BOOTP/DHCP, Reply, length 301, xid 0xc4daac6a, Flags [none] (0x0000)
      Your-IP 192.168.1.223
      Server-IP 192.168.1.1
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 192.168.1.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 192.168.1.255
        Default-Gateway Option 3, length 4: 192.168.1.1
        Domain-Name Option 15, length 3: "lan"
        Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
        END Option 255, length 0
09:51:33.161433 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 255, id 9995, offset 0, flags [none], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from dc:4f:22:xx:xx:xx, length 308, xid 0x87a54e1, Flags [none] (0x0000)
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        MSZ Option 57, length 2: 1500
        Requested-IP Option 50, length 4: 192.168.1.223
        Server-ID Option 54, length 4: 192.168.1.1
        Parameter-Request Option 55, length 12: 
          Subnet-Mask, Default-Gateway, BR, Domain-Name-Server
          Domain-Name, Netbios-Name-Server, Netbios-Node, Netbios-Scope
          Router-Discovery, Static-Route, Classless-Static-Route, Vendor-Option
        Hostname Option 12, length 10: "ESP_C3C48F"
        END Option 255, length 0
        PAD Option 0, length 0, occurs 22
09:51:33.161915 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 17503, offset 0, flags [none], proto UDP (17), length 329)
    192.168.1.1.67 > 192.168.1.223.68: [udp sum ok] BOOTP/DHCP, Reply, length 301, xid 0x87a54e1, Flags [none] (0x0000)
      Your-IP 192.168.1.223
      Server-IP 192.168.1.1
      Client-Ethernet-Address dc:4f:22:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.1.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 192.168.1.255
        Default-Gateway Option 3, length 4: 192.168.1.1
        Domain-Name Option 15, length 3: "lan"
        Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
        END Option 255, length 0
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
root@openwrt:~# tcpdump -vvvi mon0 icmp
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
09:44:33.637280 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 64, id 59337, offset 2960, flags [none], proto ICMP (1), length 68)
    172.20.20.20 > 172.20.20.1: icmp
09:45:18.723786 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 64, id 36034, offset 2960, flags [none], proto ICMP (1), length 68)
    172.20.20.20 > 172.20.20.1: icmp
09:45:31.422138 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 64, id 60039, offset 2960, flags [none], proto ICMP (1), length 68)
    172.20.20.20 > 172.20.20.1: icmp
09:49:16.399876 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 64, id 5584, offset 2960, flags [none], proto ICMP (1), length 68)
    172.20.20.20 > 172.20.20.1: icmp
tcpdump: pcap_loop: The interface went down
4 packets captured
4 packets received by filter
0 packets dropped by kernel

#getting mon0 up again

root@openwrt:~# tcpdump -vvvi mon0 icmp
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
09:51:36.152332 2.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 63580, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 9998, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:39.141206 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 63806, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10000, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:40.130078 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 63834, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10001, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:41.119908 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 63910, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10003, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:43.110549 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 63945, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10005, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:44.805429 1.0 Mb/s 2462 MHz 11b 0dBm signal antenna 0 IP (tos 0x0, ttl 64, id 60163, offset 0, flags [DF], proto ICMP (1), length 72)
    172.20.20.1 > 172.20.20.20: ICMP echo reply, id 1611, seq 1, length 52
09:51:47.069355 2.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 64085, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10011, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:48.061170 1.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 64176, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10012, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:50.049335 [bit 15] IP (tos 0xc0, ttl 64, id 64371, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10014, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:54.040579 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 64517, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10016, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:55.030141 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 64531, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10017, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:56.026488 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 64609, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10018, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:51:58.001075 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 64725, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10020, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:01.990393 [bit 15] IP (tos 0xc0, ttl 64, id 65034, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10022, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:02.979849 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 65055, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10024, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:04.977891 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 65191, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10025, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:07.970345 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 65354, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10027, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:08.971615 [bit 15] IP (tos 0xc0, ttl 64, id 65385, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10029, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:09.962487 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 65422, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10030, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:11.951276 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 65444, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10032, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:15.940014 2.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 65484, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10034, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:16.929977 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 5, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10035, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:18.878399 1.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 78, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10044, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:22.870646 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 399, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10046, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:23.860260 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 480, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10048, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:24.849949 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 542, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10049, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:26.851893 2.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 560, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-a.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10051, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-a.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:30.820435 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 820, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10053, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:31.810006 5.5 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 851, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10054, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
09:52:33.790113 2.0 Mb/s [bit 15] IP (tos 0xc0, ttl 64, id 886, offset 0, flags [none], proto ICMP (1), length 90)
    CyFi.lan > ESP_C3C48F.lan: ICMP google-public-dns-b.google.com udp port 53 unreachable, length 70
    IP (tos 0x0, ttl 254, id 10056, offset 0, flags [none], proto UDP (17), length 62)
    ESP_C3C48F.lan.49153 > google-public-dns-b.google.com.53: [udp sum ok] 0+ A? mq.gw.tuyaus.com. (34)
^C
30 packets captured
30 packets received by filter
0 packets dropped by kernel
daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
kern.debug kernel: [147108.775654] ieee80211 phy1: staid 1 deleted
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated
kern.debug kernel: [147157.746569] ieee80211 phy1: staid 1 deleted
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx WPA: pairwise key handshake completed (RSN)
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated

# rebooting wlan1 without encryption

kern.info kernel: [147208.126601] device wlan1 left promiscuous mode
kern.info kernel: [147208.131207] br-lan: port 2(wlan1) entered disabled state
daemon.notice hostapd: wlan1: interface state ENABLED->DISABLED
daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED dc:4f:22:xx:xx:xx
daemon.notice netifd: radio2 (10768): Could not find PHY for device 'radio2'
daemon.notice netifd: radio2 (10790): WARNING: Variable 'data' does not exist or is not an array/object
daemon.notice hostapd: wlan1: AP-DISABLED
daemon.notice hostapd: wlan1: CTRL-EVENT-TERMINATING
daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
daemon.notice netifd: radio0 (10783): command failed: Not supported (-95)
daemon.notice hostapd: nl80211: Failed to remove interface wlan1 from bridge br-lan: Invalid argument
kern.debug kernel: [147208.296360] ieee80211 phy1: staid 1 deleted
kern.debug kernel: [147208.314028] ieee80211 phy1: change: 0x40
kern.debug kernel: [147208.395013] ieee80211 phy1: change: 0x100
daemon.notice netifd: radio1 (10837): command failed: Not supported (-95)
daemon.err hostapd: Configuration file: /var/run/hostapd-phy1.conf
kern.debug kernel: [147208.985220] ieee80211 phy1: change: 0xffffffff
kern.info kernel: [147209.074433] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
kern.info kernel: [147209.081237] br-lan: port 2(wlan1) entered blocking state
kern.info kernel: [147209.086678] br-lan: port 2(wlan1) entered disabled state
kern.info kernel: [147209.092222] device wlan1 entered promiscuous mode
kern.info kernel: [147209.097060] br-lan: port 2(wlan1) entered blocking state
kern.info kernel: [147209.102490] br-lan: port 2(wlan1) entered forwarding state
daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
daemon.err hostapd: Using interface wlan1 with hwaddr 60:38:e0:xx:xx:xx and ssid "SSID"
kern.debug kernel: [147209.108943] ieee80211 phy1: change: 0x100
kern.debug kernel: [147209.122078] ieee80211 phy1: change: 0x42
kern.info kernel: [147209.272310] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->ENABLED
daemon.notice hostapd: wlan1: AP-ENABLED
daemon.notice netifd: Network device 'wlan1' link is up
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: associated (aid 1)
daemon.notice hostapd: wlan1: AP-STA-CONNECTED dc:4f:22:xx:xx:xx
daemon.info dnsmasq-dhcp[3326]: DHCPDISCOVER(br-lan) dc:4f:22:xx:xx:xx
daemon.info dnsmasq-dhcp[3326]: DHCPOFFER(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
daemon.info dnsmasq-dhcp[3326]: DHCPREQUEST(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx
daemon.info dnsmasq-dhcp[3326]: DHCPACK(br-lan) 192.168.1.223 dc:4f:22:xx:xx:xx ESP_C3C48F
daemon.info hostapd: wlan1: STA dc:4f:22:xx:xx:xx IEEE 802.11: authenticated

PS: I have the client blocked from accessing the internet (hence the port 53 unreachable)

@eduperez
Copy link

eduperez commented Jan 29, 2020

@powderluv I found a method to keep phy#2 (which I use for my IoT devices) and still be able to use phy#0 at 160MHz: #280 (comment)

@powderluv
Copy link

powderluv commented Jan 29, 2020

Awesome!! thanks

@Attila-FIN
Copy link

Attila-FIN commented Feb 20, 2020

I've had this issue for long time with my ESP8266 IoT devices and my WRT3200ACM. My solution hasd been to completely disable the 2.4GHz interface and use an old AP at 2.4GHz.
Now that I've installed the latest Openwrt (19.07.1), I gave it a second chance and started to test if interface got better driver, but unfortunately not.
Now that I disabled the WMM, the ESP8266 devices got connected to the AP properly, however the WiFi link got 802.11g limited speed (around 18MB/s in iperf3).
I did not want to create a new SSID with disabled WMM for my IoT devices (I've been using a single SSID) and reconfigure all the IoT devices, so I decided to created a 2nd SSID with the same name as the old one, and disable the WMM for it. Then I just created the "deny" list for all my IoT devices' MAC addresses on the old SSID, and the same list as "allow" for the new SSID.

@plasmolysis369
Copy link

plasmolysis369 commented Mar 9, 2020

Is there any other solution?As far as I know, the official firmware does not have this problem.I really don‘t want to disable WMM,I want speed......

@tiliarou
Copy link

tiliarou commented Mar 10, 2020

Isn't the comment just above a solution for you ?
If I understood correctly, you create 2 networks, one with WMM and one without, you blacklist/whitelist corresponding devices for each network and you have a workaround. Can be same SSID or not, depends on your current and wanted setup.
So you can have 3 networks in total, using 3 interfaces phy#0 to phy#2

@diabl0w
Copy link

diabl0w commented Mar 26, 2020

Isn't the comment just above a solution for you ?
If I understood correctly, you create 2 networks, one with WMM and one without, you blacklist/whitelist corresponding devices for each network and you have a workaround. Can be same SSID or not, depends on your current and wanted setup.
So you can have 3 networks in total, using 3 interfaces phy#0 to phy#2

just to clarify, you can also have 3 interfaces on only 2 wifi devices... in other words, you can have multiple interfaces on one phy#. This is what I do to prevent interference at 2.4 ghz level (or at least thats my logic behind it)

@chithanhhoang
Copy link

chithanhhoang commented Sep 10, 2020

Hi all, I used to work for HP/Aruba in the wifi group, I remember we had an issue with Marvell chipset being used in a Linksys multimedia bridge. The problem behavior is exactly like the one discussed in this thread, it is related to LDPC feature, I found out if LDPC is enabled, the Linksys device won`t like it when receiving, so I end up suggesting to our customer we disable LDPC transmit from the AP (which use Atheros chipset 802.11n AR9390), even though the Linksys device advertise it can receive LDPC packet, by disabling from the AP fixed the issue of DHCP 8-)
When you disable WMM, there is no 802.11n rate, so LDPC is not being transmitted as it is a 802.11n optional feature, that is why disabling WMM looks like a work around.
So guys try to disable LDPC if you can from the radio config of the Marvell.
From the probe-request/response I can see the ESP cannot receive LDPC but it can transmit since the Marvell is advertising it can rx LDPC. Sometime strange stuff happen in wifi chip design, one cannot rx LDPC but it can tx LDPC, well at least for 802.11n, for 802.11ac I believe it is mandatory to rx LDPC.
I hope somebody can try my suggestion.
Bon wifi!!

@chithanhhoang
Copy link

chithanhhoang commented Sep 11, 2020

I just bought a used WRT1900ACS, so the issue here can cause all my wifi IOT devices problem as most of them is based on ESP8266. I have a linux laptop with AR9390 so wifi sniffing is no issue if needed.
I found this old thread https://dev.archive.openwrt.org/ticket/12356#no1 where there was issue with LDPC and work around is like I suggested i.e. disable LDPC from /etc/config/wireless or recompiling the driver.

@thecode
Copy link

thecode commented Sep 11, 2020

Looking at the ESP8266 SDK for RTOS it looks like there was a fix for not sending assoc request with LDPC
https://github.com/espressif/ESP8266_RTOS_SDK/releases

Fixed the issue where assoc capability info is sent incorrectly with LDPC support. ESP8266 does not support LDPC.

However most of the IOT devices I know are not using RTOS SDK, but using the ESP8266 core for Arduino and I did not find any info about it there.
I tried to disable LDPC by adding:

config wifi-device 'radio1'
	option ldpc '0'

It looks like the parameter is updated correctly in "hostapd-phy1.conf" but I'm not sure if the beacon frame is updated correctly.
I will need to setup a sniffer to verify.
In the meantime I compared old captures I have and indeed the driver (WRT32X) shows it supports the LDPC capability

@diabl0w
Copy link

diabl0w commented Sep 11, 2020

Hi all, I used to work for HP/Aruba in the wifi group, I remember we had an issue with Marvell chipset being used in a Linksys multimedia bridge. The problem behavior is exactly like the one discussed in this thread, it is related to LDPC feature, I found out if LDPC is enabled, the Linksys device won`t like it when receiving, so I end up suggesting to our customer we disable LDPC transmit from the AP (which use Atheros chipset 802.11n AR9390), even though the Linksys device advertise it can receive LDPC packet, by disabling from the AP fixed the issue of DHCP 8-)
When you disable WMM, there is no 802.11n rate, so LDPC is not being transmitted as it is a 802.11n optional feature, that is why disabling WMM looks like a work around.
So guys try to disable LDPC if you can from the radio config of the Marvell.
From the probe-request/response I can see the ESP cannot receive LDPC but it can transmit since the Marvell is advertising it can rx LDPC. Sometime strange stuff happen in wifi chip design, one cannot rx LDPC but it can tx LDPC, well at least for 802.11n, for 802.11ac I believe it is mandatory to rx LDPC.
I hope somebody can try my suggestion.
Bon wifi!!

Thanks for trying, but this hasn't seemed to help... at least for me. I verified that my hostapd-ph1.conf was properly configured so that isn't the problem. I've had my WRT for many years now, since this issue was opened... so far the only solution is to disable WMM, which unfortunately causes issues with some of my other devices so I end up having an extra interface as a bandaid. I provided good detailed wireshark logs in this thread somewhere back if anyone is interested

i posted the logs in my other account, here: #278 (comment)

@thecode
Copy link

thecode commented Sep 12, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
So far I have enabled WMM and disabled LDPC and 22 IOT devices are associating without any problem.
I do remember it was tricky so that it looks to be working but after a reboot of the devices or router they do not reconnect.
I have also updated firmware on my ESP devices many times since this thread started so I do not know if this was solved on the ESP side.
I will keep WMM enabled and LDPC disabled and keep tracking this.

@diabl0w
Copy link

diabl0w commented Sep 12, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
So far I have enabled WMM and disabled LDPC and 22 IOT devices are associating without any problem.
I do remember it was tricky so that it looks to be working but after a reboot of the devices or router they do not reconnect.
I have also updated firmware on my ESP devices many times since this thread started so I do not know if this was solved on the ESP side.
I will keep WMM enabled and LDPC disabled and keep tracking this.

if you have an extra nodemcu, can you try flashing this https://github.com/sidoh/esp8266_milight_hub and see if it is able to connect to your wifi?

@thecode
Copy link

thecode commented Sep 12, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
I will keep WMM enabled and LDPC disabled and keep tracking this.

if you have an extra nodemcu, can you try flashing this https://github.com/sidoh/esp8266_milight_hub and see if it is able to connect to your wifi?

I flashed a binary from the project you suggested on a generic esp8266 board, it did not connect to my router with LDPC disabled/WMM enabled, once I enabled LDPC and disabled WMM it connected OK.

So this means that the LDPC is probably not the casue for ESP devices not connecting.
Just for reference the project you suggested is using Arduino ESP core 2.4.2, most of my devices are using 2.7.x.

@diabl0w
Copy link

diabl0w commented Sep 12, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
I will keep WMM enabled and LDPC disabled and keep tracking this.

if you have an extra nodemcu, can you try flashing this https://github.com/sidoh/esp8266_milight_hub and see if it is able to connect to your wifi?

I flashed a binary from the project you suggested on a generic esp8266 board, it did not connect to my router with LDPC disabled/WMM enabled, once I enabled LDPC and disabled WMM it connected OK.

So this means that the LDPC is probably not the casue for ESP devices not connecting.
Just for reference the project you suggested is using Arduino ESP core 2.4.2, most of my devices are using 2.7.x.

thanks for the test! I have the same experience. whether this is an issue with ESP or mwlwifi I don't think has been determined, but only mwlwifi users seem to ever have a problem these devices

@chithanhhoang
Copy link

chithanhhoang commented Sep 12, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
I will keep WMM enabled and LDPC disabled and keep tracking this.

if you have an extra nodemcu, can you try flashing this https://github.com/sidoh/esp8266_milight_hub and see if it is able to connect to your wifi?

I flashed a binary from the project you suggested on a generic esp8266 board, it did not connect to my router with LDPC disabled/WMM enabled, once I enabled LDPC and disabled WMM it connected OK.

So this means that the LDPC is probably not the casue for ESP devices not connecting.
Just for reference the project you suggested is using Arduino ESP core 2.4.2, most of my devices are using 2.7.x.

Hi, can you do a wireless trace during the test with LDPC disabled and WMM on, if you disable WMM there is no LDPC because no 802.11n frame, only legacy b/g, so indirec
I saw from earlier traces of this thread the 4-ways handshake finished, and next step is DHCP, it looks from the trace the client i.e. ESP tried to send DHCP request but no reply from Marvell, so maybe Marvell did not see it well.

I will try to setup my Linksys router because if it rains tomorrow, no tennis so can play with this issue 8-)

@diabl0w
Copy link

diabl0w commented Sep 12, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
I will keep WMM enabled and LDPC disabled and keep tracking this.

if you have an extra nodemcu, can you try flashing this https://github.com/sidoh/esp8266_milight_hub and see if it is able to connect to your wifi?

I flashed a binary from the project you suggested on a generic esp8266 board, it did not connect to my router with LDPC disabled/WMM enabled, once I enabled LDPC and disabled WMM it connected OK.
So this means that the LDPC is probably not the casue for ESP devices not connecting.
Just for reference the project you suggested is using Arduino ESP core 2.4.2, most of my devices are using 2.7.x.

Hi, can you do a wireless trace during the test with LDPC disabled and WMM on, if you disable WMM there is no LDPC because no 802.11n frame, only legacy b/g, so indirec
I saw from earlier traces of this thread the 4-ways handshake finished, and next step is DHCP, it looks from the trace the client i.e. ESP tried to send DHCP request but no reply from Marvell, so maybe Marvell did not see it well.

I will try to setup my Linksys router because if it rains tomorrow, no tennis so can play with this issue 8-)

correct with wmm on, handshake completes, but there is no DHCP offer made after DHCP discover.
here is wireshark with ldpc off,wmm on which does not connect successfully:

filteredldpcoffwmmon.pcapng.zip

@Attila-FIN
Copy link

Attila-FIN commented Sep 12, 2020

I can confirm that my ESP8266 based devices are able to connect to Wi-Fi network with WMM enabled after configuring Wi-Fi interface with

config wifi-device 'radio1'
	option ldpc '0'

I could also see in Wireshark, that bit wlan.ht.capabilities.ldpccoding got zeroed out in beacon frames (HT LDPC coding capability: Transmitter does not support receiving LDPC coded packets).
I tested network speed from my laptop with 2 spatial streams (Intel AX200), at the ideal max raw 144.4 Mbps rate, and I could measure around 100 Mbps TCP traffic with iperf3.
So 2.4 GHz Wi-Fi on my WRT3200ACM works correctly, without the two interface configs with whitelist and blacklist.

Update:
After rebooting the router, the Sonoff devices (EC:FA:BC) with ESPEasy do not connect back the Wi-Fi network, but other ESP8266 based LED controllers and WEMOS D1 MINI based RF MQTT gateway work correctly. I will need to check if those Sonoff devices can connect to the WRT3200ACM when restarted or brought more near (they normally connect to an other AP).

@chithanhhoang
Copy link

chithanhhoang commented Sep 13, 2020

I have verified with a sniffer that the LDPC flag is updated correctly with "option ldpc '0'".
I will keep WMM enabled and LDPC disabled and keep tracking this.

if you have an extra nodemcu, can you try flashing this https://github.com/sidoh/esp8266_milight_hub and see if it is able to connect to your wifi?

I flashed a binary from the project you suggested on a generic esp8266 board, it did not connect to my router with LDPC disabled/WMM enabled, once I enabled LDPC and disabled WMM it connected OK.
So this means that the LDPC is probably not the casue for ESP devices not connecting.
Just for reference the project you suggested is using Arduino ESP core 2.4.2, most of my devices are using 2.7.x.

Hi, can you do a wireless trace during the test with LDPC disabled and WMM on, if you disable WMM there is no LDPC because no 802.11n frame, only legacy b/g, so indirec
I saw from earlier traces of this thread the 4-ways handshake finished, and next step is DHCP, it looks from the trace the client i.e. ESP tried to send DHCP request but no reply from Marvell, so maybe Marvell did not see it well.
I will try to setup my Linksys router because if it rains tomorrow, no tennis so can play with this issue 8-)

correct with wmm on, handshake completes, but there is no DHCP offer made after DHCP discover.
here is wireshark with ldpc off,wmm on which does not connect successfully:

filteredldpcoffwmmon.pcapng.zip

Hi, can you share the passphrase of WPA2 settings, I can input to wireshark to decode frames since your trace has 4-ways handshake. Also can you keep ACK frames in trace, it would help to troubleshoot if receiver got it right or not, thanks.

@chithanhhoang
Copy link

chithanhhoang commented Sep 14, 2020

I am using stock firmware 1.0.3.187766 on the WRT1900ACS to gather some traces with my ESP, the stock firmware is really bad with respect to configuration, cannot wait to switch to openwrt.
Anyhow, my ESP connected ok to the router, I repeated the test by having my wifi plug piggy back on another one (that is on another network and channel) to on/off and capture traces easily.
I found the dhcp does not work on first attempt, I see the ESP retries many times DHCP, and the router has to lower txrate to 1M, the distance between them is about 10m, initially I saw router sent very high rate 65M and gradually downgrade until ESP ACK, but in the end the ESP got connect.

One finding I found interesting is on probe response, the router reply with "duplicate" HT Capabilities, the first HT Capabilities tag(45) has LDPC on, but subsequent HT Capabilities tag (221) has LDPC off, my guess is the ESP parse the 2nd tag and take the latest value which is LDPC disable. From the openwrt trace here in this thread, there is no 2nd HT Capabilities Tag. You can browse my trace.

capture20200914b-marvell-channel6-iot-assoc-dhcp-retiries.zip

Tag: HT Capabilities (802.11n D1.10)
Tag Number: HT Capabilities (802.11n D1.10) (45)
Tag length: 26
HT Capabilities Info: 0x006f
A-MPDU Parameters: 0x17
Rx Supported Modulation and Coding Scheme Set: MCS Set
HT Extended Capabilities: 0x0000
Transmit Beam Forming (TxBF) Capabilities: 0x1807ff1f
Antenna Selection (ASEL) Capabilities: 0x00

Tag: Vendor Specific: Epigram, Inc.: HT Capabilities (802.11n D1.10)
Tag Number: Vendor Specific (221)
Tag length: 30
OUI: 00:90:4c (Epigram, Inc.)
Vendor Specific OUI Type: 51
802.11n (Pre) Type: HT Capabilities (802.11n D1.10) (51)
HT Capabilities Info (VS): 0x006e
A-MPDU Parameters (VS): 0x17
Rx Supported Modulation and Coding Scheme Set (VS): MCS Set
HT Extended Capabilities (VS): 0x0000
Transmit Beam Forming (TxBF) Capabilities (VS): 0x1807ff1f
Antenna Selection (ASEL) Capabilities (VS): 0x00

From my own experience during the era of 802.11n, before the 802.11n is ratified chipset vendors released pre-802.11n and probably Marvell forgot to remote the tag 221 used for pre-802.11n.

For those who want to decode with wireshark, the SSID is Linksys13548 and WPA password is 9r4nu0dxvw ,no worry 8-) this password will be short live when I switch to openwrt. Do a filter on eapol to quickly locate the area on interest.

@chithanhhoang
Copy link

chithanhhoang commented Sep 16, 2020

Today I did a switch over to WRT1900ACS 2.4G using stock fw for a test and all IOT ESP devices reconnected without any issue.
My current main router is ASUS AC68P running merlin-wrt. I could not find AC68P used at decent price so I am validating the WRT1900ACS as backup, with covid19 I work from home since March so cannot afford down time if router decides to quit.

So far I can say that the WRT1900ACS is a notch above ASUS AC68P as far as wifi performance.

@MoranLevy
Copy link

MoranLevy commented Sep 18, 2020

Had this problem for a week.
Thanks to this thread I've managed to solve it on my WRT32xb

Add
option ldpc '0' to the "config wifi-device 'radio1'" secotion
Add
option wmm '0' to the "config wifi-iface 'default_radio1'" section
Reboot
Worked

thanks everyone for the help

@BrainSlayer
Copy link

BrainSlayer commented Sep 19, 2020

@MoranLevy just wmm 0 is enough. but thats no solution. it disabled 802.11ac and 802.11n and turns the radio to legacy mode. so LDPC has no effect anymore.

@MoranLevy
Copy link

MoranLevy commented Sep 19, 2020

Thanks

When it finally worked I assumed that it is the combination and did not test it further.You are right only setting wmm is enough
Could you elaborate a bit more about the second part ?
If I set it on the 802.11n will it impact my 802.11ac ?

@chithanhhoang
Copy link

chithanhhoang commented Sep 19, 2020

@MoranLevy To answer your question about the second part, I presume you asked about LDPC disable, disable LDPC will not impact much your wifi as LDPC is an improvement of FEC (Forward Error Correction) vs the regular BCC. You will notice the good effect of LDPC if you are doing long distance. LDPC allow to recover a frame with some bits errors, usually frames that are received with weak signal.
As I mentioned earlier in this thread LDPC is optional for 802.11n but mandatory for 802.11ac.
Support for 802.11ac on 2.4G is sketchy because 802.11ac was designed for 5.8G initially, not 2.4G, Broadcom vendor was the first to introduce 802.11ac into 2.4G (they called Turbo-QAM, a very fancy name), but that requires Broadcom to Broadcom chipset, it is proprietary, however Atheros/QCA and the rest eventually follow Broadcom and allow 802.11ac to operate on 2.4G.
If you decode a beacon on the Marvell, you can see the router advertise both 802.11n and 802.11ac capabilities on 2.4G.
Most of 2.4G devices I have all connect with 802.11n on 2.4G, if you sniff wifi, when the devices associate that you can see which rates they eventually agree on.
Here you disable LDPC, it will be disabled for both 802.11n rates and 802.11ac rates, disable here mean the router tells to the remote device it will not accept to receive frame encoded with LDPC format, it does not prevent the router to send LDPC if the remote device advertises it can receive such frame.
Sorry for the lengthy answer but your question is a good one and worth explaining.

@BrainSlayer
Copy link

BrainSlayer commented Sep 23, 2020

@chithanhhoang this is wrong. turboqam works with qca, marvell, mediatek and everything else capable of doing vht in 2.4 ghz. however. mac80211 does prevent of using vht in 2.4 ghz like the rest of the drivers. its very easy to patch mac80211 and the driver to support turboqam. basicly just vht must be enabled for 2.4 ghz and hostapd must be configured to broadcast a special beacon ie info field. to archive this you need to mod the drivers for vht capabilities in 2.4 ghz and you need to set "vendor_vht=1" in hostapd.conf. this ie element is supported by alot of windows client drivers. i implemented this to dd-wrt since a long time to support turbo qam on all chipsets

@chithanhhoang
Copy link

chithanhhoang commented Sep 23, 2020

@BrainSlayer I never said turboqam i.e. 802.11ac 256QAM does not work on others vendors chipsets in 2.4, I said in my post in the beginning Broadcom was the first to put the hack into 2.4G and called it turboqam, and eventually others vendors followed. I worked on both Broadcom and Atheros proprietary drivers so I did the similar hack in 2013 on QCA9880 to interop with Broadcom 43460 2.4 256QAM. I also used the Veriwave to force 2.4 256QAM into QCA radio. Once you tune the radio any frequencies, the tx/rx of 802.11ac does not care what is happening at analog level.
I just did a test with a more recent wifi card Mediatek and you are right, the data rate used is 802.11ac in 2.4 and LDPC is being txed by Marvell and client. I could not test Intel client because I use the port for egpu experiment,
Regarding LDPC, I think Marvell rx LDPC correctly in 802.11ac but not 802.11n where ESP only 2.4.

@chithanhhoang
Copy link

chithanhhoang commented Oct 3, 2020

Looking at the ESP8266 SDK for RTOS it looks like there was a fix for not sending assoc request with LDPC
https://github.com/espressif/ESP8266_RTOS_SDK/releases

Fixed the issue where assoc capability info is sent incorrectly with LDPC support. ESP8266 does not support LDPC.

However most of the IOT devices I know are not using RTOS SDK, but using the ESP8266 core for Arduino and I did not find any info about it there.
I tried to disable LDPC by adding:

config wifi-device 'radio1'
	option ldpc '0'

It looks like the parameter is updated correctly in "hostapd-phy1.conf" but I'm not sure if the beacon frame is updated correctly.
I will need to setup a sniffer to verify.
In the meantime I compared old captures I have and indeed the driver (WRT32X) shows it supports the LDPC capability

@thecode You are right, I found the git commit that match your good findings, the change is made indeed into the opaque libcore.a of esp8266 sdk. So anything that was using the esp8266 sdk prior to the fix will cause connectivity issue if the transmitter thinks it can tx ldpc packet to receiver.

commit 31299b1ee2c886d71da92a2ac4429d5b4ecd3bc1
Author: Zhang Jun Hao zhangjunhao@espressif.com
Date: Fri Oct 26 17:47:06 2018 +0800

fix(lib): fix send assoc capability info with LDPC support

diff --git a/components/esp8266/lib/VERSION b/components/esp8266/lib/VERSION
index ca3494d2..fcd95d2a 100644
--- a/components/esp8266/lib/VERSION
+++ b/components/esp8266/lib/VERSION
@@ -1,6 +1,6 @@
gwen:
core: ab8ff83

  • net80211: 27e282b
  • net80211: 0b37e27
    pp: 3110b52
    smartconfig:01980e2
    wpa: 01980e2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests