Bug 67626 - "service netdump start" works only on eth0
Summary: "service netdump start" works only on eth0
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: netdump (Show other bugs)
(Show other bugs)
Version: 2.1
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Dave Anderson
QA Contact:
URL:
Whiteboard:
Keywords:
: 73629 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-28 14:20 UTC by Johan Walles
Modified: 2007-11-30 22:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-16 21:34:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2002:201 normal SHIPPED_LIVE Updated netdump package available 2002-09-12 04:00:00 UTC

Description Johan Walles 2002-06-28 14:20:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412
Debian/0.9.9-6

Description of problem:
Trying to start the netdump client on a machine that has eth2 configured but not
eth0 fails.

Version-Release number of selected component (if applicable):
0.6.6-1

How reproducible:
Always

Steps to Reproduce:
1. Install RHAS21 on a machine with several network cards
2. Configure eth2 only
3. "service netdump start"



Actual Results:  : cannot arp 172.22.48.89
/etc/init.d/netdump: Usage:: command not found
/etc/init.d/netdump: propagate}: command not found
/etc/init.d/netdump: line 4: 15602 Broken pipe             initlog $INITLOG_ARGS
-c "$*"
/etc/init.d/netdump: line 4: 15605 Broken pipe             initlog $INITLOG_ARGS
-c "$*"
:  must be an ethernet interface
Usage: service netdump {start|stop|status|restart|condrestart|propagate}
initializing netdump /lib/modules/2.4.9-e.3smp/kernel/drivers/net/netconsole.o:
invalid argument syntax for netdump_target_eth_byte0: 'x'
/lib/modules/2.4.9-e.3smp/kernel/drivers/net/netconsole.o: insmod
/lib/modules/2.4.9-e.3smp/kernel/drivers/net/netconsole.o failed
/lib/modules/2.4.9-e.3smp/kernel/drivers/net/netconsole.o: insmod netconsole failed
                                                           [FAILED]


Expected Results:  The netdump client should have started, prepared for dumping
on eth2.

Additional info:

The network interface to dump on should be configurable in /etc/sysconfig/netdump.

Comment 1 Michael K. Johnson 2002-07-12 14:00:35 UTC
Dave, can you look into this?

Comment 2 Dave Anderson 2002-07-12 16:24:12 UTC
> Actual Results:  : cannot arp 172.22.48.89

The error sequence is caused by the arping command in the netdump script:

    # fill the arp cache with needed data
    arping -c 1 $1 > /dev/null 2>&1
    [ $? -ne 0 ] && echo "$prog: cannot arp $1" 1>&2 && usage

What happens if you enter "arping -c 1 172.22.48.89" on a command line?


Comment 3 Johan Walles 2002-07-15 06:23:17 UTC
[root@borg root]# arping  -c 1 172.22.48.89
Interface "eth0" is down

[root@borg root]# ifconfig 
eth2      Link encap:Ethernet  HWaddr 00:06:5B:3D:E5:58  
          inet addr:172.22.48.108  Bcast:172.22.48.255  Mask:255.255.255.0
          UP BROADCAST NOTRAILERS RUNNING  MTU:1500  Metric:1
          RX packets:6053191 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6103716 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2058350921 (1962.9 Mb)  TX bytes:2149915367 (2050.3 Mb)
          Interrupt:16 Base address:0x4000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1172727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1172727 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:279730513 (266.7 Mb)  TX bytes:279730513 (266.7 Mb)

[root@borg root]# arping -I eth2 -c 1 172.22.48.89
ARPING 172.22.48.89 from 172.22.48.108 eth2
Unicast reply from 172.22.48.89 [00:02:55:AC:05:74]  0.726ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

[root@borg root]# rpm -qf `which arping`
iputils-20001110-6

Thus, a simple workaround (that I've applied) is to hard code -I eth2 into
/etc/init.d/netdump.  It works, but is of course not a long term solution.

Comment 4 Dave Anderson 2002-07-15 13:16:14 UTC
> The network interface to dump on should be configurable in
> /etc/sysconfig/netdump.

Thanks -- that's the intent of the DEV= line in /etc/sysconfig/netdump,
but unfortunately it's ignored by the arping command.

Just for sanity's sake, could you verify that this works:

 1. Set "DEV=eth2" in /etc/sysconfig/netdump
 2. Set "DEV=eth0" in /etc/rc.d/init.d/netdump (as the default that will
    get overwritten by "eth2")
 3. Change your workaround line to: arping -c 1 -I $DEV $1 > /dev/null 2>&1 

Thanks very much.


Comment 5 Johan Walles 2002-07-15 13:43:11 UTC
Yup, that seems to work.


Comment 6 Dave Anderson 2002-08-07 19:25:39 UTC
Reminder: this patch has been checked into base; needs to be part of AS errata.

--- netdump/netdump.init.orig   Mon Jul 15 11:24:35 2002
+++ netdump/netdump.init        Mon Jul 15 11:24:55 2002
@@ -28,7 +28,7 @@

 # Default values
 LOCALPORT=6666
-DEV=
+DEV=eth0
 NETDUMPADDR=
 NETDUMPMACADDR=
 NETDUMPPORT=6666
@@ -66,7 +66,7 @@
     local host=$1
     local oldIFS arp_output line

-    arping -c 1 $host &> /dev/null
+    arping -c 1 -I $DEV $host &> /dev/null
     [ $? -ne 0 ] && echo "$prog: cannot arp $host" 1>&2 && usage

     # output from arp -a of the form:

Comment 7 Suhua Ding 2002-09-19 09:53:35 UTC
*** Bug 73629 has been marked as a duplicate of this bug. ***

Comment 8 Nick Strugnell 2003-05-29 10:43:59 UTC
Another workaround is simply to comment out the line: 
[ $? -ne 0 ] && echo "$prog: cannot arp $host" 1>&2 && usage 
 

Comment 10 Jeff Needle 2003-11-24 21:15:01 UTC
This will be addressed in the 0.6.11-1 release in Update 3.


Note You need to log in before you can comment on or make changes to this bug.