Monthly Archives: July 2010

Simple method for copying files over network

Copying files between computers is, fundamental. However, sometimes it is not so easy. When struggling with NFS I have been thinking; how did Microsoft get this one more right than the other ones? But Windows file sharing is not so very simple either, and it is not exactly getting easier with new versions.

However, copying files between two computers (on the same network) IS easy, especially between *NIX-based systems. Here are two methods, and they may work on Windows too, with the right tools installed (cygwin).

The following examples presume you want to copy files from a client computer to a Mac OS X machine with IP 192.168.0.20.

SSHFS
sshfs allows you to mount any folder on the server, on any folder on the client. Normal permissions apply, and you need to have sshfs installed on the client, and sshd on the server (you have it if you can ssh to the server).

Lets assume I have a user zo0ok on the Mac OS X machine, and I want to access that users home directory. Then I do (on the client):

  > mkdir zo0ok-on-osx
  > sshfs zo0ok@192.168.0.20:/Users/zo0ok zo0ok-on-osx

I need to authenticate. Done! Now the contents of the remote home directory is available locally. Note; performance is not optimal, and things like random access to files might not work. But for many purposes it works perfectly.

Netcat (nc)
netcat (or just nc) is an insanely powerful, and simple, tool. You can pipeline things, not just between programs, but over the network. More people should know about it! The following instructions assume you are logged in and have a shell on both machines.

First just see that everything works. On the mac (server), listen to port 9999:

  macosx$ nc -l 9999

Second, on the client, send message:

  client$ echo Hello World | nc 192.168.0.20 9999

If everything is fine, the message was sent to the Mac and displayed on its prompt. nc should quit as it reaches end of file.

Copy a file (hello.txt – it must exist on the client):

  macosx$ nc -l 9999 > hello.txt
  client$ nc 192.168.0.20 9999 < hello.txt

If everything is fine, you have a file on the Mac, identical to the one on the client (use md5sum if in doubt).

Copy a large file:

  macosx$ nc -l 9999 | gunzip > ubuntu.iso
  client$ cat ubuntu.iso | gzip | nc 192.168.0.20 9999

If your CPU is faster than you network, file transfer will be faster when you compress the data.

Copy a folder:

  macosx$ nc -l 9999 | tar -x
  client$ tar -c mp3collection | nc 192.168.0.20 9999

Of course you can use the -z switch for tar to enable compression, but for you mp3-collection it is not a wise idea.

Only your imagination limits what you can do with nc!

About this blog

I was happy today to see I got some comments! Wow – I didn’t even think I had any visitors. I just started this blog, so expect it to change. WordPress is tricky stuff!

VPN Server and Routing issues (arping)

Like many other people I have a network behind a NAT. The router providing the NAT has a real world routable IP (and a domain name using DynDNS). The router can forward ports to machines inside. So, I installed a VPN server (poptop) on a local machine. My setup:

  gateway: 192.168.0.3
  vpnserver: 192.168.0.2

I configure poptop to use the following IPs:

  #options.pptpd 
  localip 192.168.0.240
  remoteip 192.168.0.241-242

As I now connect, from the internet, to the VPN server, I get IP 192.168.0.241 (or 242), and the VPN server itself holds IP 192.168.0.240 on its ppp-device.

The VPN client can now connect to the VPN server, and the other way around. What doesnt work though is:

  1. VPN client can not connect to other local machines
  2. VPN client can especially not connect to the local gateway, and thus not access the internet via VPN

What is the problem? The other machines on the network:

  1. does not know who has IP 192.168.0.241 and can not reply to it directly
  2. does not have the VPN server (but the gateway) as default gateway

Fixing routing table
One way to fix this is to add a host entry on a local machine. On Linux that would be:

  # route add -host 192.168.0.241 gw 192.168.0.2

(route is similar but the details are different in every OS).
Well, this works, but it sucks because you have to do it on every local host. It sucks even more if you have a NAT-machine that you cannot run the route command on, because then you can anyway not access the internet via VPN anyway.

