enabled (and started) the service sudo systemctl enable connman-vpn.service
created VPN configuration file following these specs and saved it under /var/lib/connman-vpn/my_vpn.config
[global]
Name = vpn
Description = VPN configuration
[provider_pptp]
Type = PPTP
Name = my_vpn
Host = x.xxx.xxx.xxx
Domain =
PPTP.User = username
PPTP.Password = password
PPPD.RequirMPPE128
PPPD.NoBSDComp
PPPD.NoDeflate
now, when I run connmanctl> services I don’t see my vpn listed there, so I’m not able to actually try and connect to the vpn…
Q: Is this approach I described above going to work at all with OSMC? If yes, what am I missing?
This is really a great news @sam_nazarko - thank you
Yes - I made sure the service was running, but I’m sure there’s much more to configure to get this working, as the connman-vpn has not been originally implemented in osmc.
Hey guys - can anyone confirm if OSMC already has everything that is needed for ConnMan VPN to work? Or is it a waste of time for me trying to set it up right with current OSMC release?
It has the connection manager (ConnMan) and we build it with VPN support. It can be configured manually, via an editor. What we don’t, presently offer, but hope to do so eventually, is offer a graphical interface for this.
A lot of users are configuring OpenVPN with /etc/init.d. This won’t work properly, as a connection manager’s duty is to handle routing. This messes with OpenVPN’s routing changes. Put shortly: ConnMan needs to be aware of OpenVPN. There’s nothing to prevent this, but I suspect a lack of documentation / guides has resulted in users falling back to the stock OpenVPN guides.
Now, when I run connman-vpn daemon and point it to the config file (connman-vpnd -c /var/lib/connman-vpn/vpn.config -n -d), I get the following error:
connman-vpnd[575]: vpn/vpn-config.c:load_provider() Cannot create provider from config file (19/No such device)
connman-vpnd[575]: Config file /var/lib/connman-vpn/vpn.config does not contain any configuration that can be provisioned!
This is one of the reasons why I removed connman and went back to if updown. I use the raspi as a nfs server for another pi wired directly on eth0 using volumio. Connman did not bring eth0 up if no connection was detected, so if the other pi was shut down when I restarted the osmc the dhcp server failed to start. Moreover kept messing up with routings setting default on eth0 if for some reason the wifi went down. Add to this that was also randomly disrupting routing when openvpn was running and you complete the picture.
Ah, no, theres is more, it has an internal dhcp server he uses when enabling tethering but there is no way (at least that I found) to simply enable it on eth0.
Frankly I do not know if it is worth the pain to have a connection manager at the same time so invasive and so limited on a pi. It would be useful in case of hotplug of network interfaces, or on a mobile device where it can take care of wifi but not on a small media box which is fundamentally configured at installation and then will keep that config forever.
The configuration done by ifupdown and wireless-tools is easier, less invasive and less error prone.
For you yes, and that’s great. But not for 99% of users that want to set up WiFi or Bluetooth, and don’t want to know what wpa-supplicant or bluez are, it’s far, far worse. From a programmatic perspective, it’s also very bad.
ConnMan can run VPN – our issue is we haven’t got a GUI tool for this yet. Changing to yet another headless mechanism for maintaining network connections won’t alleviate that.
With ifupdown you do not need to know what wpa supplicant is, wpa-essid and wpa-psk in iface definition do the magic. It is even simpler than connman.
About bluetooh, I’ve never used it so I can’t speak.
/etc/network/interfaces does not allow for multiple connections (easily), which can make roaming more challenging.
See [HOWTO] OSMC/Rasp Pi as OpenVPN client - #35 by sam_nazarko for more about VPN, ConnMan and /etc/network/interfaces. The only issues with ConnMan seem to be raised by VPN users. They would be better served working with us to get VPN working with ConnMan, then everyone wins
What made me run away from connman is that he kept changing default route to isolated eth0 randomly. I have wlan0 in dhcp connected to router, eth0 is static and serving a volumio, finally openvpn opening a tun0 that has been blacklisted. Usually everything works, but sometimes connman decided to set eth0 as default route and nothing worked anymore until manual intervention.
I tried to reproduce, nothing, tried to debug but kernel was still flooding log with those gpio messages so at the end saying goodbye to connman was the easiest thing.
IMHO is too much of not fish nor flesh. Not smart enough for basic users and not flexible enough for advanced ones, and the big winning point of OSMC on Openelec is that the OS behind OSMC is much more open and configurable.
You’re basing this on one need, which ConnMan is currently not satisfying for you. If you look at what it does do right, you’ll see that is a lot. As I say, we will eventually add a GUI interface for configuring ConnMan, for now there isn’t a perfect solution.
ConnMan should not be producing GPIO messages – can you post a snippet so I can see what you mean?
ConnMan handles routing, as it’s a connection manager. You can ‘ignore’ devices with -I and thus ConnMan won’t mess with them.
Power users have /etc/network/interfaces, and always will with OSMC. So if you do prefer it, that’s fine and I am glad you have at least some form of a solution
Thank you @sam_nazarko and @pronto89 for contributing to this thread. However, I didn’t get too much from your conversation, except for realizing that I’m still a rookie in linux world…
But at least I know now, that trying to get the VPN working with ConnMan is out of my reach right now - so thanks for saving my time!
VPN on OSMC is quite important for me. I event tried my luck with XBian - I did setup the VPN with no issue, but after two days of struggling with the whole system, I was back on OSMC. OpenELEC is not really an option, because it doesn’t have that openness, which OSMC and XBian have (which I need for configuring print server on my Pi). However, it seems that OpenELEC also uses ConnMan and they offer a GUI for configuring VPN (openvpn and pptp - afaik), so I hope it’s just a matter of time and OSMC will offer that too
So, I guess I’ll just stick to OSMC and patiently wait for developers to add GUI or someone wiser that me to post some step-by-step guide on how to get the VPN working (pptp or l2tp) with ConnMan, as there’s no better alternative to OSMC right now. I’m just a bit surprised that so little people need VPN on their media box… Or, they’ve already found a workaround for that… but if that requires removing ConnMan, I’m not sure if that’s a good option for less-experienced users like me…
Sam, the GPIO messages were coming from kernel driver of my wireless dongle. You already solved this issue but it was present when I tried to figure out what was happening with WiFi.
Sew, what are your networking needs?
Pi connecting to internet via wireless or wired?
Vpn on pptp/l2tp or openvpn would be also ok?
Do you need to hotplug any network adapter, or you have your pi confortably sitting hidden behind your tv?
I’m using wired connection only. Unfortunately, I’m limited to using only PPTP, L2TP, SSTP or SoftEther (cannot use OpenVPN with my vpn provider). No need to hotplug anything. I hardly ever touch my Pi - it stays ON for most of the time.
Have you tried adding
NetworkInterfaceBlacklist=eth0,ppp0
Configuring eth0 through a couple of lines in /etc/network/interfaces and using the pptp client as in your other post should then work as connman SHOULD at that point just sit there idling.
