mistermoonlight1
Occasional Visitor
Deeper analysis (main dhcp lan bug with guess wifi and trunk lan port)...
I have also found than once i disable the guess network at the end of post #99 (which repair the main dhcp problem), then reenable it, and assigned a trunk again to the 2.5gbps lan port (same i did in post #99 the 1st time), main dhcp is now working!!!
When main dhcp is working with the guess wifi active, i can see in the syslog something like attached "working-dnsmasq.txt" (oups, it seems i cannot attache txt file!). We can see that there is no more than 2 successive readings of the etc-host file by dnsmasq instance.
And when the main dhcp is broken, we can see something like "buggy-dnsmasq.txt" (i was not enable to attached it), with many successive reading (7 successive readings!) of etc-host file reading (dnsmasq crashed?), the number of successive reading is not fix, and can be greater than what i have seen.
About the nvram buggy left entry...
I made a comparaison between a dump of nvram when main dhcp is working with guess wifi enable and trunk configured on lan port and when it is not with the same trunk configuration on 2.5gbps (eth5 port) (it should be the same, but it is not).
a)buggy situation (with trunk enable):
lan_ifnames=eth1 eth2 eth3 eth4 eth5 eth6 eth7
vlan_trunk_rl=
vlan_trunklist=
br0_ifname=br0
br0_ifnames=
br1_ifname=br52
br1_ifnames=wl0.1 eth1.52 eth2.52 eth3.52 eth4.52 eth5.52 eth6.52 eth7.52
b)working situation (with trunk enable):
lan_ifnames=eth1 eth2 eth3 eth4 eth6 eth7
vlan_trunk_rl=<5>52
vlan_trunklist=<xx:xx:xx:xx:xx:xx>L5#all
br0_ifname=br0
br0_ifnames=
br1_ifname=br52
br1_ifnames=wl0.1 eth1.52 eth2.52 eth3.52 eth4.52 eth5.52 eth6.52 eth7.52
As we can see between a) and b), both configuration when doing "brctl show" shows exactly the same bridges definitions for br0 and br52, but the trunk definitions were not made correctly in the buggy a) version and the lan_ifnames neither.
I have also compare the nvram definitions once i am in situation a) and just disable the guess wifi definition, which also repairs the main dhcp problem.
c)working situation (after disable the trunk definition and also disable the guess wifi definition, which also repair main dhcp):
lan_ifnames=eth1 eth2 eth3 eth4 eth5 eth6 eth7
vlan_trunk_rl=
vlan_trunklist=
br0_ifname=br0
br0_ifnames=eth1 eth2 eth3 eth4 eth5
br1_ifname=br52
br1_ifnames=wl0.1 eth1.52 eth2.52 eth3.52 eth4.52 eth5.52 eth6.52 eth7.52
so if we compare a) and c), we can see we have a normal br0 definition without any trunking definitions...
I have also found than once i disable the guess network at the end of post #99 (which repair the main dhcp problem), then reenable it, and assigned a trunk again to the 2.5gbps lan port (same i did in post #99 the 1st time), main dhcp is now working!!!
When main dhcp is working with the guess wifi active, i can see in the syslog something like attached "working-dnsmasq.txt" (oups, it seems i cannot attache txt file!). We can see that there is no more than 2 successive readings of the etc-host file by dnsmasq instance.
And when the main dhcp is broken, we can see something like "buggy-dnsmasq.txt" (i was not enable to attached it), with many successive reading (7 successive readings!) of etc-host file reading (dnsmasq crashed?), the number of successive reading is not fix, and can be greater than what i have seen.
About the nvram buggy left entry...
I made a comparaison between a dump of nvram when main dhcp is working with guess wifi enable and trunk configured on lan port and when it is not with the same trunk configuration on 2.5gbps (eth5 port) (it should be the same, but it is not).
a)buggy situation (with trunk enable):
lan_ifnames=eth1 eth2 eth3 eth4 eth5 eth6 eth7
vlan_trunk_rl=
vlan_trunklist=
br0_ifname=br0
br0_ifnames=
br1_ifname=br52
br1_ifnames=wl0.1 eth1.52 eth2.52 eth3.52 eth4.52 eth5.52 eth6.52 eth7.52
b)working situation (with trunk enable):
lan_ifnames=eth1 eth2 eth3 eth4 eth6 eth7
vlan_trunk_rl=<5>52
vlan_trunklist=<xx:xx:xx:xx:xx:xx>L5#all
br0_ifname=br0
br0_ifnames=
br1_ifname=br52
br1_ifnames=wl0.1 eth1.52 eth2.52 eth3.52 eth4.52 eth5.52 eth6.52 eth7.52
As we can see between a) and b), both configuration when doing "brctl show" shows exactly the same bridges definitions for br0 and br52, but the trunk definitions were not made correctly in the buggy a) version and the lan_ifnames neither.
I have also compare the nvram definitions once i am in situation a) and just disable the guess wifi definition, which also repairs the main dhcp problem.
c)working situation (after disable the trunk definition and also disable the guess wifi definition, which also repair main dhcp):
lan_ifnames=eth1 eth2 eth3 eth4 eth5 eth6 eth7
vlan_trunk_rl=
vlan_trunklist=
br0_ifname=br0
br0_ifnames=eth1 eth2 eth3 eth4 eth5
br1_ifname=br52
br1_ifnames=wl0.1 eth1.52 eth2.52 eth3.52 eth4.52 eth5.52 eth6.52 eth7.52
so if we compare a) and c), we can see we have a normal br0 definition without any trunking definitions...
Last edited: