Release Asuswrt-Merlin 386.2_6 is now available

[autopilot]

Had to downgrade. Clean install and did 2 full resets and clean setups, but something is wrong with DHCP and manual IP’s being assigned incorrectly.

 

[Morris]

Had to downgrade. Clean install and did 2 full resets and clean setups, but something is wrong with DHCP and manual IP’s being assigned incorrectly.

Are you assigning the DHCP hosts in LAN/DHCP?

 

[autopilot]

Are you assigning the DHCP hosts in LAN/DHCP?

My DHCP pool is limited to 192.168.50.1 - 127. I then manually assign a few IP assesses over .127 to a few devices. I do this for a number of reasons, but mainly to use a secondary WAN using routing rules.

There’s a couple of devices that for some reason are being assigned IP’s over .127, even though they haven’t been manually assigned IP’s (the network map also shows a incorrectly states they are Manual). They are alway given the same IP to, so they are basically acting like they have had manual assignments when they haven’t, it’s really odd. Also some devices are actually being assigned random IP’s below .127, even though they have been manually give IP’s.

The stock Asus firmware often had all sorts of errors in the network map, but the IP’s were correctly assigned and worked as they should.

Wireless performance is also worse, with devices on the edge of my network dropping off when they never did with stock.

So far there’s too many bugs for me to use Merlin. UI is better, might try some older builds.

(AX88U BTW).

 

[Morris]

My DHCP pool is limited to 192.168.50.1 - 127. I then manually assign a few IP assesses over .127 to a few devices. I do this for a number of reasons, but mainly to use a secondary WAN using routing rules.

There’s a couple of devices that for some reason are being assigned IP’s over .127, even though they haven’t been manually assigned IP’s (the network map also shows a incorrectly states they are Manual). They are alway given the same IP to, so they are basically acting like they have had manual assignments when they haven’t, it’s really odd. Also some devices are actually being assigned random IP’s below .127, even though they have been manually give IP’s.

The stock Asus firmware often had all sorts of errors in the network map, but the IP’s were correctly assigned and worked as they should.

Wireless performance is also worse, with devices on the edge of my network dropping off when they never did with stock.

So far there’s too many bugs for me to use Merlin. UI is better, might try some older builds.

(AX88U BTW).

That's quite odd. Are they showing manual or static?
Manual - You set the IP via DHCP on the router
Static - The IP came from someplace other than the router

 

[autopilot]

That's quite odd. Are they showing manual or static?
Manual - You set the IP via DHCP on the router
Static - The IP came from someplace other than the router

Manual, which is why it’s so strange because they are definitely not manual. I’ve gone over it’s all night, checked and triple checked, thought I was going mad. Clearly a bug.

Network map often shows some incorrectly as static, but that’s a separate issue and most doesn’t cause any problems.

 

[CaptainSTX]

All devices that regularly connect to my network on the AC86 have been assigned IPs outside the small range I set aside for automatic IPs. DHCP pool is primarily for visitors. (15 static IPs ) I use other guest networks for IoT wifi connected devices and again all IoT devices have assigned IPs.

When I look at the network MAP is lists all IPs as DHCP even though they are IPs I have assigned outside the pool.

I noticed this behavior (no static IPs ) going back several versions of Merlin's firmware on my router. Since it really doesn't have any impact on my network I have just ignored it since all devices with assigned IPs are getting the correct IP.

 

[Morris]

All devices that regularly connect to my network on the AC86 have been assigned IPs outside the small range I set aside for automatic IPs. DHCP pool is primarily for visitors. (15 static IPs ) I use other guest networks for IoT wifi connected devices and again all IoT devices have assigned IPs.

When I look at the network MAP is lists all IPs as DHCP even though they are IPs I have assigned outside the pool.

I noticed this behavior (no static IPs ) going back several versions of Merlin's firmware on my router. Since it really doesn't have any impact on my network I have just ignored it since all devices with assigned IPs are getting the correct IP.

I've never seen anything outside the DHCP Range that was assigned by the router. Check the host to see the IP of the DHCP server. It sounds like you may have another one on your network.

 

[Morris]

