What's new

[Test builds] 380.58 alpha builds are now available

  • 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!

I keep seeing this A1 and C1. Mine has B1 ! Anything special I should look for or avoid with updates?

No need to worry about it.

I mentioned A1 and C1 because they are the two revisions I could test myself.
 
I have 68U with revision A2, I put the last alpha Merlin, and everything it´s okey, no issues. I think it's much better of any official firmware. Very nice work RMerlin.
 
Since upgrading to this alpha I do not get the google playstore of the country of the vpn client on some devices which is odd as ipleak checks out ok.
Has anyone else noticed anything similar?

edit: I have re-uploaded a configuration file / certificates etc and it seems good again, for now.
I'll keep an eye on it.
 
Last edited:
On my AC-88U with 380.58_alpha3, in the Daily view under "QoS - Traffic Monitor" there might be an issue: the transmission traffic ist about the same as the reception traffic which should not be as I download a lot more than I upload. Anyone else experiencing this?
 
On my AC-88U with 380.58_alpha3, in the Daily view under "QoS - Traffic Monitor" there might be an issue: the transmission traffic ist about the same as the reception traffic which should not be as I download a lot more than I upload. Anyone else experiencing this?

It looks correct on mine. There is a significant difference between up and down traffic.

One thing though, my WAN traffic seems dead when I have traffic on both the wired and wireless bands.

Is this a possible bug? o_O
 
A few low-level/advanced settings were added to the new Tweaks section under Tools -> Other Settings.
Just ran across these settings so I wanted to check if any add'l details were given. I may have missed this one, so I apologize up-front. Anyway, I see you can enable SMB2... It's been available (elsewhere) for a while, hasn't it ? I presume it's stable and no risk in enabling it ? I have minimal network-sharing needs so it's no big deal if there are problems - I'll just revert the change.

Anyone enabled it ?
 
Speaking of the tweaks and hacks section. The comcast neighbor IPv6 overflow is a nice addition. Thanks Merlin. :)
 
On my AC-88U with 380.58_alpha3, in the Daily view under "QoS - Traffic Monitor" there might be an issue: the transmission traffic ist about the same as the reception traffic which should not be as I download a lot more than I upload. Anyone else experiencing this?

Yes, the issue is specific to the RT-AC88U/3100/5300. It's probably caused by the fact I had to use the wrong Ethernet driver because the correct one was failing to build correctly. This causes the Ethernet driver to report incorrect data to the kernel.
 
Just ran across these settings so I wanted to check if any add'l details were given. I may have missed this one, so I apologize up-front. Anyway, I see you can enable SMB2... It's been available (elsewhere) for a while, hasn't it ? I presume it's stable and no risk in enabling it ? I have minimal network-sharing needs so it's no big deal if there are problems - I'll just revert the change.

Anyone enabled it ?

SMB 2.0 support was added when I switched to Samba 3.6 quite a while ago. However it causes such a performance hit that I decided to stick to SMB1, but left an undocumented nvram control there for future experiments. The newer 1.4 GHz CPU might be able to offset some of the performance issue, however I haven't retested it.
 
Speaking of the tweaks and hacks section. The comcast neighbor IPv6 overflow is a nice addition. Thanks Merlin. :)

The setting has been there for nearly two years, it was just not exposed on the webui.
 
Yes, the issue is specific to the RT-AC88U/3100/5300. It's probably caused by the fact I had to use the wrong Ethernet driver because the correct one was failing to build correctly. This causes the Ethernet driver to report incorrect data to the kernel.
Will this behaviour maybe get sorted out in a future commit (Asus default FW has not the problem?) ?
 
Will this behaviour maybe get sorted out in a future commit (Asus default FW has not the problem?) ?

Not sure if the fix will be in 380.58, I only have a (non-tested) theory as to the cause at this time.
 
Working well on my 3200 , so far getting better transfer rates on all clients , between 2 - 6 MBsps increase in rate .
 
Yes, the issue is specific to the RT-AC88U/3100/5300. It's probably caused by the fact I had to use the wrong Ethernet driver because the correct one was failing to build correctly. This causes the Ethernet driver to report incorrect data to the kernel.

Actually i don't think so :( The bug is quite old and was at least introduced in 378.56_2. Please see report: http://www.snbforums.com/threads/tr...even-with-acceleration-off.29499/#post-235272

Edit: But i may mix it up with QoS and non-QoS Trafic Monitor, sorry then :/
 
The setting has been there for nearly two years, it was just not exposed on the webui.

If i remember correctly i think you posted several firmwares back that the comcast v6 overflow fix was being removed and could be replaced by running a command via telnet or ssh. Either way nice to see the option as just a quick check mark in the UI..

nvram set ipv6_ns_drop=1
nvram commit
 
When DNSSEC was put in on 380.57, I was pretty sure that I used to get a big green tick at http://dnssectest.sidnlabs.nl/test.php

Now when I test, I get this:

ImageUploadedByTapatalk1457220718.939228.jpg


Did something change and this is expected now?

Or is it just coincidence, and it was always in permissive mode ?

Or, is it my setup, and it's maybe got something to do with the IPv6 DNS servers vs the IPv4 servers?

FYI, I'm using Google:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844


Sent from my iPhone using Tapatalk
 
Not 100% sure of what DNSSEC is or how it works but clicking the link you provided gave me this.
 

Attachments

  • test.png
    test.png
    104.1 KB · Views: 654
If i remember correctly i think you posted several firmwares back that the comcast v6 overflow fix was being removed and could be replaced by running a command via telnet or ssh. Either way nice to see the option as just a quick check mark in the UI..

nvram set ipv6_ns_drop=1
nvram commit

Actually what I did back then was to change the nvram setting to a different name, and make it default to "disabled" instead of defaulting to "enabled", as there were some concerns that this might be causing problems for some users.
 
When DNSSEC was put in on 380.57, I was pretty sure that I used to get a big green tick at http://dnssectest.sidnlabs.nl/test.php

Or, is it my setup, and it's maybe got something to do with the IPv6 DNS servers vs the IPv4 servers?

FYI, I'm using Google:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

It's working properly for me, using my ISP's DNS and the test site you pointed at.

I don't know if Google's IPv6 resolvers support DNSSEC. You might also want to double check the System Log - whenever dnsmasq is started there will be a line stating that DNSSEC validation is active.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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