colinux-devel — Cooperative Linux development mailing list

Re: [coLinux-devel] coLinux 0.6.0

[Paul S. <coo...@ua...>]

Hello Dan,

Thursday, March 25, 2004, 10:52:25 PM, you wrote:

DA> Hello, 

DA> coLinux 0.6.0 is released.

[]

  Thanks for this release! I would like to share my experiences with
it, hopefully adding some new information.

  My setup is p4-2.66(non-HT), MB SIS 651, 1Gb RAM, WinXP Home. My
interest with coLinux is to have good development/testing environment at
fingertips (including for such things as J2EE), so soon after playing
with this version I've set memsize to 256Mb (and so I cannot tell for
sure if issues below occur in any conf or due to such a "big"
memsize).

  So, generally it works quite well. One thing I noticed is that if I
run and stop coLinux several times, eventually it stops working -
it just hangs in initial startup messages or bails out. If hangs, it
can be ctrl+break'ed. Nothing bad (in terms of stability) seems to be
done to Windows. To be more precise, I have a very strong feeling that
this hanging-on-many-starts things happens if I suspended computer
inbetween - at least I couldn't reproduce this by just
running/stopping it several times in row.

  I didn't try to investigate above problem more simply because I
found that running coLinux handles suspend pretty well. For reference,
I'm using S3 suspend - all computer devices stop and it appears
powered off, but RAM retains information. With this setup, when I
un-suspend, coLinux puts "i8253 count too high! resetting.." and hangs
for about minute a so (totally unresponsive, telent connections drop).
But after that it recovers (usually see smb diagnostics messages) and
all's well.

  The overall stability and functioning is pretty good - I built some
