Two "WAN-Port LAN Mode" problems

[meyergru]

There is this setting in "Local Network" card:

Presumably, this should make eth4 (SFP) a normal LAN port. It apparently affects the config setting uci.ethernet.globals.eth4lanwanmode. However, what is does not do is change this section in /etc/config/network:

config interface 'sfp'
        option proto 'static'
        option ifname 'eth4'
        option ipaddr '192.168.2.2'
        option netmask '255.255.255.0'

That has two implications:

1. eth4 always has the IP 192.168.2.2 and the bridging seems unchanged, too. I wonder how the eth4 port can be part of the LAN that way. uci.ethernet.globals.eth4lanwanmode does a lot of things, but probably not what it was intended to do.

2. I thought that enabling that setting would be also a remedy to the problem that 192.168.2.0/24 can never be chosen for the LAN ip range in that it would remove the IP adress from that interface, but it is not for the reasons given above.

[Ansuel]

so what you suggest to do?

i need to change eth4 and add it to the lan bridge but what about the ipaddr i should add an exception to the lan modal to automatically change the ipaddr of the sfp part automatically...

[meyergru]

I think it should be like this:

• with WAN-Port mode off, the IP assignment should be removed and the port must be added to the bridge
• with WAN-Port mode on, an IP must obviously be assigned and eth4 must be removed from the LAN bridge.

Thus, any IP address range could be used unless WAN-Port LAN Mode is on. However, switching back could be difficult if 192.168.2.0/24 has been assigned to the LAN while LAN Mode was off. That could only be fixed by choosing a free IP range automatically (say, 192.168.(X+1).0/24 if 192.168.X.0/24 is used by LAN.

[Ansuel]

Can you test the new stable? i should have fixed this 2 problems...

[meyergru]

Woa. Something bad happened... I tried 8.6.23 via manual upgrade. The bar went all the way to the right but then the GUI did not reappear as usual.

The modem was offline (i.e. not pingable) and stays like that after a reboot. It is neither reachable via the IP I had assigned to it nor via 192.168.1.1. I can see the firewall messages via the serial console.

I have not managed to do a factory reset by using the little reset hole - pressed >= 30 seconds, nothing happened.

I even reflashed 1.1.0 by pressing reset. Afterwars, the GUI comes up (I can see the Ansuel Logo in the serial console), but no network connectivity. It seems like the br-lan is configured to no adress at all.

[Ansuel]

FK .... can you menage to take the network config?

[meyergru]

As I have no network access at all, the only thing I can do is log the whole booting process and append it here - but I do not see which IP range is assigned there.

log.txt

Is there a special way to do a factory reset with the DGA4132?

[Ansuel]

reset should work...

you can try to change bank with serial

[meyergru]

I have read about the need to push some other button in order to reset?

[meyergru]

What I found interesting was this log entry:

[   57.257000] dosprotect rpfilter drop IN=br-lan OUT= MAC= SRC=192.168.10.29 DST=224.0.0.22 LEN=48 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 MARK=0x9800

Because the SRC address is the IP that was assigned to the modem. It looks like the firewall eats its own packets.

[Ansuel]

to reset with system loaded push for 7 second the reset button and release

[meyergru]

Ah, so not 30 seconds?

[Ansuel]

that ip addres should be the sfptag new interface

[Ansuel]

7 second and release wait some time and it should autoreboot....

something in serial console should appear...

[meyergru]

I think that the factory reset has taken place - the WiFi LEDs are on now (and I disabled both WiFis before). Now, the modem is reachable via 192.168.1.1 again.

The GUI is "503 Service Temporarily Unavailable", I can login via SSH.

Should I reinstall the GUI or is there anything I can try to look at first?

[Ansuel]

ummm yes... anyway keep the wifi enabled...

so we cans till access the modem with it :)

Think we need to make some test to track down what went wrong...

[meyergru]

Maybe it would be nice if the rootdevice script would show the network config on the console - that would bother nobody but provide a nice way to see what the result of any modifications is? I just added that manually.

And now I see what went wrong: the sfptag interface is assigned 192.168.10.1/24. So there was a collision with my home IP range.

[Ansuel]

owww! so that was the problem...

then i should add a check for that...

i found in the script some documentation about the sfp interface and i found that you can create it in 2 way...

sfp and sfptag

sfptag use 192.168.10.1 as ip and i changed it to workaround the problem of the local modem...

think i need to find a better way for this...

[meyergru]

Yup, that's a problem: We need disjoint IP ranges for WAN, LAN and SFP but have to make sure that they do not collide with networks in use. The only way I can see fit is to have a default assignment first and let the user decide on any of these...

BTW: The 192.168.1.1 not working was my fault... it would probably work - however, few users can setup a network that can handle multiple IP ranges...

[Ansuel]

think i will solve this problem this way...

move sfp to sfptag (and check if that ip is not used... if it is, allocate the ip +1 )

then on the lan card show some alert or just create an entities to set the sfp local ip...

[meyergru]

Yes, but the problem was not with the manual config via GUI anyway - I cannot choose 192.168.10.29 as the validation sees the collision. The problem in my case was that the GUI upgrade made the same mods and did not see the collision.

[meyergru]

