Yeah, it is, and proven by the fact that we can browse the modem config page. Before I sent this thing off, I connected it as intended to my own LAN and tested that it got a DHCP address and was able to install SQM that way and etc. So I know this thing is configured in a working config. It's just this modem that stays locked to the nighthawk (as soon as she plugs the nighthawk in it works instantly).
I think currently it's just because the modem is still locked to her netgear nighthawk... Once it accepts the Pi, I expect this to "just work". The question is which magic incantation resets the modem's MAC lockout? That's the real bizarre thing.
I hope you're right.
On my Arris modems (SB6121, SB6141, SB6183), a restart (possibly a few times) clears the MAC binding. I've changed routers a few times and that has been the only necessary action.
this means pressing the little pinhole reset switch, or just unplugging and plugging back in?
It's a netgear modem... I forget the model though.
Hey I just had a thought, I might have turned on the loop-control thingy, and it might be sending loop detection packets from the switch... locking it to the switch instead of the router! I'm going to msg her the idea to check that.
I'm having a hope that it's the loop prevention thing. That would explain everything. But I really think the switch is configured fine otherwise, like I said I set it up at home and installed SQM through this switch, I know the VLANs are right with the right tagging... it's just something is locking us out of the modem, the loop prevention packets make the most sense, I'm hoping that's it.
BTW do you have a GS1200-8 from zyxel? this is the other candidate switch for this kind of application, and I'm wondering if it doesn't have the VLAN flaws and/or is a good candidate overall?
manual suggests explicitly that you can lock yourself out of the switch if you remove the management vlan from all the ports... so I think Zyxel is on the right track:
That's probably going to be my new go-to for small switches, since it's also cheaper!
The only thing it doesn't have is DSCP based QoS... or rate-limiting... meh
oh nice about the OpenWrt support. I've got a gs1900-24e and it's my main switch (in fact I just uploaded the latest factory firmware right now) but for the application here I think the price point is closer to $50 or less (the sg108e was $30) and the cheapest GS1900 I can see is the 16 port for $85. The RPi router with case and power supply is only ~$85 and the application is for a non-technical user. If I were setting up a family of 6 with 3 access points, 6 desktops etc I'd definitely look at the GS1900-24e though full 24 ports for $99 and excellent QoS features etc.
WDYT about the idea of plugging the pi direct to the modem, turning the modem off and on again, and waiting for it to fully boot... it'd be seeing packets from the RPi mac only, and get locked to the RPi hopefully, then we could just move ethernet cables over to the switch and move on with at least confirming it can work. Eventually I need to solve the problem of being able to have the modem on the switch from a clean power-up, but it's a lot easier to debug if we know the modem is capable of getting connected to the Pi and doesn't need some kind of unlock from Comcast support (and I do really love my sister, so I'm desperately trying to keep her from having to call Comcast support @psherman)
My guess is it will just look at layer 2 the first mac it sees, so it wouldn't even matter what the ethertype was etc. I could be wrong of course, but if the loop detection packets are setting it off... then evidently it doesn't care. anyway, I've got a couple of things I can try now.
Maybe I should explain my thinking because I feel like something got confused (we may already be on the same page, but just in case)...
AFAICT, you have the wan tagged on your Pi (and then the switch port configuration to the modem is untagged). And your LAN is untagged on the Pi.
If the above is correct, when you plug the Pi directly into the modem in this configuration, the untagged networks on the wire will be the WAN from the CM and the LAN from the Pi. Since the LAN has a static IP and a DHCP server, it will not initiate a DHCP client request that would begin the MAC address binding process on the cable modem.
Therefore, you should seriously consider making the WAN untagged and the LAN tagged.
Right now it's tagged eth0.1 for LAN and tagged eth0.2 for WAN. If i connect it direct to the modem I expect the modem won't understand anything being sent to it, but will grab the mac address of the first thing it hears and bind to that...
Then after a few seconds, we switch the cables back to the switch, and the modem will start to hear untagged packets on VLAN 2 which contain DHCP requests from the same MAC as it had previously latched to.
that's my guess... could be wrong about the modem ignoring VLAN frames.
If that were the case, it'd be already working though... because I've checked and the switch is definitely not in DHCP mode, so the only thing sending DHCP requests is the RPi. So I do think it's latching to whatever the first MAC is. It's also the case that I've heard of situations where OpenWrt routers with built in switches leak packets for the first few seconds during boot, and can cause a modem to latch to a MAC on the LAN. That seems to be the case whether the LAN machine is sending DHCP or not.
It's all very mysterious though. When my sister has a chance I'll find out if those loop detection packets are being sent. if it's latching to whatever the first MAC is that's almost certainly going to be the loop detection packets from the switch. If that's not enabled, then I'm a little flummoxed still.
I still maintain that the highest probability of success will be wan untagged on Ethernet, direct connection between pi and modem, and lan connecting by WiFi.
If that works, then insert the switch into the equation and see if it still works.
I would recommend that you remove that static route or interface you mentioned that connects to the modem’s admin subnet.
understood, will try out lots of these things probably tomorrow when sister and her husband don't need to be in zoom meetings, and I will definitely come back and explain what seems to have happened... as this is in my opinion the worst part of searching the internet on this particular issue... tons of people saying they have the problem... no solutions.
or rate-limiting... meh
)