Manual, which is why it’s so strange because they are definitely not manual. I’ve gone over it’s all night, checked and triple checked, thought I was going mad. Clearly a bug.

Network map often shows some incorrectly as static, but that’s a separate issue and most doesn’t cause any problems.

It sounds like there is junk in the DHCP table (internal database) You could try turning DHCP off, then back on and assign all the hosts again. If that does not work, A reset to factory and then enter the configuration over. You are the only person I've seen report these symptoms

 

[Sean Nelson]

This can likely happen when the accounts get "out-of-sequence" in nvram. If you look at the underlying nvram variable over ssh login:

nvram get acc_list

You will probably find that user and its password is listed before admin and its password. You probably also have errors applying any settings on the Administration / System page.

If you understand the "<" and ">" delimited field in the nvram output, you could reorder them correctly:

nvram set acc_list="admin>theencryptedpassword<user>theencrypteduserpassword"
nvram commit
service reboot

The last reboot command can be done when convenient. Otherwise just refresh the samba page and see if it works properly.

You were 100% correct in both the diagnosis and the fix. Thanks!

(Now the "admin" profile is not modifiable. But I suppose this is by design (?) -- not sure since I never paid attention to this before.)

So this was probably not an issue with the update but with the nvram fill-up/clean-up? How did they get out-of-sequence?

 

[CaptainSTX]

I've never seen anything outside the DHCP Range that was assigned by the router. Check the host to see the IP of the DHCP server. It sounds like you may have another one on your network.

My supposition is that this non standard DHCP behavior could have resulted from implementing YazFi which uses its own DHCP serving function to assign IPs from different DHCP pools for guest networks. Currently I have removed YazFi and am testing the VPN Director's functionality. (Works great!) All devices that connect to my AC86 are connecting to a guest WiFI SSID.

The solution to the anomaly I am experiencing is probably a factory reset however since the only issue that I am seeing is just that the label on all connected devices is DHCP instead of static I am in no hurry to "fix it" since nothing is really broken. I will postpone a factory reset until I have an issue effecting performance. Turning DHCP off then on again didn't fix the labeling problem.

 

[ottofreud]

It will only happen when you have a client connected to that band and actively using it. If you have clients on both bands, then you should move both of them.

I am actually getting this error with no guest network enabled. In the last FW, I got it when I used the Guest 1 networks (2.4 / 5 GH), but now even with all Guest Networks off, I still get this error many times per second. Enabling / disabling the Guest Network(s) seems to have no effect

 

[ottofreud]

I am actually getting this error with no guest network enabled. In the last FW, I got it when I used the Guest 1 networks (2.4 / 5 GH), but now even with all Guest Networks off, I still get this error many times per second. Enabling / disabling the Guest Network(s) seems to have no effect

I had my IP6 settings all gunked up. After I fixed those, the error messages stopped.

 

[CoyoteDen]

This is a weird one. When a device joins the guest network, WAN will drop out until you manually cycle the WAN connection.

I thought it was coincidence too, but nope. Three days in a row now when I boot my work laptop, it connects to the guest network and my WAN drops. Syslog is not very helpful. I see the wl1.1 assoc, DHCP lease, and then WAN goes down. Oddly enough, I can disconnect and reconnect to the guest network all day and WAN will stay up, it only seems to happen when nothing has been using the guest network for a while.

I've been using 386.2_6 for longer than that, but the difference is three days ago I stopped using YazFi. YazFi places the wl* interfaces on the default LAN bridge br0 and uses iptables rules to restrict them. ASUS places them on a different bridge if you have intranet access disabled.

Jun 23 12:56:45 syslog: wlceventd_proc_event(527): wl1.1: Auth ******************, status: Successful (0), rssi:0
Jun 23 12:56:45 syslog: wlceventd_proc_event(556): wl1.1: Assoc ******************, status: Successful (0), rssi:0
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPDISCOVER(br2) *****************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPOFFER(br2) 192.168.102.242 ******************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPREQUEST(br2) 192.168.102.242 ****************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: Ignoring domain **************** for DHCP host name ***************
Jun 23 12:56:50 dnsmasq-dhcp[14132]: DHCPACK(br2) 192.168.102.242 ***************
Jun 23 12:57:19 WAN_Connection: ISP's DHCP did not function properly.
Jun 23 12:57:20 DualWAN: skip single wan wan_led_control - WANRED off

 

