Asuswrt-Merlin 3.0.0.4.374.38 is out

[TeMpL]

Jan 13 00:44:14 kernel: ------------[ cut here ]------------
Jan 13 00:44:14 kernel: WARNING: at fs/fs-writeback.c:560 wb_writeback+0x2bc/0x2d8()
Jan 13 00:44:14 kernel: module:  wl	 bf7fc000	 3924437
Jan 13 00:44:14 kernel: module:  igs	 bf7f2000	 12935
Jan 13 00:44:14 kernel: module:  emf	 bf7e8000	 16229
Jan 13 00:44:14 kernel: module:  tun	 bf7d2000	 12723
Jan 13 00:44:14 kernel: module:  nf_nat_sip	 bf7c8000	 5586
Jan 13 00:44:14 kernel: module:  nf_conntrack_sip	 bf7b8000	 16679
Jan 13 00:44:14 kernel: module:  nf_nat_h323	 bf7a5000	 5137
Jan 13 00:44:14 kernel: module:  nf_conntrack_h323	 bf78d000	 34844
Jan 13 00:44:14 kernel: module:  nf_nat_rtsp	 bf770000	 3400
Jan 13 00:44:14 kernel: module:  nf_conntrack_rtsp	 bf762000	 4268
Jan 13 00:44:14 kernel: module:  nf_nat_ftp	 bf75c000	 1314
Jan 13 00:44:14 kernel: module:  nf_conntrack_ftp	 bf755000	 5131
Jan 13 00:44:14 kernel: module:  ip6table_mangle	 bf74f000	 1093
Jan 13 00:44:14 kernel: module:  ip6table_filter	 bf749000	 893
Jan 13 00:44:14 kernel: module:  ipt_account	 bf739000	 8737
Jan 13 00:44:14 kernel: module:  xt_length	 bf733000	 890
Jan 13 00:44:14 kernel: module:  ip6t_LOG	 bf72c000	 4705
Jan 13 00:44:14 kernel: module:  sr_mod	 bf717000	 11507
Jan 13 00:44:14 kernel: module:  cdrom	 bf708000	 33318
Jan 13 00:44:14 kernel: module:  zaurus	 bf702000	 2146
Jan 13 00:44:14 kernel: module:  rndis_host	 bf6fb000	 5193
Jan 13 00:44:14 kernel: module:  net1080	 bf6f5000	 2871
Jan 13 00:44:14 kernel: module:  cdc_ether	 bf6ef000	 3224
Jan 13 00:44:14 kernel: module:  asix	 bf6e6000	 11629
Jan 13 00:44:14 kernel: module:  usbnet	 bf6dc000	 12057
Jan 13 00:44:14 kernel: module:  mii	 bf6d6000	 3484
Jan 13 00:44:14 kernel: module:  usblp	 bf6cd000	 9354
Jan 13 00:44:14 kernel: module:  ohci_hcd	 bf6c2000	 19288
Jan 13 00:44:14 kernel: module:  ehci_hcd	 bf6b3000	 34220
Jan 13 00:44:14 kernel: module:  xhci_hcd	 bf69e000	 53286
Jan 13 00:44:14 kernel: module:  ufsd	 bf5f8000	 595091
Jan 13 00:44:14 kernel: module:  jnl	 bf5eb000	 27927
Jan 13 00:44:14 kernel: module:  ext2	 bf5d5000	 55581
Jan 13 00:44:14 kernel: module:  ext4	 bf58c000	 234233
Jan 13 00:44:14 kernel: module:  jbd2	 bf575000	 52386
Jan 13 00:44:14 kernel: module:  crc16	 bf56f000	 1081
Jan 13 00:44:14 kernel: module:  ext3	 bf548000	 113117
Jan 13 00:44:14 kernel: module:  jbd	 bf533000	 45524
Jan 13 00:44:14 kernel: module:  mbcache	 bf52b000	 5156
Jan 13 00:44:14 kernel: module:  usb_storage	 bf518000	 34163
Jan 13 00:44:14 kernel: module:  sg	 bf50b000	 21138
Jan 13 00:44:14 kernel: module:  sd_mod	 bf4ff000	 23159
Jan 13 00:44:14 kernel: module:  scsi_wait_scan	 bf4f9000	 502
Jan 13 00:44:14 kernel: module:  scsi_mod	 bf4ca000	 114857
Jan 13 00:44:14 kernel: module:  usbcore	 bf49f000	 108178
Jan 13 00:44:14 kernel: module:  jffs2	 bf47e000	 94871
Jan 13 00:44:14 kernel: module:  zlib_deflate	 bf474000	 19990
Jan 13 00:44:14 kernel: module:  nf_nat_pptp	 bf46e000	 1796
Jan 13 00:44:14 kernel: module:  nf_conntrack_pptp	 bf468000	 3739
Jan 13 00:44:14 kernel: module:  nf_nat_proto_gre	 bf462000	 1047
Jan 13 00:44:14 kernel: module:  nf_conntrack_proto_gre	 bf45c000	 3499
Jan 13 00:44:14 kernel: module:  et	 bf000000	 63696
Jan 13 00:44:14 kernel: Modules linked in: wl(P) igs(P) emf(P) tun nf_nat_sip nf_conntrack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_rtsp nf_conntrack_rtsp nf_nat_ftp nf_conntrack_ftp ip6table_mangle ip6table_filter ipt_account xt_length ip6t_LOG sr_mod cdrom zaurus rndis_host net1080 cdc_ether asix usbnet mii usblp ohci_hcd ehci_hcd xhci_hcd ufsd(P) jnl ext2 ext4 jbd2 crc16 ext3 jbd mbcache usb_storage sg sd_mod scsi_wait_scan scsi_mod usbcore jffs2 zlib_deflate nf_nat_pptp nf_conntrack_pptp nf_nat_prot
Jan 13 00:44:14 kernel: [<c0043ff8>] (unwind_backtrace+0x0/0xf8) from [<c0061588>] (warn_slowpath_common+0x4c/0x64)
Jan 13 00:44:14 kernel: [<c0061588>] (warn_slowpath_common+0x4c/0x64) from [<c00615bc>] (warn_slowpath_null+0x1c/0x24)
Jan 13 00:44:14 kernel: [<c00615bc>] (warn_slowpath_null+0x1c/0x24) from [<c00e7db8>] (wb_writeback+0x2bc/0x2d8)
Jan 13 00:44:14 kernel: [<c00e7db8>] (wb_writeback+0x2bc/0x2d8) from [<c00e7e58>] (wb_do_writeback+0x84/0x1ac)
Jan 13 00:44:14 kernel: [<c00e7e58>] (wb_do_writeback+0x84/0x1ac) from [<c00e800c>] (bdi_writeback_thread+0x8c/0x160)
Jan 13 00:44:14 kernel: [<c00e800c>] (bdi_writeback_thread+0x8c/0x160) from [<c0079d08>] (kthread+0x88/0x90)
Jan 13 00:44:14 kernel: [<c0079d08>] (kthread+0x88/0x90) from [<c003eb8c>] (kernel_thread_exit+0x0/0x8)
Jan 13 00:44:14 kernel: ---[ end trace 4a0a7eb14e82dde4 ]---

 

