Closed SvenRoederer closed 5 years ago
possible solutions:
@pmelange wrote in https://github.com/freifunk-berlin/firmware/issues/545#issuecomment-388619593
@SvenRoederer , I disagree with using the option defaultroute '0' option because if a user assigns the ffuplink ip address to the (fritz) guest network, then the packets will be sent out with the src addr of br-wan, which is not desirable.
This would just disable pulling the default-route via DHCP. As currently the ffuplink get's the gateway assigned by looking up the gateway of br-wan in the hotplug-script.
Probably also related are:
@everloop2 , @vasyugan can you please check if one of the solutions help?
@SvenRoederer
default via 192.168.100.1 dev br-wan src 192.168.100.18
default via 192.168.100.1 dev ffuplink src 192.168.100.21 metric 1
looks a lot better to me than always using the src addr of br-wan. And it is a valid use case once #547 gets resolved.
found: https://wiki.openwrt.org/doc/uci/network#protocol_dhcp -> look bottom table -> Note -> 2nd ! -> route/metrics
The up-to-date documentation is at https://openwrt.org/docs/guide-user/base-system/basic-networking It doesn't have these warnings.
Using both metric or ip{4|6}table solutions seem to work fine.
Another issue which came up while testing with the no-tunnel version is that if I run "ifup wan" the ffuplink entries in the table disappear. It doesn't matter if wan was already up or not. If I afterwards run "ifup ffuplink" then all tables and routing works as it should.
If I run "ifdown wan; ifup ffuplink" nothing happens, which is to be expected with the veth device.
The tunnel versions need to be tested.
Firmware: Freifunk Berlin 2018-alpha a0f4533 / LuCI openwrt-18.06 branch (git-18.063.28405-d9039fc), no-tunnel
network.ffuplink.ip4table='ffuplink' network.ffuplink.ip6table='ffuplink'
seems to work, VLan enabled :D
uci show network:
...
network.wan=interface
network.wan.type='bridge'
network.wan.proto='dhcp'
network.wan.ifname='eth0.2 ffuplink_wan'
network.wan.peerdns='0'
...
network.ffuplink_dev=device
network.ffuplink_dev.type='veth'
network.ffuplink_dev.name='ffuplink'
network.ffuplink_dev.peer_name='ffuplink_wan'
network.ffuplink=interface
network.ffuplink.ifname='ffuplink'
network.ffuplink.proto='dhcp'
network.ffuplink.peerdns='0'
network.ffuplink.ip4table='ffuplink'
network.ffuplink.ip6table='ffuplink'
...
-> would prefer ipXtable entries -> https://de.wikipedia.org/wiki/Metrik_(Netzwerk) -> cause if WAN_metric=0 and ffuplink_metric=1 or bigger -> router always tries WAN first -> ?overhead?
Do we still need this part of the hotplug script after the change?
worked for a few hours, then ffuplink lost ip again, WAN still had ip and internet -> ill test Hedy_1.0.1
Try giving the ffuplinik_dev device a static MAC address. See #547
config device 'ffuplink_dev'
option type 'veth'
option name 'ffuplink'
option peer_name 'ffuplink_wan'
option macaddr 'd2:aa:bb:cc:dd:ee'
I have created pull request #131 to add the ip{4|6}table options to the ffuplink interface. If the hotplug script needs to be changed too, it could be added to the pull request. But it also works as it is.
got still connection issue after 1-2 days -> setup see https://github.com/freifunk-berlin/firmware/issues/561#issuecomment-389834577
-> next try: WAN no IP assigend & FFuplink IP assigned by ISP -> working
config interface 'wan'
option type 'bridge'
option proto 'none'
option ifname 'eth0.2 ffuplink_wan'
option peerdns '0'
There seem some issues related to the way we use the ffuplink-interface in the notunnel-flavor.
these both issue seem to be caused by using a dhcp-configured interface of the same uplink. It's very likely that these issues, and probably some more, can be solved by one solution.