Bug 7646 - RP3 dials wrong configuration when using clones
Summary: RP3 dials wrong configuration when using clones
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rp3
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-12-07 03:31 UTC by Adam Jenkins
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-12-14 01:47:23 UTC

Attachments (Terms of Use)

Description Adam Jenkins 1999-12-07 03:31:58 UTC
I recently upgraded to Redhat 6.1.  I have rp3-1.0.1-1 installed.  I
already had two ppp connections configured with the old netcfg program.
They are ppp0-netway and ppp0-javanet.  When I use rp3, it presents me with
a menu of ppp0, ppp0-netway, and ppp0-javanet.  If I select either
ppp0-netway or ppp0-javanet, instead it always tries to start ppp0.  Since
I don't have ppp0 configured to dial anything, this fails.  It seems that
rp3 doesn't support clone interfaces correctly.

Also, if I run rp3-config, if I run it as non-root, it asks for the root
password, and then once I enter the password, the password windows
disappears and nothing else happens.  If I start rp3-config as root, it
crashes with a segmentation fault.

Comment 1 Michael K. Johnson 1999-12-07 15:36:59 UTC
Please try the test release at

If that doesn't work, please do
  gdb /usr/sbin/rp3-config
and provide the output here for me to examine, so that I can fix
it in an upcoming version.


Comment 2 Michael K. Johnson 1999-12-07 15:37:59 UTC
Sorry, I should have pointed out that my upgrade comment was directed
explicitly at the crashing part.  I'll be investigating the clone part

Comment 3 Michael K. Johnson 1999-12-07 15:51:59 UTC
Regarding ignoring clones, you are exactly right; it was trivially
obvious when I looked at the code.  Sorry about that..  I've fixed
this in the current development sources, so it should be fixed in
the final release.

(I'm starting to wonder if my invention of the "clone device" concept
was so bright, if even I can't keep it straight, not to mention that
this is the first report that indicates that anyone is using them with
rp3, and you were also the first to report the clone problems with the
new initscripts.)

Comment 4 Adam Jenkins 1999-12-07 18:59:59 UTC
I can't be the only one who has more than one ISP that they dial into.  I'd have
no problem with you getting rid of the clone concept as long as you provide some
other way to have multiple dialup configurations.

I noticed that the linuxconf interface for net configuration doesn't even give
me the option of clone interfaces, so that's probably why you're not seeing
reports about them.  People who have more than one ISP probably just reconfigure
their ppp0 configuration when they need to dial into another ISP, because they
don't even know about clones.

Comment 5 Michael K. Johnson 1999-12-07 19:26:59 UTC
Frankly, clone devices are not designed for multiple ISPs.  They are
designed for things like dialing into the same ISP via different
POPs, or from home/work/hotel, things like that.

For completely different setups, there's no reason not to simply set
up ppp0 and ppp1 completely separately.  That's certainly what I do
for testing this -- ppp0 is, say, mindspring, ppp1 might be uunet,

I doubt that we'll get rid of clone devices, I was just randomly
wondering if it was a useful concept in the first place.

In any case, the next version of rp3 will get this right, and if
you will send in the stack trace for your crash, there's a reasonable
chance that I'll be able to fix that, too.

Comment 6 Adam Jenkins 1999-12-07 20:05:59 UTC
rp3 1.0.2 still crashes.  Here's the requested backtrace.  It's crashing in
free(), I would guess because you're passing something to free() that's already
freed.  You can see below that it's calling free(s->fileName), but s->fileName
points to garbage, indicating that it's already been freed, or was never

Also, I had to get the source rpm and compile it, because the binary rpm
installed stripped binaries with no debug symbols.

(gdb) r
Starting program: /usr/src/redhat/BUILD/rp3-1.0.2/rp3-config/rp3-config

Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x3f000000, p=0x404ef098) at malloc.c:2985
2985	malloc.c: No such file or directory.
Current language:  auto; currently c
(gdb) bt
#0  chunk_free (ar_ptr=0x3f000000, p=0x404ef098) at malloc.c:2985
#1  0x4045ad75 in __libc_free (mem=0x404ef0a0) at malloc.c:2959
#2  0x807a5b1 in svCloseFile (s=0x80dbed8) at shvar.c:371
#3  0x807a851 in interface_shvarfiles_close (ifcfg=0x80dbed8) at interface.c:86
#4  0x807afb0 in interface_free (i=0x80dfff8) at interface.c:371
#5  0x80541a8 in load_accounts () at account.cc:473
#6  0x805ec5e in rp3_mainwin_new () at mainwin.cc:518
#7  0x80663f5 in main (argc=1, argv=0xbffffd24) at main.cc:149
(gdb) up 2
#2  0x807a5b1 in svCloseFile (s=0x80dbed8) at shvar.c:371
371	    free(s->fileName);
(gdb) p s->fileName
$1 = 0x404ef0a0

