Bug 16640

This defect is considered MUST-FIX for Winston Gold release

Please try rp3-1.1.3-4 and wvdial-1.4.1-10 from
http://people.redhat.com/nalin/test/ and see if they fix this.  Thanks!

Hans, we're running out of time and this is a must-fix bug.  Do the packages
Nalin mentions fix it?

Glen, tests I've run show that the information is properly saved before pppd
starts, even though the test accounts I'm using are plaintext logins.  I don't
see a reason why it wouldn't fix the problem for PAP users.

I don't know I'm currently not at a computer where I can test this I'll test it tomorrow morning CET (in about 8 hours from entering this)

Okay, I've been testing this and it is not fixed in all cases:
Passing the username and passwd to pppd from wvdial works fine for manually
started and stopped connections, but doesn't work for on demand connections
since it is pppd which starts wvdial there, not vica versa.

I'm also hitting other bugs while testing this so expect more bug reports :(

Please give 1.1.4-1 (also in http://people.redhat.com/nalin/test/) a shot.  The
rp3-config tool now saves the PAP setup information instead of waiting for
wvdial to do it.

Yes that fixes it, but during testing I had three other problems:

1) This time I lett rp3 autoconfig my modem, it said the modem <-> rs232
interface could do 115200, since this is an 16450 uart, it couldn't leading to
lost bits left and right, resulting in the link not coming up, this is not good!

I think it should default to 56700, since anything newer then an i386sx should
be able to handle that.


2) I already had this before, but I dunno if I should report it, since I'm using
a free and very buggy isp:

When I use on demand dialing (nice btw) then the first then I do, for example a
telnet or ping to some existing remote machine results in: Host name lookup
failure.

Doing it again after the connection has come up works fine, as said this might
very well be my isp, this is with ppp asigned DNS btw. I've registered for
another ISP, but that takes a week :(


3) Im pretty confident this is my isp, when I do a manual(not on demand)
connection pppd exits with as error: "couldn't determine remote ip", it doesn't
seem to get a remote ip either with on demand, but then it just leaves it at
10.64.64.64.

I can fix this by adding REMIP=10.64.64.64 to the ifcfg-pppX file. This is no
problem, but this does result in my finding a small bug and an RFE for
rp3-config.

Small bug: rp3-config removes the REMIP statement from ifcfg-pppX whne you
change some other settings IMHO it should not touch vars it know nothing about.

RFE: Allow specifying a static local and/or remote ip, this is needed quite
often.



Let me know (or DIY) if any of this should become a new bug, the original bug is
fixed. 1) btw is IMHO a bug must-fix candidate

Item (1) is an effect of how the kernel configures the serial device (it
actually reports that the port can do 115200), and can be changed if we remove
that option altogether.  I'm a bit leery of doing that, however, because you can
still go in and edit the modem configuration to dial the speed down.  The new
initscripts 5.49 in http://people.redhat.com/nalin/test/ should fix item (2) by
adding the 'ktune' parameter, which toggles the net.ipv4.ip_dynaddr option on
when demand dialing is started.

I'm not seeing removal of a REMIP configuration option at all with rp3-config,
even when I toggle demand-dial and peer DNS options back and forth several times
and apply the changes.

Scratch that.  We *can* use ioctl() magic to discover what kind of chip we've
got on that port, and then make a value judgement as to its practical speed
limit, but that's more than I feel safe adding in....

Well the kernel does see the chip correctly as an 16450, so I expect that
setting the speed to 115200 (with termios) would fail. I understand that this is
not something to change this late, that's why I plea for setting the speed to
57600 by default. I'm not pleaing for removing 115200, just for changing the
default. The problem was that I lett rp3-config do everything just playing dumb
user, and it ended up with a very subtile broken config (it cost my quite abit
of time to figure out, dialing worked fine, just the ppp negotiation failed with
strange errors all the time)

115200 basicly is pushing the limits for older modems and uarts (not all modems
like it either) 57600 fails sometimes to, but that's rare. And 57600 is enough
for all modems except a 56k6 under extreme good circumstances.

So my plea is to let rp3-config default to 57600 for autodetected modems, this
is what M$ does afaik :)

Nice to hear that 2) is fixed. And I'll check 3) again.

About 2) Even after doing "echo 1 > /proc/sys/net/ipv4/ip_dynaddr" the lookup
still fails. (And it is a known host) I thought this might have something todo
with the DNS being dynamicly set, but setting them on forehand in
/etc/resolv.conf doesn't help.

About 3) You're right the REMIP is left intact, guess I nuked it myself while
experimenting, oops. Still leaves the RFE to make this configurable from the
GUI. Should I bugzilla this as an RFE, or do you keep a todo list outside
bugzilla?

File part 3 as an RFE if you don't mind.  The documented fix for ppp isn't
solving part 2, so I'll have to look at it some more later.  I'll tag this bug
as resolved, then.

Okay I'll add 3) as an RFE in bugzilla.

I agree this bug is resolved, but:
- What are you going todo about 1) ?
- Since you believe that 2) is still a problem shouldn't I bugzilla that as a
seperate bug too?

Most likely I'll just leave the speed-selection behavior the way it is -- newer
hardware is predominantly 16550-based.  Please bugzilla the second problem as a
bug as well, though if the fix that's supposed to work doesn't work, it'll take
some digging.....

Okay, I'm entering both 1) and 2). If you believe 1) is not a bug resolve it as
such, but I want it in bugzilla under atleast the right summary so that people
can find it.