OpenWrt Forum Archive

Topic: SSTP status updates on trunk

The content of this topic has been archived on 2 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have an SSTP VPN running on trunk r45951 using HarveyHu's scripts found here:
https://github.com/harveyhu2012/package … stp-client
https://github.com/harveyhu2012/luci/co … r...master

Though the VPN itself is working and I have a nice source based routing setup through mwan3, I am unable to correctly get status updates for the interface. For example, the interface is not automatically added to /var/status/network and man3 only works if I manually add the interface. Also the interface page in luci does not show uptime or data transferred (although it does show an ip address).

I think this relates to the network not properly being called up. When everything is up and running I see:

root@OpenWrt:~# ubus call network.interface.PureVPN status
{
        "up": false,
        "pending": true,
        "available": true,
        "autostart": true,
        "proto": "sstp",
        "data": {

        }
}

My log shows:

Tue Jun 16 15:29:19 2015 daemon.notice netifd: Interface 'PureVPN' is setting up now
Tue Jun 16 15:29:19 2015 daemon.notice netifd: PureVPN (4691): Command failed: Unknown error
Tue Jun 16 15:29:20 2015 local0.notice sstpc[4730]: Resolved 23.232.***.*** to 23.232.***.***
Tue Jun 16 15:29:20 2015 local0.notice sstpc[4730]: Connected to 23.232.***.***
Tue Jun 16 15:29:21 2015 local0.notice sstpc[4730]: The certificate did not match the host: de1-sstp.pointtoserver.com
Tue Jun 16 15:29:21 2015 local0.info sstpc[4730]: Server certificated failed verification, ignoring
Tue Jun 16 15:29:21 2015 local0.notice sstpc[4730]: Sending Connect-Request Message
Tue Jun 16 15:29:21 2015 local0.notice sstpc[4730]: Started PPP Link Negotiation
Tue Jun 16 15:29:21 2015 daemon.notice pppd[4768]: pppd 2.4.7 started by root, uid 0
Tue Jun 16 15:29:21 2015 daemon.info pppd[4768]: Using interface sstp-PureVPN
Tue Jun 16 15:29:21 2015 daemon.notice pppd[4768]: Connect: sstp-PureVPN <--> /dev/pts/1
Tue Jun 16 15:29:21 2015 kern.info kernel: [  827.260000] sstp-PureVPN: renamed from ppp0
Tue Jun 16 15:29:24 2015 daemon.notice pppd[4768]: CHAP authentication succeeded
Tue Jun 16 15:29:24 2015 local0.notice sstpc[4730]: Sending Connected Message
Tue Jun 16 15:29:24 2015 local0.notice sstpc[4730]: Connection Established
Tue Jun 16 15:29:25 2015 kern.warn kernel: [  831.200000] mppe_decomp_init[0]: unknown key length
Tue Jun 16 15:29:25 2015 daemon.notice pppd[4768]: local  IP address 23.232.***.***
Tue Jun 16 15:29:25 2015 daemon.notice pppd[4768]: remote IP address 23.232.***.***
Tue Jun 16 15:29:25 2015 daemon.notice pppd[4768]: primary   DNS address 208.67.222.222
Tue Jun 16 15:29:25 2015 daemon.notice pppd[4768]: secondary DNS address 208.67.220.220
Tue Jun 16 15:29:25 2015 daemon.notice netifd: Network device 'sstp-PureVPN' link is up

Note on the last line netifd is telling me it has brought the link up, which confuses me as to why the ubus call still shows it as down.

It may be related to the error in the second line which is the result when: proto_send_update "$config" is called.

Any ideas on how to track this down? Thanks.


network config if it helps:

config interface 'PureVPN'
    option proto 'sstp'
    option server '*****.pointtoserver.com'
    option username '******'
    option password '*******'
    option sstp_options '--cert-warn'
    option pppd_options 'refuse-eap refuse-pap refuse-chap'
    option defaultroute '0'
    option ifname 'sstp-PureVPN'
    option log_level '3'

(Last edited by amwalters on 17 Jun 2015, 15:41)

Fixed, I reinitialized after the interface was up and that seemed to fix everything. After proto_run_command I have the script wait 10sec and reissue:
        proto_init_update "$ifname" 1
        proto_send_update "$config"

My guess is the problem was when initializing the interface is ppp0 which is later renamed to sstp-PureVPN. If there is a proper way to handle this aside from my little hack, let me know.

The discussion might have continued from here.