Hide Forgot
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
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?
Hi, I'll definitely stop by when I'm in Brno.
compare /etc/NetworkManager/system-connections /etc/sysconfig/network-scripts
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.
(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
Created attachment 674964 [details] /var/log/messages
(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
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.
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.