Can you please provide a debug log-file?

A good way to do that, is add the lines:

[logging]
level=DEBUG
domains=ALL

to /etc/NetworkManager/NetworkManager.conf and restart NM.

Afterwards try to reproduce the error and show the logfile.

I suspect that on Arch Linux, you find the logfile with 
  journalctl -b 0 -u NetworkManager > nm-logfile.txt


The log shouldn't contain any sensitive information, but depending on what you consider sensitive, you might want to review that before posting.


Also, show please show your configuration. E.g. the file /etc/NetworkManager/system-connections/<pptp-connection-name>. Again, review for sensitive data before posting.


Thank you

Created attachment 281231 [details]
journalctl -b 0 -u NetworkManager > /tmp/ttt.txt

edited

Same here on debian, nm 0.9.10.0-1

You specify as gateway 192.168.4.254, but there is no direct route to 192.168.4.254. That cannot work.

you should configure one of the following set of routes (depending on the setup of your network):

  192.168.4.254/32 via 0.0.0.0
  192.0.0.0/8 via 192.168.4.254

or

  192.0.0.0/8 via 0.0.0.0

(In reply to comment #4)
> You specify as gateway 192.168.4.254, but there is no direct route to
> 192.168.4.254. That cannot work.
> 
> you should configure one of the following set of routes (depending on the setup
> of your network):
> 
>   192.168.4.254/32 via 0.0.0.0
>   192.0.0.0/8 via 192.168.4.254
> 
> or
> 
>   192.0.0.0/8 via 0.0.0.0

Thank you Thomas, you are right, fixing it helped.

Ideally, the rule would have been like this:

route add -net 192.168.2.0 netmask 255.255.255.0 dev ppp0

But nm doesn't allow me to add it in this way, so setting up nm pppt route to 192.168.2.0 to go via gw 0.0.0.0 works. 

It adds:
192.0.0.0       0.0.0.0         255.0.0.0       U     1024   0        0 ppp0

Interestingly, the previous rule going via 192.168.4.254 has worked for many years :), not sure what route it actually did set. 

So it seems that the issue as reported was caused by tightening rules somewhere.

Btw. when pptp vpn setting up failed (due to the above), resolv.conf didn't get restored to previous, resulting in "broken" networking. Should i file another bug report for that?

(In reply to comment #5)
> (In reply to comment #4)
> > You specify as gateway 192.168.4.254, but there is no direct route to
> > 192.168.4.254. That cannot work.
> > 
> > you should configure one of the following set of routes (depending on the setup
> > of your network):
> > 
> >   192.168.4.254/32 via 0.0.0.0
> >   192.0.0.0/8 via 192.168.4.254
> > 
> > or
> > 
> >   192.0.0.0/8 via 0.0.0.0
> 
> Thank you Thomas, you are right, fixing it helped.
> 
> Ideally, the rule would have been like this:
> 
> route add -net 192.168.2.0 netmask 255.255.255.0 dev ppp0
>
> But nm doesn't allow me to add it in this way, so setting up nm pppt route to
> 192.168.2.0 to go via gw 0.0.0.0 works. 

It does. Configuring
  192.168.2.0/24 via 0.0.0.0
is just the same. Via 0.0.0.0 means that it is a direct route, no gateway involved.
The "dev ppp0" is implicit as you configure the route for the pptp VPN connection.



> It adds:
> 192.0.0.0       0.0.0.0         255.0.0.0       U     1024   0        0 ppp0

Either you set a route with prefix length 8 (netmask: 255.0.0.0) or 24 (netmask: 255.255.255.0). Whatever you want. Note that 192.168.2.0/8 doesn't make much sense and is just the same as 192.0.0.0/8.



> Interestingly, the previous rule going via 192.168.4.254 has worked for many
> years :), not sure what route it actually did set. 
> 
> So it seems that the issue as reported was caused by tightening rules
> somewhere.

I don't think that something changed in this regard. But I don't know what your configuration before was :) . Do you mean "worked for many years with an older version of NetworkManager"? Which version?


