Except that it’s the same Apple TV I’ve had for years. And there was no firmware update on that device during the time when the problem began. AND if I reboot my ROUTER (not the Apple TV), then the router will assign it the correct IP. (ALSO, When I simply manually enter the correct IP on the Apple TV — instead of rebooting the router — it doesn’t fix anything.)Manual DHCP assignment is handled by recognizing the MAC address of the device that you want to have a custom IP address. Many new devices now have a feature that sends a random MAC addrress to the wifi router to limit tracking. This feature is typically enabled by default. Your Apple TV is probably set to provide a random MAC address to the router. The setting can be found in the network settings section of your Apple TV.
View attachment 54679
Definitely WiFi issues caused by 386.12_2 and 386.12_4. As you can see rolled back 386.12 has 0 problems.
This is slightly different than what was implied in your previous post. You said the Apple TV was getting a "random IP address" which we assumed was in your LAN's 192.168.x.y range. However 169.254.x.y is not a random address. It is a self assigned address that the device gives to itself when it cannot get a reply from a DHCP server. This usually means that the device has no connection to the network (e.g. a cable fault) or the DHCP server is offline.ALSO, my router normally assigns private IPs in the 192.168… range, whereas the incorrect IP address being assigned to the Apple TV when it comes out of standby is in the 169.254… range AND it has a diff subnet mask.
Months away. My current focus will be on 388.6.Any ideas on when the next GPL from Asus, and consequently, major upgrade of AsusWRT-Merlin is likely to be released?
I'm on a shared Aimesh network with multiple apartments sharing a fibre connection, so I don't have enough control over the devices on the network to do the kind of rigorous testing that would be required to pin down such intermittent issues.@heywire, seems like they're trickling them out as they can for stock users and for RMerlin too. But there won't be a 'mass rollout' until all the new/supported routers are on the 3.0.0.6.xxx level firmware base.
And then there are these points too for that now long in the tooth model:
Solved - LAN client running qBittorrent crashes gt-ax6000 (running Merlin 3004.388.4)
Test with Asuswrt and report your findings in Feedback or Asuswrt-Merlin release thread depending on the results. Thank you. I will, but only on the weekend, because that is the time when I can stay awake after midnight when the family is sleeping.www.snbforums.com
Have you posted about your concerns and/or started a new thread? It may be something RMerlin can fix for 386.12_5... if that is in the works, of course.
Dreaming of one day having a stable, worry-free setup
multiple apartments sharing a fibre connection
I honestly don't see the need to keep Trend Micro activated, the protections it adds are negligible, i replaced the adaptive qos with Cake which is excellently integrated into the Rmerlin firmware, i play online and download from torrents and my network latency is always perfect , just put 90-95% of the bandwidth and you're good to go.I'm on a shared Aimesh network with multiple apartments sharing a fibre connection, so I don't have enough control over the devices on the network to do the kind of rigorous testing that would be required to pin down such intermittent issues.
But I have a feeling it could be caused by bittorrent traffic (by other tenants, I don't use bt on this network) overloading the router, thus causing small crashes, just like the thread you linked explained. (but the person in that thread said that putting back his AC86U helped his situation, while I'm on AC86U and have the problem).
I have considered rolling back to 386.11 or something. But that would bring back the Trend Microsystems crashes that 386.12_4 fixed. And there is no new official firmware with the TM fix that I can try out to see if that helps the situation. So I feel I'm kind of cornered here.
So tired of constantly having to worry about this setup, I'm wondering if a solution could be to put the whole Aimesh setup behind a pfsense router (or similar router software) would fix the problem, allowing me to find a stable Asus firmware that could take care of the wifi and leave it at that, not having to constantly worry about various f*ups in every new firmware release, one fix breaking the other. I will do some research.
Dreaming of one day having a stable, worry-free setup without having to fork out hundreds of dollars for a new setup to replace my AC86U w/2 wireless AC68U and 1 wired AC66_B1 setup.
just put 90-95% of the bandwidth and you're good to go
That was sort of my implicit question: If I put them behind a pfsense router with CakeQOS and use the Asus AC routers w/Aimesh for wifi only, I'd by unfaced by any troubles down the stack and not be in need of those security fixes as the pfsense router would act as the gateway to the internet and the EOL Asus routers' security flaws?There are better hardware choices for your application. You have to replace the AC routers anyway if you want further support. All are facing EoL soon.
Unfortunately I have serious doubts that'll be the case.@heywire, those 3 RT-AC68Us (and varients) are not doing your network any favors.
You may find that a single, well placed, AX class router is more than sufficient to cover the area, and give you a more stable network too.
That was sort of my implicit question: If I put them behind a pfsense router with CakeQOS and use the Asus AC routers w/Aimesh for wifi only
CHATGPT:
From the logs you shared, there are several interesting points around 22:07 that may indicate a network-related crash or issue:
To determine the exact cause of the crash, it would be helpful to look more closely at the kernel logs just before and after the specified time. Further diagnostics might include checking for known issues with firmware or drivers, signal strength problems in the network, or potential issues with specific devices on the network.
- Deauthentication and Disconnection of Devices: There are multiple logs of deauthentication and disconnection (disassociation) of devices from the network around this time. This could be symptomatic of a network issue causing devices to lose connection.
- Signal Strength Indicators (RSSI): Some of the deauthentications mention low RSSI (e.g., rssi:-90). This indicates weak signal strength, which can cause instability in network connections.
- Kernel Error Messages: There is a series of kernel log messages starting around 22:04:24. These messages might indicate a low-level problem or crash in the system. For example, lines like kernel: CPU: 1 PID: 27293 Comm: dcd Tainted: P O 4.1.27 #2 and subsequent stack trace information are typical of kernel crashes or critical errors.
- Potential Software Issue: The use of the word "Tainted" in the kernel log might suggest an issue with a driver or another part of the software that is either not fully supported or has known issues.
- Network Device Activity: Several network devices (like eth5 and eth6) show activity around this time, which might be related to the issue, especially if these devices were involved in the crash or problem.
Is this simply because the crash is causing the time server to restart?
ChatGPT
Do you think I wrote that myself, just to pull your leg somehow? Yes, I used ChatGPT. Do you have any comment on its findings?Really?
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!