Comment 1 Mikhail Zabaluev 2007-08-20 10:29:12 UTC

Can any other internet connection be established through this VPN?

What are your SIP account settings?

Yes. I am able to use VNC to control one of my servers through the VPN link. I
can also log into a server and ping the Asterisk server. We are running
ASterisk 1.2.24 on a CENTOS Trixbox. I have my SIP account defined as username
@ ip_of_asterisk. If I am logged on my local Wireless network (With a linksys
WRT-54GS, factory default) i can make and receive sip calls no problem. Seems
to me that the SIP stack on the N800 is using eth0 instead of the tun device.

Comment 3 Mikhail Zabaluev 2007-09-14 18:04:25 UTC

Setting the proper component.
Looks like a bug in Sofia-SIP, which is known to have problems with multiple
interfaces.

Comment 4 Mikhail Zabaluev 2007-09-26 20:03:22 UTC

*** Bug 2042 has been marked as a duplicate of this bug. ***

Comment 5 Mikhail Zabaluev 2007-09-26 20:06:55 UTC

Looks like we've got a solution to try, but the result will depend on whether
the Internet Connectivity Daemon is aware of OpenVPN connections. Bear with
us...

Ok, will be looking forward to try it on.

Since my bug was marked as a dupe of this one (no biggie) I'm going to chime in
here with the hope that a  fix happens soon.
My work refuses to put their wi-fi APs on the same LAN segment as the Asterisk
server (and all our other servers) for good security reasons.  THe only way in
from the WLAN is to VPN in.

Guess that the beta is over, with OS2008 coming out in nov... we'll have to
wait for it to see ...

Comment 9 Mikhail Zabaluev 2007-10-18 19:07:08 UTC