pretty big J2EE app (JBoss/Tomcat, processes up to 170Mb in size,
etc.) and it seems to be ok (haven't done extensive testing yet
though). The real good news is performance - I yet have to do exact
comparisons with natively running Linux, but it's close enough
(nothing like VMware which times slower) and faster than the same app
builds in native Windows ;-) (and that's with more memory available).


-- 
Best regards,
 Paul                            mailto:coo...@ua...

Re: [coLinux-devel] Fedora Core 1 root image/script for coLinux

[morfic <mo...@bb...>]

not having a fc1 host i much rather d/l the image , that would be great

Jaroslaw Kowalski wrote:

>Hi guys!
>
>I've recently downloaded coLinux 0.6.0 and I must say it's really great
>piece of software. I run it successfully on Windows 2003 EE and I'm really
>impressed with its performance and stability.
>
>I've written a simple script that prepares a customizable root image for
>Fedora Core 1. You need to run it as root @FC1 host.
>
>Included are:
>
>- base system (minimum set of rpms)
>- openssh client/server
>- wget
>- apt-get preconfigured for 'freshrpms.net'
>
>Note that the package contains no kernel, so Fedora's native posix threads
>aren't supported.
>
>Note that you need to specify:
>
>    <bootparams>ro root=/dev/cobd0</bootparams>
>
>in your config file.
>
>The script is available (NO WARRANTY) at:
>
>http://jaak.sav.net/fedora_colinux/
>
>I can provide binaries too, but they are large (>65 MB bzip2 for 1GB root
>image) so I'd rather put them on the sourceforge.net website.
>
>Let me know if anyone finds this useful.
>
>Jarek
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>
>
>  
>

Re: [coLinux-devel] Odd /dev/cobd* semantics for raw partitions

[Ronald P. <pij...@ds...>]

>>Say, I forgot to mention that I'm running colinux on WinXP Home.  Do
>>other people see this problem?  Perhaps it's peculiar to XP.  It's
>>quite easy to test: if you have a raw partition (not a file) on, say,
>>/dev/cobd2, just do a "file -s /dev/cobd2" and see if it gives you
>>"empty" or the partition type...
> 
> 
> I'm using Windows XP Pro and running the RedHat 9 ext3 1gb image under 
> coLinux-20040319.  I had to install the "file" package via apt-get first.  
> Then the command "file -s /dev/cobd2" also gives me "empty" even though
> I can mount this device (a VFAT partition located at 
> \Device\HarddiskVolume4) on my RedHat VM.

Ditto here. However, as said earlier, this prevents me from mounting the 
  device. I am willing to spend time debugging this, but I could use 
some pointers where to start looking. Ideas?

Ronald.

[coLinux-devel] Fedora Core 1 root image/script for coLinux

[Jaroslaw K. <ja...@zd...>]

Hi guys!

I've recently downloaded coLinux 0.6.0 and I must say it's really great
piece of software. I run it successfully on Windows 2003 EE and I'm really
impressed with its performance and stability.

I've written a simple script that prepares a customizable root image for
Fedora Core 1. You need to run it as root @FC1 host.

Included are:

- base system (minimum set of rpms)
- openssh client/server
- wget
- apt-get preconfigured for 'freshrpms.net'

Note that the package contains no kernel, so Fedora's native posix threads
aren't supported.

Note that you need to specify:

    <bootparams>ro root=/dev/cobd0</bootparams>

in your config file.

The script is available (NO WARRANTY) at:

http://jaak.sav.net/fedora_colinux/

I can provide binaries too, but they are large (>65 MB bzip2 for 1GB root
image) so I'd rather put them on the sourceforge.net website.

Let me know if anyone finds this useful.

Jarek

[coLinux-devel] coLinux ported to Linux

[Dan A. <da...@co...>]

Hello,

This weekend I've successfully ported coLinux to Linux. It means that a 
vmlinux can load under an unmodified Linux 2.6.3 using a kernel module 
named colinux.ko (which is the equivalent of linux.sys in Windows).

It also means that now coLinux officially joined the club that User 
Mode Linux and plex86 had started as a Linux on Linux virtualization 
solution.

hostile17:~/colinux# uname -a
Linux hostile17 2.6.3 #3 Fri Mar 26 16:22:08 IST 2004 i686 GNU/Linux
hostile17:~/colinux# ./run
Cooperative Linux daemon
daemon: manager is already running
daemon: manager not initialized (0)
daemon: removing driver leftover
daemon: installing kernel driver
Memory size: 268435456
daemon: loading configuration from default.colinux.xml
daemon: creating monitor
co_message_switch: setting callback rule for 7
co_message_switch: setting callback rule for 2
co_message_switch: setting callback rule for 6
co_message_switch: setting callback rule for 3
co_message_switch: setting callback rule for 0
co_message_switch: setting callback rule for 4
colinux: launching net daemons
Linux version 2.4.25-co-0.6.0 (ka...@ca...) (gcc version 
3.3.3 (Debian)) #225 Sat Mar 27 17:41:45 IST 2004
64MB LOWMEM available.
On node 0 totalpages: 16384
zone(0): 0 pages.
zone(1): 16384 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/cobd0
Initializing CPU#0
Setting proxy interrupt vectors
CPU_HAS_TSC: 1Detected 2192.935 MHz processor.
Console: colour CoCON 80x25
Calibrating delay loop... 4364.69 BogoMIPS
Memory: 62128k/65536k available (1126k kernel code, 0k reserved, 62k 
data, 52k init, 0k highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 256K
CPU:     After generic, caps: bfebf9ff 00000000 00000000 00000000
CPU:             Common caps: bfebf9ff 00000000 00000000 00000000
CPU: Intel Mobile Intel(R) Celeron(R) CPU 2.20GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rg...@at...)
devfs: boot_options: 0x0
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
cobd: loaded (max 8 devices)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Cannot open root device "cobd0" or 75:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 75:00
 daemon: monitor terminated, reason 3
colinux: shutting down
daemon: daemon cleanup
daemon: removing kernel driver

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] Odd /dev/cobd* semantics for raw partitions

[Ronald P. <pij...@ds...>]

