What's new

Beta [Beta] FragAttack patched test builds (386.2_5)

  • 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.
Any idea when you plan to make this part of 386.3_a1 with all the changes ?
It appears to me (based upon change log comparison) that the latest 386.3 Alpha 1 includes everything in this release (including the FragAttack patch) plus more. @RMerlin is simply trying to baseline the security critical updates as soon as possible.
 
It appears to me (based upon change log comparison) that the latest 386.3 Alpha 1 includes everything in this release (including the FragAttack patch) plus more. @RMerlin is simply trying to baseline the security critical updates as soon as possible.

I think you are correct.
 
Did the update on a lone AP - my RT-AC86U - to give it a check. Was a filthy upgrade from the 386.3_alpha1-gb5bff52d3d.

Devices re-connected but I did notice this in the logs that was not there before:

Jun 5 10:00:30 roamast: ROAMING Start...

Roaming Assist is disabled on both bands.
 
Any idea when you plan to make this part of 386.3_a1 with all the changes ?
"386.3_a1" itself is not a release. They are just development snapshots that I may occasionally build when I decide to do so.

Obviously, all the 386.2_x fixes will eventually make it into a final 386.3 release.
 
Both Main/AP working smoothly with latest fw.
I thought the AC86 was frag fixed, as per the change log in previous alpha, yet the latest change log states:
- UPDATED: chart.js to 2.9.4.
- UPDATED: tor to 0.4.5.8.
- FIXED: Fragattack security issues


No network issues after fw upgrade, Thank You RMerlin!
 
Both Main/AP working smoothly with latest fw.
I thought the AC86 was frag fixed, as per the change log in previous alpha, yet the latest change log states:
- UPDATED: chart.js to 2.9.4.
- UPDATED: tor to 0.4.5.8.
- FIXED: Fragattack security issues


No network issues after fw upgrade, Thank You RMerlin!
Again, 386.3 alpha is unrelated to 386.2_xxx. Alphas are development snapshots, they are not releases.
 
Installed today, and all seems well.
Here are the only log items of note:

Jun 5 12:49:40 inadyn[1789]: /etc/inadyn.conf:3: unexpected token '='
Jun 5 12:49:40 inadyn[1789]: Parse error in /etc/inadyn.conf
Jun 5 12:49:40 syslog: Error code 74: Missing .conf file
Jun 5 12:49:43 inadyn[1811]: /etc/inadyn.conf:3: unexpected token '='
Jun 5 12:49:43 inadyn[1811]: Parse error in /etc/inadyn.conf
Jun 5 12:49:43 syslog: Error code 74: Missing .conf file

Jun 5 12:49:47 kernel: gro disabled
Jun 5 12:49:59 lld2d[766]: packetio_recv_handler: mis-matched sequence number: got 1, expecting 6; ignoring
Jun 5 12:50:02 kernel: SHN Release Version: 2.0.1 f45bb18
Jun 5 12:50:02 kernel: UDB Core Version: 0.2.20
Jun 5 12:50:02 kernel: sizeof forward pkt param = 192
Jun 5 12:50:05 kernel: ERR[qos_start:3363] qos_ops is not registered!
Jun 5 12:50:05 kernel: ioctl_iqos_op_switch(1) fail!


Otherwise, it seems to run very well...
 
Again, 386.3 alpha is unrelated to 386.2_xxx. Alphas are development snapshots, they are not releases.
This is more like a hotfix off release or master depending on your branching bend... mmmm love that gitflow. Heh heh.

bW7z5eb.png
 
Eric, I posted a Wi-Fi related issue on the previous page, as you requested to specifically check the Wi-Fi functionality and maybe I’m mistaking, yet it feels like I’m the only one not getting a reply. Did you simply miss it or is my question so incredibly dumb, you’ve decided not to respond to it? Please let me know so I can decide whether i have anything useful to contribute to alpha or beta stages. Otherwise I might as well quit alpha-and betatesting and wait for the final releases.
 
@Hazel, this is RMerlin's thread, of course, he won't miss what you contributed. Patience is a prerequisite on international forums. :)
 
I should be able to do a dirty downgrade from the alpha to this release, right??
 
