Asuswrt-Merlin 374.40 is out

[geops]

Thanks for the suggestion, but my PC is hard wired.

In that case try a different computer with a different lan card. It is a weird issue.

 

[cofetym]

Roll Back

I've had dropouts with 374.40 and rolled back to .39 and all is well again in my environment.

 

[Vandergraff]

I have an SB6121 and same router as Keenan RT-N66 and saw similar behavior with 39_0-em and below. It only seemed to change when I updated to 374.40

That's the first time I saw ICMPv6 ECHO REQUEST returning a reply with an IPv6 port test. Previously it had been 'stealth'ed

Well, I've never tried that particular test site before and have only tried it with my current FW of 39_0-em. On the ShieldsUp site I've always had stealth/green results on the tests I've ran there.

I just removed the router and went straight computer to the modem and got the same results, all green including the echo request.

I went back to 39_0-em and confirm that ICMPv6 ECHO REQUEST returned : ECHO NO REPLY

As I reported last night on 374.40 ICMPv6 ECHO REQUEST returned : ECHO REPLY

I have a RT-N66U and SB6121 modem on Comcast and am using http://ipv6.chappell-family.com/ipv6tcptest/ as an IPv6 port test.

I understand Merlin said 'Nothing has been changed to the IPv6 firewall' on these releases and it sounds like the 374.40 result is the expected behavior - yet at least for me 39_0-em (and earlier) showed 'ICMPv6 ECHO REQUEST' as 'stealth'.

 

[Bitgod]

Had one hiccup upgrading my N66U from .32 to .40.

So I flushed the NVRAM before the update, then updated, then flushed again.
I started to set up the router, making my LAN a 10.x.x.x network. I got to the port forwarding tab and entered 4 ports that I had open under .32, I hit apply...and the router reset itself, including the password and going back to the 192.168 IP address.

I ran through the setup again, changed LAN IP, then jumped to the port forwarding in case my time got wasted again, and this time I didn't have an issue. So I have the router set up the way I wanted. SHRUG

 

[sm00thpapa]

I just went back to .35_4-SDK5 on my N66W to see how it runs. It seems the SDK6 wireless drivers were not meant for the N66U. Any firmware with an SDK6 driver I have range issues on wireless. I may go back to .276 for good and I don't care about the security issues. I just need good wi-fi range. Anything with sharing will be turned off.

 

[Keenan]

I went back to 39_0-em and confirm that ICMPv6 ECHO REQUEST returned : ECHO NO REPLY

As I reported last night on 374.40 ICMPv6 ECHO REQUEST returned : ECHO REPLY

I have a RT-N66U and SB6121 modem on Comcast and am using http://ipv6.chappell-family.com/ipv6tcptest/ as an IPv6 port test.

I understand Merlin said 'Nothing has been changed to the IPv6 firewall' on these releases and it sounds like the 374.40 result is the expected behavior - yet at least for me 39_0-em (and earlier) showed 'ICMPv6 ECHO REQUEST' as 'stealth'.

I checked the two other computers on the same home network and they both in fact show the yellow "Echo Reply" on the Echo Request. My main usage PC does not, it shows the "green" response. I'm not sure what the deal is, it's a bit beyond my knowledge base. Is this something that should be fixed?

Everything seems to work just fine, but if it's a security concern I definitely want to rectify it if possible.

I'll be updating to 40_0 later today, maybe it will "fix" itself then.

 

[zboq]

Hi, I updated my N66U to .40 and I have a problem. This is what I have in the routers log:

Mar 13 20:02:05 smbd[1300]: [2014/03/13 20:02:05, 0] rpc_server/srv_pipe_hnd.c:make_internal_rpc_pipe_p(295)
Mar 13 20:02:05 smbd[1300]:   ERROR! no memory for pipes_struct!
Mar 13 20:02:05 smbd[1300]: [2014/03/13 20:02:05, 0] rpc_server/srv_pipe_hnd.c:open_rpc_pipe_p(231)
Mar 13 20:02:05 smbd[1300]:   open_rpc_pipe_p: make_internal_rpc_pipe_p failed.
Mar 13 20:02:05 smbd[1300]: [2014/03/13 20:02:05, 0] rpc_server/srv_pipe_hnd.c:make_internal_rpc_pipe_p(295)
Mar 13 20:02:05 smbd[1300]:   ERROR! no memory for pipes_struct!
Mar 13 20:02:05 smbd[1300]: [2014/03/13 20:02:05, 0] rpc_server/srv_pipe_hnd.c:open_rpc_pipe_p(231)
Mar 13 20:02:05 smbd[1300]:   open_rpc_pipe_p: make_internal_rpc_pipe_p failed.
Mar 13 20:02:05 smbd[1300]: [2014/03/13 20:02:05, 0] rpc_server/srv_pipe_hnd.c:make_internal_rpc_pipe_p(295)
Mar 13 20:02:05 smbd[1300]:   ERROR! no memory for pipes_struct!

