Bug 455348 - NetworkManager is unable to create broadband connection when ethernet connection active
NetworkManager is unable to create broadband connection when ethernet connect...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-14 18:23 EDT by Leonid Kanter
Modified: 2008-09-28 14:45 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-28 14:45:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leonid Kanter 2008-07-14 18:23:00 EDT
Description of problem:

When wired or wireless ethernet connection is active, NetworkManager is unable
to create mobile broadband connection.

Version-Release number of selected component (if applicable):

NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386

How reproducible:

always

Steps to Reproduce:
1. try to create mobile broadband connection when ethernet connection is active
  
Actual results:

Connection will not be established

Expected results:

Connection should be established because somebody may need access to external
resources when ethernet is limited to LAN resources only.

Additional info: I think the reason is in pppd because it may try to use
Ethernet IP as it's local address but cellular operator's access server refuse it.
Comment 1 Dan Williams 2008-07-18 13:44:44 EDT
Could you attach the contents of /var/log/messages from your machine after
trying to connect with mobile broadband?
Comment 2 Leonid Kanter 2008-07-21 10:50:17 EDT
Whith ethernet connected:

Jul 21 17:46:58 d620 NetworkManager: <info>  Starting pppd connection
Jul 21 17:46:58 d620 NetworkManager: <info>  Activation (ttyACM1) Stage 2 of 5
(Device Configure) complete.
Jul 21 17:46:58 d620 pppd[13625]: Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so
loaded.
Jul 21 17:46:58 d620 kernel: PPP generic driver version 2.4.2
Jul 21 17:46:58 d620 pppd[13625]: pppd 2.4.4 started by root, uid 0
Jul 21 17:46:58 d620 pppd[13625]: Using interface ppp0
Jul 21 17:46:58 d620 pppd[13625]: Connect: ppp0 <--> /dev/ttyACM1
Jul 21 17:46:58 d620 NetworkManager: <WARN>  impl_ppp_manager_need_secrets():
Cleared secrets, but setting didn't need any secrets.
Jul 21 17:46:58 d620 pppd[13625]: No secret found for PAP login
Jul 21 17:46:58 d620 pppd[13625]: PAP authentication succeeded
Jul 21 17:46:58 d620 NetworkManager: <info>  (ttyACM1): device state change: 5 -> 7
Jul 21 17:46:59 d620 pppd[13625]: LCP terminated by peer
Jul 21 17:47:02 d620 pppd[13625]: Connection terminated.
Comment 3 Leonid Kanter 2008-07-21 10:54:21 EDT
Ethernet disconnected:
Jul 21 17:50:32 d620 NetworkManager: <info>  Starting pppd connection
Jul 21 17:50:32 d620 NetworkManager: <info>  Activation (ttyACM1) Stage 2 of 5
(Device Configure) complete.
Jul 21 17:50:32 d620 pppd[13876]: Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so
loaded.
Jul 21 17:50:32 d620 pppd[13876]: pppd 2.4.4 started by root, uid 0
Jul 21 17:50:32 d620 pppd[13876]: Using interface ppp0
Jul 21 17:50:32 d620 pppd[13876]: Connect: ppp0 <--> /dev/ttyACM1
Jul 21 17:50:33 d620 NetworkManager: <WARN>  impl_ppp_manager_need_secrets():
Cleared secrets, but setting didn't need any secrets.
Jul 21 17:50:33 d620 pppd[13876]: No secret found for PAP login
Jul 21 17:50:33 d620 pppd[13876]: PAP authentication succeeded
Jul 21 17:50:33 d620 NetworkManager: <info>  (ttyACM1): device state change: 5 -> 7
Jul 21 17:50:34 d620 pppd[13876]: local  IP address 10.192.99.88
Jul 21 17:50:34 d620 pppd[13876]: remote IP address 10.6.6.6
Jul 21 17:50:34 d620 pppd[13876]: primary   DNS address 195.5.46.12
Jul 21 17:50:34 d620 pppd[13876]: secondary DNS address 195.5.46.10
Comment 4 Leonid Kanter 2008-07-21 11:04:30 EDT
From pppd debug output:

Jul 21 17:46:58 d620 pppd[13625]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01>
<addr 172.20.90.160> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jul 21 17:46:58 d620 pppd[13625]: rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
Jul 21 17:46:58 d620 pppd[13625]: sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
Jul 21 17:46:58 d620 NetworkManager: <info>  (ttyACM1): device state change: 5 -> 7
Jul 21 17:46:59 d620 pppd[13625]: rcvd [LCP TermReq id=0x1]
Jul 21 17:46:59 d620 pppd[13625]: LCP terminated by peer