[goldrose1980]

Why is no one test Asuswrt-Merlin 3.0.0.4.374.38 HW acceleration with throughput under PPPoE mode？
pppoe mode being a large number of broadband providers are using me very concerned about this issue

 

[cvx01]

EM Build is Working Great!

Thanks for those who reported their feedback on the N66U driver. Please keep bringing it, especially if you are able to compare your wifi performance with the old SDK5 driver. Also interested in hearing if others do see better performance out of the EM build vs the regular build.

Hi Merlin,

Thanks for all the work on these builds. Here are my first test results on the N66U. This is without an NV reset coming from 3.0.0.4.374.36_beta1-sdk5 to 3.0.0.4.374.38_1-em.

3.0.0.4.374.36_beta1-sdk5
*2.4 GHz -54 dBm
*5.0 GHz -63 dBm

3.0.0.4.374.38_1-em
*2.4 GHz -50 dBm
*5.0 GHz -67 dBm

This was measured "best of" as received and recorded on my Android device using the app below. Device was fixed in same location when testing old vs new firmware.

app: https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer

The problem with the SDK6 builds for me wasn't so much the dBM as it was the throughput. I had a decent signal, but could never get over 35Mbs on my phone. With SDK5 and now the new EM Build, I can achieve well over 60Mbs while on 5Ghz.