In the same time top shows this:

Mem: 172464K used, 67248K free, 0K shrd, 1916K buff, 110396K cached
CPU0:  0.0% usr  100% sys  0.0% nic  0.0% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.25 0.16 0.18 1/81 1320

Of course with this error I can't browse through local share .
Can anyone tell me what's going on ?

Edit: question is what memory was router out of because after stopping pyload, smb started to work :/.
Maybe I should create a swap ?

 

[hazza]

.40_0 does not work with my Hurricane Electric IPv6 6in4 tunnel, giving me a 0/10 rating on http://test-ipv6.com.

Neither does all the other recent firmware versions that I have tried. (38_2, 39_0, 40_Beta)

This is after a 30/30/30 reset, manual reentry of all settings, etc.

Reverting to 374.35_4 fixes the issue, giving me a 10/10 on the above mentioned test URL.

 

[geops]

.40_0 does not work with my Hurricane Electric IPv6 6in4 tunnel, giving me a 0/10 rating on http://test-ipv6.com.

Neither does all the other recent firmware versions that I have tried. (38_2, 39_0, 40_Beta)

This is after a 30/30/30 reset, manual reentry of all settings, etc.

Reverting to 374.35_4 fixes the issue, giving me a 10/10 on the above mentioned test URL.

I have HE tunnel working fine on .40.

 

[RMerlin]

.40_0 does not work with my Hurricane Electric IPv6 6in4 tunnel, giving me a 0/10 rating on http://test-ipv6.com.

Neither does all the other recent firmware versions that I have tried. (38_2, 39_0, 40_Beta)

This is after a 30/30/30 reset, manual reentry of all settings, etc.

Reverting to 374.35_4 fixes the issue, giving me a 10/10 on the above mentioned test URL.

My HE tunnel works fine as well. Make sure the endpoint does get properly updated with Hurricane.

 

[Vandergraff]

I checked the two other computers on the same home network and they both in fact show the yellow "Echo Reply" on the Echo Request. My main usage PC does not, it shows the "green" response. I'm not sure what the deal is, it's a bit beyond my knowledge base. Is this something that should be fixed?

Everything seems to work just fine, but if it's a security concern I definitely want to rectify it if possible.

I'll be updating to 40_0 later today, maybe it will "fix" itself then.

Well I reverted back to 374_40 today and this time "Echo Reply" was green (using same PC as before).

EDIT - yet when I run the test from my iPad the "Echo Reply" is yellow. Not sure why different clients give different results? I thought the Port Scan was testing the router IPv6 firewall and results should be independent of which client is used

Like you this is beyond my knowledge base.

 

[Vandergraff]

As posted above this is beyond my knowledge base.

From the Wiki on "Tim’s Online IPv6 TCP/UDP Port Scanner (IPv6 Firewall Tester)" - which is the test we have been using.

http://ipv6.chappell-family.com/timswiki/index.php5?title=IPv6_Firewalls

-----------------
One other change IPv6 introduces compared to IPv4 is that additional ICMP traffic flows are necessary for normal protocol signalling whereas it was predominantly used for error-case reporting in IPv4 networks. This requires IPv6 firewalls to admit certain ICMPv6_Types_Codes in order to handle IPv6 address allocation, neighbour discovery (IPv6 replacement for ARP) and several other IPv6 processes. For many client devices this will be handled directly by the firewall itself, but if you are developing your own IPv6 firewall then you need to ensure you follow the recommendations in RFC4890 which includes an ip6tables packet filter example.
---------------

 

[RMerlin]

Well I reverted back to 374_40 today and this time "Echo Reply" was green (using same PC as before).

EDIT - yet when I run the test from my iPad the "Echo Reply" is yellow. Not sure why different clients give different results? I thought the Port Scan was testing the router IPv6 firewall and results should be independent of which client is used

Like you this is beyond my knowledge base.