(In reply to comment #8)
> Guess that the beta is over, with OS2008 coming out in nov... we'll have to
> wait for it to see ...

Unfortunately, no fix is likely to make it to this OS2008 release.
But we haven't forgotten about the problem.
To solve it properly, the VPN daemon needs to talk to icd (the system
connectivity service) and inform it of the new tunnel interface. This requires
a supporting API from icd which was not implemented in Chinook. We may still
come up with a specially hacked vpnc package (if only ifup/ifdown scripts need
to be changed) that will at least tell Mission Control about the IP address
obtained for the VPN. Please inform which VPN solution you use on your device,
what are the packages and where they came from; in time, we may post some
customized packages for testing through our garage project.

Hum...  I use openvpn 2.0.9, that I got from Paul Ruben's blog
(http://www.rubens.org/n800/) and at my office have an Trixbox Asterisk,
running OpenVPN version 2.0.9, OpenSSL version 0.9.7e.  I have a DES-CBC signed
certificate, the same one I use on my macbook pro to get into the VPN.

Now, from my understanding, this is a problem with all VPN connections, right?
switching to a different VPN software won't help. I even tried with
the--redirect-gateway def1 option openvpn, to no avail. And I can telnet/VNC my
servers through the openvpn from the n800, so it's functional.

Thanks for the response and for keeping this open. I imagine you guys are busy
with the new releases.

(In reply to comment #9)
> Please inform which VPN solution you use on your device,
> what are the packages and where they came from; in time, we may post some
> customized packages for testing through our garage project. 

kinda vote for openvpn and a scriptable icd informer ;)

Openvpn user here also.. after banging my head against the wall why I have the
source IP of WLAN interface in the packets going to the openvpn tun-interface
from SIP phone sw. 

I'm ready to help fix this (scripting or OpenVPN patch) but looks like there's
really no tools to do that right now? And I'm supposed to evaluate this N810
for our enterprise use.. kind of kills that if there is no VPN possible.

I am using vpnc and openvpn (and maintain both ports in extras/) - and it is
pretty anoying that SIP cannot be used.
I don't think any VPN-client should be changed to make the phone working. If I
have complex setups where e.g. only the SIP-Server routes trough tunX, what
would that notify-icd-stuff fix?

I am using other SIP software on my laptop like for example twinkle. Twinkle
explicitly asks for the device to be used (eth0/wlan0 or in my case:
tun0/tun1).
I guess asking users about the device is not a good idea, but couldn't the
device be easily guessed by looking at the current routes?

Comment 14 Mikhail Zabaluev 2008-01-24 18:16:23 UTC

OK, we might not have reached a complete solution, but there is a kludge you
can try. For SIP accounts, there's a string parameter "ip-address" which, if
set, causes the SIP client to bind to the specified address. You can use the
command line utility mc-account from libmissioncontrol-utils to set this
parameter in an existing account.

Note however, that will also select the same IP address as the preferred
candidate in SDP offers, so currently you can only use the same route for both
signaling and media. Unfortunately, there doesn't seem to be a good way to
determine the workable source address for media in absence of connectivity
checks in the manner of ICE.
If there is a real-world demand to exchange media unencrypted in the global
internet between peers that are using the same VPN cloud to do signaling, we
could think of adding a separate parameter to clamp the media IP address.

Alberto might also shed light on the dynamic MC kludges that could be used in
ifup/ifdown scripts for VPN clients.

Ok I really appreciate the effort here and I'll explore that possible kludge.
However I'm a bit confused at the root cause of this.. My understanding is that
the Linux kernel (as well as other Unices and even Windows) chooses the
appropriate source ip based on the outgoing interface unless the software has
explicitly bound it's socket to a specific IP. 

So why is the SIP client using my wlan IP? Is it using some Maemo API to tell
the icd that it needs to communicate to a specific address and then getting
back a struct or something to use for that connection? This is my guess as
there is probably some layer of connection management to handle wlan/bt
connection switchovers etc. And the D-Bus seems to be involved.. Am I getting
it even nearly right? And does this also mean that any manually added routes
need to be somehow communicated to the icd as well to make them work with
"smart networking" apps?

I guess the cleanest way to handle this would be to write an applet for OS2008
that works like the OpenVPN GUI does in Windows and it could handle the dirt
here.. until we get a clean fix.

P.S. As a kludge I tried to put in a NAT rule using iptables - to source-nat
all SIP packets going out on tun0 but unfortunately the OS2008 kernel doesn't
seem to have nat table support compiled in...

Comment 16 Mikhail Zabaluev 2008-01-25 13:44:33 UTC

(In reply to comment #14)
> For SIP accounts, there's a string parameter "ip-address"

Sorry, this is "local-ip-address".

Comment 17 Mikhail Zabaluev 2008-01-25 13:54:53 UTC

(In reply to comment #15)
> Ok I really appreciate the effort here and I'll explore that possible kludge.
> However I'm a bit confused at the root cause of this.. My understanding is that
> the Linux kernel (as well as other Unices and even Windows) chooses the
> appropriate source ip based on the outgoing interface unless the software has
> explicitly bound it's socket to a specific IP.

Sure it does, but it doesn't readily tell the application which actual source
address it is using. And SIP is braindamaged in a way that you have to use this
address also in the application layer protocol. Currently, the Sofia-SIP stack
has a bug that it can use an incorrect source address in case there are
multiple network interfaces and the socket is bound to INADDR_ANY.

> So why is the SIP client using my wlan IP? Is it using some Maemo API to tell
> the icd that it needs to communicate to a specific address and then getting
> back a struct or something to use for that connection? This is my guess as
> there is probably some layer of connection management to handle wlan/bt
> connection switchovers etc. And the D-Bus seems to be involved.. Am I getting
> it even nearly right? And does this also mean that any manually added routes
> need to be somehow communicated to the icd as well to make them work with
> "smart networking" apps?

Yes, we want some DBus notifications to avoid polling for changes in the
routing table.
The recent thought has it that we don't necessarily need icd to do this,
instead we could associate Telepathy accounts to groups or tags, and provide
the VPN clients with a mission control command (invoked over DBus) to bring
up/down the accounts associated with a certain "VPN group".

Thank you for the tip with "local-ip-address", it sounds great fiddling around
with some stun-settings :-)

> Yes, we want some DBus notifications to avoid polling for changes in the
> routing table.

Wouldn't it be possible to just poll for changes when connecting the SIP phone?
(So the user might have to manually re-connect it, but that wouldn hurt that
much imho.)

> The recent thought has it that we don't necessarily need icd to do this,
> instead we could associate Telepathy accounts to groups or tags, and provide
> the VPN clients with a mission control command (invoked over DBus) to bring
> up/down the accounts associated with a certain "VPN group".

So to make sure I get you right - you want the vpn client to tell telepathy
that we're ready to connect some SIP-account?

Just tried the Local-ip-address hack and IT WORKS!!! I was able to log into my
asterisk server and make a call.... It's kind of a pain to set up, but I can
configure my VPN server to allways assing me the same ip and add the mc-account
setup to my vpn startup script... perhaps a textbox could be added to the
advanced section of the SIP account set up screen to assing this more cleanly?
Thanks guys!

Comment 20 Mikhail Zabaluev 2008-01-29 14:13:40 UTC

(In reply to comment #18)
> Wouldn't it be possible to just poll for changes when connecting the SIP phone?

That will be done eventually: for every "flow" established with a proxy, the
source address will need to be determined through rtnetlink woodoo. The only
problem is when the route changes happen under the stack's feet. Certainly when
the next socket operation fails, it's time for reconnecting. But we probably
don't want to wait for a failure and reconnect just after the change (and,
hopefully, gracefully disconnect just before it).

> So to make sure I get you right - you want the vpn client to tell telepathy
> that we're ready to connect some SIP-account?

It's rather, that a set of accounts somehow associated with that [kind of] VPN
connection shall now connect. I agree it's still ugly, that's why this bug
still depends on bug #2691.

(In reply to comment #14)
> Alberto might also shed light on the dynamic MC kludges that could be used in
> ifup/ifdown scripts for VPN clients.

Unfortunately the VPN client does not currently execute any of the scripts
under /etc/network. If it did, then I could release a modified version of
mission-control that would be able to listen to such network changes -- it's
hackish, but proven to work.
The network script would be as simple as a dbus-send command.

(In reply to comment #20)
> But we probably
> don't want to wait for a failure and reconnect just after the change (and,
> hopefully, gracefully disconnect just before it).

So what is needed to do it properly? Is there any already-existing framework
that could be used? Alberto writes about those scripts in /etc/network, but all
I can see there is /etc/network/if-down.d/mc-disconnect-script. Not much.

Once there is a clean solution I'll happily patch vpnc and openvpn packages.

Comment 23 Mikhail Zabaluev 2008-01-29 18:18:31 UTC

(In reply to comment #22)
> So what is needed to do it properly?

There's an ongoing discussion on the Telepathy mailing list promulgating MC
account management rules in regard to connectivity events. It's not specific to
maemo, but we think a good platform-agnostic solution could benefit us. You may
want to share your thoughts there.

Comment 24 Andre Klapper 2008-05-05 14:30:02 UTC

(In reply to comment #23)
> There's an ongoing discussion on the Telepathy mailing list promulgating MC
> account management rules in regard to connectivity events. It's not specific to
> maemo, but we think a good platform-agnostic solution could benefit us. You may
> want to share your thoughts there.

for the archives:
http://lists.freedesktop.org/archives/telepathy/2008-January/001448.html seems
to be the link to the discussion

A big glowing Thank You for mentioning the local-ip-address tweak to the
configuration.  This hack has enabled me to work SIP through every NAT-enabled
router/firewall I've tried.  Without the use of a VPN, my success had been
poor... STUN doesn't always seem to work out all that well in practice.

I now have an OpenVPN tunnel available from my N810, which terminates in a new
IP subrange I've set up on my home server (firewall, mail router, and Asterisk
server).  The additional overhead of the VPN encryption and validation doesn't
seem to bother either the N810, or the home server (a lowly 200 MHz Pentium).

Thanks to the flexibility of OpenVPN, I've been able to automate the process of
switching a Telepathy SIP account configuration back and forth between VPN'ed
and non-VPN'ed operation.  This trick also eliminates the need to "hard-code"
the Maemo-side VPN IP address into the SIP account configuration, and it can be
extended to control other aspects of the SIP configuration dynamically.  I
suspect that a similar trick may be possible with other VPN clients, although I
haven't tried any.

Here's what I did.  In my /etc/openvpn/nokia.conf configuration file, I added
the following stanzas:

# Our up script will establish proper SIP bindings 
# once the VPN is alive.
up /etc/openvpn/nokia.up

# Our down script will dismiss the SIP bindings to
# the VPN once they're no longer required (or usable)
down /etc/openvpn/nokia.down

OpenVPN passes a bunch of parameters involving the VPN connection to each
script when it's executed.

The /etc/openvpn/nokia.up script reads:

#!/bin/sh
# Force the VPN SIP account to bind itself to the
# VPN address we have just been allocated.
mc-account set sip2 string:local-ip-address=$4
# Use the VPN host's address as the SIP proxy,
# since we can't count on any other being reachable.
mc-account set sip2 string:proxy-host=vpn-host.example.com 

This adjusts the SIP account configuration to bind to the IP address just
assigned by OpenVPN, and to use an "inside the VPN" endpoint on my server as
its SIP proxy.

These settings are deleted when the VPN is torn down.  The mc-account shell
utility doesn't have an "unset" option (even though the underlying library does
support this) so I do it the clumsy way via the gconftool utility:

#!/bin/sh
# When the VPN goes down, remove the forcible binding
# of the SIP account to our VPN IP address (since it
# no longer exists) and remove the requirement to use the
# host-side VPN host address as the SIP proxy.
gconftool --unset /apps/telepathy/mc/accounts/sip2/param-local-ip-address
gconftool --unset /apps/telepathy/mc/accounts/sip2/param-proxy-host

Similar tweaking can be done to other parameters in the configuration... e.g.
external-address discovery can be enabled and a STUN server specified when the
VPN connection is torn down, and discovery and STUN can be disabled when the
VPN  starts up.

It'd be nice to have a user-friendly UI to manage these sorts of settings
changes, but I'm not at all sure how such a UI can be created... "simple" and
"user friendly" don't always get along well with an intricate collection
of settings-adjustments.

Comment 26 Andre Klapper 2009-02-10 19:06:20 UTC

...so it's still valid in current versions.

Comment 27 Quim Gil 2009-05-19 00:35:27 UTC

Mikhail, Alberto, do you know whether this is fixed in Fremantle?

(In reply to comment #27)
> Mikhail, Alberto, do you know whether this is fixed in Fremantle?

I'm not sure, but it *can* be solved -- as last resort, one could now write a
mission-control plugin to track the VPN connectivity status.

Props to Mikhail Zabaluev for discovering a workaround, and Dave Platt for
automating it.  

I must add that supplying the VPN host as a VOIP proxy breaks the connection,
using the internal and external VPN host IPs.  So I recommend commenting out
this line:

  mc-account set sip2 string:proxy-host=vpn-host.example.com 

and only trying to use it if the connection fails.  I also recommend looping on
sip accounts so they all get set in a generic way, regardless of how many
accounts there are.  So the nokia.up script would look like this:

#!/bin/sh

for acct in $(ls -d /var/lib/gconf/apps/telepathy/mc/accounts/sip* | while read
i; do echo $(basename $i); done); do\

  # Force the VPN SIP account to bind itself to the
  # VPN address we have just been allocated.
  mc-account set $acct string:local-ip-address=$4

  # Use the VPN host's address as the SIP proxy,
  # since we can't count on any other being reachable.
  #mc-account set $acct string:proxy-host=vpn-host.example.com 

done

For a more generic nokia.down, use:

#!/bin/sh
# When the VPN goes down, remove the forcible binding
# of the SIP account to our VPN IP address (since it
# no longer exists) and remove the requirement to use the
# host-side VPN host address as the SIP proxy.
for acct in $(find /var/lib/gconf/apps/telepathy/mc/accounts -name sip\* | sed
's@/var/lib/gconf@@g'); do\
  gconftool --unset ${acct}/param-local-ip-address
  gconftool --unset ${acct}/param-proxy-host
done

I think that the previous suggestion would be the right thing to do for some
VPN applications, and the wrong thing for others.

My original automation is just the opposite:  it's the wrong thing for some
VPN applications and the right thing for others :-)

Specifically:  my automation was designed for the specific situation in which
the VPN termination and the SIP server are on the same machine.  Only one
specific SIP account is being "tunneled" through the VPN - the VPN is being
used primarily for this one purpose, and not as a generalized "secure pipe to
the rest of the Universe" tunnel.  My approach has the advantage that the
OpenVPN/SIP server doesn't have to provide routing or NATing of packets
arriving
through the tunnel - they go only to the SIP proxy on that machine.  Return
routing of SIP is easy, and since the SIP server/proxy "stays in the loop" for
calls from the Maemo device (i.e. doesn't reinvite the RTP away) there's no
problem in routing packets back to the Maemo device.

I believe that the most recent suggestion would be what you might want to do
if you're setting up an OpenVPN tunnel which then acts as the *sole* route
between the Maemo device and the outside world (except for the direct, one-IP
address route to the OpenVPN server itself).  In this case, switching all of
the SIP accounts over to use the VPN IP endpoint address makes sense,
because all of the SIP/RTP will be routed through the tunnel.  This approach
*will* require the continued use of STUN and/or NAT, I believe, because the
Maemo device is going to be continuing to send packets to multiple SIP servers.

I have a feeling that even with this approach, any SIP sessions in progress
at the time that the VPN goes up (or down) are still going to be broken,
because the Maemo device's SIP endpoint is going to change its IP address in
the middle of the call, and the packets are going to be routed differently
and may go through a complete different NAT gateway.

Both approaches seem valid... but they appear to serve slightly different
usage scenarios for the VPN.

The automated workarounds that hook into the client configuration break in the
most recent version of openvpn, apparently because of a security hardening
feature being introduced.  The fix is to add "script-security 2" to the client
configuration file.

It seems that the n900 meamo 5 is also affected by this bug. Using tcpdump i
see that the sip source address is the same as the wlan even though the
destination is on another network. 

The program mc-account isnt available from libmissioncontrol-utils anymore. Is
there another way to use the workaround?

If you can't use mc-account to set the local-ip-address and the proxy-host
parameters, I'd suggest adapting the code in the "nokia.down" script.

This script uses gconftool to unset these two parameters... I did it this way
because mc-account lacks an "unset" capability.  You can probably use
gconftool to set these two parameters as well - you'd need the --set
option, and perhaps the --type option as well.  I'm not sure which types
to use (probably "string" for the proxy;  dunno about the local IP address).

mc-account has been replaced in maemo5 by mc-tool which provides more or less
the same features.

Thanks for the quick response. I couldnt find the gconftool paths to use.. have
they moved? are they still used at all?

However the mc-tool does seem to do its job, even clearing the value:

~ $ mc-tool list
gabble/jabber/mjbroek_40gmail_2ecom0
sofiasip/sip/_32130
spirit/skype/mjbroek0
ring/tel/ring
~ $ mc-tool update sofiasip/sip/_32130 string:local-ip-address=192.168.8.163
~ $ mc-tool show sofiasip/sip/_32130 | grep local-ip-address
      (string) local-ip-address = 192.168.8.163

~ $ mc-tool update sofiasip/sip/_32130 clear:local-ip-address       
~ $ mc-tool show sofiasip/sip/_32130 | grep local-ip-address
~ $ 

It should be easy to change the up/down scripts with these commands. 

Eventually I was able to sip connect over openvpn.. thanks!

Having no luck in getting voip/sip to work over openvpn (N810).
I read the posts in https://bugs.maemo.org/show_bug.cgi?id=1860 and applied the
work arounds, outline in #25 and also #29 and #31. Here is the error read out I
get when I run a test in Openvpn Gui test option:

/etc/openvpn/nokia.up tun0 1500 1542 192.168.66.6 192.168.66.5 init
script failed: could not execute external program
Exitng

Here is my nokia.up script file in /etc/openvpn

#!/bin/sh

for acct in $(ls -d /var/lib/gconf/apps/telepathy/mc/accounts/sip* | while read
i; do echo $(basename $i); done); do\

  # Force the VPN SIP account to bind itself to the
  # VPN address we have just been allocated.
  mc-account set $acct string:local-ip-address=$4

  # Use the VPN host's address as the SIP proxy,
  # since we can't count on any other being reachable.
  #mc-account set $acct string:proxy-host=vpn-host.example.com 

done

Looking for help, thanks

See comment #31.  With the current version of openvpn, you must specifically
configure openvpn to allow the execution of external scripts/programs.

Also, make sure that your nokia.up and nokia.down scripts have the
execute-permission bit set.

(In reply to comment #37)
> See comment #31.  With the current version of openvpn, you must specifically
> configure openvpn to allow the execution of external scripts/programs.
> 
> Also, make sure that your nokia.up and nokia.down scripts have the
> execute-permission bit set.
> 
Thanks for your quick response. From comment #31 I understood I needed to add
the line   script-security 2   to openvpn.conf file, which I did. Here is the
execute-permission bit for /etc/openvpn/nokia.up 

-rw-r--r--   1 root    root         3443 Dec 28 10:07

The permissions are your problem.  You've set them so that the root user
can read and write the script file, but not execute it.

Try doing a "chmod 755 /etc/openvpn/nokia.up /etc/openvpn/nokia.down" to
set the execute-allowed bits.

Since you've already made the necessary security authorization change in
the openvpn configuration, I think that this should resolve your problem.

Comment 40 Andre Klapper 2009-12-30 15:44:50 UTC

(In reply to comment #32)
> It seems that the n900 meamo 5 is also affected by this bug.

Updating version info.

(In reply to comment #39)
> The permissions are your problem.  You've set them so that the root user
> can read and write the script file, but not execute it.
> 
> Try doing a "chmod 755 /etc/openvpn/nokia.up /etc/openvpn/nokia.down" to
> set the execute-allowed bits.
> 
> Since you've already made the necessary security authorization change in
> the openvpn configuration, I think that this should resolve your problem.
> 

That seem to had been the problem.

I had to use 'mc-account set sip2 string:proxy-host=vpn-host.example.com' to
get voip to work with some level of stability. For some reason my voip
(Sipgate, Gizmo, or GoogleVoice) will not stay up for a period of time.

Hi, can someone help me with the workaround for VPNC?(In reply to comment #1)

Comment 43 Mikhail Zabaluev 2010-02-21 16:32:15 UTC

(In reply to comment #41)
> I had to use 'mc-account set sip2 string:proxy-host=vpn-host.example.com' to
> get voip to work with some level of stability. For some reason my voip
> (Sipgate, Gizmo, or GoogleVoice) will not stay up for a period of time.

If you really meant the proxy-host parameter and not local-ip-address, you can
configure it in the UI.

Thanks for all comments above.
Adapted workaround for maemo5 is below:

UP script:
----------
#!/bin/sh

source /etc/osso-af-init/af-defines.sh

for acct in `mc-tool list | grep sofiasip/sip`; do 
        mc-tool update $acct string:local-ip-address=$4
done

DOWN script:
----------
#!/bin/sh

source /etc/osso-af-init/af-defines.sh

for acct in `mc-tool list | grep sofiasip/sip`; do
        mc-tool update $acct clear:local-ip-address
done
---------

Comment 45 Andre Klapper 2010-03-05 17:32:44 UTC

I must admit that I've lost track of this report because of its many comments.
So this is still a problem in 3.2010.02-8, and if so can someone please post
*exact* steps to reproduce, click by click, the expected outcome, and the
actual outcome?

(In reply to comment #45)
> I must admit that I've lost track of this report because of its many comments.
> So this is still a problem in 3.2010.02-8, and if so can someone please post
> *exact* steps to reproduce, click by click, the expected outcome, and the
> actual outcome?

This is still a problem in 3.2010.02-8.
What I did today was setup a sip account in "VoIP and IM accounts" and I am
able to login on the VoIP server with these settings if I'm in the same network
as the SIP server is - so at work for example.
To be able to connect to the SIP server when I'm at home I connect to the "work
network" using OpenVPN - this works with my computer.
This bug describes that it is by default not possible to connect to the SIP
server through this VPN connection - unless you use the workarounds as
described in previous comments.
There is nothing special to do, just create a generic SIP account and try to
connect through an OpenVPN/VNC connection. You will see that the SIP requests
are sent from your public ip address in stead of your vpn address and will not
arrive on the SIP server.

*** Bug 9837 has been marked as a duplicate of this bug. ***

#9837 was me, thanks for resolving the duplicate.

Scientific literature does state that the average life-span of a bug is 81 days
for female bugs and 148 days for male bugs
[http://memorias.ioc.fiocruz.br/105(1)/105_1_1829.pdf]

I don't know which sex this one belongs to, but it seems to be one hell of a
long-living sample. From quick reading the information in this thread, why
doesn't the SIP stack just leave the Source IP selection to the IP stack like
most other applications do? I think it could be assumed that control and data
channel will go over the same interface. That would resolve the issue without
having to work with every application that might create another interface.
Not being a SIP expert I don't know if this is feasible or why it wasn't
implemented that way in the first place.

Anyway thanks everybody for your effort and the workaround tips presented.

Disregard, after reading Bug#2691 answered that question. Sorry for noise.

How do i create up and down script files? I am using N900. do I need to set
permissions mentioned in comments 31 & 39? Pleae guide me.

(In reply to comment #44)
> Thanks for all comments above.
> Adapted workaround for maemo5 is below:
> 
> UP script:
> ----------
> #!/bin/sh
> 
> source /etc/osso-af-init/af-defines.sh
> 
> for acct in `mc-tool list | grep sofiasip/sip`; do 
>         mc-tool update $acct string:local-ip-address=$4
> done
> 
> DOWN script:
> ----------
> #!/bin/sh
> 
> source /etc/osso-af-init/af-defines.sh
> 
> for acct in `mc-tool list | grep sofiasip/sip`; do
>         mc-tool update $acct clear:local-ip-address
> done
> ---------
>

Hi heavyt

I am using N900. I am facing the same problem
/etc/openvpn/nokia.up tun0 1500 1542 10.9.170.78 10.9.170.77 init
script failed: could not execute external program
Exitng

I added these 3 lines to my .ovpn file

script-security 2

up /etc/openvpn/nokia.up

down /etc/openvpn/nokia.down


My nokia.up script

#!/bin/sh

source /etc/osso-af-init/af-defines.sh

for acct in `mc-tool list | grep sofiasip/sip`; do
mc-tool update $acct string:local-ip-address=$4
done


My nokia.down script

#!/bin/sh

source /etc/osso-af-init/af-defines.sh

for acct in `mc-tool list | grep sofiasip/sip`; do
mc-tool update $acct clear:local-ip-address
done

I have tried doing "chmod 755 /etc/openvpn/nokia.up /etc/openvpn/nokia.down" to
set the execute-allowed bits.

What is missing? Please help.

(In reply to comment #36)
> Having no luck in getting voip/sip to work over openvpn (N810).
> I read the posts in https://bugs.maemo.org/show_bug.cgi?id=1860 and applied the
> work arounds, outline in #25 and also #29 and #31. Here is the error read out I
> get when I run a test in Openvpn Gui test option:
> 
> /etc/openvpn/nokia.up tun0 1500 1542 192.168.66.6 192.168.66.5 init
> script failed: could not execute external program
> Exitng
> 
> Here is my nokia.up script file in /etc/openvpn
> 
> #!/bin/sh
> 
> for acct in $(ls -d /var/lib/gconf/apps/telepathy/mc/accounts/sip* | while read
> i; do echo $(basename $i); done); do\
> 
>   # Force the VPN SIP account to bind itself to the
>   # VPN address we have just been allocated.
>   mc-account set $acct string:local-ip-address=$4
> 
>   # Use the VPN host's address as the SIP proxy,
>   # since we can't count on any other being reachable.
>   #mc-account set $acct string:proxy-host=vpn-host.example.com 
> 
> done
> 
> Looking for help, thanks
>

Anybody successful on N900?

(In reply to comment #44)
> Thanks for all comments above.
> Adapted workaround for maemo5 is below:
> 
> UP script:
> ----------
> #!/bin/sh
> 
> source /etc/osso-af-init/af-defines.sh
> 
> for acct in `mc-tool list | grep sofiasip/sip`; do 
>         mc-tool update $acct string:local-ip-address=$4
> done
> 
> DOWN script:
> ----------
> #!/bin/sh
> 
> source /etc/osso-af-init/af-defines.sh
> 
> for acct in `mc-tool list | grep sofiasip/sip`; do
>         mc-tool update $acct clear:local-ip-address
> done
> ---------
>

Comment 53 Andre Klapper 2010-04-25 00:22:29 UTC

(Jitu: Please don't fullquote previous comments and don't answer above quotes.)

Changing Severity to enhancement to reflect the reality as this wasn't (yet)
planned to be officially supported and as bug 2691 (dependency required to
solve first) is also an enhancement request.

(In reply to comment #53)
> (Jitu: Please don't fullquote previous comments and don't answer above quotes.)

Okey

I don't quite agree with setting Severity to "enhancement". An enhancement
would be to add functionality to an otherwise working system. While I can
understand that it does not affect most people, it still is unexpected behavior
of the software ("bug"). In my opinion "minor" would be a good category.

Therefore I would politely ask if we could put Severity to "minor" to reflect
this.

Comment 56 Mikhail Zabaluev 2010-05-03 18:03:21 UTC

(In reply to comment #55)
> I don't quite agree with setting Severity to "enhancement". An enhancement
> would be to add functionality to an otherwise working system. While I can
> understand that it does not affect most people, it still is unexpected behavior
> of the software ("bug"). In my opinion "minor" would be a good category.

I agree, we shouldn't treat even third-party VPN solutions as something
unexpected on the device.

(In reply to comment #56)
> I agree, we shouldn't treat even third-party VPN solutions as something
> unexpected on the device.
> 

Isn't minor a bit low for this ? I don't know if Nokia views the N900 as a
business phone. But for all the corporate and government VOIP deployments I
have seen VPN was mandatory. 

Priority and severity should IMHO be medium and normal.

(In reply to comment #57)
> Isn't minor a bit low for this ? I don't know if Nokia views the N900 as a
> business phone. But for all the corporate and government VOIP deployments I
> have seen VPN was mandatory. 
> 
> Priority and severity should IMHO be medium and normal.
> 

Minor is really too low for it. Working VPN support is an important feature
which extends mobility and allows to use any service even when you're somewhere
behind restrictive NAT or firewall.

Could somebody please tell me how to get mc-tool installed so I can try this. I
have a N900 running version 10.2010.19-1. It tells me that I have
osso-mission-control installed but there is no mc-tool.

Thanks,
  Graham

(In reply to comment #59)
> Could somebody please tell me how to get mc-tool installed so I can try this.

Nokia-N900:~# dpkg -S mc-tool
libmissioncontrol-utils: /usr/bin/mc-tool

Comment 61 Andre Klapper 2010-08-26 20:02:50 UTC

I don't expect much progress here as it's late in the Maemo5 development cycle
and there won't be big changes anymore.

In case that you are a developer: MeeGo Handset is where the unstable
development is taking place. Feedback about MeeGo Handset issues is welcome,
e.g. via the MeeGo bugtracker at https://bugs.meego.com

Comment 62 Quim Gil 2010-08-26 20:59:52 UTC

This one doesn't even seem to be related to MeeGo Handset but MeeGo Core. See
http://bugs.meego.com/buglist.cgi?quicksearch=SIP for reference.

Comment 63 Mikhail Zabaluev 2010-08-27 17:00:15 UTC

We seem to have a vaguely specified VPN feature requirement for MeeGo:
http://bugs.meego.com/show_bug.cgi?id=4752

Comment 64 Mikhail Zabaluev 2010-08-27 17:01:58 UTC

The problem with multiple interfaces is tracked upstream:

http://sourceforge.net/tracker/?func=detail&aid=1751089&group_id=143636&atid=756076

Comment 65 Mikhail Zabaluev 2010-08-27 17:16:29 UTC

Filed as a MeeGo feature request:
http://bugs.meego.com/show_bug.cgi?id=5946

Because it has been asked here several times, this is how to get it to work on
N900 with vpnc:

/etc/vpnc/vpnc-script-post-connect-action
----------
#!/bin/sh

source /etc/osso-af-init/af-defines.sh

for acct in `mc-tool list | grep sofiasip/sip`; do 
        mc-tool update $acct string:local-ip-address=$INTERNAL_IP4_ADDRESS
done
----------

/etc/vpnc/vpnc-script-post-disconnect-action
----------
#!/bin/sh

source /etc/osso-af-init/af-defines.sh

for acct in `mc-tool list | grep sofiasip/sip`; do
        mc-tool update $acct clear:local-ip-address
done
---------

Hi.

Running Maemo 5 ver. 20.2010.36-2, which I believe is the newest and last
version that will ever come.

As I am also experiencing this issue, I guess, that the problem has still not
been fixed.

I have therefor been trying the suggested workarounds in this thread, but
unfortunately, it just breaks me openVPN connection on my device (which is
working without the fix. When I connect, it takes some seconds more than
without the fix, and I end up getting a "socket.connect().failed"

Has anyone got SIP working on N900 with 20.2010.36-2 over OpenVPN... and if so,
can you share how you succeded?

Best regards, Lars.