Help configuring VLAN for WAN (escalated to crisis)

Software SW help
#1

Basically a re-open of:

Help configuring VLAN for WAN

It comes so close and yet. I have had an Omnia on the Australian NBN with an ISP (TPG) using PPPoE for nigh on a decade if not more and it works a dream. I have just today churned to a new ISP (Dodo - who I was with before TPG actually). And they’ve given me the configs for PPPoE, only surprised me with one more a VLAN ID of 100.

Hence I landed on the topic above.

I have spent hours on the phone with these folk thus far and am fading and all my services are down in the interim and until this is fixed.

I have only the suspicion that the VLAN ID is the issue as staff at the these big ISPs come in various levels of education and empowerment but it’s a magical thing rarely attained (and still not) to get someone who can diagnose PPPoE connection issues and confirm for example that VLAN tagging or lack of it is the problem (or even knows what a VLAN is or VLAN tagging).

This game involves three parties, me, my ISP (now Dodo) and the NBN (which won’t talk to me only ISPs). The NBN provide optic fibre to the premises and supply an NTD (Network Termination Device) which is in fact just their router that provides an RJ45 ethernet out. This is plugged into the WAN port of the Omnia.

I have in fact two Omnias one that’s been running for the decade and a spare that is factory clean. Neither have I got connected.

On problem with the closed topic above I have is clarity, or the lack of it, and another is specifics.

For example folk there are finding that custom Interface set to eth1.vlanid works. And yet on my Omnia to date with TPG, I had it set to eth2. So suddenly I’m stuck asking which of eth0, eth1, eth2 is that WAN port. On my old Omnia perforce it was eth2. Doc online span different models and more and I’m in a stressed muddle as a consequence.

Needless to say I have tried eth2.100 and eth1.100 with my ISP on the phone.

They can see my Omnia is connected. But their test suits fail, and the PPPoE connection fails. Further diagnosis has eluded them and it cost some hours and hoops and I’m about to call them again. But if I can get some clarity here on ISP VLAN configs I’d be chufffed. The clarity might include explaining just what this is, why it was never needed before and might be now, and also how to work out which of the ethn interfaces shown in Luci is the AN port at the back of the Omnia or better still, how to work this out physically for the given Omnia or any given model ) mine are just Turris Omnia, both I think on Turris OS 5 but would need to check.

I need to get online again ASAP as I host services for folk. All free, and so downtime is a risk, as it’s provided as a kindness by a hobbyist or home geek if you will who has servers and and extensive home LAN.

Forever grateful for any support I find here. Feeling stressed.

#2

Crisis abated.

The eth2.100 interface specification did the job. it took several tries, and I tried eth1 and eth2 alternating, but we got it connected.

The questions do remain. Albeit not under the stress of crisis management. How does one associate the physical ports behind the Omnia with interface numbers eth0, eth1, eth2? There must be a way to do this without drawing on arcane lore?

#3

Nowadays you can simply click in reForis to set VLAN ID on WAN. (but I don’t really know this stuff myself)

#4

Have you tried to check the documentation?

1 Like
#5

Yes indeed I did. I also found this though:

https://wiki.turris.cz/doc/en/howto/vlan_settings_omnia

which says the WAN is on eth1 but more importantly that it changed based on TurrisOS version and the thread above referred to eth1 and so I wanted to find some way with in Luci or at the bash prompt to confirm the mappings in particular given the manuals and wiki suggest that Turris OS can change the mapping, to wit, it’s a software mapping to wit there might ideally be some what to answer the burning question in the heat of a given moment, on this router how are the physical ports mapped to the interface names?

This: VLAN - Turris Documentation
of course was also a life saver in the heat of the moment.

We got there in the end, and I was stressed when eth2.100 did not work, so tried eth1.100 and that did not work, and then tried th01.100 and it did not work. So took a lunch break after posting this (in hope of maybe a tip after some sustenance) but lo and behold I phones support again to have them watching their end for the connection (though the ISP staff are poorly educated and lack tools for assessing much of anything prior to an authenticated connection) and I tried eth2.100 and blam I was on, got my DHCP assign WAN IP and was rolling.

Conclusion: human error on the first effort with eth2.100 before lunch. Nothing had changed in the cycle of tries, really just the digit after eth, as I cycled through them. And I did start with eth2 based on fact the earlier WAN connection (previous ISP) was eth2, and the doc said eth2, but I was thrown int confusion by the earlier threads reference to eth1, then found the eth1 doc I linked to above, in the wiki, then had no success on eth2 or eth1 so was wondering if we can’t find out somehow which ports are on eth0, eth1, and eth2, from the OS somehow, given they appeared in that wiki to be redefined by TurrisOS!

And that question does remain. Which I would document in my note app if I had a way :wink:

#6

The top of the page shows a flashy warning that it’s obsolete:

This documentation applies only Turris OS 3.x that is no longer present in newly sold routers. The new documentation is located at https://docs.turris.cz/.

1 Like
#7