[RMerlin]

This is a weird one. When a device joins the guest network, WAN will drop out until you manually cycle the WAN connection.

Try using Guest Network 2 instead, to see if maybe it might be a routing conflict, as GN1 uses the 192.168.101.0 and 192.168.102.0 subnets.

 

[CoyoteDen]

GN2/3 aren't properly isolated from the LAN. I don't want my company-issued laptop on my LAN for privacy reasons.

see here: http://www.snbforums.com/threads/rt-ac68p-fios-wan-dropouts-on-386-x.73214/post-696303

ASUS *could* put them on br1/br2 for isolation, but they didn't. Might be a bug, as the access intranet setting is present but has no effect on GN 2/3. I have tested this on two different 66 B1s, one has a clean config, so it's not my NVRAM.

 

[RMerlin]

GN2/3 aren't properly isolated from the LAN. I don't want my company-issued laptop on my LAN for privacy reasons.

This is just for testing purposes, to determine if there is a link.

 

[CoyoteDen]

This is just for testing purposes, to determine if there is a link.

I’ll try that tomorrow (it doesn’t drop unless the GN has been unused for hours, like overnight) but I have a feeling it won’t trigger a WAN drop. Because of the bridging bug, GN2/3 are basically like YazFi GNs on br0.

 

[CoyoteDen]

Ok, I'm pretty sure I've figured out the problem with guest network 1 killing the WAN, and it's dumb. Really dumb.

admin@RT-AC66U_B1-0:/tmp/home/root# robocfg show
Switch: enabled
...
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 4 5t
   2: vlan2: 0 5
502: vlan502: 0t 1t 2t 3t 4t 5t
admin@RT-AC66U_B1-0:/tmp/home/root# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.38d547dbe940    no        vlan1
                            eth1
                            eth2
                            tap22
br2        8000.38d547dbe945    yes        wl1.1
                            eth0.502
                            eth1.502
                            eth2.502

So what we have here is br2 with GN1 (wl1.1) and VLAN 502 across eth0/eth1/eth2. I don't know what that VLAN is used for, but it doesn't show up unless you have a Guest Network 1 enabled. 2.4G Guest Network 1 creates br1 and VLAN 501. Maybe something to do with AiMesh?

eth1 and eth2 are 2.4/5 radios, and eth0 goes to the switch. On the switch port 0 is WAN, 1-4 are LAN, and 5 is the CPU. VLAN 1 traffic is tagged on port 5, so it goes to vlan1 interface and the LAN bridge. WAN traffic is untagged so it goes to the eth0 WAN interface.

The problem: enabling Guest Network 1 adds VLAN 501/502 to the switch, and puts the WAN port in those VLANs. This means Guest Network 1 broadcasts will go to the WAN port, including DHCP queries. When a GN1 device requests an IP, your WAN connection may respond first and kill the router's DHCP lease!

The fix is to add the following to your firewall-start script to remove those VLANs from the bridges and switch

robocfg vlan 501 ports ""
robocfg vlan 502 ports ""
brctl delif br1 eth0.501 
brctl delif br1 eth1.501                                 
brctl delif br1 eth2.501                                 
brctl delif br2 eth0.502                              
brctl delif br2 eth1.502                                 
brctl delif br2 eth2.502

I can confirm that without removing VLAN 501/502, a DHCP query on the guest network may steal the WAN IP. After removing those VLANs, guest network 1 functions properly. Yes, this bug makes the leaked traffic on the WAN port tagged, but my Fios ONT doesn’t care, and cable modems probably don’t either. They will respond to a DHCP broadcast.

 

[jksmurf]

It will only happen when you have a client connected to that band and actively using it. If you have clients on both bands, then you should move both of them.

Thank you, appreciated.

 

[JoeBee]

Did a dirty flash to latest from 384.19 firmware just now, got an almost 30% broadband speed drop sadly.

Does that mean I have to do a factory restore and re-do the settings again ?