In summary....
*About 5 dBm was lost on 5GHz band with EM Build
**Initial limited testing says this loss this does NOT impact performance
*About 4 dBm was gained on the 2.4GHz band
**I have not tested speed on this band yet as nearly all my speed dependent devices are 5GHz
*The EM build solves for the 5GHz wireless throughput issue (<35Mbs) I had on previous SDK6 builds

Overall, with an hour of limited initial testing, the EM build seems to be a viable candidate to replace the SDK5 build.

Next things to test:
--NV Reset to see if it makes a difference
--Does my Nest and Wireless Scale drop at random, like it did on SDK5 when legacy mode was not enabled on 2.4GHz

Thanks again and hope this provides some insight.

EDIT: Just performed an NV Reset. Reloaded my old config file. dBm is now IDENTICAL to what the SDK5 build was providing. Speed throughput is good too. EM build seems to solve for both signal and thoughput issues.

 

[klwillis]

IPV6 not working

I installed "RT-AC66U_3.0.0.4_374.38_1" and found that IPV6 no longer worked.
I went back to "RT-AC66U_3.0.0.4_374.35_4" everything working on this build.
Using IPV6, Open VPN and the DDNS client.


Wonder did anyone else experience this issue?

Thanks
Keith

 

[L&LD]

EDIT: Just performed an NV Reset. Reloaded my old config file. dBm is now IDENTICAL to what the SDK5 build was providing. Speed throughput is good too. EM build seems to solve for both signal and thoughput issues.

Reloading your old config file negated any benefit you would get from the NV Reset and manually entering your settings again.

This link (and the link it contains) shows how I got increased performance with each step when I upgraded to .38_1-em for my N66U.

http://forums.smallnetbuilder.com/showpost.php?p=98490&postcount=168

I installed "RT-AC66U_3.0.0.4_374.38_1" and found that IPV6 no longer worked.
I went back to "RT-AC66U_3.0.0.4_374.35_4" everything working on this build.
Using IPV6, Open VPN and the DDNS client.


Wonder did anyone else experience this issue?

Thanks
Keith

Known issue (see a RMerlin's response a few posts above) and fixed in next point release.

 

[cvx01]

Reloading your old config file negated any benefit you would get from the NV Reset and manually entering your settings again.

Generally, I would agree with your assessment. But.....

I've tested this on past upgrades and something interesting seems to happen with ASUS software updates.

1) When upgrading ASUS software (Merlin or Official), it appears certain, albeit important NV variables are not touched at all.
2) This means, if ASUS adds, changes or modifies some underlying code, it will never hit the NV Table (and reach the end user) unless a factory reset occurs, or something in the user interface is programmed to create the specific variable.
3) When the factory reset occurs, it restores the NV back to whatever the SW says are the defaults.
4) When a CFG file is restored, it appears NOT all values are restored.
5) In other words, it seems ASUS was smart enough to have your backup file only restore the user level data that is important, and lower underlying NV variables (Which in my opinion can can cause the most issues) are ignored.


DETAILS/METHOD (Feel free to test if you haven't factory reset yet after the latest or prior updates):
1) Upgraded from 3.0.0.4.374.36_beta1-sdk5 to 3.0.0.4.374.38_1-em
2) After update to 3.0.0.4.374.38_1-em I exported NVRAM in clear text using method here (Thanks Merlin!)
3) Performed .CFG file backup in Web GUI
4) At this point, the file exported using steps 2 and 3 should be identical (In theory)
5) Factory Reset (Using both GUI and hardware button)
6) Restore .CFG file from step 3 using the Web GUI
7) Exported NVRAM in clear text, again using Step 2
8) Using NVRAM clear text export files from Step 2 and Step 7, sort variables alphabetically, remove blank lines, diff/compare the two.

