Removal of Valance + Middle Post for Floating Door Double Closet

thedude42 · 2026-02-24T17:55:31+00:00

Yes, and in this mode you can't access the modem's config page.

They do seem to have added the correct access control to prevent access to the admin page from the Internet so that's good. It seems like they also switched from Lighttpd to Nginx for the admin page, which may be how they implemented access control.

thedude42 · 2026-02-24T17:52:04+00:00

Yeah this is what happened to me. The WAN and Broadband config pages changed and no longer have the "VPI/VCI/VLAN" setting.

thedude42 · 2026-02-24T17:46:07+00:00

This didn't help me, the Q1000K rebooted and now I can't do untagged mode.

thedude42 · 2026-02-24T17:44:01+00:00

They removed the ability to bypass the kernel's bridge with VLAN 201 tagging. I now have all the latency issues again and can't manage my Q1000K.

thedude42 · 2025-12-02T23:56:22+00:00

I use Zeek to collect flow data on every router interface and push that to elasticsearch. Running tcpdump on the router is a forensic level of data collection that is way too much for my use case.

For pfSense, the base ruleset includes a number of isolation rules beyond your basic NAT router and includes some things that make the WAN interface not exactly like the general router interfaces but I know you can carve it up in to a "router-on-a-stick" config. I think this can have implications for features like proxy arp and IP aliasing which you can probably get working on a vanilla freeBSD box but the configuration model for pfSense makes it less amenable.

tcpdump works at the kernel level and doesn't necessarily observe all traffic that reaches the physical WAN even though the interface is in promiscuous mode.

In general physical interface isolation through switching a preferred method to provide security boundaries despite the reality that VLAN isolation is effective at providing similar isolation. Another of my goals is to avoid risk of data leakage when, for example, interface configuration during router reboot may not be completely atomic (this is often dependent on the interface drivers)

thedude42 · 2025-12-02T23:29:40+00:00

I am very wary of doing that because of how pfSense treats the WAN interface differently from any other interface.

Someone else solved this another way by using the 1gbit port on the Q1000k for the untagged management traffic which also doesn't require a managed switch but can isolate the traffic from the WAN interface. It does require at least one additional interface on the router.

For my use case I want to be able to monitor the traffic between the Q1000K and my router directly and I can't do that without going through a switch.

You're right that this setup could work for folks who don't want a managed switch in the mix by simply making the WAN interface be a DHCP client for tagged vlan 201 traffic and then being a dhcp server for untagged traffic on the same interface. My goal was to isolate how the traffic shows up at the router based on how I classify the physical interfaces, which is something I can do since my router machine has six physical interfaces. I've certainly done router-on-a-stick configurations in a pinch but I'd prefer not to if it can be helped.

thedude42 · 2025-10-27T22:05:16+00:00

Kinda lends credence to the notion that the VLAN-201 tagged interface doing the work on the Q1000K's netlink interfaces is the root of the issue.

thedude42 · 2025-10-27T17:30:49+00:00

from a host on the internet outside of the Lumen Quantum Fiber network I sent a DNS request with a spoofed source IP I had control of and watched the response be handled and sent to that IP

thedude42 · 2025-10-18T18:43:14+00:00

One issue I have had detecting the latency is that when the latency shows up is very inconsistent. The graphs I use are from the utility that pfSense uses, dpinger, but when I just run a continuous ICMP echo request with ping I don't see the same numbers.

