Afternoon all, I have a box with 5 NICs, which I intend to use as an external interface, and an internal and dmz interface for each of 2 companies. They are all (currently) 3c905b''s, but this could change in the future (in that I may replace 2 of them with gig cards). Anyway at boot they are apparently labeled according to the order the modules are loaded and then their order on the bus(es) (eth0, eth1... ethn). I''d like to be able to avoid a situation where a failed, removed or replaced card, modified kernel, etc. results in reordering and subsequently the wrong firewall/dhcp/etc. is running on the wrong network. I intend to do this by looking up each interface in turn in a mac->name mapping file and renaming them appropriately, before the network configuration scripts run. I believe there is a tool to do this but I can''t find it and can''t remember its name. I wonder how one would go about adding this functionality to shorewall? You can use fairly arbitrary names for the devices too, so you could potentially use the zone names (ie aos-dmz instead of eth4), for risk of upsetting some broken software which makes assumptions about zone names. I believe the command to do so is ''ip link dev eth0 name aos-dmz''. Anyway I think this would be a really handy feature and would probably only take a few LOC. - samj -- Sam Johnston, Director Australian Online Solutions 1300 132 809
--On Sunday, December 22, 2002 01:34:23 PM +1100 Sam Johnston <samj@aos.net.au> wrote:> Afternoon all, > > I have a box with 5 NICs, which I intend to use as an external interface, > and an internal and dmz interface for each of 2 companies. They are all > (currently) 3c905b''s, but this could change in the future (in that I may > replace 2 of them with gig cards). > > Anyway at boot they are apparently labeled according to the order the > modules are loaded and then their order on the bus(es) (eth0, eth1... > ethn). I''d like to be able to avoid a situation where a failed, removed > or replaced card, modified kernel, etc. results in reordering and > subsequently the wrong firewall/dhcp/etc. is running on the wrong > network. I intend to do this by looking up each interface in turn in a > mac->name mapping file and renaming them appropriately, before the > network configuration scripts run. I believe there is a tool to do this > but I can''t find it and can''t remember its name. > > I wonder how one would go about adding this functionality to shorewall? > You can use fairly arbitrary names for the devices too, so you could > potentially use the zone names (ie aos-dmz instead of eth4), for risk of > upsetting some broken software which makes assumptions about zone names. > I believe the command to do so is ''ip link dev eth0 name aos-dmz''. Anyway > I think this would be a really handy feature and would probably only take > a few LOC. >I''ll make you a deal -- you demonstrate how few LOC it takes then I''ll merge your patch. I will never have enough spare hardware to test such a patch... -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
--On Saturday, December 21, 2002 06:49:01 PM -0800 Tom Eastep <teastep@shorewall.net> wrote:> > I''ll make you a deal -- you demonstrate how few LOC it takes then I''ll > merge your patch. I will never have enough spare hardware to test such a > patch... >Here''s some ideas based on a few minutes of experimentation: a) The device must be down before you can change its name. b) On a [re]start, the device could be up but have the wrong name. So in that case, I would think that you would ''down'' the device, change its name and up it again. I hope that all of the address information is retained during a down/up sequence; otherwise you get to capture it before the ''down'' and re-apply it in the ''up'' command. c) The correct command syntax is "ip link set <DEVICE> name <NAME>" d) I would recommend enhancing the INTERFACE column in the interfaces file to contain: <interface>[:<MAC>] When the MAC is specified, device renaming is activated. e) If no device with MAC is found, an error is generated. f) With this change, there is a nonsensical combination of column contents possible in an entry in the interfaces file; namely including a MAC and having ''detect'' in the BROADCAST column. You probably should point those out in both the ''shorewall check'' and ''shorewall [re]start'' cases. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> a) The device must be down before you can change its name. > > b) On a [re]start, the device could be up but have the wrong name. So > in that case, I would think that you would ''down'' the device, change > its name and up it again. I hope that all of the address information > is retained during a down/up sequence; otherwise you get to capture it > before the ''down'' and re-apply it in the ''up'' command.Yes, the interface needs to be down, and yes they retain the addressing information over an up/down cycle.> c) The correct command syntax is "ip link set <DEVICE> name <NAME>"Thanks.> d) I would recommend enhancing the INTERFACE column in the interfaces > file to contain: > > <interface>[:<MAC>] > > When the MAC is specified, device renaming is activated.The logic I have applied so far is ''if the interface starts with a ~, it''s a MAC address and you should use the zone name instead''. Your approach is more flexible.> e) If no device with MAC is found, an error is generated.Noted.> f) With this change, there is a nonsensical combination of column > contents possible in an entry in the interfaces file; namely including > a MAC and having ''detect'' in the BROADCAST column. You probably should > point those out in both the ''shorewall check'' and ''shorewall > [re]start'' cases.I guess the renaming of the interfaces has to occur *before* the networking scripts run in which case there will be no (or worse, incorrect) information. That said, on Debian at least, shorewall is started some time after the interfaces are configured, and indeed after many (most?) of the services have started. This sounds like a bug to me...> -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.sf.net > Washington USA \ teastep@shorewall.net >
--On Saturday, December 21, 2002 07:33:05 PM -0800 Tom Eastep <teastep@shorewall.net> wrote:> > b) On a [re]start, the device could be up but have the wrong name. So in > that case, I would think that you would ''down'' the device, change its > name and up it again. I hope that all of the address information is > retained during a down/up sequence; otherwise you get to capture it > before the ''down'' and re-apply it in the ''up'' command.I just tested -- address information isn''t retained. And another wart -- once you have renamed the device, if your distribution is RedHat then ''ifup'', ''ifdown'' and ''service network restart'' no longer work on that device. I assume that other distributions work similarly since their network scripts are keyed on the name that the device had when it was detected. Are you sure you want to do this? For your Shorewall configuration, you could use a shell variable for each interface name; when the interface names changed, you would only have to change the shell variable assignments in /etc/shorewall/params. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
--On Sunday, December 22, 2002 02:51:07 PM +1100 Sam Johnston <samj@aos.net.au> wrote:> Tom Eastep wrote: > >> a) The device must be down before you can change its name. >> >> b) On a [re]start, the device could be up but have the wrong name. So >> in that case, I would think that you would ''down'' the device, change >> its name and up it again. I hope that all of the address information >> is retained during a down/up sequence; otherwise you get to capture it >> before the ''down'' and re-apply it in the ''up'' command. > > Yes, the interface needs to be down, and yes they retain the addressing > information over an up/down cycle.But apparently not over a rename -- at least all addresses were lost in my ''rename'' experiment.> >> c) The correct command syntax is "ip link set <DEVICE> name <NAME>" > > Thanks. > >> d) I would recommend enhancing the INTERFACE column in the interfaces >> file to contain: >> >> <interface>[:<MAC>] >> >> When the MAC is specified, device renaming is activated. > > The logic I have applied so far is ''if the interface starts with a ~, > it''s a MAC address and you should use the zone name instead''. Your > approach is more flexible. > >> e) If no device with MAC is found, an error is generated. > > Noted. > >> f) With this change, there is a nonsensical combination of column >> contents possible in an entry in the interfaces file; namely including >> a MAC and having ''detect'' in the BROADCAST column. You probably should >> point those out in both the ''shorewall check'' and ''shorewall >> [re]start'' cases. > > I guess the renaming of the interfaces has to occur *before* the > networking scripts run in which case there will be no (or worse, > incorrect) information. That said, on Debian at least, shorewall is > started some time after the interfaces are configured, and indeed after > many (most?) of the services have started. This sounds like a bug to me...While there are security advantages to starting Shorewall before bringing up interfaces, none of the Shorewall features that require the interfaces to be up will work (''detect'', DETECT_DNAT_IPADDRS, etc.). I agree that starting Shorewall MUCH later than the interfaces is a bug. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
--On Saturday, December 21, 2002 07:59:03 PM -0800 Tom Eastep <teastep@shorewall.net> wrote:>> Yes, the interface needs to be down, and yes they retain the addressing >> information over an up/down cycle. > > But apparently not over a rename -- at least all addresses were lost in > my ''rename'' experiment. >Ok -- the following seems to work: [root@mail postfix]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:40:D0:07:3A:1B inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:316 errors:0 dropped:0 overruns:0 frame:0 TX packets:2587 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:44543 (43.4 Kb) TX bytes:1903985 (1.8 Mb) Interrupt:10 Base address:0x4000 [root@mail postfix]# ip link set eth1 down [root@mail postfix]# ip link set eth1 name foo up [root@mail postfix]# ifconfig foo foo Link encap:Ethernet HWaddr 00:40:D0:07:3A:1B inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:318 errors:0 dropped:0 overruns:0 frame:0 TX packets:2650 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:44663 (43.6 Kb) TX bytes:1911564 (1.8 Mb) Interrupt:10 Base address:0x4000 [root@mail postfix]# -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net