[Beta] Asuswrt-Merlin 380.62 Beta is available

[hellboy2]

if even the static list ends up empty, first likely cause would be that you are running out of nvram. Check your nvram usage under Tools -> Sysinfo.

NVRAM usage 50724 / 65536 bytes

I think I was wrong about DHCP list size, because there is much bigger difference between results when I change from Firefox to Chrome. As I remember, this part is acutally unchanged from ASUS' orginal code. I can live with it ...

 

[Grimba]

Hello RMerlin,

in the changelog i noticed following line:

- FIXED: DHCP lease renewals would fail with ISPs with a broken DHCP server that sent replies from a different IP address.

I wanted to ask you, what exactly is fixed here. Isn't that kind of a security problem if lease renewals are accepted from a different IP address? Or do i get that wrong? Could you pls give a short explaination? Thank you

 

[Naftali Oziel]

Yes it worked in 380.61 in AP showing the connected devices both MAC and IP. Now it only shows the MAC address all systems are connected no issues so this is a cosmetic issue.

I was finally able to reproduce the missing IPs. It's indeed related to the Linux kernel not having the device's MAC in its ARP table - it can take a while for this to happen, and it depends on the clients.

I was also able to reproduce the exact same issue with 380.61. This is NOT new to 380.62.

Asuswrt-Merlin relies on the ARP cache to determine the IP of a given MAC address. Now, when a client connects to the AP, it does not communicate with that AP at an IP level, but only with the main router. That causes IPs to either quickly disappear from the AP's tables, or flat out never appear in them.

The only way for an AP to be able to know about the IPs would be to scan the entire subnet, causing the AP cache to get populated. This happens for instance when networkmap scans the LAN to build a list of clients. You can see this by accessing the networkmap (first page when you log into the AP), wait 2 minutes, then go back to the Wireless Log page. Any missing IPs should now be visible... for the time being. That is, until the kernel flushes its ARP tables of these stale entries.

An alternative might be to rely on the networkmap database instead of the arp table to retrieve IPs. However I'm not really a fan of that idea, as its has its own drawbacks (stale entries, or missing newly connected clients).

So in summary:

1) It's nothing new, it was also happening in 380.61
2) It's related to the kernel's handling of the ARP table, forcing a refresh would have significant side-effects (like waking up any device in sleep mode on your LAN)

