Nortel IP 1535 Development

[tshif]

Instructions for setting up OpenVPN-2.1.4 on the Nortel IP 1535 Videophone:
...
Dave

HW: v1
FW: 2.7.6

I was wondering how many folks have tried these steps with success. I seem to be having some troubles.

All the steps get accomplished - but when it comes time to launch OpenVPN on the phone:
/usr/local/bin/openvpn --config /etc/openvpn/client.conf
I get:
'-sh: /usr/local/bin/openvpn: Cannot allocate memory' error.

When working with the hardware clock, when I get to
:
/usr/local/bin/ontpd -s -f /usr/local/bin/ntp.conf

I get a 'Segmentation fault"

I know youll need more info to help - but Im not sure what.

Anyone have any thoughts?

 

[rxcomm]

I seem to be having some troubles.

Sounds like you may have a corrupt binary. Double-check the filesizes to make sure they are the same as these:

# cd /usr/local/bin
# ls -las ontpd
 320 -rwxr-xr-x    1 0        0          323599 ontpd
# ls -las openvpn
1858 -rwxr-xr-x    1 0        0         1892887 openvpn

If not, be sure you transfer the files to the phone using binary mode. Windows likes to add little bits into the file if you transfer in ascii mode.

If they are the same, then hmmm.... I'll have to think about that one.

Dave

 

[tshif]

Dave - 100% correct. It was a binary transfer issue. I cant beleive I did that....
Thanks!!! And thanks for the process. Its amazing, and it works!

 

[rxcomm]

it works!

That's good to hear.

Also, TheMole and I have been working to optimize OpenVPN on the IP 1535. I'll have some more to say on this in a day or two.

Dave

 

[tshif]

Also, TheMole and I have been working to optimize OpenVPN on the IP 1535. I'll have some more to say on this in a day or two.
Dave

Most cool! This has been a great project - even to be a bystander - whats not to like with a Crypto-phone? :clapb:

I just wish I had some skills to offer the project - ah well, I'll just be a really happy consumer/cheerleader for this one.

 

[rxcomm]

DSCP/TOS bits

It looks like the Nortel 1535 phone application does not set DSCP bits in SIP or RTP packets. In some network configurations, this may make a difference in latency/jitter. If your phone and pbx are on the same subnet, its not worth worrying about.

The DSCP bits can be changed using iptables, but you need to insert the kernel module ipt_DSCP.o.

You can download the module here.

Put the module in the /lib/modules/2.4.25-vrs2-pxa1/kernel/net/ipv4/netfilter directory, and load it with:

insmod /lib/modules/2.4.25-vrs2-pxa1/kernel/net/ipv4/netfilter/ipt_DSCP.o

You can then add the following rules to iptables:

iptables -A OUTPUT -t mangle -p udp --dport 5060 -j DSCP --set-dscp-class CS3
iptables -A OUTPUT -t mangle -p udp --dport 23000:23999 -j DSCP --set-dscp-class EF
iptables -A OUTPUT -t mangle -p udp --dport 24000:24999 -j DSCP --set-dscp-class CS4

You need to wait until after the phone application has started, however, as one of the first things it does is clear out iptables.

Dave

 

[tshif]

Dave - do you have reccomendations about where and what exactly to put in your start up script (when used with the VPN system you put together with Mole)?

 

[rxcomm]

Nortel 1535 startup scripts

Actually, I've changed the way I do startup quite a bit since I last posted about it. You can find my lastest startup scripts here. I've modified the way I start the network. In the case of starting OpenVPN, I start the network in the scripts, rather than running the phone application once to start the network and again with OpenVPN. So you will need to configure your network parameters in the rc.ovpn script before starting with OpenVPN. This version of the script does work with both ethernet and wireless networking.

A couple of comments about the OpenVPN config: 1) I recommend removing the lzo-comp line from your config. RTP packets are compressed already due to the codecs used, and so removing the OpenVPN compression actually increases VoIP network performance significantly. 2) The PXA270 processor in the phone just doesn't have the horsepower to run a full 128 bit key with the Blowfish cipher (default OpenVPN cipher). So I've reduced the keysize by adding the lines:

cipher BF-CBC
keysize 48