ARP-hack
I found a solution I liked better. There is a command called arpspoof. Chances are you dont have it :(. What it does is that it sends out pings to machine A, pretending it is machine B. That way, machine A will send its packages to you, instead of to machine B. Normally, that is not such a legitimate thing to do.

However, there is another program that you might have on your VPN server; arping. This program does what arpspoof does, but it doesn’t lie if you ask it to. But it doesn’t need to know it lies, does it? I wrote this little script (works on linux – requires bridge-utils – run it on the VPN server):

  #!/bin/sh
  brctl addbr tmpbr
  ifconfig tmpbr 192.168.0.241
  arping -c 1 -U -I eth0 -s 192.168.0.241 192.168.0.3
  ifconfig tmpbr down
  brctl delbr tmpbr

So we bring up a temporary virtual network interface (tmpbr). We assign it the IP we would want other computers to believe us to have. We send an arp-ping through our normal network interface (eth0), but from the IP of the VPN-client, to the default gateway. Then we bring down tmpbr.

Now, our gateway (192.168.0.3) believes the vpn server has IP 192.168.0.241 (which is actually true). And beyond my knowledge, it seems the other computers on the network learn this thing too 🙂 But they forget quickly if they dont use the information, so you need to run the above script often (like every minute).

You can run the arping command with slightly different switches and still be successful. This worked and made sense to me.

My VPN server happens to run OpenWRT. Both arping and bridge-utils are included by default. If you let the VPN-server be installed on your NAT-router everything is easier. You can also make some things work fairly well setting up a NAT-server on the VPN-server as well, making double NAT to the internet.

Windows 7 – faster and simpler graphics

Windows 7 is arguably the best client OS from Microsoft. It can be a little slow on old computers or netbooks). When you have enjoyed the GUI a few days and want more productivity, at the cost of some appearance, stop and disable this service:

  Desktop Windows Manager Session Manager

It still looks like Windows 7, but it looks a bit less transparent and fat.

Citrix Program Neighbourhood and Linux

If you access Windows applications via Citrix, and it is a fairly modern Citrix server chances are you can just start your Citrix receiver, give server, username and password; and voila you get your applications immediately (without the need to start a browser and log on to the Citrix portal). For me this worked easily on Windows, Android and iOS. But not on Linux. The Linux (and probably Unix) Citrix receiver (wfcmgr) has more weird features, and it is more… compliant.

PNAgent/config.xml
The key to everything is a little file:

  http://portal.mycompany.com/Citrix/PNAgent/config.xml

On all platforms except Linux/Unix you can just give Server

  http://portal.mycompany.com

but on Linux/Unix, you need to give the Server URL. Well that is kind of easy to figure out.

Connection View vs Citrix XenApp View
If you just want your applications right away, in the View menu in wfcmgr you need to switch to Citrix XenApp view. After that, start making settings under the Tools menu. I wasted hours in the useless Connection View.

Overriding in config.xml
Maybe, at this point, you are already up and running. Good for you! If not, keep reeding. In the config.xml-file, you can find the following lines:

  <LogonMethod>sson</LogonMethod>
  <LogonMethod>prompt</LogonMethod>

First one means that Single-sign-on is ok. Second one means that user/password is ok. My file did not contain the “prompt” line, nevertheless the iOS and Android app (and probably also Windows) did use the prompt mode, ignoring the policys from the file – and getting away with it (yes, Wireshark was involved at this point). But the Linux client is dead compliant, and failes with no useful error message. I really put lots of effort into running the Linux client through a NTML-proxy to get SSON – totally wasted.

So, I downloaded the confix.xml file. I replaced sson with prompt. Then I hosted the confix.xml file on my local webserver:

  http://localhost/Citrix/PNAgent/config.xml

That almost worked. But the clever (stupid!) wfcmgr then replaced all URLs in the files from portal.mycompany.com to localhost. And since I dont have a full Citrix server, it didnt find things like enum.aspx (on localhost). Well, turns out there are plenty of things like:

  <Location replaceServerLocation="true" modifiable="true" ...

that you can change into

  <Location replaceServerLocation="false" modifiable="false" ...

and then it does not destroy the URLs anymore. Now it worked!

As a final revenge I modified the following line:

  <EnableSavePassword>true</EnableSavePassword>

Windows VPN on Linux and Qemu