Seth LaForge wrote:
> I had similar problems to others here with getting raw partitions to
> work, but for a somewhat different reason: raw partition access seems
> to be rather incomplete.  In particular, a raw partition mounted as a
> /dev/cobd* device, when read using ordinary tools, always seems to
> show up as a zero-length file.  If /dev/cobd2 is a raw partition, 
> "cat /dev/cobd2" will return immediately and "file -s /dev/cobd2" prints
> "empty".  This is probably also the cause of mount not autodetecting
> filesystem type.  From these signs I had decided that my raw
> partitions weren't working, when in fact they were working fine and a
> 'mount -t ext3 /dev/cobd2 /mnt/whatever' worked.
> 
> However, if /dev/cobd0, say, is pointed at a file (rather than
> partition), it acts like a normal block device: you can cat it, 'file
> -s' it, strings it, etc.
> 
> So, it looks to me like there's something incomplete about the raw
> partition access.  Perhaps colinux isn't getting the correct partition
> size from Windows somehow?

This would explain why I can't get my ReiserFS partition mounted. 
ReiserFS does some checking on the size of the device, and currently 
complains about it.

Ronald.

Re: [coLinux-devel] Odd /dev/cobd* semantics for raw partitions

[Clemmitt M. S. <sig...@bl...>]

Hi,

On Fri, 26 Mar 2004, Seth LaForge wrote:
> Say, I forgot to mention that I'm running colinux on WinXP Home.  Do
> other people see this problem?  Perhaps it's peculiar to XP.  It's
> quite easy to test: if you have a raw partition (not a file) on, say,
> /dev/cobd2, just do a "file -s /dev/cobd2" and see if it gives you
> "empty" or the partition type...

I'm using Windows XP Pro and running the RedHat 9 ext3 1gb image under 
coLinux-20040319.  I had to install the "file" package via apt-get first.  
Then the command "file -s /dev/cobd2" also gives me "empty" even though
I can mount this device (a VFAT partition located at 
\Device\HarddiskVolume4) on my RedHat VM.

					Clemmitt

Re: [coLinux-devel] Odd /dev/cobd* semantics for raw partitions

[Seth L. <se...@of...>]

Ronald Pijnacker <pij...@ds...>:
> Seth LaForge wrote:
> > So, it looks to me like there's something incomplete about the raw
> > partition access.  Perhaps colinux isn't getting the correct partition
> > size from Windows somehow?
> 
> This would explain why I can't get my ReiserFS partition mounted. 
> ReiserFS does some checking on the size of the device, and currently 
> complains about it.

Probably so.

Say, I forgot to mention that I'm running colinux on WinXP Home.  Do
other people see this problem?  Perhaps it's peculiar to XP.  It's
quite easy to test: if you have a raw partition (not a file) on, say,
/dev/cobd2, just do a "file -s /dev/cobd2" and see if it gives you
"empty" or the partition type...

Seth

[coLinux-devel] Odd /dev/cobd* semantics for raw partitions

[Seth L. <se...@of...>]

I had similar problems to others here with getting raw partitions to
work, but for a somewhat different reason: raw partition access seems
to be rather incomplete.  In particular, a raw partition mounted as a
/dev/cobd* device, when read using ordinary tools, always seems to
show up as a zero-length file.  If /dev/cobd2 is a raw partition, 
"cat /dev/cobd2" will return immediately and "file -s /dev/cobd2" prints
"empty".  This is probably also the cause of mount not autodetecting
filesystem type.  From these signs I had decided that my raw
partitions weren't working, when in fact they were working fine and a
'mount -t ext3 /dev/cobd2 /mnt/whatever' worked.

However, if /dev/cobd0, say, is pointed at a file (rather than
partition), it acts like a normal block device: you can cat it, 'file
-s' it, strings it, etc.

So, it looks to me like there's something incomplete about the raw
partition access.  Perhaps colinux isn't getting the correct partition
size from Windows somehow?

Seth

[coLinux-devel] coLinux 0.6.0

[Dan A. <da...@co...>]

Hello, 

coLinux 0.6.0 is released.

This is the same as the 20040322 snapshot.

Stability on SMP / HT setups was not addressed yet, so beware.

The supplied vmlinux supports iso9660, reiserfs, and smbfs.

