Wednesday 05 May 2010 22:38:03 Bernhard Loos wrote: > Hello > I'm sorry nobody answered you until know.
Hi, I'm glad I can finally hear from someone on this subject. > I talked with jow about it > and part of the reson is, that this is a pretty complicated problem > and your patch solves this only partially. Yes, only pppoe over dhcp or static is fully addressed and tested. > <xMff> rtz2: actually I think the multi config thing could actually > work, even for ppp* as long as you have multiple deidcated config > interface sections sharing physical devices > <xMff> it would also fit into the current uci schema and be supported > ootb by both x-wrt and luci > <xMff> actually the only missing bit is some kind of dependency > specification <xMff> to define some bringup order for the protocols > <xMff> one of the most prominent use cases is pptp over something > <xMff> e.g. pptp over pppoe In fact, I never thought of one ppp over another as a possible case. It really sounds complicated, since a dynamically created pppN, not an interface of a known name, should be used as a base here. Indeed, my implementation may not address this case, when the base is already ppp provided. > <xMff> with the current approach both ppp instances would be launched > simultanously which could lead to race conditions (esp. when both > compete for the defaultroute or dns entries) This sounds like a more general problem. Couldn't a similiar race condition already occure in case of pptp over eth0.1 + pppoe over eth0.2, for example? This problem doesn't seem my patches tied. > <xMff> also certain combinations are undefined, e.g. what happens with > static + dhcp, static + static and so on > <xMff> most protocol backends assume that they're the sole owner of a > physical device, so they would end up overwriting each others settings What we have now is that these certain combinations may give unpredictable results and can be assumed illegal as such. If you define static + dhcp or static + static over the same iface, the first one, in the config file order, wins. With my proposed multi config support, the last one would win. Is it really a difference? I think it could be enough, if really necessary, to provide a machanism that would prevent users from specifying two or more conflicting configurations over one interface. Maybe teaching luci to hide interfaces already occupied by a conflicting configuration from a selection list could do the job. A demand for this, as a configuration error prevention mechanism, seems equal whether a multi config support is implemented or not. > <xMff> and handling multiple ips on one interface is a pite with ifconfig > <xMff> iproute2 would work better but it adds quite some code to the base > system <xMff> while ifconfig and route come for free > <xMff> almost that is > <xMff> so in order to implement this properly, almost all protocol > backends need to be changed, the uci firewall needs adaption to work > with real aliases (not only rely on -i and -o but use -s and -d to > specify subnets on top of a interface carrying multiple protocols) and > possibly others I overlooked yet > <xMff> it boils down to a larger rewrite operation :) It looks like a "multiple virtual interfaces / configs / firewall zones over one IP interface" concept, not what I should probably better name as a "one or more IP interfaces encapsulated over a base one that has its own IP setup", is what you are talking about here. I'm far from being an expert on the OpenWRT way of doing things, but it seems to me that simply providing a means of assigning an interface configuration like name to an already implemented IP alias subconfig, or assigning aliases to different zones, could be much simpler than trying to modify existing scripts for handling several static + optional dhcp or more advanvced over one interface as separate interface configurations. That would probably have nothing to do with my proposed support for encapsulated interfaces over static / dhcp. Similiar extra support in firewall would be required anyway, whether extended aliases or separate configs way. This support also seems not related to encapsulated over static / dhcp. What is still missing from my implementation is pptp integration. What I can think of is setting up its base interface with ipproto=none. Than, maybe it would be possible to handle it in a pppoe similiar way. > But he does have plans to fix this properly. If you think I could help, please let me know. Thanks, Janusz > > Bernhard > > 2010/5/4 Janusz Krzysztofik <[email protected]>: > > Hi, > > > > Any chances for this set of patches being either accepted, or rejected, > > or changes requested, not just postponed silently? > > > > Thanks, > > Janusz > > > > > > ---------- Original message ---------- > > > > Subject: [PATCH] Add base support for multiple configs over one network > > interface Date: 2010-03-17 > > From: Janusz Krzysztofik <[email protected]> > > To: OpenWrt Development List <[email protected]> > > > > This patch modifies /etc/hotplug.d/net/10-net:addif() function in a way > > that allows for automatic startup of all network interface configs that > > match the just hot/cold-plugged interface name, not only the first one > > found. For that, it makes use of a new function, > > /lib/network/config.sh:find_configs() provided by my preceding patch, > > "Provide a helper function that gives a list of all configs matching a > > network interface"[1] > > > > For multiple configs over one interface working correctly, other patches > > may be required as well. One working example is my prevois patch, "Allow > > for PPPoE over LAN"[2]. > > > > Depends on patch [1]. > > Created and tested against openwrt svn revision 20252. > > > > [1] > > https://lists.openwrt.org/pipermail/openwrt-devel/2010-March/006340.html > > [2] > > https://lists.openwrt.org/pipermail/openwrt-devel/2010-March/006316.html > > > > Signed-off-by: Janusz Krzysztofik <[email protected]> > > --- > > --- trunk/package/base-files/files/etc/hotplug.d/net/10-net.orig > > 2010-03-11 23:45:25.000000000 +0100 +++ > > trunk/package/base-files/files/etc/hotplug.d/net/10-net 2010-03-17 > > 14:27:47.000000000 +0100 @@ -15,13 +15,16 @@ addif() { > > esac > > > > scan_interfaces > > - local cfg="$(find_config "$INTERFACE")" > > + local cfgs="$(find_configs "$INTERFACE")" > > > > - # check the autoload setting > > - config_get auto "$cfg" auto > > - case "$auto" in > > - 1|on|enabled) setup_interface "$INTERFACE";; > > - esac > > + local cfg > > + for cfg in $cfgs; do > > + # check the autoload setting > > + config_get auto "$cfg" auto > > + case "$auto" in > > + 1|on|enabled) setup_interface "$INTERFACE" > > "$cfg";; + esac > > + done > > > > > > # find all vlan configurations for this interface and set them up > > as well > > > > ------------------------------------------------------- > > _______________________________________________ > > openwrt-devel mailing list > > [email protected] > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