Eric, I posted a Wi-Fi related issue on the previous page, as you requested to specifically check the Wi-Fi functionality and maybe I’m mistaking, yet it feels like I’m the only one not getting a reply. Did you simply miss it or is my question so incredibly dumb, you’ve decided not to respond to it? Please let me know so I can decide whether i have anything useful to contribute to alpha or beta stages. Otherwise I might as well quit alpha-and betatesting and wait for the final releases.
I didn't reply simply because I don't have anything to say about it. Anything related to wifi is closed source and outside of my control, as I've been saying for years now. This beta is strictly to confirm that the new drivers aren't majorly broken, and that radios do come up, and clients are able to connect. If something is really broken with the automatic channel selector daemon, it's outside of my control.
 
Asus AC68U. Dirty upgrade from 386.2.

No issues with various brand devices connected 2.4 or 5ghz band.
WAN speeds are consistent on all devices. I have gained up to 15Mbps while doing WAN Speedtests. I use Ookla speed test app on all my devices.
With 386.2 and previous firmwares, I would get up to 220 Mbps down. I pay for 200Mbps

With firmware 386.2_5, I’m getting up 235Mbps. I’ve tested it on 4 local servers and I’m getting similar results. I’ve retested the speed test 4 hours apart. I’m still getting similar speed test results.

I live in an apartment building, that is heavily saturated with WiFi and we use same Comcast ISP. Yet I’m seeing better speeds.

I will do more testing over the next week and if I see different results, I will post my findings.

YouTube and YouTube videos load faster. I’m no longer getting random crashes in the middle of the YouTube videos. More testing needed.

Many Webpages load a bit faster as well. I manually power cycle my router and isp modem once a week. But with firmware 386.2_5 I am seeing many positive results. I will do more testing, but for the past 6 hours I have no complaints.

Skynet and Diversion, are working properly to my knowledge with firmware 386.2_5.

Thank you again for your hard work.

Cheers.
 
Last edited:
Here is an example. I did a speed test using Safari web browser on my 5th gen iPad and I got 235Mpbs. I’m seating on a balcony and two brick walls away from my WiFi router.
 

Attachments

  • 251D0C14-89AC-4841-8904-C5A4F6FB1B06.png
    251D0C14-89AC-4841-8904-C5A4F6FB1B06.png
    91.8 KB · Views: 126
My 2.4Ghz radio is always set to control channel 6, but Wireless log shows it has shifted to control channel 5. I verified with WinFi Lite and both routers (Main + AiMesh Node + GN on Main) are active on control channel 5. Also the extension channel is set to 'Above' but looking at graph at the bottom of this post it's using 20Mhz bandwidth with channel 5 as centered control channel. Router has been rebooted twice after upgrade. 5Ghz band has not shifted.
Should just set it to 20 as you will never get 40 to stick unless there are no other routers broadcasting in your area.
 
Should just set it to 20 as you will never get 40 to stick unless there are no other routers broadcasting in your area.
I’m fully aware of that, but thanks for the remark (that was meant sincere). The area I live in still isn’t saturated with routers (yes, they do still exist) and most of the time outside office hours, it utilizes 40Mhz instead of 20Mhz. I have a large school close in my vicinity, which disables WiFi outside office hours and because of COVID-19 is still not fully open, giving the router the option to utilize 40Mhz when available.

Which does not justify a control channel set to 6 ending up at 5 not set to 1 ending up at 9 when I had it set to 20/40. I have it set to 20 MHz now because apparently with the new drivers that’s the only way I can keep the 2.4 GHz radio at the selected control channel. This has never occurred prior to uploading the latest build.

Yet apparently no one is willing to verify and the developer has decided ‘simply not to respond’ (although he specifically requested to check WiFi which I did) and a flock of sheep liking his post responding to me as usual seems to justify his decision to ‘simply not reply’ to the only post in this thread which provided feedback on behavior that seems related to the radio drivers. Yes they come up, yes my devices connect, however there’s something going on with the channel selector.

Don’t get me wrong: I’m truly grateful for Asuswrt-Merlin but I’m somewhat stunned to see that off-topic replies are being responded to, yet on-topic reports are just getting ignored. Why ask about checking WiFi only to reply now that ‘it’s out of his control’. Being ignored by the great and mighty Merlin doesn’t motivate alpha or beta testing, so I’ll just stick to stable. Saves me a lot of time and frustration.
 
Last edited:
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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