What's new

Asuswrt-Merlin 3.0.0.4.270.24 BETA 4 is out

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
So what are we looking for that you want/need feedback on?

All answered in the first post of this thread:

- IPv6
- 3 TB HDD support (one report so far that the issue is still there)
- OpenVPN
- General operation
 
Thanks merlin, actually i just put beta 24 on there, still having the same issue, actually its better, now i can download the update that wasn't pulling in at all, but its pulling in at 2 kbps, when everything else on the ps3 is showing 11mbps and all downloads from playstation network are at 256KBps, so something improved from stock to your beta, but still not quite there. and its my router, all other issues have been ruled out, directly plugging the ps3 to modem will pull the same update at a good speed.

Try toggling Enhanced Interference Management on the Wireless -> Professional page, make sure your cable between modem and router is Cat5e or Cat6, try using a different wireless channel (and use a fixed one instead of Auto), use 20 MHz band instead of 20/40.
 
Haven't seen anyone else with download issues, but I still can't get through to the mediafire link either here at work or at home (both Win 7, IE machines). I was able to get through on my Blackberry Playbook and download the zip file, but I think that might be routed to MediaFire's mobile site. One of my connection issues may be that the Playbook won't work with the Asus set at N-only. But I am going to install the beta tonight, so thanks again Merlin.

Try doing a traceroute to www.mediafire.com to see if it's your ISP doing something funky. Also try a different browser just in case.
 
RMerlin, perhaps a dumb question:

Does upgrading from stock firmware to yours wipe out existing configuration settings? I know in the case of most custom firmwares the answer is yes, but as yours is based on ASUS' existing firmware, I didn't know if this was the case or not.

I just need to make sure I plan in advance if that is the case.

Provided your firmware isn't older than 3.0.0.4.220 on an RT-N66U, all settings will be preserved.
 
Openvpn serve1 does not work

I was running up to .23b. My openvpn server 1 and openvpn server 2 both worked. The only difference was the listening port. Never a problem. I installed .24 beta. server 2 worked and server 1 did not work. I swapped ports and server 2 still worked and server 1 did not work.

Here is the log

Dec 31 16:18:48 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:18:48 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:18:51 kernel: printk: 9 messages suppressed.
Dec 31 16:18:51 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:18:52 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:18:52 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:18:55 notify_rc : start_vpnserver1
Dec 31 16:18:55 rc_service: start_vpnserver1 is waitting restart_vpnserver1...
Dec 31 16:18:57 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:18:57 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:01 crond[550]: crond: USER admin pid 1281 cmd service vpnserver2 start
Dec 31 16:19:01 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:01 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:05 kernel: printk: 3 messages suppressed.
Dec 31 16:19:05 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:05 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:06 kernel: printk: 2 messages suppressed.
Dec 31 16:19:06 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:06 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:06 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:10 rc_service: skip the event: start_vpnserver1.
Dec 31 16:19:10 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:10 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:14 kernel: printk: 145 messages suppressed.
Dec 31 16:19:14 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:15 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:15 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:15 kernel: printk: 11 messages suppressed.
Dec 31 16:19:15 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:19 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:19 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:20 kernel: printk: 251 messages suppressed.
Dec 31 16:19:20 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:24 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:24 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:28 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:28 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:29 kernel: printk: 15 messages suppressed.
Dec 31 16:19:29 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:31 kernel: printk: 3 messages suppressed.
Dec 31 16:19:31 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:33 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:33 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:34 kernel: ACCEPT <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:31:e4:41:08:00 <1>SRC=73.71.20.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=47313 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Dec 31 16:19:35 kernel: printk: 77 messages suppressed.
Dec 31 16:19:35 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:37 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:37 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:41 kernel: printk: 101 messages suppressed.
Dec 31 16:19:41 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:42 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:42 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:46 kernel: printk: 35 messages suppressed.
Dec 31 16:19:46 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:46 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:46 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:50 kernel: printk: 221 messages suppressed.
Dec 31 16:19:50 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:19:51 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:51 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:19:55 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:19:55 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:20:00 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:20:00 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:20:01 crond[550]: crond: USER admin pid 1288 cmd service vpnserver2 start
Dec 31 16:20:04 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:20:04 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
Dec 31 16:20:05 kernel: printk: 171 messages suppressed.
Dec 31 16:20:05 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:20:05 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:20:08 kernel: printk: 2 messages suppressed.
Dec 31 16:20:08 kernel: protocol 0000 is buggy, dev eth0
Dec 31 16:20:09 dnsmasq-dhcp[547]: DHCPREQUEST(br0) 192.168.163.114 00:50:c2:40:c1:b3
Dec 31 16:20:09 dnsmasq-dhcp[547]: DHCPACK(br0) 192.168.163.114 00:50:c2:40:c1:b3 TL-150
 
Yout ran in the same problem as I did the VPN require time and your time sync didn't work.


Chris
 
Yout ran in the same problem as I did the VPN require time and your time sync didn't work.


Chris

Correct. His log shows that his clock was still set to Dec 31st, which will prevent OpenVPN from working - SSL requires an accurate clock.
 
IPv6 and general operation look good here. Time will tell, though.
 
Ist this ok ???
 

Attachments

  • 01.jpg
    01.jpg
    63.1 KB · Views: 504
Well the firmware upgrade went very smoothly, and this was the first time I've tried this with a router. And everything connected and stayed connected overnight, including the two devices that had previously been dropping. So well done Merlin! I have notices a significant drop-off in the inSSIDer max rate, from 450 under the official firmware, down to 216 with this beta. I will try a few of the tweaks suggested here and on similar threads.
 
I updated to .24 from .23b this morning.

Everything seems to be working ok but for me at least, I cannot access my usb drive.