One other possibility would be to leave the unneeded interfaces unconfigured.

[Escart94]

The problem is that OpenWRT will assign the IP anyway, without considering If isn't used. So this isn't a good possibilty honestly...I think that the best way to bypass this problem is to switch It to SFPTag and check If the 192.168.10.1/24 class is already used.

[meyergru]

I see - with most other Linux variants, you can have an interface named but leave out the IP address and netmask, for example, when you need the interface for bridging only.

I now understand that there is no "proto 'none'" in OpenWRT, so that giving an ipaddr seems mandatory - but you could use an IPv6 instead. For example, the FE80 LL address would work. But choosing a subsequent free IPv4 range is fine and follows the same pattern I initially suggested.

[Ansuel]

can you test this dev?

i added a check to the sfp conversion and also in the lan card i added an option to actually set the local ip of the sfp interface...

[Ansuel]

Use ipv6 address would be very good... but the sfp scripts comunicate with the sfp module with telnet and because of this use ipv6 is not possible... (i don't think telnet support ipv6...)

[meyergru]

Works. Just one small glitch: When I changed the status of the "WAN-Port LAN-Modus" from off to on, I got an error saying that the SFP port IP must not be in the SFP range. Probably because this effectively tries to set the SFP IP address to itself while the only changed item was another one.

[Ansuel]

ok thx...

[Ansuel]

@meyergru can you tell me the exact message?

[meyergru]

SFP IP should not be in sfptag IP Range

But it must be modular, as "IP Range" is translated to "IP Bereich" on my machine.

[Ansuel]

try now

[meyergru]

8.6.30 still has that behavior. You can easily try it: Switch the WAN port mode to the other value of what it was and try to save. Then the validation fails. I think it is because you check the SFP IP against ANY other interface IP, including itself.

[Ansuel]

i can't test cause i don't have tim hub and i don't have also any modem ahahha

[meyergru]

😲

[Ansuel]

anyway this version now should be good...

[meyergru]

+1

[meyergru]

Ups... I just found that turning LAN mode off does not change /etc/config/network at all? How can the WAN port be associated/disassociated from the bridge, then? What am I missing?

[Ansuel]

Can you check sfptag interface in the network file? It should move eth4 from there to the lan bridge

[meyergru]

As I said: I toggled the setting back and forth and the /etc/config/network did not change one bit. Both say always:

config interface 'sfptag'
        option proto 'static'
        option ifname 'eth4'
        option netmask '255.255.255.0'
        option ipaddr '192.168.111.2'

That only changes when I alter the IP address.

[Ansuel]

so when you change ip addr (and the switch is on) eth4 goes to br-lan right?

[meyergru]

No, only the IP changes. ifname stays the same. Nothing changes AT ALL when I toggle the switch, regardless of any other settings.

[meyergru]

Retested with 8.6.55: Still no change on button toggle.

[Ansuel]

check with this latest version

[meyergru]

Still no change. Toggling the setting does not change the sfptag section.

[Ansuel]

Can you check the ethernet config?

[meyergru]

How? Anything apart from /etc/config/network?

[Ansuel]

The ethernet config file

[meyergru]

Yup, that changes eth4lanwanmode from 0 to 1 and back - nothing else is changed:

config port 'eth0'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth1'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth2'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth3'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth4'
        option enable '1'
        option speed 'auto'
        option duplex 'full'
        option wan '1'

config port 'eth5'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config mapping
        option port 'eth5'
        option wlan_remote '1'

config globals 'globals'
        option eth4lanwanmode '0'

config port 'eth0'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth1'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth2'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth3'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config port 'eth4'
        option enable '1'
        option speed 'auto'
        option duplex 'full'
        option wan '1'

config port 'eth5'
        option enable '1'
        option speed 'auto'
        option duplex 'full'

config mapping
        option port 'eth5'
        option wlan_remote '1'

config globals 'globals'
        option eth4lanwanmode '1'

[Ansuel]

Also if possible give me the log after the switch It should execute a script...

[meyergru]

I get this:

Jul 29 11:46:21 | daemon.err | transformer[26780] | async exec of '/etc/init.d/ethernet  reload ; /usr/share/tranformer/scripts/check_wan.sh' failed exit code=127
-- | -- | -- | --
Jul 29 11:46:19 | kern.warn | kernel | [1102636.516000] Cross Bar MUX Config : Internal Port 02 maps to External Port 00 <reg_val : 0x00000012>
Jul 29 11:46:19 | kern.warn | kernel | [1102636.507000] Cross Bar MUX Config : Internal Port 01 maps to External Port 02 <reg_val : 0x00000012>
Jul 29 11:46:19 | kern.warn | kernel | [1102636.497000] Cross Bar MUX Config : Internal Port 00 maps to External Port 02 <reg_val : 0x0000000a>
Jul 29 11:46:19 | kern.warn | kernel | [1102636.490000] Unused MUX Internal Port#1 connects to Crossbar External Port#2
Jul 29 11:46:19 | kern.warn | kernel | [1102636.483000] Unused MUX Internal Port#0 connects to Crossbar External Port#2

Seems to be a typo: 'tranformer' instead of 'transformer' in the script path.

[Ansuel]

Fixed