Bug 881087 - DSL connection not working if wired interface set to automatic
Summary: DSL connection not working if wired interface set to automatic
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-28 15:47 UTC by Karel Volný
Modified: 2013-07-31 23:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-31 23:42:25 UTC
Type: Bug


Attachments (Terms of Use)
/var/log/messages (784.77 KB, text/plain)
2013-01-08 16:42 UTC, Karel Volný
no flags Details

Description Karel Volný 2012-11-28 15:47:42 UTC
Description of problem:
I have my machine set to automatically connect to wired network and set it up using DHCP.
After configuring a new DSL connection, I cannot use this connection until I disable the default wired one.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.6.4-3.fc17.x86_64
kde-plasma-networkmanagement-0.9.0.5-1.fc17.x86_64

How reproducible:
90%

Steps to Reproduce:
1. configure your wired interface (em1?) to get address from dhcp, to be a system connection and connect automatically
2. configure a DSL connection
3. connect the cable from your DSL provider
4. watch the tray icon & system messages
5. manually disconnect the wired connection
6. manually choose to connect to the DSL connection
  
Actual results:
4. you get "connection to em1 failed" or something like that, because the DSL infrastructure does not respond without logging in first
5. you get disconnected status, the system no longer tries to obtain address from DHCP
6.
a) the applet reports connection attempt to your DSL connection
b) it fails
c) the applet reports connection attempt to your wired connection
d) it fails
after some timeout, c) and d) repeats

if you repeat steps 5 and 6, maybe, once in ten tries or so, you eventually get connected to DSL

Expected results:
4. you are connected to your DSL provider
alternatively, if DSL is not recognised and normal wired connection is tried at first, you try steps 5 and 6
5. you get disconnected status
6. you are connected to your DSL provider

Additional info:
this is not 100% reproducible across different machines, unfortunately - I see it on 2 of 3 Fedora installs I had available

the other failing one fails in a bit different manner - it is able to connect automatically to DSL after the boot/first login, but it never connects again if the cable gets physically disconnected and connected again

Comment 1 Karel Volný 2012-11-30 15:37:08 UTC
once upon a time, I've heard there is a mysterious volunteer willing to help to resolve all NM issues ... pavlix, would you be willing to stop by my cube in a near future to discuss this bug?

Comment 2 Pavel Šimerda (pavlix) 2012-12-04 00:53:57 UTC
Hi, I'll definitely stop by when I'm in Brno.

Comment 3 Karel Volný 2012-12-20 15:58:48 UTC
compare

/etc/NetworkManager/system-connections
/etc/sysconfig/network-scripts

Comment 4 Jirka Klimes 2013-01-08 13:09:10 UTC
Karel, would you attach /var/log/messages, so that we can see what's going on?
Also, config files ifcfg-em1, and the DSL one would be helpful. Thanks.

Comment 5 Karel Volný 2013-01-08 16:27:57 UTC
(In reply to comment #3)
> compare
> 
> /etc/NetworkManager/system-connections

machine that works:

# cat /etc/NetworkManager/system-connections/Digi
[pppoe]
service=Digi
username=10051785
password=the_super_secret_password

[connection]
id=Digi
uuid=1d5c077e-0484-4ed8-8602-cde811f0d69b
type=pppoe

[ipv6]
method=ignore

[802-3-ethernet]
port=mii

[ipv4]
method=auto
may-fail=false


machine that fails:

# cat /etc/NetworkManager/system-connections/Digi 
[pppoe]
service=Digi
username=10051785
password=the_super_secret_password

[connection]
id=Digi
uuid=1f8fd373-a329-4008-aa18-ac9a0bbae93c
type=pppoe
timestamp=1352124512

[ipv6]
method=ignore

[802-3-ethernet]
port=mii

[ipv4]
method=auto
may-fail=false


> /etc/sysconfig/network-scripts

machine that works:

# cat /etc/sysconfig/network-scripts/ifcfg-p3p1 
DEVICE="p3p1"
UUID="e198c586-67ca-4fd2-8c76-16f616a0b7e5"
NM_CONTROLLED="yes"
BOOTPROTO="dhcp"
HWADDR="F0:DE:F1:CF:32:6E"
ONBOOT="yes"


machine that fails:

# cat /etc/sysconfig/network-scripts/ifcfg-em1 
UUID="265edd49-dd33-4f27-948c-1badd7def3f6"
NM_CONTROLLED="yes"
NETBOOT="yes"
BOOTPROTO="dhcp"
DEVICE="em1"
TYPE="Ethernet"
ONBOOT=no
NAME=em1                                                                                                                                                                                                       
DEFROUTE=yes                                                                                                                                                                                                   
IPV4_FAILURE_FATAL=yes                                                                                                                                                                                         
IPV6INIT=no                                                                                                                                                                                                    
HWADDR=F0:DE:F1:07:33:BA                                                                                                                                                                                       
PEERDNS=yes                                                                                                                                                                                                    
PEERROUTES=yes

Comment 6 Karel Volný 2013-01-08 16:42:52 UTC
Created attachment 674964 [details]
/var/log/messages

Comment 7 Karel Volný 2013-01-08 17:03:06 UTC
(In reply to comment #4)
> Karel, would you attach /var/log/messages, so that we can see what's going
> on?

see the attachment

this is from the last weekend

after a while, it stopped working even if I've disabled connecting to em1 automatically

however, I've found out that I can reconnect(*) to the DSL without rebooting the whole machine if I restart NetworkManager(**) and possibly (not always needed) pull out the network cable meanwhile(***)

(*) I got a lot of disconnections because of bad connector

(**) usually, after two or three failing attempts from the GUI I got the dialogue box with connection details which had the password field empty; after restarting NM and going to the configuration dialogue the password was there ... so it seems NM somehow forgets the password even if it is still untouched (and in plaintext, oh) in the configfile

(***) I believe this has something to do with the messages

Jan  4 15:09:56 kvolny pppd[7264]: Remote message: ^M^JYou are already logged in - access denied^M^J^J^J
Jan  4 15:09:56 kvolny pppd[7264]: PAP authentication failed
Jan  4 15:09:56 kvolny pppd[7264]: Connection terminated.

however, I wouldn't blame the other party here, as sometimes the cable got disconnected by the connector bad contact for a long time, and yet after replugging and restarting NM I still had to manually disconnect it just for a few seconds again to make it working, so it doesn't look like dependent on some timeout expiration on the device I was trying to login on

> Also, config files ifcfg-em1, and the DSL one would be helpful. Thanks.

see comment #5

Comment 8 Fedora End Of Life 2013-07-03 22:04:53 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 9 Fedora End Of Life 2013-07-31 23:42:29 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.