| Message ID | c75d9dea-6bff-b26a-e5d4-f73eccdfc521@ezplanet.net |
|---|---|
| State | Rejected |
| Delegated to: | Mathias Kresin |
| Headers | show |
11.02.2017 18:55, Mauro M.: > This proposed patch applies to BT Home Hub 5 Type A and: > > 1) it includes configuration for the Red Ethernet port as an additional > "dmz" interface (feature request FS#490) NAK. It's a WAN port and not a DMZ port. It should be used by default as WAN port. If you need it as DMZ port, feel free to add your own _local_ configuration. > 2) it fixes FS#390 providing the ability to associate port 5 to the main > switch VLAN. Looks exactly like one part of the changes I've in my staging tree to which I pointed you to. Or to be more clear, thanks for copying my code without mention the author. Consider your patch as rejected. I pointed you to the commits in my staging tree which are properly fixing the issues you are seeing and some others you are not aware of. I can only please you once more (the third time?) to test my staging tree as it is and report if there are still issues left or new issues introduced. Mathias
@Mathias On this router, that has already a WAN xDSL port, another WAN port is not a priority. If one wants to use the Red Ethernet as you intend to, one would use a different router that does not have an xDSL WAN. I do not want to test your staging tree because your analysis is flawed, you refuse to listen to input and feedback and therefore it would be a waste of my time. You should make an effort to be less hostile in your comments. I am very satisfied with the change I posted on lede-dev because it is simple, backward compatible and it does exactly what is required. And yes it removes port 5 definition which is also in your patch. Thank you. You may close the request. Mauro On 11/02/17 20:32, Mathias Kresin wrote: > 11.02.2017 18:55, Mauro M.: >> This proposed patch applies to BT Home Hub 5 Type A and: >> >> 1) it includes configuration for the Red Ethernet port as an additional >> "dmz" interface (feature request FS#490) > > NAK. > > It's a WAN port and not a DMZ port. It should be used by default as > WAN port. If you need it as DMZ port, feel free to add your own > _local_ configuration. > >> 2) it fixes FS#390 providing the ability to associate port 5 to the main >> switch VLAN. > > Looks exactly like one part of the changes I've in my staging tree to > which I pointed you to. Or to be more clear, thanks for copying my > code without mention the author. > > Consider your patch as rejected. I pointed you to the commits in my > staging tree which are properly fixing the issues you are seeing and > some others you are not aware of. > > I can only please you once more (the third time?) to test my staging > tree as it is and report if there are still issues left or new issues > introduced. > > Mathias
On 2017-02-11 21:53, Mauro M. wrote: > @Mathias > > On this router, that has already a WAN xDSL port, another WAN port is > not a priority. If one wants to use the Red Ethernet as you intend to, > one would use a different router that does not have an xDSL WAN. > > I do not want to test your staging tree because your analysis is flawed, > you refuse to listen to input and feedback and therefore it would be a > waste of my time. You should make an effort to be less hostile in your > comments. > > I am very satisfied with the change I posted on lede-dev because it is > simple, backward compatible and it does exactly what is required. And > yes it removes port 5 definition which is also in your patch. Thank you. > > You may close the request. Hey Mauro, please don't take Mathias' feedback as hostile, it really isn't. His patch seems to take the same basic approach as yours, so I would consider his request for testing his staging tree reasonable. While you can treat the extra port in your configuration as a 'dmz' interface, I don't think it is reasonable for the default config. You should be able to make your configuration work even with his changes. Could you please run the test even if you still like your change better? Note that other devices (e.g. the Buffalo WBMR-300HPD) have a similar configuration where one ethernet port can also be used as an optional WAN port. Thanks for looking into this, - Felix
Hello Felix, Thank you for your comments. On 11/02/17 21:49, Felix Fietkau wrote: > Hey Mauro, > please don't take Mathias' feedback as hostile, it really isn't. His Please see the threads on FS#390 and FS#321 there is a pattern. > patch seems to take the same basic approach as yours, so I would > consider his request for testing his staging tree reasonable. I am sure that technically Mathias' patch will work. The problem is not technical, but rather in the prioritization of the Red Ethernet Use Cases that I documented in my previous post. > While you can treat the extra port in your configuration as a 'dmz' > interface, I don't think it is reasonable for the default config. > You should be able to make your configuration work even with his changes. > Could you please run the test even if you still like your change better? I understand the logic to name the Red Ethernet as "wan". This would be aligned to the majority of routers that do not have an xDSL port. However, since I want to have full control from the wire entering my premises, I always prefer a router with an actual xDSL WAN port. In my area the upgrade from xDSL is an actual Ethernet IP/IP Subnet (no pppoe necessary). Therefore I never had any use for routers with a WAN Ethernet as WAN. I just use the WAN Interface with a static IP on the DMZ. On xDSL routers the DSL port has always been the WAN interface. The Red Ethernet on BT Home Hub 5 xDSL router is an extra bonus. I believe that renaming the current "wan" to "xwan" on xDSL routers would be a mistake because it is not backward compatible. An impact scenario for an "end user" is: I have routers in unmanaged remote locations, if I upgrade my routers to a firmware that renames the WAN interface, they will fail to reconnect the WAN on reboot. I could prepare the new configuration in /etc/config/network before flashing the new firmware, but without testing it would be a risk that might cost me a 3000Km round trip. If you want to configure the Red Ethernet as a WAN, please name it something which isn't WAN. It would be ok for my use cases, because I can always turn it into an interface with a static IP. Best regards, Mauro
On 2017-02-12 15:16, Mauro M. wrote: > Hello Felix, > > Thank you for your comments. > > > On 11/02/17 21:49, Felix Fietkau wrote: >> Hey Mauro, >> please don't take Mathias' feedback as hostile, it really isn't. His > Please see the threads on FS#390 and FS#321 there is a pattern. I don't see any real hostility in there, I guess he was sometimes a bit frustrated because in your patches and responses you seemed to consider only your device and ignored his concerns about these changes affecting other devices in a negative way. >> patch seems to take the same basic approach as yours, so I would >> consider his request for testing his staging tree reasonable. > I am sure that technically Mathias' patch will work. The problem is not > technical, but rather in the prioritization of the Red Ethernet Use > Cases that I documented in my previous post. Yes, I understand your use case. >> While you can treat the extra port in your configuration as a 'dmz' >> interface, I don't think it is reasonable for the default config. >> You should be able to make your configuration work even with his changes. >> Could you please run the test even if you still like your change better? > I understand the logic to name the Red Ethernet as "wan". This would be > aligned to the majority of routers that do not have an xDSL port. > However, since I want to have full control from the wire entering my > premises, I always prefer a router with an actual xDSL WAN port. In my > area the upgrade from xDSL is an actual Ethernet IP/IP Subnet (no pppoe > necessary). Please note that I'm not comparing this situation to routers without xDSL part at all. I specifically mentioned the Buffalo device, because it is also a VR9 device with built-in modem and with a separate WAN ethernet port. > Therefore I never had any use for routers with a WAN Ethernet as WAN. I > just use the WAN Interface with a static IP on the DMZ. > > On xDSL routers the DSL port has always been the WAN interface. > The Red Ethernet on BT Home Hub 5 xDSL router is an extra bonus. You really don't need to go on explaining your use case to me, I already fully understood it from the first time you described it. I also understand why you prefer it over having the port labelled as WAN. However, the default use of this port (just as on the Buffalo device) is as a secondary WAN port (in case the xDSL part does not get used). This is the reason why I consider Mathias' change to treat the port as a secondary WAN port more appropriate here, including the fact that this makes support for the HomeHub device more consistent with other devices that have a similar hardware configuration, e.g. the Buffalo device that I mentioned. > I believe that renaming the current "wan" to "xwan" on xDSL routers > would be a mistake because it is not backward compatible. Technically, both your change and Mathias' change are breaking backwards compatibility in some cases, because eth1 gets changed to a VLAN on eth0. There is no real way around that. @Mathias: could you perhaps refactor the commits to put the wan->xwan rename *after* the ethernet port VLAN change? I'm also a bit sceptical about the interface rename and would like to discuss this further, but I think the VLAN change is important enough to get it in the tree soon. - Felix
12.02.2017 15:55, Felix Fietkau: > @Mathias: could you perhaps refactor the commits to put the wan->xwan > rename *after* the ethernet port VLAN change? > I'm also a bit sceptical about the interface rename and would like to > discuss this further, but I think the VLAN change is important enough to > get it in the tree soon. I'm not entirely sure if I got your concerns right. The overall objective is to have an out of the box usable ethernet wan port beside the xdsl wan. My approach is to use the wan network name for ethernet wan ports only. A few month ago, we had already a discussion about renaming wan to ewan to make clear that it is the ethernet wan network. But I was the only one who was the opinion that it was a good idea and I discarded this approach. The xwan network is intended to be used for router having an ethernet wan port and a 3G/4G modem as well. None of the commits should break anything. The xwan network has the same default firewall settings as the wan network. In the end it doesn't really matter to which network an interface belongs. It should work the same way for both. Existing configs should work as before, since the it isn't really a rename of the wan network. I just add a new network and old configs would use the still existing wan network. It is quite unlikely that the vlan change breaks anything. The default vlan config is only changed for devices which are having the lantiq,wan device tree property. The port with this dt property is exposed as eth1 but not configured/considered by default in any way. It is even more worse. The eth1 interface can not be used as it is. Due to xrx200 switch driver oddities, the lantiq,wan interface gets the vlan 2 assigned without being mentioned in ucidef_add_switch. If the user wants to use this interface (s)he need to add a not that obvious configuration (eth1.2 instead of eth1). To use a different vlan than 2 for the lantiq,wan interface, the user needs to change the default vlan config despite the lantiq,wan interface doesn't look like related to the switch config (eth1 instead of eth0.n). I'm fine to discuss any ideas to fix/workaround the limitations. I have this commit in my staging tree since a few months and so far I have no idea how to fix/workaround the limitations in a better way. Mathias
On 12/02/17 15:56, Mathias Kresin wrote: > 12.02.2017 15:55, Felix Fietkau: >> @Mathias: could you perhaps refactor the commits to put the wan->xwan >> rename *after* the ethernet port VLAN change? >> I'm also a bit sceptical about the interface rename and would like to >> discuss this further, but I think the VLAN change is important enough to >> get it in the tree soon. > > I'm not entirely sure if I got your concerns right. > > The overall objective is to have an out of the box usable ethernet wan > port beside the xdsl wan. My approach is to use the wan network name > for ethernet wan ports only. A few month ago, we had already a > discussion about renaming wan to ewan to make clear that it is the > ethernet wan network. But I was the only one who was the opinion that > it was a good idea and I discarded this approach. > Although I agree with Mathias that the Ethernet WAN could be renamed to EWAN, I understand also that this will deviate from the current standard and break backwards compatibility too for Ethernet WAN only routers. It is the same case we have for xDSL routers. If we want both Ethernet and xDSL defined as WANs, one of them cannot be named WAN. > The xwan network is intended to be used for router having an ethernet > wan port and a 3G/4G modem as well. > > None of the commits should break anything. The xwan network has the > same default firewall settings as the wan network. In the end it > doesn't really matter to which network an interface belongs. It should > work the same way for both. Existing configs should work as before, > since the it isn't really a rename of the wan network. I just add a > new network and old configs would use the still existing wan network. You are correct that the name does not matter, however if we have routers already configured to associate the xDSL or Ethernet to WAN, when we flash the new firmware we will have to reconfigure them to rename the device. This is all good if the routers are physically there, but when the routers are in remote unmanaged locations (like I have) it becomes a problem. Renaming the interface is a small thing, but it will impact many end users. I advocate to maintain WAN for xDSL out of my use case interest and also because personally I think an xDSL is truly a WAN interface whilst an Ethernet can be anything. > It is quite unlikely that the vlan change breaks anything. The default > vlan config is only changed for devices which are having the > lantiq,wan device tree property. The port with this dt property is > exposed as eth1 but not configured/considered by default in any way. > > It is even more worse. The eth1 interface can not be used as it is. > Due to xrx200 switch driver oddities, the lantiq,wan interface gets > the vlan 2 assigned without being mentioned in ucidef_add_switch. If > the user wants to use this interface (s)he Agreed, the vlan change fixes a serious issue. We should commit the change asap. Mauro
12.02.2017 17:40, Mauro Mozzarelli: > You are correct that the name does not matter, however if we have > routers already configured to associate the xDSL or Ethernet to WAN, > when we flash the new firmware we will have to reconfigure them to > rename the device. This is all good if the routers are physically there, > but when the routers are in remote unmanaged locations (like I have) it > becomes a problem. Renaming the interface is a small thing, but it will > impact many end users. I advocate to maintain WAN for xDSL out of my use > case interest and also because personally I think an xDSL is truly a WAN > interface whilst an Ethernet can be anything. Please keep in mind that your existing config is not touched and the wan network still exists with my patches applied. I fail to see how it should break existing xDSL configs. But you are right, the ethernet wan config will most likely not work any longer for people who managed to workaround all the outlined issues. But the same applies to your patch, since you are moving the ethernet wan from eth1 to eth0 as well. Lets hope that only the minority of the uses managed to configure a working ethernet wan. Mathias
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh b/package/base-files/files/lib/functions/uci-defaults.sh index f4c1d96..b6dd1f6 100755 --- a/package/base-files/files/lib/functions/uci-defaults.sh +++ b/package/base-files/files/lib/functions/uci-defaults.sh @@ -71,6 +71,12 @@ ucidef_set_interface_lan() { json_select .. } +ucidef_set_interface_dmz() { + json_select_object network + _ucidef_set_interface dmz "$@" + json_select .. +} + ucidef_set_interface_wan() { json_select_object network _ucidef_set_interface wan "$@" diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network b/target/linux/lantiq/base-files/etc/board.d/02_network index bc61a73..00279d5 100755 --- a/target/linux/lantiq/base-files/etc/board.d/02_network +++ b/target/linux/lantiq/base-files/etc/board.d/02_network @@ -15,6 +15,7 @@ annex="a" encaps="llc" payload="bridged" lan_mac="" +dmz_mac="" wan_mac="" interface_wan="" @@ -77,8 +78,10 @@ BTHOMEHUBV3A) BTHOMEHUBV5A) lan_mac=$(mtd_get_mac_binary_ubi caldata 4364) wan_mac=$(macaddr_add "$lan_mac" 1) + dmz_mac=$(macaddr_add "$wan_mac" 3) ucidef_add_switch "switch0" \ - "0:lan:3" "1:lan:4" "2:lan:2" "4:lan:1" "6t@eth0" + "0:lan:3" "1:lan:4" "2:lan:2" "4:lan:1" "5:dmz" "6t@eth0" + ucidef_set_interface_dmz "eth0.2" ;; DGN3500*) @@ -180,6 +183,7 @@ ucidef_set_interface_wan "$interface_wan" "pppoe" [ -n "$lan_mac" ] && ucidef_set_interface_macaddr "lan" "$lan_mac" [ -n "$wan_mac" ] && ucidef_set_interface_macaddr "wan" "$wan_mac" +[ -n "$dmz_mac" ] && ucidef_set_interface_macaddr "dmz" "$dmz_mac" board_config_flush diff --git a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts index 7f19e52..59b6cee 100644 --- a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts +++ b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts @@ -244,15 +244,6 @@ phy-mode = "gmii"; phy-handle = <&phy13>; }; - }; - - wan: interface@1 { - compatible = "lantiq,xrx200-pdi"; - #address-cells = <1>; - #size-cells = <0>; - reg = <1>; - lantiq,wan; - ethernet@5 { compatible = "lantiq,xrx200-pdi-port"; reg = <5>;
This proposed patch applies to BT Home Hub 5 Type A and: 1) it includes configuration for the Red Ethernet port as an additional "dmz" interface (feature request FS#490) 2) it fixes FS#390 providing the ability to associate port 5 to the main switch VLAN. Signed-off-by: Mauro Mozzarelli <openwrt@ezplanet.net> ---