[Release] Asuswrt-Merlin 384.9 is now available

[UserUnknown]

Upgraded RT-ac68u (a real one!) with no problems, then reset to default settings, hopefully fixing the radio problem I've mentioned in another thread. Seeing the post above, I set the channels manually as well.

 

[MoonPie2000]

Hey my system log file is filling up with these messages - kernel: TCP: time wait bucket table overflow - any ideas what is causing them? Sorry if this has already been posted.

 

[D_Day]

Hey my system log file is filling up with these messages - kernel: TCP: time wait bucket table overflow - any ideas what is causing them? Sorry if this has already been posted.

Browser cache.

 

[kernol]

Hey my system log file is filling up with these messages - kernel: TCP: time wait bucket table overflow - any ideas what is causing them? Sorry if this has already been posted.

See this thread on the forum ... https://www.snbforums.com/threads/c...wait-bucket-table-overflow-on-rt-ac68u.46242/

Always helps to search the forum before you post a query.

Also - could you please edit your profile - and at the very least add your Router Model to your Signature.
I see from past posts that you have an AC3200 - but shouldn't have to dig to find it - just in case the issue is model specific.
It helps contributors if you also include your current add-ons [see my Signature for an example].

 

[Advis]

Thank you to @RMerlin for getting the RT-AC87U back into this release. I have updated and begun testing of this release. So far so good.

 

[kernol]

Hey my system log file is filling up with these messages - kernel: TCP: time wait bucket table overflow - any ideas what is causing them? Sorry if this has already been posted.

I also see from your past posts that you are in the habit of doing "dirty flash" from one firmware to the next.
See this thread covering same issue you raise - where a factory rest / initialize solved the OP's problem.

https://www.snbforums.com/threads/time-wait-bucket-overflow.29745/

 

[RMerlin]

Those TCP bucket errors often happen right after you flashed a firmware, because your browser was flooding the router with connection attempts right after the router finished rebooting. Just closing and reopening the browser will often resolve that issue.

 

[Gar]

Finally updated from Beta 1 and it all works. A recurring issue remains with this firmware. When I reboot the unit it doesn't come back on, it shuts off (all LEDs off) requiring the power switch to be cycled. But everything starts and works fine then.

Thanks Merlin for another great update!

 

[Butterfly Bones]

Finally updated from Beta 1 and it all works. A recurring issue remains with this firmware. When I reboot the unit it doesn't come back on, it shuts off (all LEDs off) requiring the power switch to be cycled. But everything starts and works fine then.

Thanks Merlin for another great update!

Known issue.
https://www.snbforums.com/threads/ac86u-sometimes-powers-completely-off-during-reboot.48296/

 

[Gar]

Known issue.
https://www.snbforums.com/threads/ac86u-sometimes-powers-completely-off-during-reboot.48296/

Yeah, I knew I read it somewhere, just a bad search on my part.

 

[ml_stephens]

Upgraded my Asus AC68U from 384.8_2 to 384.9 and had a problem with wireless connections. Macbook seemed to connect fine, but our iPhones wouldn't connect consistently to the 2.5Ghz band or at all to the 5Ghz. Downgraded to 384.8_2 and all is back to normal. Very strange, couldn't see anything obvious in config.

 

[ubimea]

Thank you for updating the Asus 87u and 3200; much appreciated and working fine after simple update from stock firmware.

 

[Morac]

I don’t think it’s running out of ip addresses, but something definitely has changed.

My TV just reported it lost connection again to the Internet despite still reporting it can access my LAN and having an IP address. This happened about an hour after I rebooted it. I don’t know how it determines if it has Internet access or not. It does have an IPv6 address, but so do a number of other devices I have and they are working.

Since updating to 384.9 this has happened at least 3 times: twice where the TV reported loss of Internet, but still had an IP address (it said to check the router for an Internet connection) and once where it had no IP address at all.

I’m not sure what’s going on as disconnecting the Ethernet cable and reconnecting seems to correct this, but this all started after updating to 384.9. Never had a problem before that.

Edit:

I just noticed that the TV is renewing it’s DHCP lease around every 10 or 15 minutes. I have no idea why and that’s definitely excessive, but it shouldn’t cause issues unless the router decides not to respond.

I just ran into an issue with my Android TV where it had an Internet connection, but network connections were very sluggish. Other devices connected to the same switch were getting 300 Mbps down from the Internet, but the TV couldn’t stream video at all.

I took a look at the connections on the router and saw the TV had at least a hundred open connections, many to the same server and port. I have no idea why that would be, but the problems started after I upgraded to 384.9 so something in that release appears to be messing with the network connections on the TV which get so bad that it fails the DHCP request after awhile. I need to reboot the TV to get things working.

That’s the only device I’ve noticed a constant problem with, though I did see an app complain a few times of connection issues on my iPad.

Is anyone with Android devices having problems, more specifically an Android (Sony) TV device?

 

[Frankflash]

@Morac what was web browsing like web pages slow
to open i have a tablet connections slow on 5g and web pages slow to open

 

[Morac]

@Morac what was web browsing like web pages slow
to open i have a tablet connections slow on 5g and web pages slow to open

There was no slowdown on any other devices. The TV is connected via Ethernet.

The TV just reported it lost connection again. I noticed the router’s reported connections dropped from around 1800 to 1300, which means the TV had 500 connections open for some reason.

Edit:

I went back to 384.8_2 and now the TV has 1 connection according to the router’s connections log instead of over 100. The Tools page reports 48 active connections as opposed to 140 under 384.9.

Now the one odd thing I noticed with 384.8_2 is that the router is reporting that the TV is trying to use 8.8.8.8 DNS which has a state of “unrealized”. That may also have been under 384.9, but I just missed it in the 100 other open connections to Google’s servers.

