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.
Could you attach the contents of /var/log/messages from your machine after trying to connect with mobile broadband?
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.
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
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.
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?
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?
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
(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
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.
(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.
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.
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
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
Already tested it from koji, works fine, thank you!
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
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
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
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
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
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
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.
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.