Theoretically, we should see zero difference in the NVRAM before and after the .CFG restore, if the theory holds true that 100% of data (and problems) is restored when you restore settings (.CFG restore) after a factory reset

However, that's not what appears to be happening. A boatload of values still change, even when restoring the same data. I've tested this exact scenario on prior builds and the same thing happens after a factory reset and .cfg file restore

1) New NV variables are added
2) Deprecated values are deleted
3) Low level, non user accessible radio parameters are updated

While it may restore a problem, for me at least, it has done more good than harm since low level radio parameters (Such as maxp5ga0) are updated. This are the type of things that can cause weird issues with drop outs and wonky behavior.

My theory is Asus appears to tweak certain low level settings between updates, but some of the low level tweaks never get implemented until a reset occurs when the NV defaults are called by the CFE, which I believe performs the reset.

And I'd venture a guess someone at Asus was smart enough to not allow the average joe to restore low level variables when performing a .cfg file restore, this is perhaps why only user accessible settings are restored and everything else low level is updated to the current SW baseline NV settings.

Below is what changed between backup/reset/restore of the exact same .CFG file after updating from 3.0.0.4.374.36_beta1-sdk5 to 3.0.0.4.374.38_1-em. I also cleared NV and restored prior to loading the SDK5 build, so there should not be carryover from prior builds.

- = NV variable deleted in 3.0.0.4.374.38_1-em
+ = NV variable added in 3.0.0.4.374.38_1-em
* = NV variable value changed after NV Reset & 3.0.0.4.374.38_1-em .CFG file restore

-networkmap_status=1
*pci/1/1/cckbw202gpo=0x5555 to 0x3333
*pci/1/1/cckbw20ul2gpo=0x5555 to 0x3333
*pci/1/1/legofdmbw202gpo=0x97555555 to 0x55555555
*pci/1/1/legofdmbw20ul2gpo=0x97555555 to 0x55555555
*pci/1/1/maxp2ga0=0x70 to 0x64
*pci/1/1/maxp2ga1=0x70 to 0x64
*pci/1/1/maxp2ga2=0x70 to 0x64
*pci/2/1/legofdm40duppo=0x0000 to 0x2222
*pci/2/1/legofdmbw205ghpo=0x77777777 to 0x75311111
*pci/2/1/legofdmbw205gmpo=0x77777777 to 0x75311111
*pci/2/1/legofdmbw20ul5ghpo=0x77777777 to 0x75311111
*pci/2/1/legofdmbw20ul5gmpo=0x77777777 to 0x75311111
*pci/2/1/maxp5ga0=0x6A to 0x5E (Seems related to Max Power or Amp gain)
*pci/2/1/maxp5ga1=0x6A to 0x5E
*pci/2/1/maxp5ga2=0x6A to 0x5E
*pci/2/1/maxp5gha0=0x6A to 0x5E
*pci/2/1/maxp5gha1=0x6A to 0x5E
*pci/2/1/maxp5gha2=0x6A to 0x5E
*pci/2/1/mcs32po=0x7777 to 0x2222
*pci/2/1/mcsbw205ghpo=0x77777777 to 0x75311111
*pci/2/1/mcsbw205gmpo=0x77777777 to 0x75311111
*pci/2/1/mcsbw20ul5ghpo=0x77777777 to 0x75311111
*pci/2/1/mcsbw20ul5gmpo=0x77777777 to 0x75311111
*pci/2/1/mcsbw405ghpo=0x77777777 to 0x75311111
*pci/2/1/mcsbw405gmpo=0x77777777 to 0x75311111
*sshd_dsskey= PRIVATE TO DIFFERENT KEY AFTER RESTORE
*sshd_ecdsakey = PRIVATE to DIFFERENT KEY AFTER RESTORE
*sshd_hostkey = PRIVATE to DIFFERENT KEY AFTER RESTORE
-usb_path1_host=2
-usb_path1_label0=ASUS
-usb_path1_label10=
-usb_path1_label11=
-usb_path1_label12=
-usb_path1_label13=
-usb_path1_label14=
-usb_path1_label15=
-usb_path1_label1=
-usb_path1_label2=
-usb_path1_label3=
-usb_path1_label4=
-usb_path1_label5=
-usb_path1_label6=
-usb_path1_label7=
-usb_path1_label8=
-usb_path1_label9=
-usb_path2_host=
-usb_path2_label0=
-usb_path2_label10=
-usb_path2_label11=
-usb_path2_label12=
-usb_path2_label13=
-usb_path2_label14=
-usb_path2_label15=
-usb_path2_label1=
-usb_path2_label2=
-usb_path2_label3=
-usb_path2_label4=
-usb_path2_label5=
-usb_path2_label6=
-usb_path2_label7=
-usb_path2_label8=
-usb_path2_label9=
-usb_path3_fs_path0=sdb
-usb_path3_host=2
-usb_path3_label0=
-usb_path3_label10=
-usb_path3_label11=
-usb_path3_label12=
-usb_path3_label13=
-usb_path3_label14=
-usb_path3_label15=
-usb_path3_label1=
-usb_path3_label2=
-usb_path3_label3=
-usb_path3_label4=
-usb_path3_label5=
-usb_path3_label6=
-usb_path3_label7=
-usb_path3_label8=
-usb_path3_label9=
-usb_path3_pool_error=0
-usb_path3_removed=0
+usb_path3_node=1-1.4
+usb_path3_speed=480