How to connect to a Windows VPN-server using Linux? In my case PPTP was not allowed; I was required to use L2TP and a certificate (plus domain\user and password of course). All my attempts with OpenVPN, Network Manager and Mac OS X were in vain – only Windows VPN clients seemed to work. I wanted to connect from Linux, and was successful with the following strategy:

  1. Install Windows 2000 under Qemu
  2. Configure VPN in virtual machine and share it
  3. Route VPN traffic to virtual Windows machine

My linux machine is located behind a NAT (192.168.0.2) on the 192.168.0.* network.
The network behind VPN is 10.2.*.

Windows and Qemu
I will not write a guide on how to install Windows on Qemu. But, Windows 2000 or later should work. Pick up TinyXP if you dont have a problem with it. Older version of Windows means less disk/ram usage, and you will only use it as a VPN-client anyways. On 2000/XP check out MS knowledge base article 818043.

I used real network mode in Qemu (ie a tap-device). So, I configured a bridge (br0) device, that you I connected both eth0 and tap0 to. See example below for some help. Perhaps -net user can work as well (but be aware that the Windows must have IP=192.168.0.1, see below).

Configure and Share VPN in Windows
Configuring Windows to connect to the VPN should be very easy. When you are done, right-click on your VPN connection and choose the Sharing-tab. Check “Enable Internet Connection Sharing for this connection”. Now happens something weird – the Windows machine has to have IP=192.168.0.1! You have to accept that, and hopefully your local network can be 192.168.0.* and the network you want to connect to is not 192.168.0.*.

Route VPN-traffic to Windows machine
For me, the following command on the linux machine is enough:
sudo route add -net 10.2.0.0/16 gw 192.168.0.1
Now try to ping or ssh to something on the 10.2-network. You might want to change your DNS to a DNS on the VPN.

Qemu-startup-script
I use the following script to start my Qemu machine:

  sudo route add -net 10.2.0.0/16 gw 192.168.0.1
  sudo tunctl -t tap1
  # sudo brctl addif br0 tap1
  sudo qemu -m 128 -net nic -net tap,ifname=tap1 vpn2000.qcow
  # sudo brctl delif br0 tap1
  sudo tunctl -d tap1
  sudo route del -net 10.2.0.0/16 gw 192.168.0.1

I really have no idea why I dont need to connect br0 to tap1, but it happens automatically 🙂

My working routing table looks like this:

  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  192.168.0.0     *               255.255.255.0   U     0      0        0 br0
  10.2.0.0        192.168.0.1     255.255.0.0     UG    0      0        0 br0
  link-local      *               255.255.0.0     U     1000   0        0 br0
  default         192.168.0.2     0.0.0.0         UG    100    0        0 br0

Huawei E1550 and Ubuntu 10.04 (Lucid)

There are countless guides on how to make your 3G USB Modem work on Linux. Here are some findings I made with E1550 on Ubuntu Lucid NBR.

Most importantly, the 1550 is a storage device, that later turns into a modem. To make this transformation happen, on Ubuntu you need to call a program called modem-modeswitch. I made a script for me:

  sudo umount /media/4GB
  sleep 1
  sudo umount /media/Comviq
  sleep 1
  sudo rmmod usb-storage
  sleep 1
  sudo /lib/udev/modem-modeswitch -v 0x12d1 -p 0x1446 -d -t option-zerocd 

Note:

  1. My modem has space for a memory card, mine is formatted with the label 4GB and thus mounted on 4GB.
  2. The modem-modeswitch command failed for me unless I ran rmmod (telling usb-storage uses the device). There are probably milder methods
  3. Other guides will tell you how to make this automatically happen when you insert your modem

Now Network Manager didnt work for me, I didnt understand why, and installed GnomePPP instead. Very few configurations were needed. First add yourself to the UNIX group dip. This is what it should look like:

  gt@gt-701:~$ grep dip /etc/group
  dip:x:30:gt

Reboot – or whatever is needed to make that configuration effective.
To GnomePPP I gave very little information:

  1. User = user
  2. Number = *99#
  3. Device = /dev/ttyUSB0
  4. Type = USB Modem

Odd thing is that GnomePPP didnt accept an empty user name. I didnt need an APN to get online.