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.
Please try the test release at ftp://people.redhat.com/johnsonm/rp3/rp3-1.0.2-1.i386.rpm If that doesn't work, please do su gdb /usr/sbin/rp3-config r bt and provide the output here for me to examine, so that I can fix it in an upcoming version. Thanks.
Sorry, I should have pointed out that my upgrade comment was directed explicitly at the crashing part. I'll be investigating the clone part separately.
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.)
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.
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, etc. 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.
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 allocated. 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 "\230pN@\230pN@P>\r\bP>\r\b(pN@(pN@0pN@0pN@8pN@8pN@@pN@@pN@HpN@HpN@PpN@PpN@XpN@XpN@`pN@`pN@hpN@hpN@ppN@ppN@xpN@xpN@" (gdb)
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.
> 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. (gdb) 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.
Re-read what I wrote above -- you didn't *quite* do what I asked: su gdb /usr/sbin/rp3-config r bt 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.
>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 >rp3-config. 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. 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. ftp://people.redhat.com/johnsonm/rp3/rp3-1.0.3-1.i386.rpm
> 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 called.
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....