Asuswrt-Merlin 3.0.0.4.270.24 BETA 4 is out

[emax.b]

You mean it's not working at all, or it's not preserving the traffic data between reboots? The router will not normally save the 24 hour data, and you will lose it if you reboot or update the firmware. The router will start collecting the data again from scratch.

I save the "History" on USB pen:

The graphic of "Last 24 Hours" not preserve the traffic data between reboot

 

[RMerlin]

I save the "History" on USB pen:

The graphic of "Last 24 Hours" not preserve the traffic data between reboot

That's normal. The router only saves daily traffic, not hourly traffic. Otherwise, the database would be far too large, and would require a lot of RAM.

The last 24 hours will always only report data since the last reboot at the oldest.

 

[RMerlin]

client list missing entries

I just tested the Client list with pretty much all the wireless devices I could power on here (my laptop, work's netbook, Xoom tablet, Nexus 4 and Nexus 7), and everyone is happily showing up. It can sometime take a few seconds before all device start showing up, but this isn't anything abnormal. For now I have to conclude that any issue there is either on the user end, or something that only occurs in a very specific scenario.

 

[bluepoint]

Here's my take on this. All my devices that were added in the manually assigned IP reservations with "tagged" name shows their name/IP in the "clients status" all the time even if the lease has expired. The other clients that I didn't assigned in the DHCP reservation are the clients that changes to MAC addresses when lease has expired then comes up with their names when they renews their leases. So, I think if you want "all" to show their names in the client status all the time, you need to put them in the DHCP reserved list, although right now, the list is limited to 32.

 

[geko53]

client list missing entries

I just tested the Client list with pretty much all the wireless devices [...].
For now I have to conclude that any issue there is either on the user end, or something that only occurs in a very specific scenario.

I tested the issue with different tablets and smartphones - none of the android tablets (Samsung Note 10.1, 2 Nexus 7) are shown in the client list, but no problem with android smartphones (Samsung Galaxy S3 and S2) or with IOS devices (iPad, iPhones) - those are listed without flaw...

Btw.: all my devices are entered with a manually assigned IP in the DHCP-list...

At work I'm using a RT-N56U router - the same tablets that are not listed at home with my RT-N66U will be shown in the client list of the RT-N56U (firmware: 3.0.0.4.342)...

The flaw seems not to be related with the firmware version - I can observe this behavior regardless of the firmware version I use on the RT-N66U...

 

[geko53]

client list missing entries

So, I think if you want "all" to show their names in the client status all the time, you need to put them in the DHCP reserved list, although right now, the list is limited to 32.

Good idea - but the answer is "no" - it doesn't work. All my devices are assigned a fixed IP - and even though the tablets are not listed...

 

[bluepoint]

Good idea - but the answer is "no" - it doesn't work. All my devices are assigned a fixed IP - and even though the tablets are not listed...

You have fixed IP and "name" assigned? All my devices with fixed IP/Name shows in the client status. Are you using RMerlin's 24 B4 firmware? Maybe you need to erase the NVRAM then reconfigure?

 

[joegreat]

New error message in syslog.log

Hi,

Yesterday I installed Beta 4 and have now a new error message in the syslog:

Feb 12 08:16:38 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection timed out
Feb 12 08:16:38 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection timed out
Feb 12 08:16:38 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection timed out
Feb 12 08:19:29 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection reset by peer

Is this anything I need to take care of? Or can I just forget it?

With kind regards
Joe

 

[RMerlin]

Hi,

Yesterday I installed Beta 4 and have now a new error message in the syslog:

Feb 12 08:16:38 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection timed out
Feb 12 08:16:38 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection timed out
Feb 12 08:16:38 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection timed out
Feb 12 08:19:29 miniupnpd[836]: upnp_event_process_notify: connect failed: Connection reset by peer

Is this anything I need to take care of? Or can I just forget it?

With kind regards
Joe

I usually get that error after a reboot. Probably just mean that a forwarded port is no longer answering. At this point I wouldn't worry about it, unless you experience issues with your uPNP-enabled devices/softwares.

It seems that newer miniupnpd are more chatty than previous ones. Tomato/Oleg were already removing some logging calls, but new ones were added. I'd rather have more logging than not enough for now tho.

 

[lilstone87]

Decided to mess around with my wireless extender on the 2.4ghz, and I redid all the setting's. Which something with the wireless range extender was causing the router to log this same entry below often. But the weird thing is, even with nothing connected to the range extender wired/wirelessly, it was still causing the router to log this entry. The good thing is now after redoing the setting's on the range extender, this is no longer adding up in the router log often.

kernel: br0: received tcn bpdu on port 2(eth1)
kernel: br0: topology change detected, propagating

 

[RMerlin]

Decided to mess around with my wireless extender on the 2.4ghz, and I redid all the setting's. Which something with the wireless range extender was causing the router to log this same entry below often. But the weird thing is, even with nothing connected to the range extender wired/wirelessly, it was still causing the router to log this entry. The good thing is now after redoing the setting's on the range extender, this is no longer adding up in the router log often.

kernel: br0: received tcn bpdu on port 2(eth1)
kernel: br0: topology change detected, propagating

Did you re-enable STP?

 

[ChrisR]

I just tested the Client list with pretty much all the wireless devices I could power on here (my laptop, work's netbook, Xoom tablet, Nexus 4 and Nexus 7), and everyone is happily showing up. It can sometime take a few seconds before all device start showing up, but this isn't anything abnormal. For now I have to conclude that any issue there is either on the user end, or something that only occurs in a very specific scenario.

Today, I monitored the client status for a while and all devices were displayed in the list correctly. Also when switch on/off several devices.

 

[lilstone87]

Did you re-enable STP?

I only disabled that for a short period of time, just to see if that log would go away, which it did. But since then I have left it enabled, and today I decided to mess with the range extender. As I had a good ideal it was causing that to be logged. But nothing was connected to it both wired/wirelessly, so I just reconfigured it to see if it would stop the router from logging that, and it did. I just wanted it to stop as I just felt like it was causing spam within the router, that was unneeded.

 

[lilstone87]

Oh I even rebooted the wireless side of the N66U, after I redid the range extender. Which was a couple hours ago, this was logged after the wireless reboot, and I consider that normal, nothing since.

kernel: device eth1 entered promiscuous mode
kernel: br0: port 2(eth1) entering listening state
kernel: br0: port 2(eth1) entering learning state
kernel: br0: topology change detected, propagating
kernel: br0: port 2(eth1) entering forwarding state
kernel: device eth2 entered promiscuous mode
kernel: br0: port 3(eth2) entering listening state
kernel: br0: port 3(eth2) entering learning state
kernel: br0: topology change detected, propagating
kernel: br0: port 3(eth2) entering forwarding state

 

[joegreat]

WLAN signal strenght

Hi,

I did some WLAN signal measurements with Beta 4 firmware.

Compared to the 23b firmware I see a clear improvement in the 5G signal on the client side (>5 dBm), and also on the router side (always >10 dBm above the noise level).

The 2.4G looks to me (unfortunatly) worse then before. Still good enough to cover my home's corners, but not as good as it was with the other firmware.

As this is only a snapshot of today evening, I might need to redo the measurement tomorrow during the day to get a more consistent picture: Maybe the high number of neighbor WLANs make the things worse.
On 5G there are no neighbors transmitting and this might make the difference.

With kind regards
Joe

 

[bluepoint]

It seems that newer miniupnpd are more chatty than previous ones. .

I agree, it's more vocal of what's happening but informational messages are good. Here's what I see sometimes.

miniupnpd[617]: upnp_event_recv: recv(): Connection reset by peer

 

[RMerlin]

I agree, it's more vocal of what's happening but informational messages are good. Here's what I see sometimes.

miniupnpd[617]: upnp_event_recv: recv(): Connection reset by peer

I'll keep these enabled for the final release. I'll re-evaluate it later on, and tone it down a bit if it gets too chatty in general.

 

[bluepoint]

Sounds like a good plan.

 

[RMerlin]

3.0.0.4.270.24 has now been released. Thank you everyone for your contributions and continuous feedback!

Locking down this (quite long!) thread.