* Version 0.6.0 AKA "Getting even"
  * Ballard, Jonathan H.:  
    * fixed implicit declarations
    * added co_os_realloc()
    * fixed overflow with the XML memory config
    * reimplemented os/winnt/user/daemon.c.
      A threaded implementation with with message queue,
      wait state, and error recovery.
    * merged the NT-native console. 
    * console updates and improvements (cocon, console-nt)
    * update FLTK/console clearscreen (20040305)
    * enabled console-nt exit (20040305)
  * Added more checks to the XML parsing.
  * Made the context switch code more sensitive about the processor's 
    capabilities, running coLinux on old AMD processors will hopefully not 
    cause a reboot anymore.
  * Linux patch upgraded to 2.4.25.
  * Hopefully fixed the %fs/%gs issue for good.
  * vmlinux can now be bigger while not causing the host to boot, this means
    that you can compile more stuff not as modules.
  * Reimplemented the method in which coLinux allocates memory in the host
    kernel. It now allocates memory from the unmapped free page pool, which  
    means you can use more than 256MB of RAM, unlike the previous method. 
    Note that the first coLinux boot may be a little slower since Windows is 
    freeing cache and swapping out stuff in order to provide accommodation for 
    Linux's memory. You can see it in action by looking at the Task Manager.
  * NSIS-based installer for the Windows binary distribution (based on 
    work by NEBOR Regis.
  * gettimeofday() now works. Things that broke because they depended on it
    should now work. I have to enable port I/O in order to for this to work,
    but I plan to disable it in the future. If you compile a new vmlinux
    Make sure that CONFIG_X86_TSC is enabled in your .config file.
  * New daemon switch -t: Type of console to launch. Default is fltk.


-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] WinPcap problems

[Crypto <cr...@dv...>]

I have a wireless lan and XP's bridging doesn't work at all. I had to setup
two subnets and to add some entries in the routing table.

--
Crypto

>How does the ctrl click 2 interfaces rt click select "bridge these
>interfaces" work with wireless in XP ? My best guess is that it would have
>to set the card to master mode or it would not work at all or it does not
>create a true layer2 bridge.

Re: [coLinux-devel] A different networking config...

[tei <42...@in...>]

<offtopic crap's>

run coLinux under coWindows under a emulated Mac OS/X86 under Bochs 
compiled for my GPU Ati Radeon 8600 XT has a pixel shader hack OpenGL 
compatible.

just kidding :D


</>



ch...@to... escribió:

> Some days this still is enough for me. But my ultimate goal is to get the
> instance of vmware that is hosting windows To run on the coLinux that is
> being hosted by that instance of windows. Then remove the hardware
> altogether ;)
> 
> chris
> 
> 
>> There's
>>gotta be something more interesting to do with colinux than to install
>>windows under vmware under colinux under windows and laugh maniacally.
>>

Re: [coLinux-devel] WinPcap problems

[<ch...@to...>]

Ok I could be totally off base with this but wouldn't putting the card in
master mode bypass the mac address requirement?

Here is an article that talks about building an AP that acts like a bridge
on linux
http://www-106.ibm.com/developerworks/library/l-wap.html?ca=dnt-429

iwconfig can tell the card to go to master mode. I do not know if this is
suposed to be possible with all cards or not.
Of course in this situation this would have to be set in windows. And the
configuration software might not allow this.
But maby it could be set with regedit.

How does the ctrl click 2 interfaces rt click select "bridge these
interfaces" work with wireless in XP ? My best guess is that it would have
to set the card to master mode or it would not work at all or it does not
create a true layer2 bridge.

Just throwing some ideas out there.

chris


> Ronald Pijnacker wrote:
>>>Ok, yeah, this one is easy. IEEE 802.11 specs require that wireless
>>>cards only transmit packets with a source MAC that is their own. You can
>>>ping your own machine because it's clever enough to deal with the packet
>>>internally, but you can't ping the router because the packet never
>>>leaves the card.
>>
>>
>> Hmm... that explains the problem. I'll try with a cable... I do see the
>> light on the wireless card blinking, though...
>
> Just to let you know that indeed it works when using a cable. Thanks for
>   saving me days of useless debugging effort.
>
> Ronald.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] A different networking config...

