Re: [coLinux-devel] Some questions, ideas and proposals regarding coLinux development

[Henry N. <Henry.Ne@Arcor.de>]

Hello Juergen,

Juergen Hennerich wrote:
> [...]
> 
> I'm currently planning to distribute a development version of coLinux.
> The feedback has been good. It runs reasonably stable. (About one crash
> per day).

This is not normal.  We would fix it, if we know, how can crash it.

> On Windows XP SP2 should be mandatory. I have observed, that SP2 reduced
> the crashes on my computer by about 90% and the slirp performance
> enhanced from 60kB to about 3.5MB per second. I heard about similar
> experiences from qemu users.
> Suggestion: Put some warning about XP pre SP2 into colinux-daemon.exe
> and on the coLinux homepage.
> 
> Most crashes seems to be cofs related. It looks like cofs is not in best
> shape. I get regularly crashes, when I leave a FD open in cofs, run a
> find in cofs or in most cases if I do a mkswap or a mkfs.... on a file
> in a cofs. Is there some development planned in the near future?

I would fix this, but I have never seen this bug on my system.
dd and mkfs on file works for me.  find and du works to.

mkswap or swapon on a file on cofs should definitly not use.
mkswap or swapon should only run, if this drive configured as cobd and 
not in use from cofs.  Remember: cofs is async! So some crashes can 
preent, if you waits 1 second after close the file and sync the filesystem.

The opened FD is perhaps a good condition for a NULL-Pointer.  How is 
the file opened?  Please give the open mode as C file or in other 
languages.  I'll try this next times.

> Also I thought I heard somewhere, that cofs is a forked version of fuse.
> I guess this means that cofs is incompatible with fuse? Are there any
> plans to change that in the near future?

The cofs source in kernel goes forward with fuse, because cofs is fuse. 
  The user daemon is separate special for colinux.  This would never 
merge with fuse scripts in a real linux world.  If you use cofs, you can 
not use fuse in the same kernel configuration.

> Are there plans to make it possible of having different coLinux drivers
> (linux.sys) installed? (I don't ask for different coLinux versions
> concurrently running)

No.  The daemon can only find linux.sys, if the daemon know the name of 
pipe.  The pipe is fix coded in linux.sys and all daemons.
Why you ask this?  You can run different colinux-daemons without 
problems.  All running colinux-daemons are separate.  You need only 
separate TAP devices, if TAP used.

One linux.sys is a manager for multiple colinux seassions at same time, 
from different images, in separate terminals.


> Is it just me or is the cosearial daemon currently broken? If I do
> something like echo hallo | colinux-serial-daemon.exe and cat <
> /dev/ttyS0 with 50% probability coLinux crashes and with another 50%
> probability windows crashes. Do others also experience this behavior or
> was that not a valid use of the coserial daemon?

Serial daemon is not usable.  It crashed all times.

> Is it possible to make a connection from inside coLinux to a device
> connected to the windows serial port? If not does anyone know a free
> tool, that can connect the windows serial port to a network port?

This is on my TODO list.  It would nice to open my internal win-modem or 
serial port from colinux.  colinux-serial-daemon with additional options 
for direct open the device is the idea.

> I have currently the following network setup:
> eth0=slirp,"",tcp:22:22/tcp:10000:10000/udp:69:69
> eth1=tuntap
> I use slirp to access the Internet from coLinux and give Windows access
> to the sshd, webmin and let the development board access the tftpd
> inside coLinux.
> 
> For mounting shares exported from coLinux I use eth1. There is no
> default bridging planned.
> 
> Now I have a few questions:
> 
> Are there plans to support the tftpd inside the slirp daemon?

tftp is include in SLiRP.  Have nerver tested it.  I'm not know, how to 
ust this feature.  Perhaps it's not right configured (inside slirp source)?
What should tftp do?  A server for host (Windows) or guest (linux) side?

> Is there an easy way to check if port 22 on Windows is already used?

