Brian J. Murrell wrote: Hey you updated the /sbin/dhclient-script in 1999.
> On Tue, 2008-02-12 at 19:29 -0600, Jerry Vonau wrote: >> My what you miss when your sleeping... >> >> If your talking init scripts here, right? > > Well, initscripts in terms of any > of /etc/init.d, /sbin/dhclient-script /etc/ppp/ip-up[.d] and so forth, > yes. > >> The issues I found with >> dealing with iproute2, is that the packages that deal with >> obtaining/creating an ip address only assume the main routing table >> should be used. > > _Exactly!_ Even routing protocols like quagga only deal with the single > main routing table -- AFAIK. > pppd is easy enough to fix with the ip-up.local file. /sbin/dhclient-script is fixable, then comes the rest of the network functions. What really is needed is some convention regarding table names, you can use whatever you want in rt_tables, hence the suggestion below. Once that is in place, at least porting the rest of the scripts won't be as bad, you'll know in advance what the advanced table name should be. >> While what we really want here, I think, is one table >> per ip, > > IP or interface? > >> maybe one per net route with secondary ips using src. Much like >> what a table looks like with what shorewall generates without an entry >> in the copy column for a provider, just the ip specific routing. Not interface, you could have more that one network per interface. Need to play around a bit, not sure if that should be one per ip or per network gateway. >> Then >> the other issue becomes /etc/iproute2 data, what should the table names >> be? Tom's manipulation of rt_tables could be used to set the table's >> name based on the interface name, and the related route rule code use to >> create the routing rule. >> Thus, to look up a route it would be: ip route ls table ppp0, >> ip route ls table tun0, ip route ls table eth0 etc... > > Hrmmmm. > >> I'm I on track here or way off base? > > I'm not sure. I'd have to flesh out an example or see an example to > know for sure. > Quick test, use the interface name as the ISP name in the providers file. I'd be looking to handle the rt_tables/rules in the same way that the providers' functions do, just a different sourcing for the names. >> To change the networking scripts would be a major under taking here, >> and maintaining patches until upstream came on board would be a >> headache, > > Agreed. > >> I gave up with the little bit I came up with for multi-dhcp >> provider support for fedora. Maybe, I'm up for it now, if there is >> others who are interested, otherwise I'm not going to bother trying to >> change the world. > > It seems to me that what we really want is configurable route > manipulation. Something like a set of rules and filters between "route > add" (and quagga and whatever else will want to manipulate routing) and > the final routing manipulation. The idea would be a process that > receives input in the form of a userspace routing request (source, dest, > interface, etc.) that goes through user configurable filters and rules > before it is finally inserted (or deleted or replaced as the case may > be) into one or more routing tables. > > Or am I way off base? > I think that is a stop gap hack, another file to edit... I believe that the correct way would be to create the routing table/rules when the interface is created, then port whatever else your using to change the routing to use the advanced tables. See what I mean about changing the world. That might be a very big task at first or it might be just a few lines here and there, but the rewards might be worth it . Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
