VLAN, Cannot access LuCI (but ssh fine) [Solved]

That's it! It's working now, through the switch and all :smiley:. Really appreciate it! But I do have to ask ... what made you think of that. LOL. Just wondering.

Thanks again so much for the help and pointers.

PS: tcpdump only shows vlan headers on eth0, not eth0.5. Still need to wrap my head around that one ... LMAO.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

1 Like

Awesome! Glad you're running now!

TBH, I don't recall who on this forum had contributed similar advice... I learned about the VLAN limitation of some switch chips from that person/people, but I've never experienced it myself. Fortunately, though, the info remained resident in my mind and I could offer that suggestion to you. Once we had gotten as far as not bringing down the upstream interface (good work, btw!), that seemed like the only other thing that could explain the behavior you were seeing. I was out of ideas, so glad this one worked!

1 Like

Yes, I plan to! I'll summarize the key items, so they are in one place - make it easier for folks (like me, thinking most folks don't want to read the entire thread :laughing:). I don't really like marking my summary as the solution, but seems from the link that's the way to do it.

@psherman, thinking these are the key items I need / plan to capture. Anything to add?

  1. LuCI incorrectly sets vlan (for the ipq40xx) ... the first one added is set to ID 2, which breaks wan. Change it, to a different value (and restart network) ... wan should return, and vlan will be OK (with the new ID).
  2. The ipq40xx switch seems to be limited in terms of vlan ID that can be used. Stick to 15 or less.

And some key notes I plan to also capture,
a) Keep one switch port as access (untagged vlan). It's really helpful for debugging, and is always accessible (even when you screw things up, trust me :grinning_face_with_smiling_eyes:)
b) Hats off to @psherman for the help an patience, working through this

BTW, I'll then post to the ipq40xx thread this solution as well, try to help folks there out.

Thanks!

1 Like

Much appreciated! Glad you retained it :smiley:

POST addition: found this, MAX_VLANS, tried it ...

fgrep -r MAX_VLAN target/linux/ipq40xx/* | fgrep define
target/linux/ipq40xx/files/drivers/net/ethernet/qualcomm/essedma/edma.h:#define EDMA_MAX_VLAN_SUPPORTED  EDMA_MAX_PORTID_SUPPORTED
target/linux/ipq40xx/files/drivers/net/phy/ar40xx.h:#define AR40XX_MAX_VLANS    128

So 128!

Hi,

Let me try to summarize the findings here - hopefully help others out. @psherman, by all means yell if I missed anything (and a new nugget below, that I just found :wink:). The key items,

  1. LuCI incorrectly sets vlan (for the ipq40xx) ... the first one added is set to ID 2, which breaks wan. Change it, to a different value (and restart network) ... wan should return, and vlan will be OK (with the new ID).
  2. The ipq40xx switch seems to be limited in terms of vlan ID that can be used. Stick to 127 or less (this is updated from above, as I found AR40XX_MAX_VLANS in the source).

And a key helpful finding, keep one switch port as access (untagged vlan). It's really helpful for debugging, and is always accessible (even when you screw things up, trust me :grinning_face_with_smiling_eyes:)

And the new new nugget, that sort of confirms the findings above ... checking swconfig dev switch0 show, I get (counter info removed, to make it more readable),

Port 5:
        pvid: 2
        link: port:5 link:up speed:1000baseT full-duplex auto

So while this is not noted anywhere - yep, wan is auto-configured to be on VLAN 2 ... hence the LuCI breakage above.

Hats off to @psherman for the help an patience, working through this. Thanks!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.