Comment 7 Michael K. Johnson 1999-12-08 16:36:59 UTC
Aha, that was a double-free in rp3-config that got fixed about a week
ago.  Closing in on time for a new test release -- I have meant to in
the past, but keep waiting because there always seems to be one more
pending bug report to fix...

Thanks for the backtrace.  BTW, the symbols available in the installed
binary should be good enough for most things -- I can normally puzzle
it out as-is.  However, the extra information sure helps make it easier,
so thanks for rebuilding.

Comment 8 Adam Jenkins 1999-12-08 17:40:59 UTC
> BTW, the symbols available in the installed
> binary should be good enough for most things

Not in this case.  Here's what gdb tells me with the version of rp3-config that
the rpm installs:

gdb) r
Starting program: /usr/bin/rp3-config
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program exited normally.
(gdb) bt
No stack.

Note that the program didn't really exit normally.  It popped up the window
saying that the application had died with a segmentation fault.  It seems that
gdb isn't even catching the signal in this case; it's being caught by the GNOME
signal handler.  With the debug version, gdb catches the signal instead.  I
don't know why that is.

Comment 9 Michael K. Johnson 1999-12-08 18:33:59 UTC
Re-read what I wrote above -- you didn't *quite* do what I asked:
  gdb /usr/sbin/rp3-config
Note the "s" in sbin.  :-)

/usr/bin/rp3-config is a pointer to a setuid wrapper that eventually
calls /usr/sbin/rp3-config after checking your password.
  ls -l /usr/bin/rp3-config
  ls -l /usr/sbin/rp3-config

------- Email From  "Adam P. Jenkins" <adampjenkins> 12/08/99 15:08 -------
Attached to Bug # 7646.

Comment 10 Michael K. Johnson 1999-12-09 00:38:59 UTC
>For instance I have /usr/sbin/ in my
>path in my user account, because I use usernetctl to bring up my network
>interfaces (I'll stop once rp3 works correctly :-).  Luckily I added
>/usr/sbin to the *end* of my path so I still get the correct version of

Don't use usernetctl -- it's only intended as a wrapper.  Just do
ifup ppp0
(or whatever) as a normal user, and usernetctl will be used behind your
back to make everything work.

I made the mistake in the past of not explicitly saying that usernetctl
was a wrapper in its man page, and so lots of people type this long
"usernetctl" thing instead of just using ifup, which is shorter and is
in everyone's path.

Users with *sbin* in their paths (*'s as globs, not emphasis) should
have it at the end of their path, as you do.

  man userhelper
  man consolehelper
to understand why we did that this way.  It was precisely to make things
work transparently for normal users.

Users who know how to get sbin into their path can probably figure
out what is happening here.  That's the tradeoff.

In any case, I've now released rp3-1.0.3 as a test release, so feel
free to test it.

Comment 11 Adam Jenkins 1999-12-09 22:57:59 UTC
> I made the mistake in the past of not explicitly saying that usernetctl
> was a wrapper in its man page, and so lots of people type this long
> "usernetctl" thing instead of just using ifup, which is shorter and is
> in everyone's path.

ifup is not in my path, unless I add /sbin to my path.  I don't think it's any
more common or likely for users to have /sbin in their path than /usr/sbin.  But
thanks for the clarification about using ifup instead of usernetctl.  In any
case though, I was just using usernetctl as an example of a program in /usr/sbin
that a user might want to use.  Other examples might be sendfax or pppstats.
The point was that it seems unwise and fragile to have two different programs,
one in /usr/bin and one in /usr/sbin, with the same name, and to depend on users
knowing not to prepend /usr/sbin to their path for the right version to get

Comment 12 Nalin Dahyabhai 2000-02-07 19:52:59 UTC
I take it that the newer version of rp3 from Raw Hide works correctly for you?

Assuming that the user won't have /usr/sbin in her path is probably not a great
idea, but unless I can figure out a better (and backward-compatible) way to
gate access to programs that need root privileges, it'll probably stay that way.

However, it might be worth looking into to see if /usr/sbin/rp3 could exec
/usr/bin/rp3 if it detects that it isn't being run as the root user....

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