Problem is in <addr 172.20.90.160> (my ethernet address), remote side refuse it.  
Comment 5 Dan Williams 2008-07-21 11:48:33 EDT
Hmm, pppd shouldn't be sending any custom address at all, there isn't anything
specific in NM that would cause pppd to send an address, so there must be
something here in the exchange that's odd.  also, do you need a username and
password for authentication?
Comment 6 Dan Williams 2008-07-21 11:49:38 EDT
Is that 172.20.x.x address the address on your ethernet interface at the time
you try to connect?  pppd has some really weird code to autodetect interface
stuff that we may need to try to work around.  just a thought, but could you
verify what the address on the ethernet interface is when you try the 3G connection?
Comment 7 Leonid Kanter 2008-07-21 11:52:51 EDT
According to man pppd, "The default local address is the (first) IP address of
the system (unless the noipdefault option is given)". I added "noipdefault" to
/etc/ppp/options and successfully connected to 3G network. It looks like
"noipdefault" should be passed to pppd by default, because it's unbelieveable
that operators's NAS will accept IP from LAN. This option is also in use in
/etc/sysconfig/network-scripts/ifup-ppp:

        if [ "$DIALIN" != "on" ]; then
        options="$options noipdefault"
        fi
Comment 8 Leonid Kanter 2008-07-21 11:56:33 EDT
(In reply to comment #6)
> Is that 172.20.x.x address the address on your ethernet interface at the time
> you try to connect?  pppd has some really weird code to autodetect interface
> stuff that we may need to try to work around.  just a thought, but could you
> verify what the address on the ethernet interface is when you try the 3G
connection?

I'm sure that 172.20.90.160 is my address. This behaviour of pppd is described
in man. Here is my IP configuration with "noipdefault" option:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
    link/ether 00:15:c5:37:c7:71 brd ff:ff:ff:ff:ff:ff
    inet 172.20.90.160/24 brd 172.20.90.255 scope global eth0
    inet6 fe80::215:c5ff:fe37:c771/64 scope link 
       valid_lft forever preferred_lft forever
17: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
18: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
    link/ether 00:13:02:88:93:c0 brd ff:ff:ff:ff:ff:ff
    inet 172.20.90.239/24 brd 172.20.90.255 scope global wlan0
    inet6 fe80::213:2ff:fe88:93c0/64 scope link 
       valid_lft forever preferred_lft forever
19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 3
    link/ppp 
    inet 10.193.114.240 peer 10.6.6.6/32 brd 10.193.114.240 scope global ppp0

Comment 9 Leonid Kanter 2008-07-21 12:03:57 EDT
Debug output with "noipdefault" in /etc/ppp/options:

Jul 21 18:52:24 d620 pppd[19148]: PAP authentication succeeded
Jul 21 18:52:24 d620 pppd[19148]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01>
<addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jul 21 18:52:24 d620 pppd[19148]: rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
Jul 21 18:52:24 d620 pppd[19148]: sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
Jul 21 18:52:24 d620 NetworkManager: <info>  (ttyACM1): device state change: 5 -> 7
Jul 21 18:52:25 d620 pppd[19148]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Jul 21 18:52:25 d620 pppd[19148]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>
<ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jul 21 18:52:25 d620 pppd[19148]: rcvd [IPCP ConfNak id=0x2 <addr
10.193.114.240> <ms-dns1 195.5.46.12> <ms-dns3 195.5.46.10>]
Jul 21 18:52:25 d620 pppd[19148]: sent [IPCP ConfReq id=0x3 <addr
10.193.114.240> <ms-dns1 195.5.46.12> <ms-dns3 195.5.46.10>]
Jul 21 18:52:25 d620 pppd[19148]: rcvd [IPCP ConfAck id=0x3 <addr
10.193.114.240> <ms-dns1 195.5.46.12> <ms-dns3 195.5.46.10>]
Jul 21 18:52:25 d620 pppd[19148]: local  IP address 10.193.114.240
Jul 21 18:52:25 d620 pppd[19148]: remote IP address 10.6.6.6
Jul 21 18:52:25 d620 pppd[19148]: primary   DNS address 195.5.46.12
Jul 21 18:52:25 d620 pppd[19148]: secondary DNS address 195.5.46.10

There is no 172.20.90.160 in it and connection was established successfully,
even with eth0 up.
Comment 10 Leonid Kanter 2008-07-21 12:12:08 EDT
(In reply to comment #5)
> Hmm, pppd shouldn't be sending any custom address at all, there isn't anything
> specific in NM that would cause pppd to send an address, so there must be
> something here in the exchange that's odd.  also, do you need a username and
> password for authentication?

No need for username and password. Sending IP is not NM-specific, it's default
behaviour of pppd, and it should be turned off by "noipdefault" option.
Comment 11 Dan Williams 2008-07-21 12:45:45 EDT
Thanks for figuring that out.  Yes, NM should be passing "noipdefault" to pppd.
 This has been committed upstream to NM svn r3842.  Should show up in Fedora in
the next update.
Comment 12 Fedora Update System 2008-07-24 18:41:46 EDT
NetworkManager-vpnc-0.7.0-0.10.svn3846.fc9,NetworkManager-openvpn-0.7.0-15.svn3846.fc9,NetworkManager-0.7.0-0.11.svn3846.fc9 has been submitted as an update for Fedora 9
Comment 13 Fedora Update System 2008-07-30 15:59:43 EDT
NetworkManager-0.7.0-0.11.svn3846.fc9, NetworkManager-vpnc-0.7.0-0.10.svn3846.fc9, NetworkManager-openvpn-0.7.0-15.svn3846.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager NetworkManager-vpnc NetworkManager-openvpn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-6761
Comment 14 Leonid Kanter 2008-07-30 16:55:05 EDT
Already tested it from koji, works fine, thank you!
Comment 15 Fedora Update System 2008-08-11 22:29:33 EDT
NetworkManager-openvpn-0.7.0-15.svn3930.fc9,NetworkManager-vpnc-0.7.0-0.10.svn3928.fc9,NetworkManager-0.7.0-0.11.svn3930.fc9 has been submitted as an update for Fedora 9
Comment 16 Fedora Update System 2008-08-11 22:34:40 EDT
NetworkManager-openvpn-0.7.0-15.svn3930.fc8,NetworkManager-vpnc-0.7.0-0.10.svn3928.fc8,NetworkManager-0.7.0-0.11.svn3930.fc8 has been submitted as an update for Fedora 8
Comment 17 Fedora Update System 2008-08-29 10:56:06 EDT
NetworkManager-openvpn-0.7.0-15.svn4027.fc9,NetworkManager-vpnc-0.7.0-0.10.svn4024.fc9,NetworkManager-0.7.0-0.11.svn4022.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-openvpn-0.7.0-15.svn4027.fc9,NetworkManager-vpnc-0.7.0-0.10.svn4024.fc9,NetworkManager-0.7.0-0.11.svn4022.fc9
Comment 18 Fedora Update System 2008-09-02 16:41:20 EDT
NetworkManager-0.7.0-0.11.svn4022.fc8,NetworkManager-openvpn-0.7.0-15.svn4027.fc8,NetworkManager-vpnc-0.7.0-0.10.svn4024.fc8,NetworkManager-pptp-0.7.0-0.10.svn4027.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.11.svn4022.fc8,NetworkManager-openvpn-0.7.0-15.svn4027.fc8,NetworkManager-vpnc-0.7.0-0.10.svn4024.fc8,NetworkManager-pptp-0.7.0-0.10.svn4027.fc8
Comment 19 Fedora Update System 2008-09-10 02:36:16 EDT
NetworkManager-pptp-0.7.0-0.10.svn4027.fc9, NetworkManager-openvpn-0.7.0-15.svn4027.fc9, NetworkManager-vpnc-0.7.0-0.10.svn4024.fc9, NetworkManager-0.7.0-0.11.svn4022.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager-pptp NetworkManager-openvpn NetworkManager-vpnc NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7375
Comment 20 Fedora Update System 2008-09-10 02:54:23 EDT
NetworkManager-0.7.0-0.11.svn4022.fc8, NetworkManager-openvpn-0.7.0-15.svn4027.fc8, NetworkManager-vpnc-0.7.0-0.10.svn4024.fc8, NetworkManager-pptp-0.7.0-0.10.svn4027.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager NetworkManager-openvpn NetworkManager-vpnc NetworkManager-pptp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-7484
Comment 21 Fedora Update System 2008-09-28 14:42:41 EDT
NetworkManager-0.7.0-0.11.svn4022.fc8, NetworkManager-openvpn-0.7.0-15.svn4027.fc8, NetworkManager-vpnc-0.7.0-0.10.svn4024.fc8, NetworkManager-pptp-0.7.0-0.10.svn4027.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2008-09-28 14:44:25 EDT
NetworkManager-pptp-0.7.0-0.10.svn4027.fc9, NetworkManager-openvpn-0.7.0-15.svn4027.fc9, NetworkManager-vpnc-0.7.0-0.10.svn4024.fc9, NetworkManager-0.7.0-0.11.svn4022.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

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