If I run this entire scenario again, only the SSDH keys change, which furthers my belief that there isn't very good NV update control between updates. Only when an update occurs does a delta in NV values occur. I don't think this is a Merlin problem , but the nature of how Asus has implemented their update process.

PS: To be clear, I'm not saying a factory reset and manual re-entry doesn't solve issues. It's probably the preferred route for most people. But, for those of us that have highly customized configurations that are too lazy or don't have the time to set everything back up from scratch, this may be an interim step and there may be some benefit to backup/reset/restore after an update given the number of low level parameters that change.

 

[saulos]

All working fine for me.
Thanks Marlin

 

[jim769]

I keep seeing that ipv6 Is broke in the new build yet it works fine here am I missing something?

 

[RMerlin]

Router = RT-AC66U Fiber internet 50 Mbps down 5 Mbps up
i am not quite sure if the problems i have at the moment is related to this firmware but all i know is that nothing has changed on my side
except this new firware.
Aside from regular internet usage i heavily stream media localy from my macbook pro to apple tv and also stream audio to an airplay
enabled speaker system. this almost always worked perfectly.no glitch whatsoever. after flashing this new firmware however i am having some connetion problems
and glitch when streaming audio. apple tv got disconnocted from the wifi twice in 2 hours which has never happened before.
tried rebooting etc but no dice. on the otherhand i cant just produce this error. its random and doesnt happen all the time.

Try erasing and reconfiguring the wifi profile on the device. The wireless driver on the RT-AC66U was updated in this release.

 

[RMerlin]

Looks like in general the RT-N66U owners like the performance of 374.38_1. But for me on the RT-AC68R the performance seems to have taken a small, but noticeable, step backwards from the 374.37_2 build I was running on before. I think 374.37_2 was based on the .501 wireless drivers. Don't know which newer version of the driver is used in 374.38_1 for the AC68R. But I do share the frustration with Asus that someone expressed earlier. Asus does not seem to have any continuity or progression with wireless performance with each newer iteration of the drivers they release. You would expect the performance to get better or at least stay the same with a newer driver. But apparently not with Asus drivers

374.37_2 was actually based on a buggy driver that pre-dated 501. A lot of people were having problems with that driver.

374.38 is based on a driver that should be closer to 501.

 

[RMerlin]

I've just hit a strange problem with my RT-N66U.

