Bug 10348 - Device name set to null when renew fails
Summary: Device name set to null when renew fails
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: pump (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-03-26 01:03 UTC by Olivier Baudron
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-02 23:44:57 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)
fix pb with pump if renewal server is unreachable (428 bytes, patch)
2000-08-02 23:44 UTC, Olivier Baudron
no flags Details | Diff

Description Olivier Baudron 2000-03-26 01:03:54 UTC
I use pump-0.7.8-1 and my ISP is Cybercable (www.cybercable.fr).
When connecting to my ISP, the boot server address I obtain for renewal is
buggy, and does not respond to ping. This problem is known for years, and
lots of subscribers complained to Cybercable ...with no success.
It results that renew fails and pump dies:

pumpd[11798]: failed to renew lease for device eth0
modprobe: can't locate module
pumpd[11798]: terminating as there are no more devices under management

I had a look in the sources and can explain why modprobe outputs an error
message:

1. In pump.c after renew failed, line 333 is executed:
        if (pumpDhcpRun(intf[closest].device, 0,
              intf[closest].reqLease,
              intf[closest].set & PUMP_NETINFO_HAS_HOSTNAME
                ? intf[closest].hostname : NULL,
              intf + closest, o)) {

2. In dhcp.c, line 1102, in pumpDhcpRun, it reads:
        memset(intf, 0, sizeof(*intf));
        strcpy(intf->device, device);
The bug is here: when the structure 'intf' is set to null, the string
'device' is erased because it is a pointer to a string inside the structure
'intf'. Therefore, intf->device is always set to NULL.

It results that a few lines later, line 1122:
    } else if ((chptr = pumpPrepareInterface(intf, s))) {
Then, line 295, in procedure pumpPrepareInterface:
    if (ioctl(s, SIOCSIFADDR, &req))
causes the module error because req.ifr_name is set to intf->device which
is null.

It should be easy to fix, I think;)

Comment 1 Olivier Baudron 2000-03-26 08:29:59 UTC
This patch fixed the bug:

--- pump-0.7.8/dhcp.c   Tue Feb 15 21:59:11 2000
+++ pump-0.7.8-fixed/dhcp.c     Sun Mar 26 03:58:20 2000
@@ -1085,6 +1085,7 @@
 char * pumpDhcpRun(char * device, int flags, int reqLease,
                   char * reqHostname, struct pumpNetIntf * intf,
                   struct pumpOverrideInfo * override) {
+    char device_save[10];
     int s, i;
     struct sockaddr_in serverAddr;
     struct sockaddr_in clientAddr;
@@ -1099,8 +1100,9 @@
     int numOptions;
     short aShort;

+    strcpy(device_save, device);
     memset(intf, 0, sizeof(*intf));
-    strcpy(intf->device, device);
+    strcpy(intf->device, device_save);
     intf->reqLease = reqLease;
     intf->set |= PUMP_INTFINFO_HAS_REQLEASE;

Comment 2 Olivier Baudron 2000-03-26 23:53:59 UTC
In my first report, it should read:
intf->device points to an empty string
instead of:
intf->device is NULL.

Comment 3 Olivier Baudron 2000-08-02 13:23:09 UTC
The problem persists with pump-0.7.11-2
At last, my ISP fixed his renewal buggy address, so I tried the following:
#~ pump -l 1
then I pulled the ethernet cable two minutes before renewal.
In the log, pump output the same error message telling that it did not find the
empty module '.o'
It seems that the code changed quite a lot between 0.7.8-1 and 0.7.11-2, so I
cannot propose a patch for now...

Comment 4 Olivier Baudron 2000-08-02 23:44:56 UTC
Created attachment 1874 [details]
fix pb with pump if renewal server is unreachable

Comment 5 Erik Troan 2000-08-04 15:07:23 UTC
Applied, thanks!


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