DHCP on VLAN suddenly stopped working after energy loss (?) on 2 Omnias

michalko58 · June 24, 2019, 7:30pm

Hi, strange things happened last weekend.

On 22.6.2019, after storm and energy loss, two Turris Omnia routers got strange behaviour. Vlan stopped working. Maybe it is due the update to latest 3.11.5 or energy lost? Have been trying reboot, but with no success.

TO1 at my parent´s:
Vlan (for internet sharing with their neigtbour) - devices unable to obtain correct ip (169.xxx.xxx.xxx instead expected 192.168.3.xxx ) = no internet. When connected to normal network (port with no vlan) everything works fine.

TO2 at my home:
Vlan - device obtain ip from normal network range (192.168.1.xxx instead expected 192.168.3.xxx), but internet is working.

No settings were changed by me or anyone else. Any idea what could happen?

anon50890781 · June 24, 2019, 7:44pm

the 3.11.5 update should have created a snapshot, actually 2 - one prior commencing the update and one upon completion.

If you are familiar with cli and the schnapps tool you could schnapps list and find the snapshot number for the snapshot done prior to the update. then schnapps rollback - append the snapshot number you want to rollback to. that done reboot.

If everything works after the reboot you can be sure at least that the hardware is working and not not having suffered some sort power surge or something during the tempest.

michalko58 · June 25, 2019, 6:13am

Well I will try to rollback at leas at mine TO…

But, I have backup of network settings and dhcp settings files (made after proper setting of vlan). According to compare of the two files:

for TO1 case:
DHCP - changes only made by me after backup (start ip range), no other changes. This should be ok, Only order of settings has changed, but it is not important (am I right?).

NETWORK - no changes

for TO2 case:
DHCP - line 27 added by OS (?)

NETWORK - some changes made by OS (?)

It is very strange…

michalko58 · June 27, 2019, 6:45am

Well, I did rollback to snapshot before last update and no change. IP assigned in VLAN is from the same range as on normal network= 192.168.1.xxx instead 192.168.3.xxx

It seems problem is somewhere else then in dhcp or network settings. Is there any chance to find out why is this happening?

anon50890781 · June 27, 2019, 7:26am

dnsmasq is pretty chatty with its logs. it should reveal when and which ip gets assigned and to which client. if that matches your observation then there is likely a misconfiguration in network a/o dnsmasq

If it does not match your observation than there might be another party distributing dhcp leases to your vlan ifaces.

michalko58 · June 27, 2019, 8:08am

So I will have to look into dnsmasq settings… Where are dnsmasq logs stored? Network settings were not changed, so they should be ok.

anon50890781 · June 27, 2019, 8:24am

it reports to syslog-ng, unless otherwise filtered, and is accessible either via LuCI or ssh browser /tmp/log/messages

more likely in network (where the ip subnet assignment is stipulated) since dhcp covers ip range (start/limit) and lease time

michalko58 · June 27, 2019, 9:17am

Network settings should be ok.

Complete Network settings:

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd2a:c5a2:11ed::/48'

config interface 'lan'
	option ifname 'eth0.1 eth2'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'lan_2'
	option ifname 'eth0.3'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.3.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option ifname 'eth1'
	option proto 'dhcp'
	option ipv6 '0'

config interface 'wan6'
	option ifname '@wan'
	option noserverunicast '1'
	option proto 'none'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '5t 0 1 3'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4 6'
	option vid '2'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option ports '5t 2'
	option vid '3'

config interface 'guest_turris'
	option enabled '1'
	option type 'bridge'
	option ifname 'guest_turris_0 guest_turris_1'
	option proto 'static'
	option ipaddr '10.111.222.1'
	option netmask '255.255.255.0'
	option bridge_empty '1'

anon50890781 · June 27, 2019, 10:57am

At at glance it looks ok. Did you check the logs? Is there any other device in the network that hands out dhcp leases, e.g. upstream modem/router that handles connectivity with the ISP?

michalko58 · June 27, 2019, 12:17pm

A have no access to router now, I´ll check logs in the evening.

There are no devices on VLAN on my own TO - that VLAN serves only for testing of VLAN for my parent´s TO. So I didn´t noticed this problem unless neightbour called me, that internet is not working after storm.
On my normal network, there is only GPON connected to WAN port and it is in bridge mode.

It is very strange that two TO with almost the same network and dhcp settings, independently, started behaving strange, almost at the same time…