Basically it looks like network connections made by the TV were staying open under 384.9 (I.e. never closing or going to time wait) and eventually the TV’s network stack died.

That or the IP address was being reset so often that the TV was doing it’s network up processing nearly continuously. That seems unlikely,but I’m noticing so far under 384.8_2, that it’s been 30 minutes and the TV hasn’t made another DHCP request whereas under 384.9 it was requesting at least every 15 minutes.

@RMerlin any idea what in 384.9 could cause that?

 

[RMerlin]

There was no slowdown on any other devices. The TV is connected via Ethernet.

The TV just reported it lost connection again. I noticed the router’s reported connections dropped from around 1800 to 1300, which means the TV had 500 connections open for some reason.

Edit:

I went back to 384.8_2 and now the TV has 1 connection according to the router’s connections log instead of over 100. The Tools page reports 48 active connections as opposed to 140 under 384.9.

Now the one odd thing I noticed with 384.8_2 is that the router is reporting that the TV is trying to use 8.8.8.8 DNS which has a state of “unrealized”. That may also have been under 384.9, but I just missed it in the 100 other open connections to Google’s servers.

Basically it looks like network connections made by the TV were staying open under 384.9 (I.e. never closing or going to time wait) and eventually the TV’s network stack died.

That or the IP address was being reset so often that the TV was doing it’s network up processing nearly continuously. That seems unlikely,but I’m noticing so far under 384.8_2, that it’s been 30 minutes and the TV hasn’t made another DHCP request whereas under 384.9 it was requesting at least every 15 minutes.

@RMerlin any idea what in 384.9 could cause that?

Do you use any OpenVPN client? 384.9 fixed Strict DNS ordering, so if it was previously working "by accident", that part might no longer work as expected under 384.9 - you should switch to Exclusive DNS mode instead.

If your TV has so many tracked connections, it might be trying (and failing) to connect to these destinations.

Some apps will have hardcoded nameservers. One well known case is Netflix. That might be why the TV keeps trying to use 8.8.8.8.

 

[Morac]

Do you use any OpenVPN client? 384.9 fixed Strict DNS ordering, so if it was previously working "by accident", that part might no longer work as expected under 384.9 - you should switch to Exclusive DNS mode instead.

If your TV has so many tracked connections, it might be trying (and failing) to connect to these destinations.

Some apps will have hardcoded nameservers. One well known case is Netflix. That might be why the TV keeps trying to use 8.8.8.8.

I don’t have an OpenVPN client defined on the router. I do have an OpenVPN server running, but nothing is connected to it.

As far as I could tell the TV’s connections would succeed, but either never close or take a long time to do so and eventually the network stack would get sluggish and eventually die at which point no network traffic would work. I couldn’t even ping the TV at that point.

I find the TV still frequently refreshes DHCP while the TV is off with 384.8_2, but I think that’s because it wakes up from sleep periodically. When it wakes up it opens a few outbound connections, but so far in 384.8_2 they are closing in a reasonable time frame such that there are only ever around 10 open at a time. Under 384.9 these wouldn’t close or time out.

All in all the TV is much better behaved under 384.8_2 than 384.9. Without putting a packet sniffer on the network, I really have no idea why.

 

[RMerlin]

I don’t have an OpenVPN client defined on the router. I do have an OpenVPN server running, but nothing is connected to it.

As far as I could tell the TV’s connections would succeed, but either never close or take a long time to do so and eventually the network stack would get sluggish and eventually die at which point no network traffic would work. I couldn’t even ping the TV at that point.

I find the TV still frequently refreshes DHCP while the TV is off with 384.8_2, but I think that’s because it wakes up from sleep periodically. When it wakes up it opens a few outbound connections, but so far in 384.8_2 they are closing in a reasonable time frame such that there are only ever around 10 open at a time. Under 384.9 these wouldn’t close or time out.

All in all the TV is much better behaved under 384.8_2 than 384.9. Without putting a packet sniffer on the network, I really have no idea why.

When conntrack (or the DPI engine I assume) sees a new connection, it will track it for a certain period of time even after it's "closed". So it's normal for closed connections to still appear in the tracked list for a while.

 

[Morac]

When conntrack (or the DPI engine I assume) sees a new connection, it will track it for a certain period of time even after it's "closed". So it's normal for closed connections to still appear in the tracked list for a while.

The connections in this case aren’t showing as “closed”, they are showing as “established”.

I think the problem may still be happening in 384.8_2 when the TV is “off”. After turning off the TV I started seeing the number of established connections begin to increase and it’s making DHCP requests about once a minute. I think what’s happening is that the TV wakes up and requests an IP address and makes its “wake up connections”.

When I turn the TV on though under 384.8_2, the active connections slowly begin to drop which wasn’t happening under 384.9.

 

[scjr]

Upgraded my Asus AC68U from 384.8_2 to 384.9 and had a problem with wireless connections. Macbook seemed to connect fine, but our iPhones wouldn't connect consistently to the 2.5Ghz band or at all to the 5Ghz. Downgraded to 384.8_2 and all is back to normal. Very strange, couldn't see anything obvious in config.

No issues here with 2 iPhones and 2 iPads on 5GHz. I only use 2.4GHz for my TVs. I’ve been on 384.9 for nearly 4 days of uptime, without disconnects.

If you haven’t already, some things you can try:

Forget your WiFi connections on those devices and reconnect them.

Manually set your control channel on 5GHz and 2.4GHz.

Make sure 2.4GHz channel bandwidth is set to 20MHz.

Under 5GHz wireless/professional settings, disable universal beamforming. (ac beamforming remains enabled)

If those don’t work, you may have to factory reset and manually enter your settings.