This is the best way to setup CoLinux networking, because it has a high speed TAP interface for the local X server traffic, and only uses WinPCap for external traffic. It also does not require Internet Connection Sharing to be enabled because WinPCap creates a virtual network adapter on top of the existing one.
Note that this will only work if your local X server can accept connections from 192.168.x.x, some commercial X servers have a license scheme limiting the IP range. If yours does, you can assign IP addresses within that range to your coLinux VM, but be sure to get the netmask, network, and broadcast addresses correct! (Hint: Try using an online calculator like this one: http://www.treachery.net/tools/calculator/ )
Also note that it is impossible to create a connection from the host PC to coLinux, or vice versa, using WinPCap. (You can ping though.)
1. Install TAP driver that comes with coLinux. This will create another host network interface.
2. Configure the TAP interface to 192.168.37.10, netmask 255.255.255.0, no default gateway. It will show as “disabled” unless coLinux is running. (If you enter a default gateway, your default gateway will be overwritten whenever the interface comes up, resulting in loss of connectivity to your external network.)
3. Install WinPCap 3.1
4. Configure default.coLinux.xml as follows:
4a. Be sure to change "Local Area Connection" to the Windows name of the network connection you wish to piggyback on, and that the MAC address does not conflict with anything on your network.
5. Configure your DHCP server to dish out an IP address on your network for the MAC address above.
6. Configure /etc/network/interfaces inside coLinux as follows:
<pre>auto eth0 eth1
iface eth0 inet static
address 192.168.37.20
network 192.168.37.0
netmask 255.255.255.0
broadcast 192.168.37.255
iface eth1 inet dhcp</pre>
7. Configure /etc/hosts inside coLinux as follows:
<pre>127.0.0.1 localhost
192.168.37.20 colinux
192.168.37.10 windows</pre>
<h2>Connecting via X server</h2>
<h3>Application-mode X server</h3>
First, modify your login script to export DISPLAY=windows:0.
Run an X server (such as Cygwin-XFree86, <a href="http://wiki.freedesktop.org/wiki/Xming">Xming</a>, WeirdX/WeirdMind) on the Windows side, and permit connections from 127.0.0.1 and 192.168.37.20 (the latter is required because a connection through the coLinux TAP adapter is not considered to be a "localhost" connection, like an X connection tunneled through ssh is).
The easiest way to do this for Cygwin is to add an .xinitrc file in your user's Cygwin home directory containing the following:
<pre><code>
#!/bin/sh
xhost 192.168.37.20
exec /etc/X11/xinit/xinitrc
Remember to make it executable with “chmod +x .xinitrc”.
For Xming, you will have to do the following in a NT cmd shell after starting Xming using the xhost from the Xming-tools package:
set DISPLAY=localhost:0
xhost 192.168.37.20
You could automate this with a batch file in an execN line in the coLinux configuration file (something like exec0=c:\xming.bat).
On the coLinux side, place the following in /etc/bash.bashrc:
if [ -z "$DISPLAY" ]; then
export DISPLAY=windows:0
fi
Then any X11 application that is run under coLinux will automatically connect to the X server running on the Windows side.
XDMCP (X-terminal) login for session-centric X server
Alternatively, you can use XDMCP to log into a graphical session on the Linux VM. In order to do this, you will need to install a display manager such as xdm, gdm, or kdm and a window manager (such as IceWM or blackbox) and/or desktop environment (such as GNOME, KDE, or XFCE) in the coLinux VM.
To avoid excessive configuration, install a window manager or desktop environment that installs a .desktop file into /usr/share/xsessions. (For example, XFCE 4 does this.) This .desktop file will be read by the display manager and then presented as a choice on the login screen.
To configure gdm to accept remote XDMCP connections, first make sure gdm is running, then run gdmsetup as root. Go to the ‘Remote’ tab, and to the ‘Configure XDMCP’ button. Make sure ‘Listen on UDP port’ is set to 177. Also, remove the preconfigured X server on screen 0 so that gdm doesn’t try to start an X server inside coLinux when it starts up (this would be silly because coLinux has no access to the Windows graphics device). Close gdmsetup, and restart gdm if you made any changes.
Run the following command to start your desktop session:
"C:\Program Files\Xming\Xming.exe" :0 -query 192.168.37.20 -notrayicon
You can add other Xming options such as -clipboard if you wish (as of this writing, -clipboard didn’t work with a XDMCP session). Or you can use the Cygwin XWin.exe with similar options.
If you have a X server already running and listening for single application connections, you can start your XDMCP session on :1 instead of :0.
Windows Firewall note
Disable the Windows Firewall on the primary network interface, otherwise the proxy traffic will not get through. Hope you have an external firewall or a NAT router…
HTTP Proxy
Privoxy or another HTTP/FTP proxy server is useful as well if all you can get going is the private connection and not the bridge. For Privoxy, check the “listen-address” in c:\Progra~1\Privoxy\config.txt and make sure it is set to either 0.0.0.0 or 192.168.37.10. Then configure Apt, wget, web browsers, etc inside coLinux to use http://windows:8118/ as the proxy server. Watch the output in the Privoxy window if you have problems.
Note that starting Privoxy on boot will not work if the listen-address is not 0.0.0.0, because the coLinux instance must be running first, or the TAP interface will not be available for Privoxy to bind to. But setting it to 0.0.0.0 allows anyone who can reach your computer to use your Privoxy. A convenient way around this is to create a batch file privoxy.bat in the coLinux directory:
@echo off
ping -n 20 localhost > NUL
c:
cd \progra~1\privoxy
privoxy
This waits 20 seconds (long enough for coLinux’s network to be brought up) and then launches Privoxy.
And then in coLinux’s config file, add this line:
exec0=privoxy.bat
Then Privoxy will be launched when coLinux is started.
TODO:
Proxy auto-configuration may be useful. Privoxy itself, or Apache under Cygwin, could serve the autoconfiguration file. I don’t think WPAD is useful because it requires a DHCP or DNS server which is typically not installed on a Windows workstation, but PAC only requires a web server (which Privoxy could behave as for the purposes of proxy discovery, if appropriately modified). Then the user would enter http://windows:8118/wpad.dat and all proxy settings would be taken care of. Unclear if this is much easier than manual proxy configuration, since Privoxy only supports HTTP/HTTPS proxy.
http://en.wikipedia.org/wiki/Proxy_auto-config
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
http://www.wrec.org/Drafts/draft-cooper-webi-wpad-00.txt
http://www.ehsco.com/reading/20061003iwc1.html
SOCKS Proxy
To proxy ALL network traffic, it is possible to set up a SOCKS proxy. Some free SOCKS proxy servers for Windows are jsocks and hhproxy.
Far from conflicting with Privoxy, this is actually a fairly nice setup, because HTTP traffic will go directly to Privoxy (as long as 192.168.37.10 is the application’s configured HTTP proxy server) while all other application-layer traffic will go through the slower SOCKS proxy. No unnecessary double-proxying!
SOCKS Server setup
jsocks (note: no DNS support)
Download the JSocks binary distribution. If you have a modern Java JRE and the java.exe is in your path, make the bin/SOCKS.bat line look like this:
@java.exe -cp ..\lib\socks_apps.jar;..\lib\socks.jar SOCKS %1 %2 %3 %4 %5 %6 %7 %8 %9
Edit the socks.properties using the defaults, except the following:
range = localhost;192.168.
and comment out the “users”, “proxy” and “directHosts” options. Then run the SOCKS.bat from the bin/ directory. You should see the following in a NT shell window:
Loading properties Reading file socks.properties Setting iddle timeout to 600000 ms. Setting accept timeout to 60000 ms. Setting udp timeout to 600000 ms. Using Ident Authentication scheme: Range:localhost; 192.168. Users:Everybody is permitted.
I am not sure yet how if DNS requests can be proxied with jsocks. (TODO).
hhproxy
The alternative is hhproxy, which is a closed source SOCKS 4 proxy, but is free and supports proxying DNS requests. This document describes setting up coLinux with hhproxy.
SOCKS client setup
The Linux applications must know to contact the SOCKS server for network requests instead of trying to contact the real server. This is accomplished by overriding the BSD Socket API functions in the C library.
On the coLinux side, first edit your /etc/resolv.conf to point to the Windows host:
nameserver 192.168.37.10
tsocks
apt-get install tsocks. Edit /etc/tsocks.conf as the following:
local = 192.168.37.10/255.255.255.255
local = 192.168.37.20/255.255.255.255
server = 192.168.37.10
# If you are using hhproxy, set this to 4 instead of 5
server_type = 5
server_port = 1080
and comment out the Path { } section. Test some application by:
$ LD_PRELOAD=/usr/lib/libtsocks.so telnet 1.2.3.4
If that connection (to some outside IP address) succeeds, the proxy is working. Edit /etc/ld.so.preload and add /usr/lib/libtsocks.so to the list. This is necessary because setuid network applications will not allow LD_PRELOAD, as a security measure. Be sure to heed the warnings in tsocks(8) regarding LD_PRELOAD.
(If your Windows side proxy server doesn’t support DNS requests, and thus you need to send DNS requests through the proxy to a nameserver on the proxy side, you will need to recompile tsocks with the --enable-socksdns option to configure. Unfortunately, this will only work for programs that use the C library resolver functions. Any program that implements its own resolver code will not have its DNS requests proxied. It is a much better solution to have a Windows side proxy server like hhproxy, so that DNS requests are handled at the protocol level rather than at the library level.)
proxychains
An alternative to tsocks is proxychains. The disadvantage of proxychains is that setuid network programs must be run as root. apt-get install proxychains, and edit /etc/proxychains.conf:
random_chain
chain_len = 1
tcp_read_time_out 15000
tcp_connect_time_out 10000
socks5 192.168.37.10 1080
Then test it:
$ proxychains ssh 1.2.3.4
I have encountered a problem where, due to some spurious Windows problem or perhaps a new group policy, it became impossible for the SOCKS server to bind to port 1080 on the Windows side, returning a Winsock Access denied error instead. The only way around this was to change to a different port (e.g. 1081) both in the SOCKS server and in the SOCKS client library configuration.
Samba/SMB/CIFS file sharing
Client-based connection
To use a Samba client such as smbclient or smbfs/cifsfs to connect from coLinux to the Windows host, you will have to connect using the IP address of the Windows end of the TAP tunnel (i.e. 192.168.37.10) instead of its name “windows”. If you do not do this, the connection will fail with NT_STATUS_DUPLICATE_NAME for reasons unknown to me.
Mount-based connection
coLinux comes with SMB filesystem support built into the kernel. (CIFS was unavailable as of this writing.) A convenient way to make use of this is with pam_mount. Download the pam_mount source package, apt-get build-dep libpam-krb5 (to pull in common PAM module build dependencies), ./configure && make install. Then follow the instructions in README to add pam_mount.so to the ‘auth’ and ‘session’ PAM module configuration, copy config/pam_mount.conf to /etc/security/pam_mount.conf. and place a line like the following in /etc/security/pam_mount.conf:
volume * smbfs 192.168.37.10 & /home/&/nthome uid=&,gid=&,fmask=0640,dmask=0751,workgroup=WORKGROUP - -
where WORKGROUP is the name of your workgroup or NT domain. This MUST be set to the correct workgroup or domain or logins will fail.
This will automatically create the directory ‘nthome’ in the user’s directory and mount their Windows home directory into it, assuming that their login name and Windows volume name are the same, and that their coLinux and Windows passwords match. (If not, a more complex configuration is required.) You may need to install other programs like lsof, since coLinux is shipped as a barebones Debian system.
You may need to adjust the NT security on the Windows side so that your username has read-write access to your Windows home folder, and thus you will have read-write access on the Linux side. It sounds counterintuitive that this would not be the default, but that is the way it is sometimes.
Note: I have noticed that occasionally the Samba connection will begin to fail for no apparent reason. In my case, this was caused by smbfs not being able to reconnect because the NT password had expired. Since the user’s session is still logged in, the user has no idea that this is the case until he receives a message from Windows to that effect (usually at login). You can check for this by using smbclient -L 192.168.37.10 and if the return code is NT_STATUS_PASSWORD_EXPIRED, then you know that this is the culprit. Change the password on both the Windows and coLinux sides, and logout/login and things will be back to normal.
Printing
Setting up printing requires that you set up a shared printer on the Windows host to print via Samba, or enable the built-in Windows LPD server. Then either configure CUPS with the smb backend to print to that printer from coLinux, or install and configure LPRng using ‘windows’ as the remote host and the Windows printer name as the queue name.
For Samba printing, use smbclient -L 192.168.37.10 to find out what the printer share name is.
Note that the Windows LPD service will return an error and log an error 4008 in the event log if there is a space in the printer name. Also, when connecting to the Windows LPD service you are using the printer “friendly name” rather than the share or network name. This poses a problem because “friendly names” frequently contain spaces, and also cannot be changed by the user in Windows 2000 or later. If you want to use LPD to print to a network printer that has a “friendly name” with spaces in it, you will have no choice but to use a SOCKS proxy to connect directly from coLinux to the print server.
Audio
NAS method
To enable audio, install nas, nas-bin, and audiooss on the coLinux side, and add your user to the “audio” group:
# addgroup user audio Adding user 'user' to group 'audio' ... Done.
Also, add ‘export AUDIOSERVER=windows:0’ to /etc/bash.bashrc. (The :0 implies that nasd is listening on TCP port 8000. If you omit this variable, $DISPLAY is used, but $DISPLAY may be windows:1, which would cause NAS clients to try to connect to the wrong port.)
Log the user out and log back in.
Download the Cygwin build of NAS (linked from the NAS homepage). After extracting the archive, copy all the *.exe files to your Cygwin bin directory (i.e. c:\cygwin\bin). Then open a Cygwin shell. Invoke ‘nasd.exe -aa &’. (-aa disables MIT Magic Cookie authentication, which is unnecessary and unnecessary as well as hard for me to configure correctly. ) Then run ‘auinfo -audio tcp/localhost:8000’. The response should include “Network Audio System Release 1.8 – VoxWare” or similar. Run auinfo -audio tcp/windows:8000 in coLinux and you should have the same output. You can test sound output quickly by installing ‘alsa-utils’ and issuing in coLinux:
$ auplay /usr/share/sounds/alsa/Front_Center.wav
You should hear a voice say “Front Center”. If you do not, and there are no error messages, check your Windows mixer settings and speaker volume.
Try to use applications which directly support NAS for best performance, such as alsaplayer-nas or mpg123-nas. mpg123-nas is especially nice because it can stream files over the network and can use a HTTP proxy server: (mpg123-nas -p http://windows:8118 http://myserver/mysoundfile.mp3). Invoke alsaplayer as ‘alsaplayer -o nas’ or set up an alias (alias alsaplayer=”alsaplayer -o nas” in /etc/bash.bashrc); alsaplayer is useful because of all the different sound encodings it supports (i.e. Vorbis, FLAC, MOD).
To enable sound for applications which use the OSS /dev/dsp device, add /usr/lib/audiooss/libaudiooss.so to /etc/ld.so.preload. (FIX)
ALSA applications cannot use NAS since there is no NAS backend for alsa-lib. Some ALSA applications such as alsaplayer provide NAS output plugins.
To enable sound in KDE applications, install artsd, kcontrol, and kmix, set the mixer output to maximum in kmix, then run kcontrol and go to ‘Sound & Multimedia -> Sound System’. Ignore the “Enable networked sound” option. Go to Hardware, and select ‘Network Audio System’ for the audio device. Click ‘Apply’. Then go to “System Notifications” and play some sounds. You should hear the sounds (albeit with some lag).
It is not currently possible for GNOME/ESD to use NAS directly (a patch for that exists and may be integrated into EsounD someday). For now, just try to use the audiooss preload hack.
For SDL programs, install libsdl1.2debian-all and add export SDL_AUDIODRIVER=nas to /etc/bash.bashrc.
Links
http://wiki.colinux.org/wiki/Network
http://wiki.colinux.org/wiki/WinPcap
http://www.sklar.com/blog/archives/55-Wrangling-CoLinux-Networking.html
PulseAudio method
PulseAudio is a newer sound server than NAS that does not have many of its legacy limitations.
Go to this document which tells you how to set up PulseAudio server on the Windows side. I recommend using anonymous authentication, telling PulseAudio to listen only on the coLinux network interface IP address, and creating a shortcut that starts pulseaudio.exe with the --high-priority option.
In coLinux, then install the pulseaudio package. Once installed, then run padevchooser, click on the tray icon, expand Default Server, click Other… and then enter windows as the server and hit OK. Then, under Preferences, enable the applet to startup on session login.
Having done this, then start up Audacious or some other program with a PulseAudio output plugin and check that the sound works correctly.
Once the basic PulseAudio setup is verified to work, then you can tweak it to a “perfect” setup to work best with all applications by following these instructions.