michalko58 · July 1, 2019, 6:50pm

Well, from dnsmasq log:

2019-07-01 20:41:00 info dnsmasq-dhcp[5729]: DHCPREQUEST(br-lan) 192.168.1.225 20:1a:06:4f:da:08 
2019-07-01 20:41:00 info dnsmasq-dhcp[5729]: DHCPACK(br-lan) 192.168.1.225 20:1a:06:4f:da:08 DESKTOP-UKDAUIT
2019-07-01 20:41:01 info /usr/sbin/cron[18254]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
2019-07-01 20:41:01 warning odhcpd[3671]: DHCPV6 SOLICIT IA_NA from 000100012084fd64201a064fda08 on br-lan: ok fd2a:c5a2:11ed::39c/128 
2019-07-01 20:41:01 info dnsmasq-dhcp[5729]: read /etc/ethers - 0 addresses
2019-07-01 20:41:02 warning odhcpd[3671]: DHCPV6 REQUEST IA_NA from 000100012084fd64201a064fda08 on br-lan: ok fd2a:c5a2:11ed::39c/128 
2019-07-01 20:41:02 info dnsmasq-dhcp[5729]: read /etc/ethers - 0 addresses

I don´t understand it very much, but strange is that DHCPREQUEST and DHCPACK (don´t know what it is) has there “br-lan” - it should be “br-lan_2”, I think…

Second strange thing (for me) is /etc/ethers - that file is empty

anon50890781 · July 1, 2019, 7:08pm

No issue, particularly since the file is empty. If not mistaken that option comes enabled as default setting and

can be turned off in LuCI (or via ssh)

DHCPREQUEST = client requesting ip from server
DHCPACK = server acknowledgement and providing client with ip

the client named DESKTOP-UKDAUIT then apparently is connected on br-lan and not br-lan_2

michalko58 · July 1, 2019, 7:56pm

And there is the problem - that port should be lan_2. So somehow vlan is no more vlan, but in settings everything looks ok.

anon50890781 · July 1, 2019, 8:26pm

what is the output of swconfig dev switch0 show ?

michalko58 · July 1, 2019, 8:33pm

Sorry, edited, due to pc was disconnected, during original post…

Global attributes:
        enable_vlan: 1
Port 0:
        mask: 0x0000: (0)
        qmode: 3
        pvid: 1
        link: port:0 link:up speed:100baseT full-duplex
Port 1:
        mask: 0x0000: (1)
        qmode: 3
        pvid: 1
        link: port:1 link:down
Port 2:
        mask: 0x0000: (2)
        qmode: 3
        pvid: 3
        link: port:2 link:down
Port 3:
        mask: 0x0000: (3)
        qmode: 3
        pvid: 1
        link: port:3 link:up speed:1000baseT full-duplex
Port 4:
        mask: 0x0000: (4)
        qmode: 3
        pvid: 2
        link: port:4 link:down
Port 5:
        mask: 0x0000: (5)
        qmode: 3
        pvid: 0
        link: port:5 link:up speed:1000baseT full-duplex
Port 6:
        mask: 0x0000: (6)
        qmode: 3
        pvid: 2
        link: port:6 link:up speed:1000baseT full-duplex
VLAN 1:
        port_based: 0
        vid: 1
        ports: 0 1 3 5t
VLAN 2:
        port_based: 0
        vid: 2
        ports: 4 6
VLAN 3:
        port_based: 0
        vid: 3
        ports: 2 5t

And now I can see that port 3 has pvid 1 (the same as ports 0 and 1) and port 2 has pvid 3… After connecting cable to port 2 ip has the right range 192.168.3.xxx

I really don´t know what happened, that ports changed…

I´ll try this tomorrov on second TO. Thank you.

anon50890781 · July 1, 2019, 8:50pm

There is no client connected on that port or else it would/should show link:up

michalko58 · July 1, 2019, 8:51pm

Sorry, just edited my message

anon50890781 · July 1, 2019, 8:54pm

the pvid is derived from the vid and since not configured it defaults to 1.

michalko58 · July 1, 2019, 8:59pm

But I don´t remember that I was changing cables between ports on this TO. ňI am really curioua if this happened on that second TO…

Thank you for your effort

anon50890781 · July 1, 2019, 9:01pm

Glad it works now. Well, I keep forgetting stuff… and then wonder. Or some mice played when the cat been away