Is anyone else having problems with Amazon devices (Echo, Dot, FireTV, etc.) and DHCP on there openwrt boxes?
I've got an Echo and three Dots and am having all sorts of trouble with them dropping off the network regularly. (This wasn't a problem with my previous configuration of a DHCP server running on linux box connected to wired ethernet with an Apple Airport Extreme as router/AP).
The issues seems to be with them having difficulty renewing their DHCP leases. An initial request after boot goes well, but subsequent renews fail.
I always see DHCPDISCOVER followed DHCPOFFER but not always the REQUEST and ACK. Sometimes the devices will continue to do REQUEST/ACK cycles before giving up and deauthenticating from the wireless.
Here's a (very) quick example:
Fri Jun 29 14:46:06 2018 daemon.info hostapd: wlan1: STA 6c:56:97:27:fd:68 IEEE 802.11: associated (aid 1)
Fri Jun 29 14:46:06 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 6c:56:97:27:fd:68
Fri Jun 29 14:46:06 2018 daemon.info hostapd: wlan1: STA 6c:56:97:27:fd:68 WPA: pairwise key handshake completed (RSN)
Fri Jun 29 14:46:06 2018 daemon.info dnsmasq-dhcp[5401]: DHCPREQUEST(br-lan) 192.168.1.193 6c:56:97:27:fd:68
Fri Jun 29 14:46:06 2018 daemon.info dnsmasq-dhcp[5401]: DHCPACK(br-lan) 192.168.1.193 6c:56:97:27:fd:68 amazon-f0083adb9
Fri Jun 29 14:46:08 2018 daemon.info hostapd: wlan1: STA 6c:56:97:27:fd:68 IEEE 802.11: authenticated
Fri Jun 29 14:46:11 2018 daemon.info dnsmasq-dhcp[5401]: DHCPREQUEST(br-lan) 192.168.1.193 6c:56:97:27:fd:68
Fri Jun 29 14:46:11 2018 daemon.info dnsmasq-dhcp[5401]: DHCPACK(br-lan) 192.168.1.193 6c:56:97:27:fd:68 amazon-f0083adb9
Fri Jun 29 14:46:11 2018 daemon.info dnsmasq-dhcp[5401]: DHCPDISCOVER(br-lan) 6c:56:97:27:fd:68
Fri Jun 29 14:46:11 2018 daemon.info dnsmasq-dhcp[5401]: DHCPOFFER(br-lan) 192.168.1.193 6c:56:97:27:fd:68
Fri Jun 29 14:46:16 2018 daemon.info dnsmasq-dhcp[5401]: DHCPDISCOVER(br-lan) 6c:56:97:27:fd:68
Fri Jun 29 14:46:16 2018 daemon.info dnsmasq-dhcp[5401]: DHCPOFFER(br-lan) 192.168.1.193 6c:56:97:27:fd:68
Fri Jun 29 14:46:24 2018 daemon.info dnsmasq-dhcp[5401]: DHCPDISCOVER(br-lan) 6c:56:97:27:fd:68
Fri Jun 29 14:46:24 2018 daemon.info dnsmasq-dhcp[5401]: DHCPOFFER(br-lan) 192.168.1.193 6c:56:97:27:fd:68
Fri Jun 29 14:46:37 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 6c:56:97:27:fd:68
Fri Jun 29 14:46:37 2018 kern.debug kernel: [17631.001497] ieee80211 phy1: staid 1 deleted
Only cold booting the Amazon device fixes it.
This thread on the mikrotik forum suggests people are seeing a similar issue with Amazon Fire TV devices and suggests it's a bug with Amazon's firmware. Mikrotik obviously doesn't use dnsmasq for dhcp, so that eliminates the server as fault.
I appreciate that this has been flagged above as an Amazon bug but I was curious if any openwrt users had come across the same issue. I'll be trying to set my devices to static IP addresses tonight to see if this fixes the problem.
I've been doing some more Googling and wonder if it's connected to this
On Wed, Apr 26, 2017 at 1:22 PM, Rahmadi Trimananda <rtrimana@xxxxxxx> wrote:
> Hi Ann,
>
> I was dealing with AUTH/DEAUTH issues recently and I was using OpenWrt's
> hostapd that has an intermediary program called UCI. So, it has a bunch of
> config files that eventually set up hostapd to run on an OpenWrt system. You
> can have a look at this page:
> https://wiki.openwrt.org/doc/uci/wireless#inactivity_timeout_options where
> it explains some UCI Wifi options that might correspond to the actual
> options on hostapd. For example, ap_max_inactivity corresponds to
> max_inactivity.
>
> I got exactly the same set of messages. My device was associated and then
> disassociated right away, and it turned out to be a checksum bug and a DHCP
> bug on hostapd, when we activated an option called disable_dgaf on our
> system. This option makes hostapd calculate wrong checksum values and it
> causes DHCP ack to not be sent. And the latter caused the device to be
> registered and soon get disassociated and lose its IP. So I guess it might
> be other reasons for you as well. One suggestion is that you can change the
> log level in hostapd so that you can see more debug messages:
> http://stackoverflow.com/questions/32205140/hostapd-debug-level-configuration
Sorry to keep replying to my own thread, but I keep finding more stuff online that looks relevant:
So we managed to get this working on our side. There are two bugs in hostapd for disable_dgaf:
(1) Multicast UDP packets that are converted to unicast have the wrong UDP checksum. We are working around this problem using iptables:
iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM --checksum-fill
(2) The handle_dhcp function in dhcp_snoop.c does not properly convert to unicast all DHCPACK messages. If any of the return conditions are hit in the if statement, the code for converting broadcast packets to unicast is not executed. The client then fails to receive a DHCPACK, and depending on the client may fail the DHCP negotiation. We worked around this by moving the code for converting broadcast messages to unicast above the if statement for DHCPACK.
It looks suspiciously like the behaviour I'm seeing with my Amazon devices. I'll try and get a tcpdump later on tonight.
@WiteWulf any update on this issue you had?
I'm having the same issue with wrt1900acs, currently at r7020-43d70a7a9d.
Echo wifi is enabled for two SSIDs 5GHz (wlan0) and 2.4GHZ (wlan1). Both have different SSID. I used to have only 5GHz but seems disconnects from 2.4GHz as well.
After restarting echo it connects back again fine.
Sun Oct 28 04:07:18 2018 daemon.info hostapd: wlan1: STA fc:65:de:25:d8:58 IEEE 802.11: authenticated
Sun Oct 28 04:07:18 2018 daemon.info hostapd: wlan1: STA fc:65:de:25:d8:58 IEEE 802.11: associated (aid 2)
Sun Oct 28 04:07:18 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED fc:65:de:25:d8:58
Sun Oct 28 04:07:18 2018 daemon.info hostapd: wlan1: STA fc:65:de:25:d8:58 RADIUS: starting accounting session DB4B16AB9F772729
Sun Oct 28 19:07:26 2018 daemon.info hostapd: wlan1: STA fc:65:de:25:d8:58 WPA: group key handshake completed (RSN)
Sun Oct 28 21:24:10 2018 daemon.info dnsmasq-dhcp[27289]: DHCPREQUEST(br-lan) 192.168.1.193 fc:65:de:25:d8:58
Sun Oct 28 21:24:10 2018 daemon.info dnsmasq-dhcp[27289]: DHCPACK(br-lan) 192.168.1.193 fc:65:de:25:d8:58 amazon-cf08cfd96
Mon Oct 29 03:09:46 2018 daemon.info dnsmasq-dhcp[27289]: DHCPREQUEST(br-lan) 192.168.1.193 fc:65:de:25:d8:58
Mon Oct 29 03:09:46 2018 daemon.info dnsmasq-dhcp[27289]: DHCPACK(br-lan) 192.168.1.193 fc:65:de:25:d8:58 amazon-cf08cfd96
Mon Oct 29 04:07:18 2018 daemon.notice hostapd: wlan0: AP-STA-CONNECTED fc:65:de:25:d8:58
Mon Oct 29 04:07:18 2018 daemon.info dnsmasq-dhcp[27289]: DHCPREQUEST(br-lan) 192.168.1.193 fc:65:de:25:d8:58
Mon Oct 29 04:07:18 2018 daemon.info dnsmasq-dhcp[27289]: DHCPACK(br-lan) 192.168.1.193 fc:65:de:25:d8:58 amazon-cf08cfd96
Mon Oct 29 04:12:16 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED fc:65:de:25:d8:58
Mon Oct 29 04:12:16 2018 daemon.info hostapd: wlan1: STA fc:65:de:25:d8:58 IEEE 802.11: disassociated due to inactivity
Mon Oct 29 04:12:17 2018 daemon.info hostapd: wlan1: STA fc:65:de:25:d8:58 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Oct 29 08:56:15 2018 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED fc:65:de:25:d8:58
Sorry, should have replied in my own thread! I eventually found that ticking "Allow legacy 802.11b rates" in the Advanced Setting tab of the wireless device configuration tab solved the problem. I only had to do this for the 2.4GHz radio on my router as I keep all the IoT stuff on 2.4GHz and leave the 5GHz for user devices like laptops, phones and tablets. This solved the same issue I was also seeing with my Logitech Harmony hubs (DHCP loop).
The Amazon devices seem to do things "their own way" and weird little things like this can really screw them up. E.g. while they say they "support" 5GHz they only operate on channel 36, which is a rather unfortunate if that channel's busy in your neighbourhood and your router supports lots of other options.
Actually, it's the design of most APs that if there's congestion, or a radar conflict detected on the higher bands, that the AP itself will change to the lowest channel (i.e. 36).
Sorry, you misunderstand me: from what I can see, the Amazon Echo and Kindle Fire HD will only operate their 5GHZ radio on channel 36. If your AP has 5GHz radio configured on any other channel the Amazon kit simply will not see the advertised SSID. OpenWrt will drop down to lower channels if it's on a DFS channel and detects radar (mine does all the time as we live near an airport) but it doesn't go straight there. It drops down through the available channels leaving 36 as a last resort in my experience.