[<ch...@to...>]

Some days this still is enough for me. But my ultimate goal is to get the
instance of vmware that is hosting windows To run on the coLinux that is
being hosted by that instance of windows. Then remove the hardware
altogether ;)

chris

>  There's
> gotta be something more interesting to do with colinux than to install
> windows under vmware under colinux under windows and laugh maniacally.
>

Re: [coLinux-devel] A different networking config...

[Hugo C. <hu...@hu...>]

Hi

I agree that having colinux provide firewall and packet shaping for a hos=
t machine may seem a bit cumbersome. However the consumer level firewalls=
 for windows that i've tried (many) are extremelly buggy, to the point of=
 not following the rules reliably! They also enjoy that lovelly feature t=
hat if one day your registry wakes un in a bad mood, they will forget the=
ir rules and either block it all or allow it all. Packet-Shaping is _unhe=
ard of_ in those kinds of products. With the growing popularity of both f=
ilesharing and VOIP a solution like this seems to have its problem waitin=
g for it already. Why should you have to yell at your daughter to turn of=
 kazza because grandma called your VOIP line? Damm, i have to turn off my=
 filesharing clients to browse the web sometimes. Not to mention that the=
 extremelly high number of connections opened by filesharing shows the gl=
aring memory leaks of modern consumer-level win32 firewalls.

It goes around. My idea with this post was to get help with the right con=
figuration for this specific aplication, but also to start a little brain=
storming. I read in the list about the (amazingly few!) technical problem=
s and bugs with colinux but not about it's real applications. I think thi=
s software is an amazing idea and execution. It brings the best of 2 worl=
ds, together, for free. You don't see that every day. There's gotta be so=
mething more interesting to do with colinux than to install windows under=
 vmware under colinux under windows and laugh maniacally.

Sorry for the long non-technical post - i started this discussion in the =
Help forum but it was only in this list that i got replies.

Hugo

> sorry Clemmitt I Just re: to you first time meant to re: all
> 
> Disclaimer: IANAMCSE and IANAcLD
> If the bridging is setup correctly then only the ethernet level of the
> stack  should be used for the unfiltered data because windows does not
> have an address on the physical lan all TCP/IP trafic will be filtered.=

> 
> But Clemmitt's point is valid because there could be non TCP/IP
> holes such
> as netbeui or any other network layer protocols that are left open on
> windows or a carefully formed TCP/IP packet that could exploit a
> flaw in
> the lower layers and also any raw ethernet holes that there may be in
> windows. Long story short this would not be any better than any
> other host
> based firewall except for maby a lot more flexability. Other windows
> specific host based firewalls probably take the fact that they are
> running
> on windows and at least holler at you if netbeui or something else
> is on.
> 
> chris
> 

Re: [coLinux-devel] A different networking config...

[<ch...@to...>]

I did not mean so much a filtering bridge like that just a virtual layer2
bridge between the physical card and eth0 with a public ip on eth0 then a
full TCP/IP connection between eth0:1 and a second tap with private
addresses. But the filtering bridge may be possible as well.

Dependending on how the ISP is set up nothing should be coming down the
pipe but TCP/IP but you never know. netbeui is unroutable so the attacker
would have to be on your side of any router.(or have a way of getting
there)

A Linux box with IPTables setup would be just as vunerable if it had an
IPX stack or a HyperSCSI driver. (scsi over raw ethernet like iSCSI but
without the TCP/IP overhead)  That is why a dedicated firewall is always
best.

With a little carefull setting up of windows It should be good enough
security