Best I could do would be to see if I could rely on the networkmap database as an alternative IP source (i.e. ONLY when the ARP table doesn't have an entry for a client). I will have to see how tricky this would be to implement however. The networkmap database is often a bit unreliable, with its own issues...

Thank you for the detailed explanation and your efforts. It makes perfect sense but weird that it every worked for me on 380.61 consistently. I will leave it to your judgement if it's even worth the effort and potential issues it may cause to have the IP's displayed. It's a nice to have, saves me from having to login into my FW. But that just simply my laziness.

 

[RMerlin]

Hello RMerlin,

in the changelog i noticed following line:

- FIXED: DHCP lease renewals would fail with ISPs with a broken DHCP server that sent replies from a different IP address.

I wanted to ask you, what exactly is fixed here. Isn't that kind of a security problem if lease renewals are accepted from a different IP address? Or do i get that wrong? Could you pls give a short explaination? Thank you

See this post, as well as the following posts on that same thread. In short, the security hole was already there, and it's necessary for some ISP to work at all. The only change was that I made it work also on renewals, not just on the initial lease. This matches how OpenWRT and Tomato work as well.

 

[RMerlin]

Thank you for the detailed explanation and your efforts. It makes perfect sense but weird that it every worked for me on 380.61 consistently. I will leave it to your judgement if it's even worth the effort and potential issues it may cause to have the IP's displayed. It's a nice to have, saves me from having to login into my FW. But that just simply my laziness.

You can use the suggest workaround, which is to access the Client List, and wait for the rescan to complete.

 

[Grimba]

Thank you for the answer. Then, i guess, this is true for the ISP "Unitymedia" in Germany, too.

I had issues getting a stable connection (which is not only software related in my house, but this will be fixed soon): My RT-AC88U would often lose connection and blame the bad ISP DHCP for that. As result, it either lost connection and blamed "your isp's dhcp service does not work properly" or it indicated a connection, but with the initial lease 0.0.0.0. Since i updated to 62 beta 1, it seems to be stable.

But thank you for explaining the security aspect on this issue. It's sad, that firmware developers have to open up security holes by design to "fix" unstable connection behaviour of a router because the ISPs are not able to configure their services right.

I still can't say that i agree with you 100% changing this like tomato and openwrt did, but i understand that there seems to be no other way atm to get a stable connection to some ISPs. What a mess

edit: Would it be possible to add a switch to the UI to enable/disable this behaviour by the User, to make the User more aware of that issue?

 

[Naftali Oziel]

You can use the suggest workaround, which is to access the Client List, and wait for the rescan to complete.

Will do, thanks again for all your support.

 

[stambeccuccio]

After several (many) tests I believe router ability to manage Network Map has some bugs or problem.
The "Wiew List Network Map" is unstable, it does not always show the devices connected to the network, the devices connected to the network disappear and reappear randomly, even when there is no change.

Router does not display (there are problems) with devices that go (rightly) into "P = Power Save Mode".

In short, the management and the vision of networked devices does not give a certain view of the network, it seems superficial, unstable and not satisfactory in my opinion.

 

[bluepoint]

Router does not display (there are problems) with devices that go (rightly) into "P = Power Save Mode".

That's correct, devices in "power save mode" will not display as it tries to conserve battery/power. If the router wakes it every time then the next thing people will complain is, damn this router eats up my battery.

 

[strangeluck]

Is it no longer possible to revert firmware in recovery mode? I have tried reverting via the Asus Utility, The MiniWeb CFE interface, as well as TFTP. I am able to enter recovery mode and successfully upload an older firmware file, but upon reboot the firmware does not revert. I have tried downgrading to 380.61 but the problem persists for me with that version as well.

 

[strangeluck]

Tested , you still can

http://www.snbforums.com/threads/re...-61-is-now-available.33994/page-6#post-274879

Thanks for confirming, though weird that it wasn't working for me. I will have a go at it again tomorrow when there aren't users requiring working internet.

 

[RMerlin]

Is it no longer possible to revert firmware in recovery mode? I have tried reverting via the Asus Utility, The MiniWeb CFE interface, as well as TFTP. I am able to enter recovery mode and successfully upload an older firmware file, but upon reboot the firmware does not revert. I have tried downgrading to 380.61 but the problem persists for me with that version as well.

Give it some time. The RT-N66U for instance can take 20-40 minutes to complete the process, due to its slower flash.

 

[Xentrk]

I flashed to RT-AC88U_380.62_beta1-g7d0d688 yesterday with my router that I use as OpenVPN client and a SAMBA mount to a WD 1TB External Hardrive connected to the USB 3.0 port. About one hour ago, I also flashed my other AC88U with 380.62_beta1-g7d0d688. Both use a PPOE connection to the ISP and are connected to a Fiberhome GPON modem/router that is placed in Bridge Mode. No issues to report.

 

[Stp]

Can't use 5 GHz with Repeater mode on RT-AC66U. Same fw after 380.59 . Main Router is RT-AC87U. I must use 2.4 GHz only.

 

[Domino]

Asus RT-AS56U beta firmvare 10 20 minute diskonnekts video over wi-fi

 

[XIII]

Like several previous stable releases this beta looses the 2.4 GHz network on my AC66U after some time.
As a result I can no longer control my WeMo devices (iOS devices continue to work on the 5 GHz band).
I have to reboot the router to get back to normal.

 

[strangeluck]

Give it some time. The RT-N66U for instance can take 20-40 minutes to complete the process, due to its slower flash.

AC68U in this case, or to be more specific a T-Mobile AC1900 (rebranded AC68U). I was able to revert today, but only when uploading an old ASUS firmware (3.0.0.4.376.3626 ) via recovery. For whatever reason (perhaps related to being a T-Mobile branded router?) it would not allow me to flash the more recent firmware versions I tried. Once I was able to flash the older Asus version I was able to upgrade to my more recent firmware version of choice via the web interface.

 

[john9527]

Once I was able to flash the older Asus version I was able to upgrade to my more recent firmware version of choice via the web interface.

This is expected behavior the first time you move from a 32M rootfs firmware to a 64M rootfs firmware. The first firmware load has to support 64M rootfs but still fit in a 32M space. (The current firmware won't fit in the 32M space).

 

[applesnowleo]

Hello, thanks for your reply Merlin, I did not change anything, just programmed your firmware over Asus latest, in SysInfo HW acceleration appears to be on, reverting back to asus the problem desappears. Reseted the router and configured from scratch but did not solve. post some pictures for notice.

Sorry Merlin, by some motive adaptive qos was the problem, put my mac on high priority and the issue was gone. sorry for the false alarm. Getting now with .62 930mb constant.

 

[bobiii]

Like several previous stable releases this beta looses the 2.4 GHz network on my AC66U after some time.
As a result I can no longer control my WeMo devices (iOS devices continue to work on the 5 GHz band).
I have to reboot the router to get back to normal.

I had the same problem on rt5300 after installing the latest beta. I would loose only the 2.4 ghz band and when I looked the channel had been set to zero. I finally solved my problem by completely powering down the router (took out the power supply) and then after plugging back in, my router has been great for the past 4 days.