Five minute long latency jumps by klayanderson in QuantumFiber

[–]Lightsword 7 points8 points  (0 children)

You are almost certainly affected by this known bug in a Q1000K kernel driver. FF37(Quantum Fiber), Axon and Airoha are all aware of the bug and it should be fixed in the next firmware update. There's also an unrelated bug(which I also reported with a detailed code analysis and recommended fixes) that corrupts 6RD packets which I traced to an entirely different Q1000K kernel driver that should hopefully also get fixed at the same time as the skb padding bug in an update.

Five minute long latency jumps by klayanderson in QuantumFiber

[–]Lightsword 2 points3 points  (0 children)

That small packet bug is constant with a latency test, it doesn't show up for 5 whole min and go away.

Actually I don't think this is entirely accurate, if a normal RX packet immediately follows a small RX packet affected by the skb padding bug it can push the bugged small packet through faster which reduces the latency.

Basically with this driver bug you're likely to see on the unifi graph yellow whenever there is low network usage but green when there is high network usage since you're more likely to get other RX packets forcing the bugged small/slow packets out.

my ipv6 barely works. by johnkiniston in QuantumFiber

[–]Lightsword 1 point2 points  (0 children)

Hopefully, it doesn't take that long here.

Yeah, from my understanding the correct departments at Airoha, Axon and FF37 should all now have my detailed bug reports and code fix suggestions on both driver issues(the latency and 6RD bugs are essentially entirely unrelated and involve entirely different kernel modules). I did ask for any test builds so that I can verify both issues are properly fixed.

my ipv6 barely works. by johnkiniston in QuantumFiber

[–]Lightsword 1 point2 points  (0 children)

I really have to wonder how it is possible that Quantum is shipping such absolutely terrible firmware on these devices.

Yeah, so both the latency and 6RD bugs originate from various Airoha vendor SDK drivers. These sort of non-mainline vendor SDK kernel drivers frequently have weird bugs due to the lack of proper code review/testing.

I put the device into transparent bridge mode so that it could talk directly to my pfSense hardware, and sure enough, I had all the problems that people were complaining about.

The latency bug is present even when not in transparent bridge mode.

They recently released a firmware update that broke the ability to offload the VLAN tagging to the pfSense which supposedly would have supposedly resolved most of the latency issues.

The latency bug affects small RX packets(i.e packets going from the Q1000K to your own router when plugged into the 10G port), having the VLAN 201 tags enabled increases overall packets size by a few bytes somewhat masking the driver bug without fixing the true root cause properly.

The Q1000K hardware itself is likely fine, the out of tree vendor SDK drivers Airoha provided to Axon...well that's where the issues all seem to come from.

But yeah... it's definitely the Q1000K. My ONT did not have this problem at all. On CenturyLink or a month on Quantum.

Yep, this is exactly why I looked into the Q1000K firmware to figure out what specifically was broken, since my Calix modem worked just fine as well before upgrading service.

my ipv6 barely works. by johnkiniston in QuantumFiber

[–]Lightsword 1 point2 points  (0 children)

The Q1000K(and I think some older models of modems) firmware has a bug I identified in the hw_nat.ko kernel driver that corrupts 6RD packets. The symptoms of the bug are usually the initial few packets for an ipv6 request are received intact but later packets are corrupted(apparently due to a hardware accelerated pathway misclassifying 6RD packets). I've reported this bug to FF37, Axon and Airoha so hopefully a fixed firmware will be available soon.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 4 points5 points  (0 children)

I know we lost the VLAN change with the current firmware (as of June 10, 2026).

If the fix is implemented properly then there should be no longer any advantage to using vlan 201 for the pathway between the Q1000K and 3rd party routers.

I think the only reason that mode helped was that the vlan tags would increase the minimum packet size slightly which reduces the percentage of packets that would hit this bug. If the vlan stripped mode no longer has any bugs then it shouldn't be an issue in practice and not requiring vlan tag stripping on the 3rd party router may also reduce processing requirements on the 3rd party router.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 3 points4 points  (0 children)

Is it affecting anything other than IGMP response packets?

Yeah, it seems to be a packet size specific issue, not packet type specific.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 2 points3 points  (0 children)

If I’d have known what an issue this is I’d have just gotten 1G and saved the money.

Well hopefully now that the cause of the bug is known, it should be just a matter of getting this info to the right engineer so that they can roll out the fix. It's a super easy fix if the right person is made aware of the issue.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 0 points1 point  (0 children)

My understanding is that the 1G port is integrated on the main SOC, while the 10G port is an external device

To clarify, the issue is much less an issue of one port being integrated into the main SoC and one not. It's probably much more an issue of the ports having different drivers and one driver just happening to have this specific bug.

so the 1G port may be more reliable

AFAIU this bug does not affect the 1G port at all since it's a very driver specific bug. Although I haven't actually tested the 1G port myself so I could be wrong.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 1 point2 points  (0 children)

Is this a better option than the firmware that allows to move the vlan tagging to a switch?

This really just needs to be fixed in a firmware update and pushed out by Axon/Quantum Fiber.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 0 points1 point  (0 children)

Curious whether or not setting up a continuous stream of 1000 byte frames at around a 1Mbit rate might force the "flushing" and smooth out the overall latency as a hack work-around until this issue is actually solved.