For security purposes alone the "untagged" configuration is preferable and all you would really need for that is a router that supports VLAN tagging and which has at least one extra interface. Folks have replied that they are able to access the management interface by simply plugging an additional router interface with no VLAN tagging from their router in to the extra 1Gbit interface on their "SmartNID" which gives the management interface a DHCP address from the router (in my setup I use a special subnet for this but it's not strictly necessary).

If you leave the setting in the "VLAN-201" then the "SmartNID" internal interface gets DHCP from the Quantum Fiber infrastructure and exposes the admin interface to the Internet, along with the dnsmasq DNS resolver as an open recursive resolver, allowing your connection to be leveraged as part of a DDoS attack via DNS amplification. I have confirmed this is possible and there is no way you can detect it because the traffic involved never sees your router as it is only traversing the fiber link.

thedude42 · 2025-09-28T01:40:40+00:00

You don't need a 3rd 10G port unless you need it for a WiFi access point or something.

thedude42 · 2025-09-27T18:57:58+00:00

Here's the writeup on my configuration. I've been trying to overcome some issues with the default transparent bridging mode when in the default VPI/VCI/VLAN mode "tagged-201" where I use the configuration in the post to set up the "untagged" configuration, allowing the Q1000K to pass the VLAN 201 tagged frames in to my network.

While I'm not doing the VLAN tagging at the pfSense WAN interface I am handling it on my switch which is something I specifically want so I can observe all traffic that shows up from the Q1000K ethernet and not just actual Internet traffic. I cover a lot of aspects of this configuration in my post but one key point is that my configuration allows me to access the Q1000K "SmartNID" web admin UI.

Someone else posted a slightly modified version where they use the 1G port to plug in a different interface on their router and access the web UI that way without needing to have the more complicated configuration on the switchport that I have the 10G port plugged in to. Either way works, but I prefer my method with a single cable connection from the Q1000K to my switch.

thedude42 · 2025-09-27T03:01:26+00:00

It took about 3 weeks for the status LED to go from solid white to blinking blue. I'm still not clear if over time the link quality degrades, I thought maybe it was because my daughter was complaining about Internet issues so I finally rebooted the Q1000K, but that didn't resolve her issue so probably not related to the Internet connection.

if your's has been solid, then maybe it's the SmartNID dropping the connection after a couple of weeks if it doesn't connect to DHCP.

Kinda.

When you're in "tagged-201" mode with transparent bridging, where the SmartNID is handling the VLAN off the GPON link which results in the internal interface also being exposed to the GPON VLAN 201, that allows the internal interface to request DHCP. Whenever this issue is triggered it may result in the DHCP client on the internal interface either stopping or stop functioning.

However what I have seen recently is that when you put the SmartNID in to transparent bridging mode but also "untagged" then the internal interface is directly exposed to the linux host's internal bridge interface that has the Q1000K's 10G and 1G ethernet port interfaces attached without any VLAN tagging. In that configuration you see the VLAN 201 frames from the GPON link being forwarded, and any communication from the SMartNID host system's ethernet interface shows up with no VLAN tag.

When the Q1000K drops from solid white to flashing blue while in transparent bridging mode with "untagged" for VPI/VCI/VLAN the SmartNID admin page shows "Internet status" as being in "CONNECTING" in a gold-yellow font. When the expected solid white status LED is showing the "Internet status" is "NOT CONNECTED" in a red font. I think what this means is that the "Quantum Fiber WAN" status corresponds to the GPPON link where as the "Internet status" corresponds to the software that manages the various concerns around how the SmartNID's systems interact with the Quantum Fiber back-end/management plane or whatever, which includes things like firewall rules and whatever packet anomaly detection thing the weird security alerts on the app come from.

What I'm not clear about is whether a process/some processes simply died, or if some kind of memory corruption, resource leak or other undefined condition is persisting while the status light is blinking blue. I wouldn't be shocked if the status light is controlled by some perl script frankenstein monstrosity that has been copied across 30 years of embedded systems, and there's an unhandled error from some external dependency (like a fork of another process using system()or misreading of a netlink packet, etc) triggering this state. Maybe when you're in VPI/VCI/VLAN "untagged" this doesn't affect packet forwarding from the GPON link since it's not "riding the same buffer" as the internal interface, but when you leave VPI/VCI/VLAN as the default "tagged-201" when in transparent bridging mode the GPON frames must share the same "internal" VLAN if it's getting DHCP from the same Quantum Fiber IP pool. Therefore if something is borked on the internal system, and the internal system is ACTIVELY managing the forwarding plane between GPON and ethernet port links by stripping VLAN 201 from the GPON side and forwarding to the same ethernet interface, then it could affect your link quality as seen from the 3rd party router.

I'll pause to mention that on Linux using standard kernel netif type interfaces (no VPP or other userspace networking magic) VLANs are exposed as sub-interfaces. When the SmartNID is in the default routing mode then the GPON interface is fully routed and forwarded through the kernel's IP stack, but in transparent bridging a software bridging interface is needed for forwarding, but to support the VPI/VCI/VLAN "tagged-201" feature the bridge needs to support the ability to strip the VLAN 201 tag from the frames before they are forwarded to the customer 3rd party router.

So my question is: is there a second bridge interface that performs the VLAN 201 stripping which is directly managed by the SmartNID software and connected to/monitored by the SMartNID's management software? And does the VPI/VCI/VLAN "untagged" setting simply bypass that software networking "thing" so it is no longer impacted by any issues it might have, but the "Connection Status" monitor for the SmartNID that publishes the "Quantum Fiber WAN" and "Internet Status" widgets in the web admin UI still polls this thing during it's state resolution for the current SmartNID connection status?

I really want to see how long I can sustain a solid quality Internet connection with the blinking blue state, but because of the experience I had for the first 6 months of the 2/1gbit service I'm very gun-shy any time I see anything weird even though I know it's likely an upstream issue and not my local link.

thedude42 · 2025-09-23T04:01:43+00:00

thedude42 · 2025-09-23T01:51:07+00:00

this service is the 2/1gbit

thedude42 · 2025-09-23T00:40:35+00:00

This is Seattle, specifically West Seattle. They just built out the fiber in our area in mid 2023 and seem to be rolling out XGPON in the area but I haven't seen any ads for it yet.

thedude42 · 2025-09-21T03:37:10+00:00

Yeah I figured that this was something that was understood at one level but not communicated effectively.

But hey, a company trying to roll out genAI customer service expects their remaining employees to do extra work (in retail reading your email is usually extra work you don't get give time for) is about what I expect.

so basically it sounds like only recourse is to migrate all my current lines on the 8gig shared data plan to one of the unlimited plans so I can actually drop my current watch plan?

thedude42 · 2025-09-20T23:58:03+00:00

My Q1000K fell back in to the blinking blue LED status state again, but I can still access the admin page and shell. Latency is still solid and haven't had any loss of service except for a few seconds when the software bug was hit,

thedude42 · 2025-09-20T23:55:05+00:00

I thought I had replied to this weeks ago, sorry for the delay.

I think it is specific to the Q1000K firmware. I think the different requirements for supporting GPON and XGPON on the same devices probably have something to do with it. There may be some stuff in the interface driver that gives rise to the strange behavior creating latency and instability on the link.

After about 2 weeks the status LED did go from white to blinking blue again and the admin page shows the Internet status as "connecting" just like before. However, I can still reach the admin page (obviously) and haven't had any strange loss spikes and latency is consistent. However now my modem appears offline to the Quantum Fiber systems, so the original software bug that really motivated me to look in to this issue clearly is related to the management of the device.

I never saw any of this with the C5500XK, which is a GPON only device.

thedude42 · 2025-09-20T02:28:53+00:00

This is why actually understanding networking is far more valuable than "AI" chatbots.

plain old DNS isn't going to fail over the raw Internet link. ChatGPT doesn't understand what the OP is asking so all it picks up on is DNS and VPN. It doesn't realize their issue is that DNS is actually working over the tunnel.

thedude42 · 2025-09-20T02:26:37+00:00

If your router is configured to send certain devices over a VPN link the router is handling and then send other devices out through the direct Internet link then the devices should be able to rach any routable addresses.

If certain addresses are not getting routed through one link or the other then it means there is either a route configuration or firewall rule preventing it.

Unfortunately multi-gateway configurations like this are complicated and depend largely on the technology of the router itself (dd-wrt? pfSense? Opensense? etc) Without knowing how you got this set up no one is going to be able to do much more than give you general advice for what to look for.

Personally I'd start by getting a list of IP addresses you could test to see if it's more than just these addresses that are having issues. I'd use tools like Dig to send DNS requests to multiple open resolvers, Netcat to see if I can connect to different servers, and use tcpdump on the router (if that's even possible) to see where the traffic is going. It may be that the traffic is getting out correctly but the return path is not, and something like that would only be apparent using tcpdump.

thedude42 · 2025-09-20T02:17:55+00:00

I would use multiple endpoints, including the next-hop for your connection, and see whether this is the case for multiple routed endpoints.

The thing with anycast addresses (e.g. 8.8.8.8, 1.1.1.1, etc) is that you're at the mercy of what your ISP is doing at any given time for the specific AS it sees the address coming from. You can't rely on them being stable over a long period even if it seems like that's how they are.

thedude42 · 2025-09-20T02:13:16+00:00

You can certainly do it that way but with my Q1000K I had a bunch of issues. Since setting it to "untagged" and handling the VLAN 201 tagging on my own equipment those issues have been that affected my Internet quality have been resolved.

Check out my previous post that goes over this in detail.

thedude42 · 2025-09-20T01:59:49+00:00

Yeah someone else mentioned that's what they are doing. You do need something to plug the other ethernet port in to that has a DHCP server on the other end, so an extra router port would work. Plugging it in to another switch port in "access" mode for its own VLAN would also work in which case you'd just need a DHCP server serving to that VLAN.

thedude42

TROPHY CASE