Grep over "netstat -a -n -p TCP -o" and locking for "0.0.0.0:22" as 
local address.  The selected line give you the PID of process (option -o).

If the port 22 is in use, before slirp starts, then slirp does not bind 
the port (still skip over).  Any sugestion is to use a alternate port on 
host for forwarding the SSH and TELNET, such as
	eth0=slirp,"",tcp:2222:22/tcp:2323:23

> While I can install the tap driver, I don't know how to set the IP
> address for the TAP driver. Is there an easy way to do this? (netsh?)
> 
> What IP address should I use. I need an unrouted unused IP address for
> the TAP device. Is there an elegant solution to find this without user
> interaction? Are there any preferred IP addresses? Is there a setup that
> works out of the box? Does a script or something else exist already?

Use not the address in range 192.168.x.x, this is often used by local 
networks.  Any idea is to use address such 10.2.x.x with non standard 
netmask 255.255.255.0.  This is no conflict with slirp and never routed. 
  Yes, class C netmask (255.255.255.0) is not the standard netmask for 
such ipaddress, beginning with 10.x.x.x, but this is exaktly your trick 
to never (99.9%) conflicts with other non routable networks.

> Wouldn't it be possible to modify the slirp daemon to bind to an IP
> address (maybe even 127.0.0.x)? So Windows programs would have a IP
> address for coLinux. This would allow for unrestricted access from
> windows to coLinux without port remapping. The port remapping would only
> be necessary for access from external computers. This would allow
> Windows to access exported SMB shares from coLinux, without installing a
> TAP driver.

You can access from host to linux via SLiRP only if slirp is listen on a 
port.  This is named as "redirect" parameter for slirp.  The device 
determine the access: 127.0.0.1 is only accessable from Windows host, 
all your LAN adapters are accessable from external network.  Slirp was 
created for external LAN access (out and in).  The localhost connection 
is only an accidental extra.

If redir enabled, SLiRP is listen on all LAN devices, also on 127.0.0.1 
(localhost).  There is a liddle bug in slirp, if you not have a real LAN 
adapter connected.  The packes goes from host to linux, but find not the 
right way back to the host.

If you have a network (LAN from host to the world), than you can use a 
redirected port from host to colinux, for sample to "127.0.0.1:22".

It's something mistaken in the slirp code near the "ouraddr".  In 
current version slirp only supports one ipaddres for host.  But in the 
real world the host has more ones (see "ipconfig /all", with LAN cable 
and without)

But slirp can never forward all ports from host to linux.

> Because of the problems with different versions of cygwin, I plan to
> distribute only software, that is not based on cygwin. I plan to use
> Xming (http://freedesktop.org/wiki/Xming) and putty
> (http://www.chiark.greenend.org.uk/~sgtatham/putty/) are there some
> better alternatives?
> 
> While Xming works perfectly on the test machine, I have no Idea if thats
> the case everywhere. Are there any experiences?
> 
> With putty I have two problems. For automatic logins I need to generate
> a private/public key pair. Unfortunately puttygen is not scripable and
> putty uses a custom key format. I found a way to generate a putty
> compatible private key inside my initrd, but I have to put the location
> and the configuration for putty inside the registry. I guess there is a
> way to dump a sample config from my registry into a file and put that
> back with regedit, but this looks like an ugly hack.
> Has someone already done this or has a better solution?

Why not use a redirected telnet and the telnet.exe or putty?  This not 
need any keywords.  If you use TAP without bridging, than the device is 
not accessable from the world.  So is not a security problem.

> The developer mailing list is not very noisy. Is the most communication
> off list or is there maybe an IRC channel ore something similar?

On IRC are mostly first-step-questions from users.  The devel list is 
very good for me to read offline.  I have not a 24h flatrate.  From time 
to time we are in IRC and talk about hard things, to understand 
internals of colinux. Your questions here is better readable as IRC ;-)

-- 
Henry Nestler