> Btw. when pptp vpn setting up failed (due to the above), resolv.conf didn't get
> restored to previous, resulting in "broken" networking. Should i file another
> bug report for that?

That is interesting. I think it's fine to handle that error in this bug. No action needed from your side (for the moment). Thank you for your help.

> > But nm doesn't allow me to add it in this way, so setting up nm pppt route to
> > 192.168.2.0 to go via gw 0.0.0.0 works. 
> 
> It does. Configuring
>   192.168.2.0/24 via 0.0.0.0
> is just the same. Via 0.0.0.0 means that it is a direct route, no gateway
> involved.
> The "dev ppp0" is implicit as you configure the route for the pptp VPN
> connection.

Makes sense

> 
> 
> 
> > It adds:
> > 192.0.0.0       0.0.0.0         255.0.0.0       U     1024   0        0 ppp0
> 
> Either you set a route with prefix length 8 (netmask: 255.0.0.0) or 24
> (netmask: 255.255.255.0). Whatever you want. Note that 192.168.2.0/8 doesn't
> make much sense and is just the same as 192.0.0.0/8.

Makes sense.

> > Interestingly, the previous rule going via 192.168.4.254 has worked for many
> > years :), not sure what route it actually did set. 
> > 
> > So it seems that the issue as reported was caused by tightening rules
> > somewhere.
> 
> I don't think that something changed in this regard. But I don't know what your
> configuration before was :) . Do you mean "worked for many years with an older
> version of NetworkManager"? Which version?


Oh yeah, it worked for many years with this now non functioning configuration. I can't remember anymore when vpn support was added to nm, perhaps together with mobile data, in the big 0.7 update. I might have changed the vpn config over the years a few times, but i have been connecting to this particular vpn for the past seven or something years. No problem, i updated my settings and can now stop using pon/poff for vpn and start using nm again :)

Btw, the original bug reporter might have had the same or different issue, we will have to see from his logs when submitted.

> 
> > Btw. when pptp vpn setting up failed (due to the above), resolv.conf didn't get
> > restored to previous, resulting in "broken" networking. Should i file another
> > bug report for that?
> 
> That is interesting. I think it's fine to handle that error in this bug. No
> action needed from your side (for the moment). Thank you for your help.

Thank you for all your help too.

I have the same issue with NM 0.9.10, but I also have a system with NM 0.9.8.4 that works OK.

The one with the older NM displays:

<info> Tunnel Device: ppp0
<info> IPv4 configuration:
<info>   Internal Address: 10.10.220.115
<info>   Internal Prefix: 32
<info>   Internal Point-to-Point Address: 10.10.220.100
<info>   Maximum Segment Size (MSS): 0
<info>   Static Route: 10.10.0.0/16   Next Hop: 10.10.0.0
<info>   Forbid Default Route: yes
<info>   Internal DNS: 10.17.3.13
<info>   DNS Domain: '(none)'
<info> No IPv6 configuration

and all's fine. The one with the newer NM:

<info> Tunnel Device: ppp0
<info> IPv4 configuration:
<info>   Internal Address: 10.10.220.107
<info>   Internal Prefix: 32
<info>   Internal Point-to-Point Address: 10.10.220.100
<info>   Maximum Segment Size (MSS): 0
<info>   Static Route: 10.10.0.0/16   Next Hop: 10.10.0.1
<info>   Forbid Default Route: yes
<info>   Internal DNS: 10.17.3.13
<info>   DNS Domain: '(none)'
<info> No IPv6 configuration
<error> [1412619643.656033] [platform/nm-linux-platform.c:1714] add_object(): Netlink error adding 10.10.0.0/16 via 10.10.0.1 dev ppp0 metric 1024 mss 0 src user: Unspecific failure

but manually doing:

# ip route add 10.10.0.0/16 via 10.10.0.1 dev ppp0