chris
> Hey,
>
> On Tue, 23 Mar 2004 ch...@to... wrote:
>> Disclaimer: IANAMCSE and IANAcLD
>> If the bridging is setup correctly then only the ethernet level of the
>> stack  should be used for the unfiltered data because windows does not
>> have an address on the physical lan all TCP/IP trafic will be filtered.
>
> You're right!  I didn't look at it the right way, now did I? :^P
> Didn't think about bridging.  I'm very NAT-centered....
>
> I've never done the "filtering bridge" setup before.  But
> it's a thoroughly cool method.  If you haven't heard about it,
> here's a decent page Google coughed up:
>
>    http://ezine.daemonnews.org/200211/ipfilter-bridge.html
>
> and there are plenty more out there about configuring xBSD as a
> filtering bridge.  In short, (I hope I'm summarizing this correctly,
> please correct me if I'm not) this is a network box configured
> without an IP address on either its up- or down-stream interfaces.
> This means it's more or less "invisible" but still filters
> packets.  Keeps crackers from knowing it's there, and makes
> it very difficult to break into as well.
>
> If Windows can work in a similar way, bridging without an IP address
> on its outside Network Connection, this would eliminate a significant
> vulnerability space and might just do what you want.  Anyone else
> out there know if this is possible (IANAMCSE, either :^)?
>
> 					Clemmitt

Re: [coLinux-devel] WinPcap problems

[Ronald P. <pij...@ds...>]

Ronald Pijnacker wrote:
>>Ok, yeah, this one is easy. IEEE 802.11 specs require that wireless
>>cards only transmit packets with a source MAC that is their own. You can
>>ping your own machine because it's clever enough to deal with the packet
>>internally, but you can't ping the router because the packet never
>>leaves the card.
> 
> 
> Hmm... that explains the problem. I'll try with a cable... I do see the
> light on the wireless card blinking, though...

Just to let you know that indeed it works when using a cable. Thanks for 
  saving me days of useless debugging effort.

Ronald.

Re: [coLinux-devel] A different networking config...

[Clemmitt M. S. <sig...@bl...>]

Hey,

On Tue, 23 Mar 2004 ch...@to... wrote:
> Disclaimer: IANAMCSE and IANAcLD
> If the bridging is setup correctly then only the ethernet level of the
> stack  should be used for the unfiltered data because windows does not
> have an address on the physical lan all TCP/IP trafic will be filtered.

You're right!  I didn't look at it the right way, now did I? :^P
Didn't think about bridging.  I'm very NAT-centered....

I've never done the "filtering bridge" setup before.  But
it's a thoroughly cool method.  If you haven't heard about it,
here's a decent page Google coughed up:

   http://ezine.daemonnews.org/200211/ipfilter-bridge.html

and there are plenty more out there about configuring xBSD as a
filtering bridge.  In short, (I hope I'm summarizing this correctly,
please correct me if I'm not) this is a network box configured
without an IP address on either its up- or down-stream interfaces.
This means it's more or less "invisible" but still filters
packets.  Keeps crackers from knowing it's there, and makes
it very difficult to break into as well.

If Windows can work in a similar way, bridging without an IP address
on its outside Network Connection, this would eliminate a significant
vulnerability space and might just do what you want.  Anyone else
out there know if this is possible (IANAMCSE, either :^)?

					Clemmitt

Re: [coLinux-devel] A different networking config...

[<ch...@to...>]

sorry Clemmitt I Just re: to you first time meant to re: all

Disclaimer: IANAMCSE and IANAcLD
If the bridging is setup correctly then only the ethernet level of the
stack  should be used for the unfiltered data because windows does not
have an address on the physical lan all TCP/IP trafic will be filtered.

But Clemmitt's point is valid because there could be non TCP/IP
holes such
as netbeui or any other network layer protocols that are left open on
windows or a carefully formed TCP/IP packet that could exploit a
flaw in
the lower layers and also any raw ethernet holes that there may be in
windows. Long story short this would not be any better than any
other host
based firewall except for maby a lot more flexability. Other windows
specific host based firewalls probably take the fact that they are
running
on windows and at least holler at you if netbeui or something else
is on.

chris

> Hi,
>
> On Tue, 23 Mar 2004, Hugo Campos wrote:
>> Hi, i've been playing with CoLinux and i've been thinking about
how one
>> would configure a windows-colinux with a single public IP so that
the
>> public IP was assigned to colinux. Then it (colinux) would share
(NAT)
>> internet access to windows. That would effectivelly provide a Linux
>> Firewall, which can be configured with fun things like packet
shaping
>> and all, in a Windows box with (i believe) little overhead for
normal
>> DSL/Cable speeds.
>
> I think Chris's earlier post sounds like something neat to try.  But
> I'll repeat what I said on the Help forum FWIW.
>
> Disclaimer: IANAcLD.  Windows is the host OS for coLinux.  To
access the
> coLinux network functionality, the packets have to pass through the
> Windows network stack first.  So I don't think it's possible for a
coLinux
> installation to filter the incoming packets for the instance of
Windows
> it's running on.
>
> But I think Chris has a good point.  If what you want is packet
shaping
> or filtering of Windows user traffic, his idea sounds like an
excellent
> place to start.  I don't think this will protect against an attack
> that exploits network-related holes in Windows.
>
> If I've got this wrong, someone please correct me!
>
>                                         Clemmitt
>
>

Re: [coLinux-devel] undefined reference in alloc.o

[Daniel S. <dan...@ya...>]

Alejandro, 
    Thanks for your help - that did the trick.
 
Also, I was wondering about how to debug linux.sys? I have WinDbg and am set up to do kernel debugging, but since linux.sys is being built with gcc, I was wondering if WinDbg would be able to read the symbols. 
 
Does anyone have any ideas about this? Has anyone tried building linux.sys with Microsoft's DDK? 
 
Bye the way - This is a great product. I have it running on my laptop using my Fedora installation with VNC for my X server. Great job guys.
 
 


Daniel R. Slater mailto:dan...@ya...

Re: [coLinux-devel] A different networking config...

[Clemmitt M. S. <sig...@bl...>]

Hi,

On Tue, 23 Mar 2004, Hugo Campos wrote:
> Hi, i've been playing with CoLinux and i've been thinking about how one
> would configure a windows-colinux with a single public IP so that the
> public IP was assigned to colinux. Then it (colinux) would share (NAT)
> internet access to windows. That would effectivelly provide a Linux
> Firewall, which can be configured with fun things like packet shaping
> and all, in a Windows box with (i believe) little overhead for normal
> DSL/Cable speeds.

I think Chris's earlier post sounds like something neat to try.  But
I'll repeat what I said on the Help forum FWIW.

Disclaimer: IANAcLD.  Windows is the host OS for coLinux.  To access the 
coLinux network functionality, the packets have to pass through the 
Windows network stack first.  So I don't think it's possible for a coLinux 
installation to filter the incoming packets for the instance of Windows 
it's running on.

But I think Chris has a good point.  If what you want is packet shaping
or filtering of Windows user traffic, his idea sounds like an excellent
place to start.  I don't think this will protect against an attack 
that exploits network-related holes in Windows.

If I've got this wrong, someone please correct me!

					Clemmitt

Re: [coLinux-devel] undefined reference in alloc.o

[Alejandro R. S. <as...@MI...>]

This was discussed sometime around Pi day. Look back into the archives
for a message from Sean Brook on March 14, 2004 which contains an
updated patch for w32api and read the surrounding discussion to find out
more.

-Alejandro

On Tue, 2004-03-23 at 12:17, Daniel Slater wrote:
> I am trying to build colinux and am getting the following error when building
> driver.o:
> 
> ------------------------
> 
> i686-pc-cygwin-gcc -Wl,--base-file,colinux/os/current/build/driver.base.tmp \
> -Wl,--entry,_DriverEntry@8 \
> -nostartfiles -nostdlib \
>         -o junk.tmp colinux/os/current/build/driver.o -lntoskrnl -lhal -lgcc
> colinux/os/current/build/driver.o(.text+0x43e2):alloc.c: undefined reference to
> `__imp__MmAllocatePagesForMdl@28'
> colinux/os/current/build/driver.o(.text+0x4539):alloc.c: undefined reference to
> `__imp__MmMapIoSpace@16'
> collect2: ld returned 1 exit status
> make: *** [colinux/os/current/build/driver.base.tmp] Error 1
> 
> -------------------------
> 
> When I ran dumpbin on libntoskrnl.a, I see that it exports
> _MmAllocatePagesForMdl@16 and
> _MmMapIoSpace@12
> 
> Looking at the headers reveals that these are the symbols it should be looking
> for - i.e. MmMapIoSPace pushes 12 bytes of arguments and MmAllocatePagesForMdl
> pushed 16 bytes of arguments.
> Any ideas about why ld us becomming confused about these symbols? 
> 
> Note: I am trying to build snapshot colinux-20040321, but I have seen the same
> problem with snapshot colinux-20040313.
> 
> 
> =====
> Daniel R. Slater mailto:dan...@ya...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

[coLinux-devel] undefined reference in alloc.o

[Daniel S. <dan...@ya...>]

I am trying to build colinux and am getting the following error when building
driver.o:

------------------------

i686-pc-cygwin-gcc -Wl,--base-file,colinux/os/current/build/driver.base.tmp \
-Wl,--entry,_DriverEntry@8 \
-nostartfiles -nostdlib \
        -o junk.tmp colinux/os/current/build/driver.o -lntoskrnl -lhal -lgcc
colinux/os/current/build/driver.o(.text+0x43e2):alloc.c: undefined reference to
`__imp__MmAllocatePagesForMdl@28'
colinux/os/current/build/driver.o(.text+0x4539):alloc.c: undefined reference to
`__imp__MmMapIoSpace@16'
collect2: ld returned 1 exit status
make: *** [colinux/os/current/build/driver.base.tmp] Error 1

-------------------------

When I ran dumpbin on libntoskrnl.a, I see that it exports
_MmAllocatePagesForMdl@16 and
_MmMapIoSpace@12

Looking at the headers reveals that these are the symbols it should be looking
for - i.e. MmMapIoSPace pushes 12 bytes of arguments and MmAllocatePagesForMdl
pushed 16 bytes of arguments.
Any ideas about why ld us becomming confused about these symbols? 

Note: I am trying to build snapshot colinux-20040321, but I have seen the same
problem with snapshot colinux-20040313.


=====
Daniel R. Slater mailto:dan...@ya...

Re: [coLinux-devel] A different networking config...

[<ch...@to...>]

This may be possible. I do not think that it is possible to have more than
1 virtual nic on coLinux yet but It probably does not matter because you
are not limited by the speed of the hardware. So an alias on the 1 nic is
probably good.
ifconfig eth0 realPublicIpAddress netmask .....
ifconfig eth0:1 192.168.0.1
enable everything to foreward for now

setup 2 TAP interfaces on windows one to do an native bridge to eth0 and
the other to eth0:1 and only give windows a 192.168.0.? address and setup
192.168.0.1 as the windows gateway.

You may want to try to create an image of smoothwall or another router
type distro to make things easy you want to be able to toggle easily
between pass everything and block everything while trying to get this
configured

check out some of the howto's on tldp.org for some networking info

just making some guesses here I have not tried any of this

chris

> Hi, i've been playing with CoLinux and i've been thinking about how one
> would configure a windows-colinux with a single public IP so that the
> public IP was assigned to colinux. Then it (colinux) would share (NAT)
> internet access to windows. That would effectivelly provide a Linux
> Firewall, which can be configured with fun things like packet shaping and
> all, in a Windows box with (i believe) little overhead for normal
> DSL/Cable speeds. Having a computer services company of my own i could see
> myself selling some form of this solution. Any ideas?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&opïick
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

[coLinux-devel] A different networking config...

[Hugo C. <hu...@hu...>]

Hi, i've been playing with CoLinux and i've been thinking about how one w=
ould configure a windows-colinux with a single public IP so that the publ=
ic IP was assigned to colinux. Then it (colinux) would share (NAT) intern=
et access to windows. That would effectivelly provide a Linux Firewall, w=
hich can be configured with fun things like packet shaping and all, in a =
Windows box with (i believe) little overhead for normal DSL/Cable speeds.=
 Having a computer services company of my own i could see myself selling =
some form of this solution. Any ideas?