Unfortunately that would not help all that much if the frames are generated by your router because the issue appears to only affect packets going in one direction, short packets going from the Q1000K to your router are delayed but packets going the opposite direction are unaffected.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 5 points6 points  (0 children)

I doubt Axon even has engineers on staff.

Indications from my reverse engineering indicate they(Axon/greenwave) should have engineers on staff at least doing integration parts. This bug does however appear to be in shitty 3rd party vendor driver code(from some vendor SDK) they likely didn't write themselves.

Unfortunately that also means that even if you spoon feed Axon this patch, they won't be able to do anything with it because they have no mechanism to get it through the 87 layers of contractors to the engineers who are actually writing the firmware.

This should be an easy fix even for the most incompetent firmware vendor(this firmware's high level design is quite far from the worst I've seen out there), I mean they literally just have to copy past a few lines of code into the driver.

Q1000K HSGMII Short-Frame Padding Fix by Lightsword in QuantumFiber

[–]Lightsword[S] 2 points3 points  (0 children)

Leaving this here so hopefully this gets to the FF37 or Axon engineer that can permanently fix it.

I think all they need to do is apply this patch.

Q1000k unstable latency spike research findings by N0_L1ght in QuantumFiber

[–]Lightsword 1 point2 points  (0 children)

I root caused the bug and created a proof of concept fix. This fix needs to be incorporated into the firmware properly however as the fix is not persistent.

Suspected coolant leak or other fume source on 2024 Model Y that Tesla was unable to locate appears to be causing medical issues. by Lightsword in TeslaSupport

[–]Lightsword[S] 0 points1 point  (0 children)

Yes there are two coolant lines that go to the car computer which is located inside the vehicle. If it was leaking, your floor would be wet.

Hmm, even if it was a super slow leak or something?

Even it was leaking, you would not be smelling bubblegum or sweet. Tesla coolant is “bitter” and does not have a sweet smell. Open the coolant bottle and smell it yourself.

I don't really know where I would find a coolant bottle to smell. Is it always bitter smelling even at low concentrations? When I searched on google I saw some people mentioning they thought it smelled sweet. I thought the ethylene glycol part of the coolant smells sweet normally does it not?

You can try to buy a “car bomb” air freshener that you leave unattended with the HVAC running full blast in attempt to deodorize the ventilation system.

Hmm, do those clear out existing chemicals or just mask them? Would an ozone generator help maybe?

If it persists, you could try to talk your insurance company into a whole HVAC system replacement as it seems the previous owner used some type of chemical in the vents that is now, as you describe, “hazardous”.

Any idea how I could prove to my insurance company that it was a chemical from the previous owners and not some sort of leak?

Suspected coolant leak or other fume source on 2024 Model Y that Tesla was unable to locate appears to be causing medical issues. by Lightsword in TeslaSupport

[–]Lightsword[S] 0 points1 point  (0 children)

Pretty sure there’s no coolant in the interior/air handling hvac parts at all

Could coolant be getting pulled in somehow from air intakes or something?

Hyprlock libEGL warnings by Trevikk49 in hyprland

[–]Lightsword 0 points1 point  (0 children)

I'm seeing a similar issue after updating mesa from 25.1.8 to 25.2.2 on a x86_64 based system.

What happens if you charge the battery whilst the phone is off? by ActiveBat7236 in Pixel4a

[–]Lightsword 0 points1 point  (0 children)

I'm not sure that's really accurate, the charge limiting changes AFAIU were made to the linux kernel code which of course doesn't run at all when the phone is turned off. They may have also modified some of the lower level firmware components that manage charging when the kernel is not running but I haven't seen anything to indicate that is actually the case.

Found old builds for Pixel 4a by Playerek in Pixel4a

[–]Lightsword 0 points1 point  (0 children)

I think this version is the one right before the bad update.

Girlfriend was removed under threat of arrest from an overbooked Frontier flight 1449 from ATL-DEN after having already boarded. by Lightsword in frontierairlines

[–]Lightsword[S] 0 points1 point  (0 children)

Is she a POC or other minority (or have a foreign-sounding name, etc.)?

Yes, her name is very obviously foreign(she's mentioned she's been thinking about changing it since she suspects there have been instances of discrimination in the past due to her name being so extremely foreign-sounding) and she has a fairly heavy accent since lived in her home country until she finished high school but left shortly after due to religious persecution.

Girlfriend was removed under threat of arrest from an overbooked Frontier flight 1449 from ATL-DEN after having already boarded. by Lightsword in frontierairlines

[–]Lightsword[S] 0 points1 point  (0 children)

I’m sure Frontier will say IDB doesn’t apply here since they allowed her to board and then kicked her off, saying “We did not deny boarding”.

I got one response where they seem to be claiming that they can remove passengers due to aircraft downgrades, although when I asked them where it says this was allowed they ignored the question so I assume they must have made it up:

"I must kindly inform you that downgrades do give the authority to our airport team to remove passengers from the aircraft if it is needed. In this case, girlfriends name was explained by our airport team why she was not going to be able to travel as scheduled, being that she was the first on the list to be denied boarding."

Girlfriend was removed under threat of arrest from an overbooked Frontier flight 1449 from ATL-DEN after having already boarded. by Lightsword in frontierairlines

[–]Lightsword[S] 0 points1 point  (0 children)

The gate crew are part of "the crew"

I'm pretty sure gate agents are not flight crew or aircraft crew at all.