I was working fine on 374.38_1 and upgraded to 374.38_1em. When this was complete I couldn't connect to 5G so after some tinkering I went back to the non-em build but I still have nothing. I recovered my config from before the em upgrade and still have no 5G. I've tried using channel 36 with no luck.

My iPhone 5S and HP Laptop both so no 5G network, and inssider tells me that there is no 5G network seen.

Any ideas?

Check which channel your router is using, and manually set it to a lower channel.

 

[RMerlin]

I keep seeing that ipv6 Is broke in the new build yet it works fine here am I missing something?

The issue is conditional to a certain configuration.

 

[RMerlin]

Jan 13 00:44:14 kernel: ------------[ cut here ]------------
Jan 13 00:44:14 kernel: WARNING: at fs/fs-writeback.c:560 wb_writeback+0x2bc/0x2d8()
Jan 13 00:44:14 kernel: module:  wl	 bf7fc000	 3924437
Jan 13 00:44:14 kernel: module:  igs	 bf7f2000	 12935
Jan 13 00:44:14 kernel: module:  emf	 bf7e8000	 16229
Jan 13 00:44:14 kernel: module:  tun	 bf7d2000	 12723
Jan 13 00:44:14 kernel: module:  nf_nat_sip	 bf7c8000	 5586
Jan 13 00:44:14 kernel: module:  nf_conntrack_sip	 bf7b8000	 16679
Jan 13 00:44:14 kernel: module:  nf_nat_h323	 bf7a5000	 5137
Jan 13 00:44:14 kernel: module:  nf_conntrack_h323	 bf78d000	 34844
Jan 13 00:44:14 kernel: module:  nf_nat_rtsp	 bf770000	 3400
Jan 13 00:44:14 kernel: module:  nf_conntrack_rtsp	 bf762000	 4268
Jan 13 00:44:14 kernel: module:  nf_nat_ftp	 bf75c000	 1314
Jan 13 00:44:14 kernel: module:  nf_conntrack_ftp	 bf755000	 5131
Jan 13 00:44:14 kernel: module:  ip6table_mangle	 bf74f000	 1093
Jan 13 00:44:14 kernel: module:  ip6table_filter	 bf749000	 893
Jan 13 00:44:14 kernel: module:  ipt_account	 bf739000	 8737
Jan 13 00:44:14 kernel: module:  xt_length	 bf733000	 890
Jan 13 00:44:14 kernel: module:  ip6t_LOG	 bf72c000	 4705
Jan 13 00:44:14 kernel: module:  sr_mod	 bf717000	 11507
Jan 13 00:44:14 kernel: module:  cdrom	 bf708000	 33318
Jan 13 00:44:14 kernel: module:  zaurus	 bf702000	 2146
Jan 13 00:44:14 kernel: module:  rndis_host	 bf6fb000	 5193
Jan 13 00:44:14 kernel: module:  net1080	 bf6f5000	 2871
Jan 13 00:44:14 kernel: module:  cdc_ether	 bf6ef000	 3224
Jan 13 00:44:14 kernel: module:  asix	 bf6e6000	 11629
Jan 13 00:44:14 kernel: module:  usbnet	 bf6dc000	 12057
Jan 13 00:44:14 kernel: module:  mii	 bf6d6000	 3484
Jan 13 00:44:14 kernel: module:  usblp	 bf6cd000	 9354
Jan 13 00:44:14 kernel: module:  ohci_hcd	 bf6c2000	 19288
Jan 13 00:44:14 kernel: module:  ehci_hcd	 bf6b3000	 34220
Jan 13 00:44:14 kernel: module:  xhci_hcd	 bf69e000	 53286
Jan 13 00:44:14 kernel: module:  ufsd	 bf5f8000	 595091
Jan 13 00:44:14 kernel: module:  jnl	 bf5eb000	 27927
Jan 13 00:44:14 kernel: module:  ext2	 bf5d5000	 55581
Jan 13 00:44:14 kernel: module:  ext4	 bf58c000	 234233
Jan 13 00:44:14 kernel: module:  jbd2	 bf575000	 52386
Jan 13 00:44:14 kernel: module:  crc16	 bf56f000	 1081
Jan 13 00:44:14 kernel: module:  ext3	 bf548000	 113117
Jan 13 00:44:14 kernel: module:  jbd	 bf533000	 45524
Jan 13 00:44:14 kernel: module:  mbcache	 bf52b000	 5156
Jan 13 00:44:14 kernel: module:  usb_storage	 bf518000	 34163
Jan 13 00:44:14 kernel: module:  sg	 bf50b000	 21138
Jan 13 00:44:14 kernel: module:  sd_mod	 bf4ff000	 23159
Jan 13 00:44:14 kernel: module:  scsi_wait_scan	 bf4f9000	 502
Jan 13 00:44:14 kernel: module:  scsi_mod	 bf4ca000	 114857
Jan 13 00:44:14 kernel: module:  usbcore	 bf49f000	 108178
Jan 13 00:44:14 kernel: module:  jffs2	 bf47e000	 94871
Jan 13 00:44:14 kernel: module:  zlib_deflate	 bf474000	 19990
Jan 13 00:44:14 kernel: module:  nf_nat_pptp	 bf46e000	 1796
Jan 13 00:44:14 kernel: module:  nf_conntrack_pptp	 bf468000	 3739
Jan 13 00:44:14 kernel: module:  nf_nat_proto_gre	 bf462000	 1047
Jan 13 00:44:14 kernel: module:  nf_conntrack_proto_gre	 bf45c000	 3499
Jan 13 00:44:14 kernel: module:  et	 bf000000	 63696
Jan 13 00:44:14 kernel: Modules linked in: wl(P) igs(P) emf(P) tun nf_nat_sip nf_conntrack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_rtsp nf_conntrack_rtsp nf_nat_ftp nf_conntrack_ftp ip6table_mangle ip6table_filter ipt_account xt_length ip6t_LOG sr_mod cdrom zaurus rndis_host net1080 cdc_ether asix usbnet mii usblp ohci_hcd ehci_hcd xhci_hcd ufsd(P) jnl ext2 ext4 jbd2 crc16 ext3 jbd mbcache usb_storage sg sd_mod scsi_wait_scan scsi_mod usbcore jffs2 zlib_deflate nf_nat_pptp nf_conntrack_pptp nf_nat_prot
Jan 13 00:44:14 kernel: [<c0043ff8>] (unwind_backtrace+0x0/0xf8) from [<c0061588>] (warn_slowpath_common+0x4c/0x64)
Jan 13 00:44:14 kernel: [<c0061588>] (warn_slowpath_common+0x4c/0x64) from [<c00615bc>] (warn_slowpath_null+0x1c/0x24)
Jan 13 00:44:14 kernel: [<c00615bc>] (warn_slowpath_null+0x1c/0x24) from [<c00e7db8>] (wb_writeback+0x2bc/0x2d8)
Jan 13 00:44:14 kernel: [<c00e7db8>] (wb_writeback+0x2bc/0x2d8) from [<c00e7e58>] (wb_do_writeback+0x84/0x1ac)
Jan 13 00:44:14 kernel: [<c00e7e58>] (wb_do_writeback+0x84/0x1ac) from [<c00e800c>] (bdi_writeback_thread+0x8c/0x160)
Jan 13 00:44:14 kernel: [<c00e800c>] (bdi_writeback_thread+0x8c/0x160) from [<c0079d08>] (kthread+0x88/0x90)
Jan 13 00:44:14 kernel: [<c0079d08>] (kthread+0x88/0x90) from [<c003eb8c>] (kernel_thread_exit+0x0/0x8)
Jan 13 00:44:14 kernel: ---[ end trace 4a0a7eb14e82dde4 ]---

