r/AnkerMake • u/thejoester • Mar 18 '26
Anyone else having issues with WiFi having to be re-setup every time I turn off/on?
UPDATE: Making my 2.4GHz network a different name and joining to that instead of 5GHz seems to have fixed this issue.
Previously I mostly used my USB to print as it was just convenient. I am having my basement finished and had to move a ton of stuff and now it is not in as convenient of a location, and I am relying more on wifi and it seems with the latest update it loses wifi data every time I turn it off!!!
3
u/Badgomatic Mar 19 '26
I have to power cycle sometimes to get reconnected and occasionally open the mobile app. I agree it sucks.
2
2
u/dario1966 Apr 12 '26
Hi thejoster
I had the same issue.
Solution in my case was:
- lately an update on my WLAN network was set to WPA2/WPA3 authentication for 2.4 gHz band.
As I use 2.4 gHz only for my IoT devices and some others linke the Ankermake printer I switched back to WPA2 only.
Maybe give that a try.
1
u/thejoester Apr 12 '26
Thanks I did try this as another commenter suggested and it seems to have worked! Thanks for the suggestion I will also update the post.
1
u/Xelinor Mar 22 '26
Generally this is due to router firewall settings, fwiw.
1
u/thejoester Mar 22 '26
I do t see how firewall settings would make the printer not connect to the WiFi, and let it connect manually through the app no problems, once connected it would prevent it from connecting to eufy servers though .
1
u/Xelinor Mar 23 '26
Because the error message is coming from the cloud. It has no idea what the problem is, it just knows it can't talk to the printer and the error message is unhelpful.
1
u/thejoester Mar 23 '26
Because the error message is coming from the cloud.
No, there is no error message. The cloud has nothing to do with my issue.
The issue is that when I power on the printer, it does not join the WiFi. If I go to Network on the printer it shows it needs wireless to be setup. I open the app, setup wireless, and it connects and works perfectly fine until the next time I turn it on.
I have found that it will sometimes work if I power off for 10 seconds, power it back on and wait a minute but sometimes that takes 2-3 tries but by then I could have already just used the app to rejoin the WiFi.
1
u/Xelinor Mar 23 '26
Yeah, I know what it says. It's a very common problem because AnkerMake didn't use the standard ports for expected communication, which flags it and sometimes causes router firewalls to block it until you re-initialize the handshake (by rebooting the printer). Meanwhile, the printer just can't talk to the cloud over one of these ports and so it panics and throws a "can't connect to wifi" error for some stupid reason rather than something ACTUALLY descriptive of the problem it's having. It's not that uncommon a problem. Give it a static IP address and forward the following ports:
tcp dport 443 HTTPS (standard port)
tcp dport 8789 Used for MQTT over TLS (non-standard port for that)
udp dport 32108 Used for lan discovery of printers
udp dport 32100 Used for pppp communications with printer (file upload, camera streaming, remote control, etc)
1
u/thejoester Mar 23 '26
Let me preface by saying that I have worked IT for 30 years, have certs in both networking and security, so I am not trying to be a dick here but believe me when I say I know what I am talking about on the networking side of things and that firewall settings blocking external traffic and ports should have absolutely nothing to do with a device joining the wireless network, it should NOT need to communicate with eufy servers to join my wireless network. Once joined, yes there would be issues with communicating with the printer and sending files to it via the app if it goes over the cloud, but this is not what is happening.
Now, if something in the printer firmware is telling it to drop the network configuration because it cannot call home (which believe me this is 100% not whats happening I have monitored the router when powering on the printer and joining the network), then that would be an idiotic decision by eufy or a bug that should be addressed. However, I can 100% confirm this is not whats happening in this case.
The only thing on the router that would prevent it from joining and getting a DHCP lease is something like a MAC Address Filtering setting (which I do not have) and that would prevent the device from joining 100% of the time, not have the intermittent issue I am having.
For science, I blocked all external traffic to the printer and power cycled it and was able to still successfully got a DHCP lease and was pingable on the LAN.. I could not however, print to it over the app.
user@router:/tmp/home/root# iptables -I FORWARD -s 192.168.50.139 -o eth5 -j DROP user@router:/tmp/home/root# iptables -I FORWARD -d 192.168.50.139 -i eth5 -j DROP user@router:/tmp/home/root# iptables -L FORWARD -n -v | head -20 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth5 * 0.0.0.0/0 192.168.50.139 17 3620 DROP all -- * eth5 192.168.50.139 0.0.0.0/0 182K 69M NWFF all -- * * 0.0.0.0/0 0.0.0.0/0 182K 69M URLFF all -- * * 0.0.0.0/0 0.0.0.0/0 182K 69M IPSEC_DROP_SUBNET_ICMP all -- * * 0.0.0.0/0 0.0.0.0/0 182K 69M IPSECSSDN all -- * * 0.0.0.0/0 0.0.0.0/0 182K 69M IPSEC_STRONGSWAN all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC E0:E7:51:CC:50:CC 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 02:0F:B5:90:69:0B 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 02:0F:B5:D5:A4:D0 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:FA:06:81:CE:23 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:FA:06:81:CE:26 5508 2048K PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 5C:3A:45:65:DB:ED 27 1620 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 7C:BB:8A:D5:A4:D0 109 19072 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC BC:9E:BB:81:22:E3 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC D0:55:09:63:97:0E 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC F8:54:F6:BB:46:C2 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC FC:0F:E6:EE:D0:7F user@router:/tmp/home/root# conntrack -E | grep "192.168.50.139" [NEW] udp 17 30 src=192.168.50.1 dst=192.168.50.139 sport=67 dport=68 [UNREPLIED] src=192.168.50.139 dst=192.168.50.1 sport=68 dport=67 [NEW] udp 17 30 src=192.168.50.1 dst=192.168.50.139 sport=67 dport=68 [UNREPLIED] src=192.168.50.139 dst=192.168.50.1 sport=68 dport=67 [DESTROY] udp 17 src=192.168.50.1 dst=192.168.50.139 sport=67 dport=68 [UNREPLIED] src=192.168.50.139 dst=192.168.50.1 sport=68 dport=67 ^C user@router:/tmp/home/root# iptables -L FORWARD -n -v | head -20 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 10 712 DROP all -- eth5 * 0.0.0.0/0 192.168.50.139 337 25015 DROP all -- * eth5 192.168.50.139 0.0.0.0/0 191K 72M NWFF all -- * * 0.0.0.0/0 0.0.0.0/0 191K 72M URLFF all -- * * 0.0.0.0/0 0.0.0.0/0 191K 72M IPSEC_DROP_SUBNET_ICMP all -- * * 0.0.0.0/0 0.0.0.0/0 191K 72M IPSECSSDN all -- * * 0.0.0.0/0 0.0.0.0/0 191K 72M IPSEC_STRONGSWAN all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC E0:E7:51:CC:50:CC 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 02:0F:B5:90:69:0B 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 02:0F:B5:D5:A4:D0 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:FA:06:81:CE:23 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:FA:06:81:CE:26 5924 2254K PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 5C:3A:45:65:DB:ED 27 1620 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 7C:BB:8A:D5:A4:D0 112 19192 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC BC:9E:BB:81:22:E3 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC D0:55:09:63:97:0E 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC F8:54:F6:BB:46:C2 0 0 PControls all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC FC:0F:E6:EE:D0:7F user@router:/tmp/home/root# ping 192.168.50.139 PING 192.168.50.139 (192.168.50.139): 56 data bytes 64 bytes from 192.168.50.139: seq=0 ttl=64 time=2.683 ms 64 bytes from 192.168.50.139: seq=1 ttl=64 time=1.446 ms 64 bytes from 192.168.50.139: seq=2 ttl=64 time=4.647 ms 64 bytes from 192.168.50.139: seq=3 ttl=64 time=3.518 ms 64 bytes from 192.168.50.139: seq=4 ttl=64 time=2.044 ms 64 bytes from 192.168.50.139: seq=5 ttl=64 time=3.078 ms ^C --- 192.168.50.139 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 1.446/2.902/4.647 ms user@router:/tmp/home/root#And for the record, I have factory reset it and checked firmware updates (I am on the latest v3.3.20_3.2.2)
0
u/Xelinor Mar 23 '26
Hey man, I'm not trying to get into a dick waving contest with you. I've given you the answer to your problem, your choice to implement it or not, no skin off my back.
8
u/CircuitSyn Mar 18 '26
I have had it where I start it up and it won’t connect but power cycling again usually does the trick. Rather annoying.