to my client.conf (and server.conf) file. This is obviously a compromise for the security of the vpn, but I don't think a bad one. OpenVPN discards the cipher key hourly. The only known attack against the Blowfish cipher is brute force, and so far as anyone knows, no one can crack a 48 bit key in one hour using brute force. I haven't exhaustively tested what keysizes give acceptable network performance - it is certainly possible that larger key sizes will work on the phone. It would be good to hear of people's experiments in this area. Blowfish keys can range in size from 32 bits to 448 bits in steps of 8 bits.

Lastly, I've significantly optimized the openvpn binary included in the above tarball. I would recommend replacing the original binary (size 1892887 bytes) with the new one (size 1407216 bytes). This new binary is about 20% faster than the old one.

Dave

 

[bmore]

Actually, I've changed the way I do startup quite a bit since I last posted about it. You can find my lastest startup scripts here.
Dave

The link is not found.

 

[rxcomm]

Sorry - should be http://dave.tycho.ws/n1535/ovpn_boot.1.2.tar.bz2 .

Dave

PS: bmore - your idea about the display name is a good one. I'll try to implement it shortly.

 

[robf]

EDIT: Ignore this. Problem Solved.
Once I properly completed the install process of the boot scripts everything worked as expected.

Not much traffic on this topic for a while so I thought I'd throw in my 2 cents on my openvpn experiences with a Turkish model of the 1535 phone which is a HW V1.0 phone with V2.93 of the firmware.

I've got things working now but I had to add an extra step that I did not see in this thread regarding openvpn configs and the use of iroute and ccd files.

That may have been necessary as a result of my phone being in the same subnet as my vpn server but I don't think so. (Not the final configuration for deployment but just long enough to get it configured.)

I point the vpn client to the external address of my internet connection and let the router loop back the traffic forwarding port 1194 to my openvpn server. That works great.

Although I could ftp, ping and telnet in both directions through the tunnel I could not get the phone to register. UDP was not making it to the TUN device on the server.

Running tcpdump -nn -i tun0 on the phone revealed the problem which I'm assuming others are not seeing.

The 10.8.0.0 subnet is my TUN0 vpn network and the
192.168.1.0 subnet is my eth0 local network.

In the tcpdump output below note the source address of the registration on 5060!
It should be 10.8.0.6 and not 192.168.1.117.

Note also that the pings are showing proper source addresses which is why they succeed.

 tcpdump -nn -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 68 bytes
18:39:55.097917 IP 192.168.1.117.5060 > 10.8.0.1.5060: UDP, length: 477
18:40:39.978853 IP 10.8.0.1 > 10.8.0.6: icmp 64: echo request seq 1
18:40:39.979168 IP 10.8.0.6 > 10.8.0.1: icmp 64: echo reply seq 1

I'm wondering if someone else with a different firmware version could try the tcpdump -nn -i tun0 command on the phone with their tunnel up.
I'd like to verify that yours shows a proper source address in the tcpdump output.

This problem causes the phone to fail when registering as the packets are dropped by the openvpn server with an invalid source address error as follows.

 MULTI: bad source address from client [192.168.1.117], packet dropped

These appear in the log while the phone is trying to register and of course, as I said, registration fails

The Kludge Fix is to do the following on the openvpn server:

create a ccd directory to hold the routes for each affected client
mkdir /etc/openvpn/ccd

Now add the following lines to the end of your server.conf file.

client-config-dir ccd
route 192.168.1.0 255.255.255.0

Substitute your local subnet in the route command. NOT the Tunnel subnet!

now in the /etc/openvpn/ccd directory created above you need a file for the client.

The following command will create that.

echo "iroute 192.168.1.0 255.255.255.0" > /etc/openvpn/ccd/client1

Change the subnet to match your phones local subnet and the client1 filename to match the common name of your client.
hint: your key and crt file are usually your common name unless you changed it when building the keys.

execute a
service openvpn restart
on the openvpn server and things should now work.
(you might have to restart openvpn on the phone.)

This kludge works but if the local subnet of the phone changes then I think you would have to change the server side to point to the new subnet.

Here is the post where I found this information on bad source address errors.

I'm investigating fixing this with iptables on the server side but wanted to ping the collective team to see if anybody else is seeing such behavior. Perhaps its just an anomaly with the Turkish firmware or I have something royally fouled up.