Right after update, I could access my drive but I could not write onto it.
It kept saying I needed permission.
I tried to reboot, and after the reboot, I cannot access my drive.
I've tried remounting, disabling share then enabling again reboot again, but nothing seems to work.

I do not know if this is just me but it was working ok in .23b for me.

EDIT: It seems the problem was with my drive. I'm back to .23b and It's still the same. I formatted this drive using Gparted to ext3 and now it's not working well with the router.
 
Last edited:
Just one minor thing here. I'm seeing a lot more MAC addresses in the client status sub-window. When I bring up the client status window from the network map page, sometimes (initially or after a while of not displaying the client status sub-window) all MAC addresses will be displayed. I need to refresh the list to get the symbolic names of the clients displayed. I'm wondering if the display should wait until it has the symbolic names, since they are almost immediately available using the refresh button.

Don't recall this happening before. Could be me, maybe I should try a reboot to see if that behavior changes?

Other than that, everything looks great.
 
3G support broken in 266.24 Beta1?

3G support seems to have been broken in 266.24 Beta1. When flashing this build my modem is recognized but doesn't connect. I tried everything (including a factory reset, removing the modem from the USB port, using the other port, removing the USB disk) to revert it to live but didn't succeed.

When flashing back to 266.23b the connection was instantly restored without flaw...

I'm using a HUAWEI E372 stick - works fine with the precedent builds, but not with 266.24 Beta1 :confused:

Ciao
Gerald
 
Just one minor thing here. I'm seeing a lot more MAC addresses in the client status sub-window. When I bring up the client status window from the network map page, sometimes (initially or after a while of not displaying the client status sub-window) all MAC addresses will be displayed. I need to refresh the list to get the symbolic names of the clients displayed. I'm wondering if the display should wait until it has the symbolic names, since they are almost immediately available using the refresh button.

Don't recall this happening before. Could be me, maybe I should try a reboot to see if that behavior changes?

Other than that, everything looks great.

The Client list might require a while to properly fill up, especially if you just rebooted the router, and you have existing DHCP leases on your network. They will typically fully resolve once they have renewed their DHCP leases.
 
3G support seems to have been broken in 266.24 Beta1. When flashing this build my modem is recognized but doesn't connect. I tried everything (including a factory reset, removing the modem from the USB port, using the other port, removing the USB disk) to revert it to live but didn't succeed.

When flashing back to 266.23b the connection was instantly restored without flaw...

I'm using a HUAWEI E372 stick - works fine with the precedent builds, but not with 266.24 Beta1 :confused:

Can you see if the System Log has any additional info? I can't see what could have broken 3G support, but since I don't have a 3G device I cannot test anything myself.

Anyone else with a similar issue with their 3G stick?
 
Can you see if the System Log has any additional info? I can't see what could have broken 3G support, but since I don't have a 3G device I cannot test anything myself.

Nothing found in syslog that would indicate a dialin-process with .24

In the syslog of .23 I found the following lines:

Jan 1 01:00:25 notify_rc : restart_wan_if 1
Jan 1 01:00:25 rc_service: restart_wan_if 1 is waitting restart_wan_if 0...
Jan 1 01:00:25 pppd[605]: Serial connection established.
Jan 1 01:00:25 pppd[605]: Using interface ppp0
Jan 1 01:00:25 pppd[605]: Connect: ppp0 <--> /dev/ttyUSB0
Jan 1 01:00:25 kernel: Ebtables v2.0 registered
Jan 1 01:00:26 kernel: kernel msg: ebtables bug: please report to author: match->check failed
Jan 1 01:00:28 pppd[605]: Could not determine remote IP address: defaulting to 10.64.64.64
Jan 1 01:00:28 pppd[605]: local IP address 178.112.yx.xxx
Jan 1 01:00:28 pppd[605]: remote IP address 10.64.64.64
Jan 1 01:00:28 pppd[605]: primary DNS address 213.94.xx.xx
Jan 1 01:00:28 pppd[605]: secondary DNS address 213.94.xx.xx
Jan 1 01:00:28 dnsmasq[627]: read /etc/hosts - 3 addresses
Jan 1 01:00:28 dnsmasq-dhcp[627]: read /etc/ethers - 21 addresses
Jan 1 01:00:28 dnsmasq[627]: using nameserver 213.94.xx.xx#53
Jan 1 01:00:28 dnsmasq[627]: using nameserver 213.94.xx.xx#53
Jan 1 01:00:28 notify_rc : start_nat_rules
Jan 1 01:00:28 rc_service: start_nat_rules is waitting restart_wan_if 0...
Jan 1 01:00:32 stop_wan(): perform DHCP release
Jan 1 01:00:32 kernel: br0: port 1(vlan1) entering disabled state
Jan 1 01:00:32 kernel: vlan1: dev_set_promiscuity(master, 1)
Jan 1 01:00:32 kernel: br0: port 1(vlan1) entering listening state
Jan 1 01:00:32 kernel: br0: port 1(vlan1) entering learning state
Jan 1 01:00:32 kernel: br0: topology change detected, propagating
Jan 1 01:00:32 kernel: br0: port 1(vlan1) entering forwarding state
Jan 1 01:00:35 rc_service: skip the event: restart_wan_if 1.
Jan 1 01:00:35 WAN Connection: WAN was restored.

A similar entry in syslog of .24 is missing, syslog ends with

Jan 1 01:00:55 pppd[639]: Timeout waiting for PADO packets
Jan 1 01:00:55 pppd[639]: Unable to complete PPPoE Discovery

syslog of .24 has only 140 lines up to that entry, in the syslog of .24 I can find 375 lines...

I could send you the two logfiles per PM if you want...
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top