kppp does not assign proper default gateway

Bug #53877 reported by Alexandros Papadopoulos on 2006-07-24
10
Affects Status Importance Assigned to Milestone
KDE Network
New
Medium
kdenetwork (Debian)
Fix Released
Unknown
kdenetwork (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: kppp

After a PPP connection is established, my prior default gateway is still active. Therefore, it's impossible to use the newly established PPP connection before one does a:
$ sudo route del default gw nnn.nnn.nnn.nnn
$ sudo route add default gw zzz.zzz.zzz.zzz

where zzz.zzz.zzz.zzz is the P-t-P IP address reported by
$sudo /sbin/ifconfig ppp0

kppp, since it is run as root anyway, and it provides the option to "assign the default route to this gateway", should do just that.

Binary package hint: kppp

After a PPP connection is established, my prior default gateway is still active. Therefore, it's impossible to use the newly established PPP connection before one does a:
$ sudo route del default gw nnn.nnn.nnn.nnn
$ sudo route add default gw zzz.zzz.zzz.zzz

where zzz.zzz.zzz.zzz is the P-t-P IP address reported by
$sudo /sbin/ifconfig ppp0

kppp, since it is run as root anyway, and it provides the option to "assign the default route to this gateway", should do just that.

Philip Guyton (phil-lxnet) wrote :

I have just observer the same behaviour so can confirm.

I am using Ubuntu edgy 6.10 with kubuntu-desktop added and all updates applied as of this writing.

My experience is as reported by Alexandros Papadopoulos but in addition if I first remove the default gateway (in this case to eth0) then the new ppp gateway is established correctly by kppp.

In other words is works fine if there is not an existing gateway.

I hope this helps.

Hi,

We (the Debian Qt/KDE team) are trying to update the bug status of some
old bugs in the BTS.

You filed the bug
 #284744 "doesn't set default gateway if already present"
some time ago, you can read the bug report at:
http://bugs.debian.org/284744

We are sorry if nobody responded when you filed the bug, KDE has gotten more bugs
in the past years than the maintainers could handle. We are trying to fix this now,
but we need your help. So please respond to this mail and tell us if:

- you are still experiencing this bug (adding in what version)
- the bug was already fixed,
- or if you have extra information on how reproduce this bug.

---
Thanks in advance,
  Ana Guerrero,
  on behalf of the Debian Qt/KDE team

tag 303336 +moreinfo
tag 389750 +moreinfo
tag 206843 +moreinfo
tag 239465 +moreinfo
tag 243270 +moreinfo
tag 284744 +moreinfo
tag 289266 +moreinfo
thanks

found #284744 3.5.5-4
thanks

On Fri, Jan 12, 2007 at 02:02:31PM +0100, Ana Guerrero wrote:
> - you are still experiencing this bug (adding in what version)

[X]

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

Marco Cimmino (cimmo) wrote :

Same here:
with kubuntu 6.10 failed to connects until I have disabled my network interface because default gateway was always the one set over there -> 192.168.1.1

Of course I have enabled option to set default gateway in KPPP but doesn't work :(

# Automatically generated email from bts, devscripts version 2.9.27
tags 284744 - moreinfo

sittisal (sittisal) wrote :

The same problem here. The strange thing is that the connection is working under konsole, so it should detect the correct gateway. But konqueror,kmail,kopete doesn't works. But if i try to launch konqueror as root from konsole with "kdesu konqueror" everithing works fine.

tag 273724 moreinfo
forwarded 276760 http://bugs.kde.org/show_bug.cgi?id=142618
tag 278433 moreinfo
tag 279253 moreinfo
tag 280014 moreinfo
tag 281168 moreinfo
forwarded 284744 http://bugs.kde.org/show_bug.cgi?id=145027
tag 287175 moreinfo
tag 290972 moreinfo
tag 290973 moreinfo
tag 291867 moreinfo
tag 292524 moreinfo
tag 294169 moreinfo
tag 294906 moreinfo
tag 295286 moreinfo
tag 295551 moreinfo
tag 316904 moreinfo
tag 331036 moreinfo
tag 332558 moreinfo
forwarded 337225 http://bugs.kde.org/show_bug.cgi?id=145034
tag 337751 moreinfo
tag 345500 moreinfo
tag 348081 moreinfo
tag 349710 moreinfo
tag 353160 moreinfo
tag 359809 moreinfo
thanks

Version: (using KDE KDE 3.5.5)
Installed from: Debian testing/unstable Packages

Reported in Debian BTS at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284744

Hi,

I am on an ethernet network that gives me a default gateway. When I
use kppp to connect to the Internet, I would expect kppp to overwrite
the already present default gateway with the PPP partner. This does
not happen.

What am I doing wrong?

Greetings
Marc

.kde/share/config/kppprc:
[Account0]
AccountingEnabled=0
AccountingFile=
Authentication=4
AutoDNS=1
AutoName=0
BeforeConnect=
BeforeDisconnect=
CallbackPhone=
CallbackType=0
Command=
DNS=
DefaultRoute=1
DisconnectCommand=
Domain=
ExDNSDisabled=0
Gateway=0.0.0.0
IPAddr=0.0.0.0
Name=GPRS
Password=t-d1
Phonenumber=*99#
ScriptArguments=
ScriptCommands=
StorePassword=1
SubnetMask=0.0.0.0
TotalBytes=29754
Username=t-d1
VolumeAccountingEnabled=3
pppdArguments=

[Account1]
pppdArguments=

[General]
DefaultAccount=GPRS
DefaultModem=rfcomm0
DockIntoPanel=1
NumberOfAccounts=1
NumberOfModems=1
PPPDebug=0
ShowLogWindow=0

[Graph]
Background=255,255,255
Enabled=true
InBytes=0,0,255
OutBytes=255,0,0
Text=0,0,0

[Modem]
AnswerResponse=CONNECT
AnswerString=ATA
BusyResponse=BUSY
ConnectResponse=CONNECT
DLPResponse=DIGITAL LINE DETECTED
Device=/dev/rfcomm0
DialString=ATDT
EscapeGuardTime=50
EscapeResponse=OK
EscapeString=+++
HangUpResponse=OK
HangupString=+++ATH
InitDelay=50
InitResponse=OK
InitString=ATZ
InitString1=
NoCarrierResponse=NO CARRIER
NoDialToneDetection=ATX3
NoDialToneResp=NO DIALTONE
PreInitDelay=50
RingResponse=RING
ToneDuration=70
VolumeHigh=M1L3
VolumeMedium=M1L1
VolumeOff=M0L0
WaitForDialTone=0

[Modem0]
AnswerResponse=CONNECT
AnswerString=ATA
BusyResponse=BUSY
BusyWait=0
ConnectResponse=CONNECT
DLPResponse=DIGITAL LINE DETECTED
Device=/dev/rfcomm0
DialString=ATDT
Enter=CR
EscapeGuardTime=50
EscapeResponse=OK
EscapeString=+++
FlowControl=Hardware [CRTSCTS]
HangUpResponse=OK
HangupString=+++ATH
InitDelay=50
InitResponse=OK
InitString=ATZ
InitString1=
Name=rfcomm0
NoCarrierResponse=NO CARRIER
NoDialToneDetection=ATX3
NoDialToneResp=NO DIALTONE
PreInitDelay=50
RingResponse=RING
Speed=57600
Timeout=60
ToneDuration=70
UseLockFile=1
Volume=1
VolumeHigh=M1L3
VolumeMedium=M1L1
VolumeOff=M0L0
WaitForDialTone=0

[WindowPosition]
WindowPositionStatWinX=355
WindowPositionStatWinY=153

I can confirm this under Feisty. I have an ethernet network at home, which normally connects via a modem router. The router IP is the default gateway. Recently the DSL connection was unavailable, and we had to use dialup. The connection was established (although pppd always crashed on the first connection attempt, and a second attempt had to be made, which always succeeded), but gateway problems prevented access to the internet.

I found two solutions: 'sudo route add default ppp0', which is very inconvenient, particularly as many of the users of the computer don't have admin access, and editing the file /etc/ppp/peers/kppp-options to include the lines "defaultroute" and "replacedefaultroute". Prior to this edit, the file contained only the line "noauth". In my opinion, these options should probably be included by default.

Hortensia (hortensia-hamilton) wrote :

Have a same issue on kubuntu-7.04-desktop-i386
The connection was established, but konqueror,kmail, etc doesn't works. Updates works, chimera2 works, can ping, etc from console.

Jim Qode (jimqode) on 2007-07-04
Changed in kdenetwork:
status: New → Confirmed
Christian González (droetker) wrote :

guys, this is a serious bug.
You cant send Mails/access the Internet wirh Konqueror using a ppp connection, and it still doesn't work on hardy.

Please fix this/ rate it higher.
Or at least say "wontfix".

Changed in kdenetwork:
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in kdenetwork:
status: Unknown → New

This still happens in KDE 4.2.1.

Changed in kdenetwork:
status: Unknown → Confirmed

Well, I have found a workaround for this: add noauth in /etc/ppp/options, that will make pppd NOT assign the default route, but it will assign the IP address. Then you have to add the 'route add default gw <gateway IP>' command in /etc/ppp/ip-up script. In Gentoo the ip-up script just walks through /etc/ppp/ip-up.d/* files and run then one by one, in one of then I add this command:

route add default gw $5

$5 is the gateway IP address pppd obtained from the ppp server. That works for me.

Hello,
In reference to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284744
Are you able to reproduce the bug with a recent version of KDE (> 4.2) ?

Thanks
Olivier

Changed in kdenetwork (Debian):
status: Confirmed → Fix Released
Jonathan Thomas (echidnaman) wrote :

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. But don't worry! This issue is being tracked by the KDE developers at:http://bugs.kde.org/show_bug.cgi?id=145027
Once fixed in KDE, it will be included in Kubuntu once the KDE version the fix is in in reaches Kubuntu.

Thanks!

Changed in kdenetwork (Ubuntu):
status: Triaged → Invalid
Changed in kdenetwork:
importance: Unknown → Medium

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!

Changed in kdenetwork:
status: New → Incomplete

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!

Changed in kdenetwork:
status: Incomplete → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.