Without knowing what you were doing at the time and on which router, this doesn't tell me anything.

 

[brummygit]

Check which channel your router is using, and manually set it to a lower channel.

I was on Auto - but the wireless log showed 36. I also manually set 36 with no success.

As my later post said, a factory reset and config restore did the trick.

 

[dzemp]

DNLA broken after upgrade to 3.0.0.4.374.38_1

I've upgraded my N66U from 3.0.0.4.374.35_4 to 3.0.0.4.374.38_1 today, which broke DNLA for some of my DNLA clients (for example my Samsung TV).
I've seen that there was a networkmap DNLA detection fix in 3.0.0.4.374.36 Beta 1, which seems to be the bug I'm hitting on. But it seems that its still not working as with 3.0.0.4.374.35_4 or older builds.

@Eric: any chance that you can have a look at it?

 

[L&LD]

Generally, I would agree with your assessment. But.....

I've tested this on past upgrades and something interesting seems to happen with ASUS software updates.

1) When upgrading ASUS software (Merlin or Official), it appears certain, albeit important NV variables are not touched at all.
2) This means, if ASUS adds, changes or modifies some underlying code, it will never hit the NV Table (and reach the end user) unless a factory reset occurs, or something in the user interface is programmed to create the specific variable.
3) When the factory reset occurs, it restores the NV back to whatever the SW says are the defaults.
4) When a CFG file is restored, it appears NOT all values are restored.
5) In other words, it seems ASUS was smart enough to have your backup file only restore the user level data that is important, and lower underlying NV variables (Which in my opinion can can cause the most issues) are ignored.

