| Summary: | kppp fails to dial when receiving first string from modem | ||
|---|---|---|---|
| Product: | [Unmaintained] kppp | Reporter: | Alejandro Villar <alx5000> |
| Component: | general | Assignee: | Harri Porten <porten> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Alejandro Villar
2002-12-05 20:38:34 UTC
SuSE 8.1 kdenetwork 3.0.4 Kppp in SuSE cannot write to chap-secrets or pap-secrets. Please see the following in the SuSE support data base: " kppp not working in SuSE 7.0" Excerpt: For security reasons, since SuSE 7.0 kppp no longer uses the superuser ID, and consequently, kppp can no longer execute or write to files with root permissions. Due to this kppp, cannot edit the files /etc/ppp/pap-secrets and /etc/ppp/chap-secrets . Solution: You must login as root and edit the two files /etc/ppp/pap-secrets and /etc/ppp/chap-secrets . Both files have the same format: loginame * password FOR EXAMPLE arcor * internet This is most likely not a Kppp bug. NOTABUG I think you didn't get my meaning... It's not the ppp part that fails, nor the pppd daemon (works correctly with wvdial). KPPP is unable even to send a first string (AT or ATZ). It's the way kppp handles incoming strings what fails. If kppp ignored nonsense strings, or if it ignored at least the first one (just like wvdial does), there would be no problem. But it keeps on trying to read the first string and waiting for OK, without having sent _any_ single string. I've the same problem here with a D-link DFM-560EL modem, "pon" & "poff" programs from Debian work fine. KPP has a default preinit time of about 50 milliseconds. I needed to increase this time to 70 milliseconds before my external modem is usable. Maybe the default time needs to be longer ? The above is off the top of my head, I am doing this online and I cannot see what the settings are while I am using it. I think I'm having the same issue trying to get kppp to interface with a phone used as a USB modem - before it even tries to dial it hangs waiting for an OK. This device works fine with pon/poff in Debian. Because of these issues, I think it would be best if future kppp releases ignored any characters sent by the modem before init strings are sent,and offered a kind of "stupid mode" which makes kppp less stringent about feedback from the modem. Any of you has the possibility to compile kppp from sources to try out a patch that I could provide? I have the same problem using a (new) Genius GM56EX serial modem (with Mandrake 2006). As per default, what I see is a series of square characters across the line. (i.e. KDE's rendering f what are probably null bytes). Then Kppp waits for $MODEM_TIMEOUT seconds before restarting. BUT if I reduce $MODEM_TIMEOUT to below about 60 seconds, the connection fails during authentication. I set the Pre-init delay to 100ms, and the problem is gone. What does Kppp need to do? 1)If it gets a string of garbage, it should re-initialise the modem. It should also give the user a helpful message. 2)$MODEM_TIMEOUT is used for 2 different things. Setting up the modem itself (for which a low value is desired); and Setting up the internet connection - dial/CHAP/etc (for which a fairly high value is desired). These 2 functions ought to be split out. I'd suggest having "Modem Timeout" in the modem tab as present, defaulting to 5 seconds, and creating "Connect Timeout" in the Accounts tab, defaulting to 60 seconds. 3)The default pre-init delay ought to be a bit higher. Saving a few ms isn't worth the reliability issues. Admittedly, this is the first time I have hit this bug in about 10 modems. Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? Thank you for helping us make KDE software even better for everyone! Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |