>It dials and right after dialing, KPPP fails.
Alex, can you add some more info about how it fails?

Hi,

The normal sequence is:
1.Click on connect
2.Them modem dials the number
3.You hear modem sounds
4.The connection is established
5.The KPPP window minimize and you're connected.

What happens:
The normal sequence is:
1.Click on connect
2.Them modem dials the number
---3.KPPP fails and you get back to the KPPP base window

This prevents myself from using my own remaster at home...
I'll still stick to 3.5.13.2...

-Alexandre

Hi,

As a followup for this bug, here is what I did try:
-I installed back the same kernel version as I had on the last release
of my remaster and it still does exactly the same problem

When it fails, it says that the ppp daemon exit status is :2
As it says on http://linux.die.net/man/8/pppd
It means:
An immediately fatal error of some kind occurred, such as an essential system call failing, or running out of virtual memory. 


I would really really like to have this issue resolved for the next TDE release. If I can provide more info, just ask!

-Alexandre

I compared the differences between source code kppp 3.5.13.2 and R14.0.2 and I see nothing major. Except for renaming are the only changes:

Use alternate 'resolv.conf' in kppp, if available
http://mirror.git.trinitydesktop.org/cgit/tdenetwork/commit/?id=e0801ae2

Fix freebsd support in kppp
http://mirror.git.trinitydesktop.org/cgit/tdenetwork/commit/?id=1aeb94bd

There simply can not see something that should be a problem.

Please, can you add to the options for pppd 'dump' that lists the options with which was pppd triggered?

Hi,


I found the bug: A file is missing:
/etc/ppp/peers/kppp-options (just create a blank leafpad file...)

I don't understand why, but every other times, it did not wrote in the error log that this file was needed. Why does this time, it was written: Can't open option file:/etc/ppp/peers/kppp-options:No such file or directory

Also, on PCLinuxOS, kppp asks for being run as root. It wasn't like that in the KDE 3 era, and I do not thing that it is a good idea to give the root password to the users, just to let them go on internet.

-Alexandre

> /etc/ppp/peers/kppp-options (just create a blank leafpad file...)
Interesting. I think there is a bug here.
Looking at the kppp package for debian (same structure as ubuntu I guess), there is a file called 
/opt/trinity/etc/ppp/peers/kppp-options
but none called
/etc/ppp/peers/kppp-options

So if the software is looking for the second one, then there is a problem ;-)
Either we move that file back to /etc or we change the software to look at the /opt location. I think the first one is better.
Slavek, what do you think?

(In reply to Michele Calgaro from comment #6)
> > /etc/ppp/peers/kppp-options (just create a blank leafpad file...)
> Interesting. I think there is a bug here.
> Looking at the kppp package for debian (same structure as ubuntu I guess),
> there is a file called 
> /opt/trinity/etc/ppp/peers/kppp-options
> but none called
> /etc/ppp/peers/kppp-options
> 
> So if the software is looking for the second one, then there is a problem ;-)
> Either we move that file back to /etc or we change the software to look at
> the /opt location. I think the first one is better.
> Slavek, what do you think?

Now I verified that in kppp from 3.5.13.2 the file kppp-options is also in /opt/trinity/etc/ppp/peers and not in /etc/ppp/peers. So the question still remains: why has not the same problem on 3.5.13.2?

With regard to other distributions that probably not use kppp-options, I propose to add checking the existence of the file. For example, the patch as follows:

--- a/kppp/connect.cpp
+++ b/kppp/connect.cpp
@@ -1253,7 +1253,9 @@ bool ConnectWidget::execppp() {
   command += " " + gpppdata.speed();

   command += " -detach";
-  command += " call kppp-options";
+  if (TQFile::exists("/etc/ppp/peers/kppp-options")) {
+    command += " call kppp-options";
+  }

   if(gpppdata.ipaddr() != "0.0.0.0" ||
      gpppdata.gateway() != "0.0.0.0") {

Hi,

Why not just ship the package with the required file, instead of changing code?

-Alexandre

> Why not just ship the package with the required file, instead of changing code?
I think this solution is better, since the file is probably required for some reason. Just testing for existance and don't do something is the file is not there, sounds like we are taking out some functionality that was meant to be there, IMO.

(In reply to Michele Calgaro from comment #9)
> > Why not just ship the package with the required file, instead of changing code?
> I think this solution is better, since the file is probably required for
> some reason. Just testing for existance and don't do something is the file
> is not there, sounds like we are taking out some functionality that was
> meant to be there, IMO.

I have no objection to move the file to the /etc/ppp/peers and not to change the code.

Just note that the file is in /opt/trinity/etc/ppp/peers already in 3.5.12 (older packages are not available), and that it remains unanswered question why this is a problem now - in R14.x?

Hi,

I remember having to create this file sometimes in the past, but I don't remember having to create it in PCLinuxOS. My theory is that since I previously based my remaster on KDE PCLinuxOS, the file was probably present, since KDE4 kppp works, him :) .


But the real question, is why did all the other time I wanted to make kppp work in R14.zzz, the message saying to create the file didn't appear at all, except for 1 time???

-Alexandre

(In reply to Alex Couture from comment #11)
> Hi,
> 
> I remember having to create this file sometimes in the past, but I don't
> remember having to create it in PCLinuxOS. My theory is that since I
> previously based my remaster on KDE PCLinuxOS, the file was probably
> present, since KDE4 kppp works, him :) .
> 
> 
> But the real question, is why did all the other time I wanted to make kppp
> work in R14.zzz, the message saying to create the file didn't appear at all,
> except for 1 time???
> 
> -Alexandre

In the finals it has one curious fact: PCLinuxOS is based on RPM, while kppp-options are installed only in Debian and Ubuntu. So move kppp-options in Debian and Ubuntu packages anyway will not affect the function on the PCLinuxOS ;)

eh, can you please find a non-distro-specific solution?

The base system for my remaster was PCLinuxOS with KDE4, but with KDE4 removed. Probably the system kept the file, provided by the KDE4 kppp, even after KDE4 removal.

-Alexandre

Created attachment 2605 [details]
tdenetwork: Add kppp options

So yeah, we have a proposal patch that could be common to all distributions :)

Besides this, of course, we also need patches for tde-packaging. I have already tested patch for Debian and Ubuntu.

If the patch works well, it looks ok to me ;-)
Alex should do the final test since he is the one that can reproduce the original problem in first place.

Alexandre, please, can you verify that the problem is solved? In the Preliminary stable builds are updated packages.

Hi,

I'll be able to test it in a few days!

Can you also look at why do I require to run kppp as root? I do not like to give the root password to the users, just to let them use internet!

Thank you!
-Alexandre

> Can you also look at why do I require to run kppp as root? I do not like to 
> give the root password to the users, just to let them use internet!
On my Debian this is not required, I can start kppp as a normal user.
I am not sure if Ubuntu is set up differently though.
Have you check the TDE menu to make sure kppp is not being run as root?
Or perhaps some security settings for internet access?
If you google "kppp requires root password" there are quite a few links coming up :-)
Beside that, is there any other bugs that prevents you migrating to R14.0 in a stable manner?

Hi,

I guess that it could be a packaging problem on PCLinuxOS.
Besides switching to Plasma 5 on many computers who are capable of running it and much lower interest in TDE due to its userbase, it should now be better.

-Alexandre

Created attachment 2622 [details]
kppp error dialog at startup

If both /opt/trinity/bin/kppp and /usr/sbin/pppd do not have the 's' bit permission, the attached error dialog is displayed.
Alex, is this what you are seeing?

Patch was pushed in Jan 2016 by Slavek (commit affe074 - R14.1 and 1a396e9 - R14.0).
Since we believe the bug has been fixed and given the long bug inactivity, I am closing the bug.
Feel free to reopen it should the problem rise again.

In fact, one note: Because the problem is not in relation with r14.0.x branch, there is no reason to put a bug to the list for bug 2575. Instead, should be in list for bug 2247.

> In fact, one note: Because the problem is not in relation with r14.0.x branch, 
> there is no reason to put a bug to the list for bug 2575.

> On my PCLinuxOS TDE remaster with TDE R14.0.1

Original bug reported against R14.0.x. Also patch already pushed to R14.0 branch long time ago.

(In reply to Michele Calgaro from comment #23)
> > In fact, one note: Because the problem is not in relation with r14.0.x branch, 
> > there is no reason to put a bug to the list for bug 2575.
> 
> > On my PCLinuxOS TDE remaster with TDE R14.0.1
> 
> Original bug reported against R14.0.x. Also patch already pushed to R14.0
> branch long time ago.

Oh, sorry, that comment 22 should be bug in 2530. This bug of course is related to the R14.0.x. I overlooked that after sending comment 22 on bug 2530 was to me load this bug...