Serge Dubrouski wrote: > On 8/23/06, Andrew Beekhof <[EMAIL PROTECTED]> wrote: >> On 8/23/06, Serge Dubrouski <[EMAIL PROTECTED]> wrote: >> > You are wrong. If you take a look at IPAddr from 2.0.7 you can seet >> this code: >> > >> > IFCMD="$FINDIF $ipaddr/$netmask_bits/$iface_base/$broadcast" >> > NICINFO=`$IFCMD` >> > >> > rc=$? >> > if [ $? -eq 0 ]; then >> > netmask_text=`echo "$NICINFO" | cut -f2` >> > broadcast=`echo "$NICINFO" | cut -f3` >> > .................................... >> > >> > *) >> > CMD="$IFCONFIG $iface $ipaddr $netmask_text $broadcast" >> > ;; >> > >> > >> > It does not exist in the current CVS version. And script doesn't work >> > correctly because ifconfig under Linux wants regular netmask not cidr. >> >> Does every OS support the "regular" netmask? > > I don't know. Probably BSD doesn't. But Linux goes unders that * and > it requires "regular".
All OSes require regular netmasks with findif. I wrote IPaddr you see, so I have a good perspective on it. It has always been documented to use the $FINDIF translates the netmask into old fashioned 255.255.xxx notation. (I wrote findif) Let me double check that it still works, and no one buggered it up. We'll here are the comments from findif: * Our single argument is of the form: * address[/netmask[/interface][/broadcast]] * * So, the following forms are legal: * address * address/netmask * address/netmask/broadcast * address/netmask/interface * address/netmask/interface/broadcast * * E.g. * 135.9.216.100 * 135.9.216.100/24 Implies a 255.255.255.0 netmask * 135.9.216.100/24/255.255.255.0/135.9.216.255 * 135.9.216.100/24/255.255.255.0/eth0 * 135.9.216.100/24/255.255.255.0/eth0/135.9.216.255 * * * If the CIDR netmask is omitted, we choose the netmask associated with * the route we selected. * * If the broadcast address was omitted, we assume the highest address * in the subnet. * * If the interface is omitted, we choose the interface associated with * the route we selected. * * * See http://www.doom.net/docs/netmask.html for a table explaining * CIDR address format and their relationship to life, the universe * and everything. */ Same comments in the code from when I first wrote it. So the findif code CLEARLY requires a CIDR netmask -- according to it's documentation. Let's see if the code still matches it... Here's the code for outputting the netmask: best_netmask = htonl(best_netmask); if (!OutputInCIDR) { printf("%s\tnetmask %d.%d.%d.%d\tbroadcast %s\n" , best_if , (int)((best_netmask>>24) & 0xff) , (int)((best_netmask>>16) & 0xff) , (int)((best_netmask>>8) & 0xff) , (int)(best_netmask & 0xff) , bcast_arg); }else{ printf("%s\tnetmask %d\tbroadcast %s\n" , best_if , netmask_bits(best_netmask) , bcast_arg); } So, unless the flag OutputInCIDR is included, the output from findif should come out in old-style format. Let's see if that's true in practice... /usr/lib64/heartbeat/findif version 1.2.5 Copyright Alan Robertson Usage: /usr/lib64/heartbeat/findif address[/netmask[/interface][/broadcast]] Where: address: IP address of the new virtual interface netmask: CIDR netmask of the network that address belongs to interface: interface to add the virtual interface to broadcast: broadcast address of the network that address belongs to Options: -C: Output netmask as the number of bits rather than as 4 octets. So, when we run findif without any arguments, it gives us a nice help message. It only mentions CIDR as the input format. So, let's see what happens when we run it... $ /usr/lib64/heartbeat/findif 10.10.10.101 eth1 netmask 255.255.255.0 broadcast 10.10.10.255 $ /usr/lib64/heartbeat/findif 10.10.10.101/22 eth1 netmask 255.255.252.0 broadcast 10.10.11.255 So, when given CIDR input, it gives old style netmask output - just like the documentation and the code both say. If invoked with the -C flag, it outputs CIDR format. $ /usr/lib64/heartbeat/findif -C 10.10.10.101/22 eth1 netmask 22 broadcast 10.10.11.255 Let's see what happens when we run IPaddr itself... # OCF_RESKEY_ip=10.10.10.199 OCF_RESKEY_cidr_netmask=22 ./IPaddr start 2006/08/24_06:58:55 INFO: eval /sbin/ifconfig eth1:0 10.10.10.199 netmask 255.255.252.0 broadcast 10.10.11.255 2006/08/24_06:58:55 INFO: Sending Gratuitous Arp for 10.10.10.199 on eth1:0 [eth1] 2006/08/24_06:58:55 INFO: /usr/lib64/heartbeat/send_arp -i 500 -r 10 -p /var/run/heartbeat/rsctmp/send_arp/send_arp-10.10.10.199 eth1 10.10.10.199 auto 10.10.10.199 ffffffffffff Well... It indicates that it runs the right ifconfig command -- with the right (non-cidr) netmask. But running 'eval' on it sounds broken.. - but not a problem in this context. And, the code used to explicitly say 'up'. But, the man page (for Linux) says it doesn't need 'up' - so I guess that's OK. I hope it works the same on other OSes. But, two OSes have special cases around them. And, I see how $CMD is set - there's no reason for the eval -- and I like 'up' myself ;-) Let's see what happens when we look at the ifconfig output: # ifconfig eth1:0 eth1:0 Link encap:Ethernet HWaddr 00:0F:EA:3C:45:3C inet addr:10.10.10.199 Bcast:10.10.11.255 Mask:255.255.252.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:193 Base address:0xe800 This is correct. I added a set -x into the code JUST TO MAKE SURE the eval didn't somehow do the wrong thing: + eval /sbin/ifconfig eth1:0 10.10.10.199 netmask 255.255.252.0 broadcast 10.10.11.255 ++ /sbin/ifconfig eth1:0 10.10.10.199 netmask 255.255.252.0 broadcast 10.10.11.255 + set +x I think the guy who translated this didn't know shell. I know of no reason at all to add the eval -- which is potentially very dangerous. So, I removed it and added the 'up' in my test copy just to make sure... # OCF_RESKEY_ip=10.10.10.199 OCF_RESKEY_cidr_netmask=22 ./IPaddr start 2006/08/24_07:07:06 INFO: /sbin/ifconfig eth1:0 10.10.10.199 netmask 255.255.252.0 broadcast 10.10.11.255 up + /sbin/ifconfig eth1:0 10.10.10.199 netmask 255.255.252.0 broadcast 10.10.11.255 up + set +x 2006/08/24_07:07:06 INFO: Sending Gratuitous Arp for 10.10.10.199 on eth1:0 [eth1] 2006/08/24_07:07:06 INFO: /usr/lib64/heartbeat/send_arp -i 500 -r 10 -p /var/run/heartbeat/rsctmp/send_arp/send_arp-10.10.10.199 eth1 10.10.10.199 auto 10.10.10.199 ffffffffffff And, it works the same as it did before. Double checking... # ifconfig eth1:0 eth1:0 Link encap:Ethernet HWaddr 00:0F:EA:3C:45:3C inet addr:10.10.10.199 Bcast:10.10.11.255 Mask:255.255.252.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:193 Base address:0xe800 So... I don't see any problem here. At all. Serge... Exactly what did you see in your tests? -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