Many Thanks in advance for reading.

Regards,
Rob.

 

[robf]

Ignore This. Problem Solved.

Greetings folks,

further analysis shows that the traffic is flowing back to the phone over the local net and not through the TUN0 net which I suspected would happen.

So the question I have is.
How do you make the phone app bind to the TUN0 device?

This is key as currently its putting its source address as the eth0 device and not the tun0 addr.

Its also putting the source address in the payload so the asterisk server wants to send back on the local net and not the TUN0 net. Not good.

Has anybody else done a successful deployment of openvpn on the turkish phones with firmware V.2.93?

If so, I'd love to hear of your experiences and see your configs.

Many Thanks,
Rob.

 

[robf]

My apologies for the previous two posts.

I was operating under the assumption that I didn't need to install rxcomm's boot scripts to make the phone app work properly and that was completely wrong. You have to install these scripts once you verify you can successfully run and connect your openvpn client.
If you don't do that then you'll see the behavior I described in my earlier posts.

Once I installed those per the instructions and made a few mods everything worked great.

I've actually bricked a 3rd phone so I'll have to get the console connection built to revive that phone but my other two phones work great.

The mod I made to the scripts in my working phones was to add the --daemon switch to the openvpn command line in the openvpn.sh script. My line of thinking is that this is what allows the rc.* scripts to continue and not hang waiting for openvpn to exit which of course it won't if you don't run it in the background. Perhaps I'm wrong but this is my current theory.
I failed to add that switch to the 3rd phone which is why I think it is hanging.

The behavior I'm seeing is that the phone hangs on the "Turkish" splash screen and what I'm thinking is that the rc.* scripts are stopped because I didn't start openvpn in daemon mode.

Why am I thinking this is the case? Because the VPN is up and I can ping on the tun0 address. Sadly, telnetd is not up yet so I can't connect to the phone.

It would be nice if I could issue a command on the openvpn server side to make the client exit as I think then the scripts would continue.

Does anybody know if there is such an incantation with openvpn?

As I said I'll be making the console connection up and getting it connected but if somebody has any other suggestions I am certainly open.

Many thanks to all who have contributed as these are great phones and the ability to use openvpn with them is huge.

Thanks,
Rob.

 

[swimboy]

OpenVPN connected, but phone won't register

I've made progress setting this up on my Turkish 1535's, but after getting the OpenVPN connection up, the phone won't register. I can use the built-in web browser on the phone to see the piaf interface on the asterisk server, so I'm certain that the connection is up, but the registration just times out.

I'm not an OpenVPN expert, and I'm wondering if there's something in my configuration that's causing the registration to fail. I'm using pfSense v2.0, and it configures everything for me. I don't see anything obvious that would block the registration.

Here's the server config:

dev ovpns1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher BF-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 10.0.3.106
tls-server
server 10.4.1.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 10.4.0.0 255.255.255.0"
ca /var/etc/openvpn/server1.ca 
cert /var/etc/openvpn/server1.cert 
key /var/etc/openvpn/server1.key 
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
persist-remote-ip
float
keysize 48

And here's the client config:

dev tun
persist-tun
persist-key
proto udp
cipher BF-CBC
tls-client
client
resolv-retry infinite
remote 10.0.3.106 1194
tls-remote fw2
pkcs12 /etc/openvpn/fw2-udp-1194.p12
tls-auth /etc/openvpn/fw2-udp-1194-tls.key 1
keysize 48

 

[swimboy]

Keep from bricking the phone

BTW, during testing, I made one change to the rc.local script that rxcomm provided that saved me from bricking my phone. I added a line between

if [ -e /usr/etc/.ovpn ]; then
  /usr/etc/rc.ovpn

so that it reads

if [ -e /usr/etc/.ovpn ]; then
  rm /usr/etc/.ovpn
  /usr/etc/rc.ovpn

That way, when I put the .ovpn file in /usr/etc, it only calls the rc.ovpn script once and removes the .ovpn file. If something causes your phone to misbehave, a reboot should bring it back. Once you're certain that you've got everything configured correctly, you can remove the extra line, and the .ovpn file will stay put, and the script will run every time you reboot the phone.