I already noted that I thought … that the mapping changes across software versions and so by implication can be changed by software (no surprise as it’s a software ID for a hardware port) and the failure of eth1.100 in the face of a thread this one spun off (which was closed, and form 2016, referred to eth1) … led to the concern that the mapping might be a) alterable by configs, b) divinable from configs.

And the questions thus remain. Is there even a convenient way to list them in the CLI, or ideally to render a mapping to hardware ports? Where is the tie made, is it compiled into the kernel and not configurable post compilation?

Loads of question arose in the heat of the moment with “as per documentation” configs not delivering connectivity results. In the end they did of course and so we’re left with the conclusion that on earlier trials human error was involved (easy to imagine human error injection points, off the cuff by entering "eth2.100 " for example (whitespace) but possibly elsewhere …

#8

And I believe I have diagnosed the human error I alluded to! If I restart the wan interface I can see it fairly clearly. After clicking restart in 8 seconds an ERROR is displayed Unknown Error (USER_REQUEST), but with patience, reliably, in 28 seconds, the connection comes up, the error disappears and an IP address appears and RX and TX start moving.

In our haste and fatigue that 20 second gap, which may not seem long but I ask ou to watch a timer for 20 seconds when you’re feeling stressed and under pressure and reconsider, we decided the connection had failed (on account of the Error!) and so proceeded to try the next thing …

In the interim, I had functional internet all afternoon, then rebooted the Omnia and it’s all broken again albeit in a different way. Reported here:

#9

Yes, compiled into the kernel.

Well, forget the net-tools commands (route, ifconfig, arp) and learn to use the iproute (ip addr show, ip route show, etc) and you can see it pretty easily.

Like in here:

root@staging-gw-prg:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1024
    link/ether d8:58:d7:00:5a:95 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether d8:58:d7:00:5a:93 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether d8:58:d7:00:13:46 brd ff:ff:ff:ff:ff:ff permaddr d8:58:d7:00:5a:94
5: lan0@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:5a:93 brd ff:ff:ff:ff:ff:ff
6: lan1@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:5a:93 brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:5a:93 brd ff:ff:ff:ff:ff:ff
8: lan3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:5a:93 brd ff:ff:ff:ff:ff:ff
9: lan4@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:5a:93 brd ff:ff:ff:ff:ff:ff
    link/none

Do you see the lan0@eth1? That means that the LANx ports are bound to eth1 interface. eth0 interface is not used.

1 Like
#10

It does and that’s great and as stated already I know and knew, BUT it made clear that the mapping was OS version dependent, raising the spectre that it was software defined and configurable, which in light of using the documented eth2.100 not working, with ISP support on the phone, and references to eth1 regularly cropping up on searches, the attendant spectre that such a config had gone awry and desire to do a confirming check.

The nearest I’ve been offered, which is a good start to remember is ip link show. It is good on revealing lan0/eth1 and family but doesn’t show the mapping wan/eth2 clearly or what eth0 is. Of course from the doc (which is excellent indeed) it looks like eth0 and eth1 feed lan0 to lan4 (which makes the ip link show output even more, mildly cryptic.

But yes, the stress was fuelled by urgency, fatigue, and total failure of everything tried so grasping at straws.

In the end, as noted above I do believe I understand where human error crept in and why it appeared the documented method (eth2.100) failed (entering this spiral of uncertainty). Alas, that is hindsight. Still, it is always good to have learned from hindsight! And so one further learning I’d still like is how in the heat of a moment to be sure of this mapping of interface names to physical ports.

#11

OK, I see. (post must be at least 20 characters)

#12

Thanks to everyone involved for the patience and tips and support BTW. It was a mildly harrowing churn, and most of the technical reason (there were also compounding business issues with the ISP and network carrier and timing of it - but, predicting those I opted for a Monday morning churn as I have some folk relying on a weekend service here) was down to the diagnosed issue above (TLDR: Luci reports a connection ERROR quickly after restarting the interface but then success a half minute later - which is not just human error, but also questionable reporting or handshaking - with the ISP).

#13

Other possible ways to test this, since you have physical access to the router:

  1. LED mapping

In /etc/config/system you should have an entry like so:

config led 'led_wan'
	option name 'wan'
	option sysfs 'rgb:wan'
	option trigger 'netdev'
	option mode 'link tx rx'
	option dev 'eth2'

That maps the WAN LED to the eth2 port. If you disconnect all others, and still see the WAN LED blinking, that’s very good indication that WAN is indeed eth2.

  1. Networking interfaces

In /etc/config/network you should have:

config interface 'wan'
	option device 'eth2'
	...

config interface 'wan6'
	option device 'eth2'
	...

That maps the wan and wan6 interfaces to eth2. That’s usually configured by the system. So, unless your TurrisOS is borked in weird ways, you can be certain that this is the right port.

  1. tcpdump

You can always just look at packages arriving on an interface and match it with whatever you expect to find from your ISP.

# tcpdump -Snvei eth2

The above should print out to your terminal all packets arriving on eth2. If they’re tagged, you will see something like vlan 100 on each line representing a packet tagged with VLAN ID 100.

#14

https://openwrt.org/docs/guide-user/network/vlan/switch_configuration