[384.9_Alpha - builds] Testing all variants.
- Status
shark
Regular Contributor
@RMerlin
Ok, i think i found the issue! This spams on the log:
When i set the ipv6 to Passthrough.
With Native mode with IPV6, the log is clear:
But after i change it to Passthrough:
Tested with both ISP, with the old one doing the PPPoE authentication strait on my RT-AC86U and with the new one, getting an network IP address from the Nokia ONT, and the wan on my RT-AC86U getting an Automatic IP.
Ok, i think i found the issue! This spams on the log:
When i set the ipv6 to Passthrough.
With Native mode with IPV6, the log is clear:
But after i change it to Passthrough:
Tested with both ISP, with the old one doing the PPPoE authentication strait on my RT-AC86U and with the new one, getting an network IP address from the Nokia ONT, and the wan on my RT-AC86U getting an Automatic IP.
D_Day
Senior Member
Never mind, I’ve checked again and it’s working fine
shark
Regular Contributor
@RMerlin
Yeah these /\ only happen when i set ipv6 to Passthrough, i even flashed 384.8_2 and reset to factory defaults(initialize), after that i just setup the wan with the automatic ip setting and my wifi! These errors only started showing up on the log after i set ipv6 to Passthrough, they stop the moment i disable ipv6 or set it to native! I tried also to remove every device from my lan and only left my desktop and there was no change in behavior. With native ipv6 everything works and there are no errors on the log with the same lan clients.
I was also getting these \/ on the latest alpha, that are not happening on the stable 384.8_2:
Yeah these /\ only happen when i set ipv6 to Passthrough, i even flashed 384.8_2 and reset to factory defaults(initialize), after that i just setup the wan with the automatic ip setting and my wifi! These errors only started showing up on the log after i set ipv6 to Passthrough, they stop the moment i disable ipv6 or set it to native! I tried also to remove every device from my lan and only left my desktop and there was no change in behavior. With native ipv6 everything works and there are no errors on the log with the same lan clients.
I was also getting these \/ on the latest alpha, that are not happening on the stable 384.8_2:
EmeraldDeer
Very Senior Member
I am not getting the buggy errors in my syslog with:
Comcast
Arris SB8200
Asus RT-AX88U running 384.8_2
IPv6 set to Passthrough
WAN MTU 1500
Comcast
Arris SB8200
Asus RT-AX88U running 384.8_2
IPv6 set to Passthrough
WAN MTU 1500
Congratulations ........ how does this have any bearing on this thread which is purely for the testing of the alpha 384-9 firmware?
EmeraldDeer
Very Senior Member
By the way, the only actual solutions to protocol is buggy were on a Ubiquiti forum.
One person had jumbo frames enabled on other equipment and problem resolved when setting the same on all equipment.
Another person had a bonded link and the problem was solved by disabling offload.
I have a LAG between LAN 1/LAN2 on the RT-AX88U and two ports on a Cisco SG300-10 switch. I did not need to change offload.
One person had jumbo frames enabled on other equipment and problem resolved when setting the same on all equipment.
Another person had a bonded link and the problem was solved by disabling offload.
I have a LAG between LAN 1/LAN2 on the RT-AX88U and two ports on a Cisco SG300-10 switch. I did not need to change offload.
EmeraldDeer
Very Senior Member
User shark received kernel protocol is buggy errors on both 384.8_2 and 384.9.
I do not receive the errors with the same IPv6 Passthrough setting on 384.8_2.
Therefore, it is unlikely that the kernel protocol is buggy errors shark gets are a 384.9 issue.
What the "buggy protocol" error typically means is the kernel tried to process a packet that didn't match an expected protocol (by protocol I mean IPv4, IPv6, NETBUI, etc...). An incorrect MTU might possibly trigger that due to fragmented packets getting pushed through the interface, leaving some packets with an invalid packet header.
The Anomaly Op error message is totally different. It`s tied to the Trend Micro engine (more specifically the UDB kernel module), and is probably a side-effect of the mismatched components that are required for me to support those 382-based models in my firmware. There is no visible solution to these, short of me dropping support for all 382-based models.
The RT-AC3200 build you guys are currently running are even more Frankenbuild than usual, due to the lack of new GPL drop for Asus. It's a mixture of 382 binaries, 384 GPL code, and 384 binaries that were never tested by Asus since they do not publish 384-based releases for the RT-AC3200. That's what the Alpha stage is for - testing these kind of experiments. The result will determine whether or not they are viable options. If they turn out not to be viable, then the RT-AC3200 will once again get dropped once I reach the Beta stage.
Bottom line is, RT-AC3200 (and RT-AC87U) owners are currently on an extended lease in terms of support by my firmware. Officially, I should have abandoned support for it the instant Asus migrated everything else to the 384 codebase. At the time it only required a couple of kludges to the code to make the two work together, so I kept going on with them. But, I always suspected that as the differences will grow between 382 and 384, it might eventually reach a point where it will no longer be possible for me to support the 382-based models at all.
This is once again a case where, as the lone developer, I simply lack the time and resource to support multiple firmware branches. I'm already having a lot of headaches dealing with the 45149 vs 52xx branches to be able to support the RT-AX88U, with the hope that eventually Asus will merge them back together. I simply don't have the time to also handle a completely separate 382 branch. This is something that someone else from the community would have to pick up for me. Since nobody came forward to do it for the RT-N66U and RT-AC66U, I doubt at this point that anyone will do so for the AC3200 and AC87U, which are far less popular models than these two older ones.
The Anomaly Op error message is totally different. It`s tied to the Trend Micro engine (more specifically the UDB kernel module), and is probably a side-effect of the mismatched components that are required for me to support those 382-based models in my firmware. There is no visible solution to these, short of me dropping support for all 382-based models.
The RT-AC3200 build you guys are currently running are even more Frankenbuild than usual, due to the lack of new GPL drop for Asus. It's a mixture of 382 binaries, 384 GPL code, and 384 binaries that were never tested by Asus since they do not publish 384-based releases for the RT-AC3200. That's what the Alpha stage is for - testing these kind of experiments. The result will determine whether or not they are viable options. If they turn out not to be viable, then the RT-AC3200 will once again get dropped once I reach the Beta stage.
Bottom line is, RT-AC3200 (and RT-AC87U) owners are currently on an extended lease in terms of support by my firmware. Officially, I should have abandoned support for it the instant Asus migrated everything else to the 384 codebase. At the time it only required a couple of kludges to the code to make the two work together, so I kept going on with them. But, I always suspected that as the differences will grow between 382 and 384, it might eventually reach a point where it will no longer be possible for me to support the 382-based models at all.
This is once again a case where, as the lone developer, I simply lack the time and resource to support multiple firmware branches. I'm already having a lot of headaches dealing with the 45149 vs 52xx branches to be able to support the RT-AX88U, with the hope that eventually Asus will merge them back together. I simply don't have the time to also handle a completely separate 382 branch. This is something that someone else from the community would have to pick up for me. Since nobody came forward to do it for the RT-N66U and RT-AC66U, I doubt at this point that anyone will do so for the AC3200 and AC87U, which are far less popular models than these two older ones.
daviworld
Regular Contributor
So with the latest alpha for the rt-ac5300 ending in 98d, like with the pervious one ending in 186, the video content won't stream over minidnla 1.2.1. I had to revert to the original 384.9 alpha ending in 516 to fix it, everything else is working as expected so far other than the above issue. This problem persists through a initialization reset, script's and no script's, looking through the log wasn't helpful either. Any other rt-ac5300 owner's experiencing issue's streaming video content on the last 2 alpha's, excluding the first?
Best,
Davi
Sent from my LG-H830 using Tapatalk
Best,
Davi
Sent from my LG-H830 using Tapatalk
shark
Regular Contributor
I don't know what more i can do to be honest, because the only place that i can change the mtu is here on my RT-AC86U:
There is no place to change the mtu on the Nokia ONT, at least not interface wise... I also tried to look on its manual to see if it had any info on changing mtu and there is nothing!
As you can see, I've already changed it from the default 1500 to 1480... I found 1480 by doing the tests to my Nokia ONT(192.168.1.254) and to google with the ping command on cmd and with the following parameters -> ping IP\HOSTNAME -f -l MTU SIZE
As you can see below:
I know that the screen shots are not in english and sorry for it, but since they are default screens, i though that it does not really matter. If anyone needs any translation, just let me know...
Anyway, i've changed the default mtu on the wan of my RT-AC86U from 1500 to 1480, and there is no change at all, my log still getting the errors:
shark
Regular Contributor
@RMerlin
One thing that I've noticed, is that when going to System Log -> Ipv6, when Passthrough is being used, the log screen does not seems right to be honest:
Yet the ipv6 works on the devices.
And here you have the configuration screens from the Nokia ONT:
If you or anyone has any procedures that i should do now or any tips, both are really appreciated! Thank you!
One thing that I've noticed, is that when going to System Log -> Ipv6, when Passthrough is being used, the log screen does not seems right to be honest:
Yet the ipv6 works on the devices.
And here you have the configuration screens from the Nokia ONT:
If you or anyone has any procedures that i should do now or any tips, both are really appreciated! Thank you!
D
Deleted member 22229
Guest
What are you using for a firewall if your using passthrough on the router ? In passthrough mode your Asus router is bypassing the IPv6 firewall. Not a good idea if you don't have another device securing your network.
shark
Regular Contributor
The nokia ONT has one built-in:
Don't know if it is any good or not, i wish i could setup the ONT on bridge mode and do the pppoe autentication on my RT-AC86U, that way i could use it native, but it requires a VLAN as you can see on my previously post and on the screen shot of the wan and as of yet, i don't know if i could do it with the RT-AC86U or not, at least i did not think of any way of doing it yet... I saw one guy on youtube doing it on a mikrotik routerboard.
now my RT-AC86U is doing the pppoe and ipv6 is in native mode, no more log errors Striker317
Regular Contributor
How many people use the ac3200/ac87. If it is a small percentage vs the other 384 based routers, pull the cord and cut support for them.
No need to be everything to everyone and end up resorting to compromises that impact the folks on 384 based firmware
No need to be everything to everyone and end up resorting to compromises that impact the folks on 384 based firmware
matthew johnson
Regular Contributor
I got a bunch of ubi codes on my ax88u. I pasted the section below could some one look and tell me what it means?
Jan 9 00:35:54 kernel: ubi1: attaching mtd9
Jan 9 00:35:54 kernel: ubi1: scanning is finished
Jan 9 00:35:54 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Jan 9 00:35:54 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jan 9 00:35:54 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jan 9 00:35:54 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Jan 9 00:35:54 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Jan 9 00:35:54 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Jan 9 00:35:54 kernel: ubi1: max/mean erase counter: 24/16, WL threshold: 4096, image sequence number: 1862459137
Jan 9 00:35:54 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Jan 9 00:35:54 kernel: ubi1: background thread "ubi_bgt1d" started, PID 1771
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 1787
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID B5453CA3-D074-46CD-A5AB-7C084A567601, small LPT model
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Jan 9 00:35:55 kernel: ubi1: detaching mtd9
Jan 9 00:35:55 kernel: ubi1: mtd9 is detached
Jan 9 00:35:56 kernel: ubi1: attaching mtd9
Jan 9 00:35:56 kernel: ubi1: scanning is finished
Jan 9 00:35:56 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Jan 9 00:35:56 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jan 9 00:35:56 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jan 9 00:35:56 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Jan 9 00:35:56 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Jan 9 00:35:56 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Jan 9 00:35:56 kernel: ubi1: max/mean erase counter: 24/16, WL threshold: 4096, image sequence number: 1862459137
Jan 9 00:35:56 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Jan 9 00:35:56 kernel: ubi1: background thread "ubi_bgt1d" started, PID 1846
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 1867
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID B5453CA3-D074-46CD-A5AB-7C084A567601, small LPT model
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Jan 9 00:35:57 kernel: ubi1: detaching mtd9
Jan 9 00:35:57 kernel: ubi1: mtd9 is detached
Jan 9 00:35:54 kernel: ubi1: attaching mtd9
Jan 9 00:35:54 kernel: ubi1: scanning is finished
Jan 9 00:35:54 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Jan 9 00:35:54 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jan 9 00:35:54 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jan 9 00:35:54 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Jan 9 00:35:54 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Jan 9 00:35:54 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Jan 9 00:35:54 kernel: ubi1: max/mean erase counter: 24/16, WL threshold: 4096, image sequence number: 1862459137
Jan 9 00:35:54 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Jan 9 00:35:54 kernel: ubi1: background thread "ubi_bgt1d" started, PID 1771
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 1787
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID B5453CA3-D074-46CD-A5AB-7C084A567601, small LPT model
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Jan 9 00:35:55 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Jan 9 00:35:55 kernel: ubi1: detaching mtd9
Jan 9 00:35:55 kernel: ubi1: mtd9 is detached
Jan 9 00:35:56 kernel: ubi1: attaching mtd9
Jan 9 00:35:56 kernel: ubi1: scanning is finished
Jan 9 00:35:56 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Jan 9 00:35:56 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jan 9 00:35:56 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jan 9 00:35:56 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Jan 9 00:35:56 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Jan 9 00:35:56 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Jan 9 00:35:56 kernel: ubi1: max/mean erase counter: 24/16, WL threshold: 4096, image sequence number: 1862459137
Jan 9 00:35:56 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Jan 9 00:35:56 kernel: ubi1: background thread "ubi_bgt1d" started, PID 1846
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 1867
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID B5453CA3-D074-46CD-A5AB-7C084A567601, small LPT model
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Jan 9 00:35:57 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Jan 9 00:35:57 kernel: ubi1: detaching mtd9
Jan 9 00:35:57 kernel: ubi1: mtd9 is detached
jernau
Regular Contributor
Been runinng this alpha on my RT-AC3200 since release and installed 384.9_alpha1-g951fac98d just over a day ago and no issues thus far, very stable. Yes I'm seeing " kernel: Anomaly Undefined op out" errors occasionaly in the logs but it is not impacting function or performance. Thanks again for your continued efforts @RMerlin !!
same here ...
Those are simply the filesystem partitions getting mounted, nothing unusual there.
- Status
Similar threads
Similar threads
Similar 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!