works just fine. I noticed that although the two NM-s are configured _identically_, one uses 10.10.0.0 as 'Next Hop' (I've configured 10.10.0.1) and the other 10.10.0.1 (the right one).

I've made it work by using 0.0.0.0 as gw, but I can't understand the sudden appearance of this difference.

I also had this issue with NM 0.9.10, similar error

[platform/nm-linux-platform.c:1716] add_object(): Netlink error adding 172.16.100.0/24 via 192.168.0.1 dev ppp0 metric 1024 mss 0 src user: Unspecific failure

and no problem with the very same configuration with 0.9.8.2.

Finding this bug report allowed me to fix the problem by removing a route.

Created attachment 292346 [details]
/etc/NetworkManager/system-connections/VPN1

My arch configuration

Created attachment 292347 [details]
Logfile while in debug mode

I am seeing the same issue with arch networkmanager 0.9.10.0-4 and 
networkmanager-pptp 0.9.10.0-2

I don't see the same issue with the same configuration under Fedora 20 NetworkManager-pptp-0.9.8.2-3.fc20.x86_64 and NetworkManager-0.9.9.0-46.git20131003.fc20.x86_64

Please see attachments (apologies I could figure out how to make it all in one comment)

Just tested Fedora 21 and NetworkManager-0.9.10.0-13 same problem.


In my case performing the work-a-rounds above didn't work. (however deleting the offending route did)

I have same problem.
After googling, I found http://chakraos.org/forum/viewtopic.php?id=13366
Here people discovered wrong configure file of NetworkManager(-pptp)-0.9.10.0 :


if test -n "$with_pppd_plugin_dir" ; then
	PPPD_PLUGIN_DIR="$with_pppd_plugin_dir"
else
	PPPD_PLUGIN_DIR="${libdir}/pppd/2.4.5"
fi


But must be PPPD_PLUGIN_DIR="${libdir}/pppd/2.4.7"

Downstream bugs:
* https://bugzilla.redhat.com/show_bug.cgi?id=1266440
* https://bugs.archlinux.org/task/45716

Seems there is a strange behavior with the ppp interface.
On my pptp server (kernel 2.6.32, pptp 1.7.2, pppd 2.4.5, no nm), I have the following:

root@intranet:/var/log# ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:192.168.1.2  P-t-P:192.168.1.200  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:100 (100.0 B)  TX bytes:1808 (1.8 KB)

root@intranet:/var/log# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.200   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eth0

routing table correctly use the P-t-P address.

On my desktop @home (ubuntu 15.10, kernel 4.2.0-22-generic, pptp 1.8.0, pppd 2.4.6, nm 1.0.4), I got:

root@bureau:~# ifconfig ppp0
ppp0      Link encap:Protocole Point-à-Point  
          inet adr:192.168.1.200  P-t-P:192.168.1.2  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          Packets reçus:4376 erreurs:5 :0 overruns:0 frame:0
          TX packets:4584 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:3 
          Octets reçus:3407332 (3.4 MB) Octets transmis:461083 (461.0 KB)

root@bureau:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    100    0        0 eno1
8X.YY.ZZ.TTT    192.168.0.254   255.255.255.255 UGH   100    0        0 eno1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eno1
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eno1
192.168.1.200   0.0.0.0         255.255.255.255 UH    50     0        0 ppp0


Routing table don't use the P-t-P remote address but the local address!!!
Since only the remote address is fixed (local is allocated by server), I cannot set specific route though the remote address.

Regards,
David

David,

Your issue related to IPv4 peer addresses was recently fixed on nm-1-0 branch [1] and already for a while on master [2]. The fix is not yet in any stable release.

Please test with an updated version, and/or report the BZ downstream.


[1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=11aa07ed939193e85516c287a57dee1837242972
[2] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=aa5b89a2ec8db5735925f78f3c91885a513ce51e




This bug is quite old and messy and the code in question changed already many times. To my knowledge this works now all correctly (upstream). I'm closing this BZ. Please open new bugs for future routing issues. Thanks.


In general, when adding a route fails with "Unspecific failure", it usually means that there is no direct route to the gateway. There were issues in NM (e.g. with IPv4 peer addresses) which should be fixed now.
If somebody experiences this issue, double-check your configuration for a missing direct route first.