While this seems to work for your specific setup - I do see a difference manually entering (and testing the new firmware) with each update.

Also, I think that the RMerlin code is 'special' in the sense that he picks and chooses which bits of code he puts in his releases (in addition to the little bug fixes he does for the Asus code along the way). This by itself is reason enough for me to do a manual restore - rather than risk bugs accumulate with each upgrade I do.

Being 'lazy' has it's benefits - but doing it right has benefits too.

 

[stephn666]

1. Could be something that Asus broke in the VLAN handling in this FW. Make a backup of your settings, reset back to factory defaults, and try just reconfiguring the basics to see if it resolves your issue. If it does, proceed with manually reconfiguring everything else. If it didn't then restore your saved settings to save time.

2. I have little experience myself with VLANs, so someone else actually using them might have a suggestion as to how to configure VLANs to you don't lose both ports.

3. Also just to be on the safe side, make sure that Dual WAN is still disabled (WAN -> Dual WAN).

Thanks,

1. Ok, maybe i don't know.
I have reconfiguring after reset, same problems.

2.
ok, I will searching some informations on the VLANs configuration hoping to find something.

3. It is disable well.

 

[TeTo]

Make sure your router isn't on a channel that isn't supported by your wireless client. To be safe, try channel 36.

Thanks Merlín, works great!

Enviado desde mi Amazon Kindle Fire HD mediante Tapatalk

 

[WET]

374.38_1 & 374.38_1-em Range NOT as good as SDK5

I loaded 374.38_1-em last night performing factory reset & manually loading inputs. Tested range this morning with a 2.4ghz only HP laptop this morning. Have a large house so coverage is important it is why I purchased the RT-N66U. I use EA-N66 as AP for 5ghz coverage.

I did forget & reload client settings in the laptop, bottom line is both 374.38_1-em & then 374.38_1 do not have the range / coverage all the SDK5's builds do. Laptop does not hook up at opposite corner of the house. After reverting back to 374.36_beta1-sdk5 same computer in same location with same router settings, laptop hooks up & has internet.

I think what everyone must be posting is that RSSI shows stronger and/or wireless bars on computer show stronger but range is still not there.

The bars on the computer when running both 374.38_1 did show stronger until it did not hook up at a lesser range.

Add'l info, I run 40mhz wide channel on my 2.4 using channels 1+5 which is best in my area which is rural. There are 4 others on the 2.4 band one other using 40mhz wide channel 11+7 (closest / strongest signal to me). I have 2.4ghz band set at 150mW.

 

[L&LD]

Delete your wireless connections on your clients and recreate them with the new firmware installed (with a reset to defaults and manually entering any settings first).

Then, I would try 20MHz wide channels instead: the 2.4GHz range overlaps (a lot).