IPv6 is not NATted. Every device on your LAN gets its own IPv6 IP. Therefore, the IP that gets tested will be of your client's, not your router's. That means the firewall in effect will be that of your client, unless you have a firewall rule in place on the router blocking the packet before it gets routed to the client.

 

[hazza]

My HE tunnel works fine as well. Make sure the endpoint does get properly updated with Hurricane.

I have a static IPv4 address assigned by my ISP, so not an issue.

The router is assigning my computer an IPv6 address, I can ping the router on both its routed and client IPv6 addresses, but get timeouts if I try to ping anything further out from that (Server IPv6, Google, etc etc). I get the same failed connectivity on other devices than my desktop too (Android phone, Android tablet, Chromebook).

Here's an odd thing I've just discovered, however - if I reinitialise the IPv6 tunnel (i.e. change a setting such as removing/adding a DNS server and hitting Apply) I get external IPv6 connectivity for about 20-25 seconds before everything returns to timeouts. This occurs whether or not the firewall (both IPv4, IPv6, and Windows Firewall) is on or off.

Like so:

C:\Users\User>ping -6 -t 2001:470:20::2

Pinging 2001:470:20::2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
Request timed out.
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=39ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=40ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=39ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=36ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=41ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=39ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2001:470:20::2:
    Packets: Sent = 60, Received = 23, Lost = 37 (61% loss),
Approximate round trip times in milli-seconds:
    Minimum = 36ms, Maximum = 41ms, Average = 37ms
Control-C
^C
C:\Users\Harry>

The first few 'Request timed out' were before the router restarted the tunnel, then obviously 'transmit failed' was while it was reconfiguring itself, then connectivity springs back into life followed by failing again.

Reverting to 374.35_4 results in everything working fine.

Any ideas anyone?

 

[hazza]

Forgot to add, here's what my tunnel configuration currently looks like...

 

[Grievous Angel]

I switched away from a Merlin build a few iterations back for reasons I don't exactly remember--maybe it was the security news.

On the latest ASUS revision I was getting random reboots . . half a dozen or so (AC66u). And my 5g speed wasn't reporting as high.

I've put on 374.40 and the 5g speed reports back to where it was, and I'm three days in without a reboot (and in prior Merlin versions I never had any random reboots).

I feel like the prodigal son.

 

[oneuser]

flashed to .40, it seems the wireless speed is more stable than an older version .34.

 

[RMerlin]

I have a static IPv4 address assigned by my ISP, so not an issue.

The router is assigning my computer an IPv6 address, I can ping the router on both its routed and client IPv6 addresses, but get timeouts if I try to ping anything further out from that (Server IPv6, Google, etc etc). I get the same failed connectivity on other devices than my desktop too (Android phone, Android tablet, Chromebook).

Here's an odd thing I've just discovered, however - if I reinitialise the IPv6 tunnel (i.e. change a setting such as removing/adding a DNS server and hitting Apply) I get external IPv6 connectivity for about 20-25 seconds before everything returns to timeouts. This occurs whether or not the firewall (both IPv4, IPv6, and Windows Firewall) is on or off.

Like so:

C:\Users\User>ping -6 -t 2001:470:20::2

Pinging 2001:470:20::2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
Request timed out.
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=39ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=40ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=39ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=36ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=41ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=39ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Reply from 2001:470:20::2: time=37ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2001:470:20::2:
    Packets: Sent = 60, Received = 23, Lost = 37 (61% loss),
Approximate round trip times in milli-seconds:
    Minimum = 36ms, Maximum = 41ms, Average = 37ms
Control-C
^C
C:\Users\Harry>

The first few 'Request timed out' were before the router restarted the tunnel, then obviously 'transmit failed' was while it was reconfiguring itself, then connectivity springs back into life followed by failing again.

Reverting to 374.35_4 results in everything working fine.

Any ideas anyone?

Try disabling HW acceleration.

 

[sephren]

I flashed the firmware on my ac68u yesterday. Seems stable to me.

But on 5ghz WiFi the dfs channels / options are missing. Do I have to reset it? As far as I see it should work?

 

[dopefish]

After 3 days wireless just stopped working. I was not able to connect to my N66U using 374.40 is out anymore. I did experience the same problem with 374.39 before. I will switch back to RT-N66U_3.0.0.4_374.35_4-sdk5 again, this one was running stable for weeks.
Unfortunately i was not able to get the system log before the reboot...