colinux-users — coLinux users mailing list

Re: [coLinux-users] port forwarding problem at colinux

[Josep M. A. S. <ja...@pa...>]

Your configuration is a bit unusual, (meaning that some of the solutions do not
apply to you), yet there are still possibilities:

First of all, your configuration only allows you to use colinux via NAT, because
else, you would need a secondary *internet* IP for it.

Usually, a router would do the NAT for you, so you would redirect packets
entering a specific port to the colinux machine. In your case, you need a
software NAT package installed in Windows, which would then map the ports. And
you're lucky: there's a mode of colinux that let's you do it: "Slirp".

http://colinux.wikia.com/wiki/Network#Slirp

Briefly: you need to specify in the config file, the ports that you need to
access from internet, and configure linux as dhcp (or static, with the info on
that page)

Note that the slirp-net-daemon shipped with the current stable release has a
minor isssue with packets, and there's an updated on on sourceforge

http://sourceforge.net/project/showfiles.php?group_id=98788&package_id=107317&release_id=385643

-- 
 _ _  /~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-\
 o o  | Josep Ma [JAZ]                 |
  *   | ICQ UIN: 7014661               |
 `-´  | Messenger: ja...@ho... |
      \-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~/

[coLinux-users] port forwarding problem at colinux

[Menghan Z. <thu...@gm...>]

I installed Debian/testing on windows xp sp3
I config my networks like this:

on XP: I have a static ip: 59.66.143.127
on Debian: my /etc/network/interfaces is like:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.0.40
netmask 255.255.255.0
gateway 192.168.0.1

I installed virtual network adapter as the tuntap way
eth1=tuntap(from example.conf)

then all goes well, colinux could connect www.google.com, and my XP can
connect my colinux
But now i have to start a service in my colinux at port 23(you're right,
it's telnet).I want to share the service to the IPs outside my local
machine,
that is to say: ip(59.66.143.126) can telnet my colinux at port 23.
how should i config my colinux network?

//I'm sorry for my poor English.

-- 
Keep In Touch!
Electronics Engineering Department, Tsinghua University

Dorm Tel: 8610 5153 4319
Mobile: 86 13401088180
MSN: zhe...@ho...
Email: zhe...@gm..., zm...@ma... 

Re: [coLinux-users] Colinux vanishing from network nieghbourhood

[Henry N. <hen...@ar...>]

Josep Maria Antolín Segura wrote:
> When you talk about a bridge, you talk about the windows XP feature that lets
> you connect two network interfaces, creating a third one that then has the IP,
> right? (I sort of got confused by you saying "both the host and the bridge have
> the same IP").
> 
> Or do you mean the pcap-bridged type of connection of colinux?
> 
> By the description of the windows machine losing connectivity to outside world,
> it indeed sounds as a problem on the bridge, or (less probable) on network
> card, cable, switch or otherwhise physical element.
> 
> So for now, take a look at
> http://colinux.wikia.com/wiki/Network#TAP_with_Windows_Software_Bridge
> and see if that's what you have.
> 

That sems me the XP-Bridge. Not the pcap-bridge mode.

One problem, I see, you have self made: "The bridge and the host have
the same IP"

You need to know, that the bridge and the host have different MAC. If
you shutting down the bridge, than the other PC would try to send
packets to the old MAC. After a while (some minutes) the MAC cache would
be cleared automaticly and the host network should work normal. You can
watch the MAC-cache from XP command prompt with "arp -a" or "arp print"
(I currently don't remember).

To fix this you have one of thise choices:
A) Configure a different IP address for the bridge (different from all
others you currently have)
B) Configure the TAP-Win32 as "always connected" to have all times the
bridge online, also if coLinux is not running
C) Run the "arp" with clear parameter after shutting down coLinux

-- 
Henry N.

Re: [coLinux-users] Colinux vanishing from network nieghbourhood

[Josep M. A. S. <ja...@pa...>]

Just to be sure:

When you talk about a bridge, you talk about the windows XP feature that lets
you connect two network interfaces, creating a third one that then has the IP,
right? (I sort of got confused by you saying "both the host and the bridge have
the same IP").

Or do you mean the pcap-bridged type of connection of colinux?

By the description of the windows machine losing connectivity to outside world,
it indeed sounds as a problem on the bridge, or (less probable) on network
card, cable, switch or otherwhise physical element.

So for now, take a look at
http://colinux.wikia.com/wiki/Network#TAP_with_Windows_Software_Bridge
and see if that's what you have.

-- 
 _ _  /~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-\
 o o  | Josep Ma [JAZ]                 |
  *   | ICQ UIN: 7014661               |
 `-´  | Messenger: ja...@ho... |
      \-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~/

[coLinux-users] Colinux vanishing from network nieghbourhood

[Dave C. <dc...@da...>]

Hi,

Windows XP has a limitation on the number of computers can connect to it.

To get around this I'm running a box with linux acting as a shared
repository so that all the XP machines on the network can read and
write small files to it (thus enabling a pretty crude communication
system). This works fine.

Now I've  installed colinux onto one of the machines in the hope of
using the colinux vm to act as the repository. I've used the same
samba smb.conf as I used with the separate linux machine.

The Colinux vm bridged to the host XP machine's network connection.

Both the host and the bridged connection have the same static IP 192.168.10.100

The Colinux vm is on 192.168.10.200

I can ping both 192.168.10.200 and 192.168.10.100 from 192.168.10.13

And I can ping 192.168.10.13 from both of the other machines.

However, accessing the Temp directory on the Colinux vm is
problematic. Sometimes the permissions are not granted for the other
XP machines, sometimes they are unable to access the contents of the
Temp directory on the VM and sometimes they can. Sometimes the Colinux
VM doesn't show up on the Network neighbourhood at all. Sometimes the
machines lock up and do not respond for long periods.

Initially all machines can see the Colinux vm and the Temp directory.
But after a while the outside machines cannot see it and then the host
XP machine cannot see the others, but can see the VM. Also, the VM and
the XP host lose the ability to  ping the outside machines.

Anyone know what's going on here? 'dmesg' and '/var/log/messages'
don't reveal much of interest.

I don't think it's a samba  issue as I can use the same smb.conf on
the linux box and that works.

I think it's an issue with the bridge. If I switch off the Colinux vm,
the XP host cannot see the other network until the bridge is removed.

Re: [coLinux-users] Colinux 0.7.3 with windows Vista 32-bit running on EM64 architecture

[Henry N. <hen...@ar...>]

Shalin Mehta wrote:
> I need to know if colinux 0.7.3 will run with windows vista 32-bit on
> 64-bit processor.

In normal case it is no problem to run coLinux on Vista 32-bit. A 64bit
CPU I have checked my self some weeks ago:
http://www.henrynestler.com/colinux/screenshoots/Vista-Album

Only one known and unresolved problem is a buggy BIOS from a Laptop:
http://www.nabble.com/Vista-SP1---complete-failure-to17936090.html

>  I am using andlinux on windows XP 32 bit for running my favorite latex
> editor kile. The version I am using relies on colinux 0.7.3.
> <http://0.7.3.> I am planning to get a new Desktop from Dell and XP is
> no longer shipped by them as standard configuration. The processor is
> Intel Core 2 Duo EM64T but the OS can be 32-bit.

PS: Dell has a "downgrade" option from Vista to XP. Some are for 10 EUR
 or 0 EUR, depens on the Vista version they ship as default.

-- 
Henry N.

[coLinux-users] Colinux 0.7.3 with windows Vista 32-bit running on EM64 architecture

[Shalin M. <sha...@gm...>]

Hi folks,

I need to know if colinux 0.7.3 will run with windows vista 32-bit on 64-bit
processor.
 I am using andlinux on windows XP 32 bit for running my favorite latex
editor kile. The version I am using relies on colinux 0.7.3. I am planning
to get a new Desktop from Dell and XP is no longer shipped by them as
standard configuration. The processor is Intel Core 2 Duo EM64T but the OS
can be 32-bit.

Thanks to developers for great software and the forum for input

cheers
shalin
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~
Shalin Mehta
mobile: +65-90694182
blog: shalin.wordpress.com
~~~~~~~~~~~~~~~~~~~~~~~~~~
Bioimaging Lab, Block-E3A, #7-10
Div of Bioengineering, NUS Singapore 117574
website: http://www.bioeng.nus.edu.sg/optbioimaging/colin/index.html

Liver Cancer Functional Genomics Lab, #6-05
National Cancer Centre, Singapore 169610
http://www.nccs.com.sg/researcher/02_04d.htm

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Mike F. <vap...@gm...>]

On Wed, Jun 25, 2008 at 1:56 PM, Henry Nestler wrote:
> Hello Mike,
> Mike Frysinger wrote:
>> On Mon, Jun 23, 2008 at 5:42 PM, Henry Nestler wrote:
>>> Have fixed. Here is the new executable. Your Netcat + tcpcopy example
>>> was working:
>>> http://www.henrynestler.com/colinux/testing/stable-0.7.3/20080623-slirp/colinux-slirp-net-daemon-0.7.3-2.zip
>>
>> sorry for the delay.  this version indeed works fine for me with tftp.
>>  thanks a ton!
>
> Ok. Thanks back, for your very good problem descriptions :-)
>
> For all others: Update for coLinux SLiRP daemon have moved to:
> http://www.henrynestler.com/colinux/releases/0.7.3/update/
>
> Is also available on SF file releases:
> http://sourceforge.net/project/showfiles.php?group_id=98788&package_id=107317&release_id=385643

you can probably close this out then:
http://sourceforge.net/tracker/index.php?func=detail&aid=1995862&group_id=98788&atid=622063

thanks again for coLinux ... it fills such a perfect niche (i
personally dont use it as i dont typically run Windows, but it's
perfect for the people i give it to)
-mike

Re: [coLinux-users] Vista SP1 - complete failure

[Henry N. <hen...@ar...>]

Hello Jonathan,

Jonathan Deitch wrote:
>  See attached ... Vista also thinks the timer is on irq0 ...

Hm. Perhaps Vista does it virtualy, I mean that is a print foe users
happynes?

I will setup a trace version for coLinux to see what IRQ we have forward
and how often. Than we can see more cleary here. I hope.

> Paolo Minazzi wrote:
>>> If you not have the tools, then please open your hardware device control
>>> center (I'm german, so please sorry for wrong translation) and view your
>>> hardware devices in a list sorted by type, than lets see the IRQ list
>>> seen by Windows. - Something must be difference from the list you send
>>> from Knoppix. The question is what? You can send me a screenshot from
>>> that view.
>>>
>>> --
>>> Henry N.
>>>     
>> I did not know this and  I lose some minutes.
>> So I post these lines ....
>>
>> Contorl-Panel
>> System
>> Device Management
>> Show (in the menu)
>> Resources for Type
>> IRQ
>>
>> This is very very important.
>> Please send a screenshot !
>>
>> Bye,
>> Paolo
>>   

I have checked a Vista near my friends, where coLinux was running last
time I have tested.

The config tool exist as C:\Windows\System32\msinfo32.exe

Free translated from german it is also available from "System
configuration", a list of special tools to view into Vista hardware lists.

I have attached a list of IRQ from a system where coLinux was running.
Interesting is, that are lots more IRQs as under Linux. Is that Vista
typicaly? The system was "Windows Vista Home Premium".

>>> cut >>>
IRQ 0	Systemzeitgeber	OK
IRQ 1	Standardtastatur (PS/2)	OK
IRQ 8	System CMOS/Echtzeituhr	OK
IRQ 10	Intel(R) ICH8 Family SMBus Controller - 283E	OK
IRQ 12	Alps Pointing-device for VAIO	OK
IRQ 13	Numerischer Coprozessor	OK
IRQ 14	IDE-Kanal	OK
IRQ 15	IDE-Kanal	OK
IRQ 16	Mobile Intel(R) 965 Express Chipset Family	OK
IRQ 16	Intel(R) ICH8 Family USB Universal Host Controller - 2834	OK
IRQ 16	Marvell Yukon 88E8039 PCI-E Fast Ethernet Controller	OK
IRQ 16	Intel(R) ICH8 Family PCI Express Root Port 2 - 2841	OK
IRQ 16	Texas Instruments PCI-8x12/7x12/6x12 CardBus-Controller	OK
IRQ 17	Intel(R) ICH8 Family PCI Express Root Port 1 - 283F	OK
IRQ 17	Texas Instruments OHCI-konformer IEEE 1394-Hostcontroller	OK
IRQ 18	Intel(R) ICH8 Family USB2 Enhanced Host Controller - 283A	OK
IRQ 18	Intel(R) ICH8 Family PCI Express Root Port 3 - 2843	OK
IRQ 18	Intel(R) ICH8 Family USB Universal Host Controller - 2832	OK
IRQ 18	Texas Instruments PCIxx12 Integrated FlashMedia Controller	OK
IRQ 19	Intel(R) ICH8 Family USB Universal Host Controller - 2831	OK
IRQ 19	Intel(R) ICH8M SATA AHCI Controller - 2829	OK
IRQ 21	Intel(R) ICH8 Family USB Universal Host Controller - 2835	OK
IRQ 22	High Definition Audio-Controller	OK
IRQ 23	Intel(R) ICH8 Family USB Universal Host Controller - 2830	OK
IRQ 23	Intel(R) ICH8 Family USB2 Enhanced Host Controller - 2836	OK
IRQ 80	Microsoft ACPI-konformes System	OK
IRQ 81	Microsoft ACPI-konformes System	OK
IRQ 82	Microsoft ACPI-konformes System	OK
IRQ 83	Microsoft ACPI-konformes System	OK
IRQ 84	Microsoft ACPI-konformes System	OK
IRQ 85	Microsoft ACPI-konformes System	OK
IRQ 86	Microsoft ACPI-konformes System	OK
IRQ 87	Microsoft ACPI-konformes System	OK
IRQ 88	Microsoft ACPI-konformes System	OK
IRQ 89	Microsoft ACPI-konformes System	OK
IRQ 90	Microsoft ACPI-konformes System	OK
IRQ 91	Microsoft ACPI-konformes System	OK
IRQ 92	Microsoft ACPI-konformes System	OK
IRQ 93	Microsoft ACPI-konformes System	OK
IRQ 94	Microsoft ACPI-konformes System	OK
IRQ 95	Microsoft ACPI-konformes System	OK
IRQ 96	Microsoft ACPI-konformes System	OK
IRQ 97	Microsoft ACPI-konformes System	OK
IRQ 98	Microsoft ACPI-konformes System	OK
IRQ 99	Microsoft ACPI-konformes System	OK
IRQ 100	Microsoft ACPI-konformes System	OK
IRQ 101	Microsoft ACPI-konformes System	OK
IRQ 102	Microsoft ACPI-konformes System	OK
IRQ 103	Microsoft ACPI-konformes System	OK
IRQ 104	Microsoft ACPI-konformes System	OK
IRQ 105	Microsoft ACPI-konformes System	OK
IRQ 106	Microsoft ACPI-konformes System	OK
IRQ 107	Microsoft ACPI-konformes System	OK
IRQ 108	Microsoft ACPI-konformes System	OK
IRQ 109	Microsoft ACPI-konformes System	OK
IRQ 110	Microsoft ACPI-konformes System	OK
IRQ 111	Microsoft ACPI-konformes System	OK
IRQ 112	Microsoft ACPI-konformes System	OK
IRQ 113	Microsoft ACPI-konformes System	OK
IRQ 114	Microsoft ACPI-konformes System	OK
IRQ 115	Microsoft ACPI-konformes System	OK
IRQ 116	Microsoft ACPI-konformes System	OK
IRQ 117	Microsoft ACPI-konformes System	OK
IRQ 118	Microsoft ACPI-konformes System	OK
IRQ 119	Microsoft ACPI-konformes System	OK
IRQ 120	Microsoft ACPI-konformes System	OK
IRQ 121	Microsoft ACPI-konformes System	OK
IRQ 122	Microsoft ACPI-konformes System	OK
IRQ 123	Microsoft ACPI-konformes System	OK
IRQ 124	Microsoft ACPI-konformes System	OK
IRQ 125	Microsoft ACPI-konformes System	OK
IRQ 126	Microsoft ACPI-konformes System	OK
IRQ 127	Microsoft ACPI-konformes System	OK
IRQ 128	Microsoft ACPI-konformes System	OK
IRQ 129	Microsoft ACPI-konformes System	OK
IRQ 130	Microsoft ACPI-konformes System	OK
IRQ 131	Microsoft ACPI-konformes System	OK
IRQ 132	Microsoft ACPI-konformes System	OK
IRQ 133	Microsoft ACPI-konformes System	OK
IRQ 134	Microsoft ACPI-konformes System	OK
IRQ 135	Microsoft ACPI-konformes System	OK
IRQ 136	Microsoft ACPI-konformes System	OK
IRQ 137	Microsoft ACPI-konformes System	OK
IRQ 138	Microsoft ACPI-konformes System	OK
IRQ 139	Microsoft ACPI-konformes System	OK
IRQ 140	Microsoft ACPI-konformes System	OK
IRQ 141	Microsoft ACPI-konformes System	OK
IRQ 142	Microsoft ACPI-konformes System	OK
IRQ 143	Microsoft ACPI-konformes System	OK
IRQ 144	Microsoft ACPI-konformes System	OK
IRQ 145	Microsoft ACPI-konformes System	OK
IRQ 146	Microsoft ACPI-konformes System	OK
IRQ 147	Microsoft ACPI-konformes System	OK
IRQ 148	Microsoft ACPI-konformes System	OK
IRQ 149	Microsoft ACPI-konformes System	OK
IRQ 150	Microsoft ACPI-konformes System	OK
IRQ 151	Microsoft ACPI-konformes System	OK
IRQ 152	Microsoft ACPI-konformes System	OK
IRQ 153	Microsoft ACPI-konformes System	OK
IRQ 154	Microsoft ACPI-konformes System	OK
IRQ 155	Microsoft ACPI-konformes System	OK
IRQ 156	Microsoft ACPI-konformes System	OK
IRQ 157	Microsoft ACPI-konformes System	OK
IRQ 158	Microsoft ACPI-konformes System	OK
IRQ 159	Microsoft ACPI-konformes System	OK
IRQ 160	Microsoft ACPI-konformes System	OK
IRQ 161	Microsoft ACPI-konformes System	OK
IRQ 162	Microsoft ACPI-konformes System	OK
IRQ 163	Microsoft ACPI-konformes System	OK
IRQ 164	Microsoft ACPI-konformes System	OK
IRQ 165	Microsoft ACPI-konformes System	OK
IRQ 166	Microsoft ACPI-konformes System	OK
IRQ 167	Microsoft ACPI-konformes System	OK
IRQ 168	Microsoft ACPI-konformes System	OK
IRQ 169	Microsoft ACPI-konformes System	OK
IRQ 170	Microsoft ACPI-konformes System	OK
IRQ 171	Microsoft ACPI-konformes System	OK
IRQ 172	Microsoft ACPI-konformes System	OK
IRQ 173	Microsoft ACPI-konformes System	OK
IRQ 174	Microsoft ACPI-konformes System	OK
IRQ 175	Microsoft ACPI-konformes System	OK
IRQ 176	Microsoft ACPI-konformes System	OK
IRQ 177	Microsoft ACPI-konformes System	OK
IRQ 178	Microsoft ACPI-konformes System	OK
IRQ 179	Microsoft ACPI-konformes System	OK
IRQ 180	Microsoft ACPI-konformes System	OK
IRQ 181	Microsoft ACPI-konformes System	OK
IRQ 182	Microsoft ACPI-konformes System	OK
IRQ 183	Microsoft ACPI-konformes System	OK
IRQ 184	Microsoft ACPI-konformes System	OK
IRQ 185	Microsoft ACPI-konformes System	OK
IRQ 186	Microsoft ACPI-konformes System	OK
IRQ 187	Microsoft ACPI-konformes System	OK
IRQ 188	Microsoft ACPI-konformes System	OK
IRQ 189	Microsoft ACPI-konformes System	OK
IRQ 190	Microsoft ACPI-konformes System	OK
IRQ 4294967294	Intel(R) PRO/Wireless 3945ABG Network Connection	OK
<<< end <<<

-- 
Henry N.

Re: [coLinux-users] Vista SP1 - complete failure

[Henry N. <hen...@ar...>]

Jonathan Deitch wrote:
>  I can't find either winmsd or msinfo under Vista ... neither seems to
> exist ...

Have you tryed the "Search ... for file"?
MS says _all_ XP and Vista have it:
http://support.microsoft.com/kb/q300887/#appliesto

> 
> I did, earlier, post the IRQ results from the working Knoppix boot ...
> was that not sufficient?
> 
>            CPU0      
>   0:      57713  local-APIC-edge-fasteoi   timer
>   1:        141   IO-APIC-edge      i8042
>   8:          1   IO-APIC-edge      rtc
>   9:         26   IO-APIC-fasteoi   acpi
>  12:        151   IO-APIC-edge      i8042
>  14:       1215   IO-APIC-edge      ide0
>  16:          0   IO-APIC-fasteoi   yenta
>  17:        122   IO-APIC-fasteoi   ahci
>  18:          2   IO-APIC-fasteoi   ohci_hcd:usb1, ehci_hcd:usb6
>  19:         29   IO-APIC-fasteoi   ohci_hcd:usb2, ohci_hcd:usb3,

Under Linux the IRQ0 is a "fake" or it is redirected. Your Linux boot
messages says, that IRQ0 is not connected to the timerchip. BIOS has
sayed it is vector 0x31, I assume it is IRQ17. But this is your USB
controller. Vector 0x31 is false listed by BIOS, that says the other
kernel message from Gparted. The question is: Where is the timer real?
Native Linux can move the IRQ by reprogramming the timer chip (set a
virtual irq line or so). But coLinux should not do it. In a
virtualisation we have per define no hardware access.

You can see it in the list above, that your IRQ0 is not an "IO-APIC".
If we would know the real Timer IRQ, we can trace it on your machine.

If you not have the tools, then please open your hardware device control
center (I'm german, so please sorry for wrong translation) and view your
hardware devices in a list sorted by type, than lets see the IRQ list
seen by Windows. - Something must be difference from the list you send
from Knoppix. The question is what? You can send me a screenshot from
that view.

-- 
Henry N.

Re: [coLinux-users] Vista SP1 - complete failure

[Jonathan D. <tz...@sp...>]

I can't find either winmsd or msinfo under Vista ... neither seems to 
exist ...

I did, earlier, post the IRQ results from the working Knoppix boot ... 
was that not sufficient?

           CPU0      
  0:      57713  local-APIC-edge-fasteoi   timer
  1:        141   IO-APIC-edge      i8042
  8:          1   IO-APIC-edge      rtc
  9:         26   IO-APIC-fasteoi   acpi
 12:        151   IO-APIC-edge      i8042
 14:       1215   IO-APIC-edge      ide0
 16:          0   IO-APIC-fasteoi   yenta
 17:        122   IO-APIC-fasteoi   ahci
 18:          2   IO-APIC-fasteoi   ohci_hcd:usb1, ehci_hcd:usb6
 19:         29   IO-APIC-fasteoi   ohci_hcd:usb2, ohci_hcd:usb3, 
ohci_hcd:usb4, ohci_hcd:usb5
NMI:          0
LOC:          0
ERR:          0
MIS:          0


- Jonathan

Henry Nestler wrote:
> Michelangelo Bottura wrote:
>   
>> On Tue, Jun 24, 2008 at 9:27 PM, Henry Nestler wrote:
>>
>>     Jonathan, please run "winmsd" from Windows command prompt, select
>>     Hardware-Ressources and IRQ from tree left side. Than "mark all" (menu
>>     edit) and Copy&Paste the full list of interrupts (IRQ) here. This all
>>     please, without running coLinux.
>>
>>     Typicaly the Timer is on "IRQ 0". If the timer is highter as IRQ 31, we
>>     have some ideas.
>>
>>     --
>>     Henry N.
>>
>> Henry,
>> as Vista seems to lack winmsd , you can obtain the same piece of info by
>> running msinfo32
>>     
>
> Ah. Thanks.
>
> XP also have such file. The file location is something strange, it is
> "C:\Program files\Shared files\Microsoft Shared\MsInfo\msinfo32.exe"
>
> It's the same output as from "winmsd", and the taskmanager identifiered
> both as "HelpCtr.exe" after starting a subprocess.
>
>   

Re: [coLinux-users] Vista SP1 - complete failure

[Henry N. <hen...@ar...>]

Michelangelo Bottura wrote:
> On Tue, Jun 24, 2008 at 9:27 PM, Henry Nestler wrote:
> 
>     Jonathan, please run "winmsd" from Windows command prompt, select
>     Hardware-Ressources and IRQ from tree left side. Than "mark all" (menu
>     edit) and Copy&Paste the full list of interrupts (IRQ) here. This all
>     please, without running coLinux.
> 
>     Typicaly the Timer is on "IRQ 0". If the timer is highter as IRQ 31, we
>     have some ideas.
> 
>     --
>     Henry N.
> 
> Henry,
> as Vista seems to lack winmsd , you can obtain the same piece of info by
> running msinfo32

Ah. Thanks.

XP also have such file. The file location is something strange, it is
"C:\Program files\Shared files\Microsoft Shared\MsInfo\msinfo32.exe"

It's the same output as from "winmsd", and the taskmanager identifiered
both as "HelpCtr.exe" after starting a subprocess.

-- 
Henry N.

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Henry N. <hen...@ar...>]

Hello Mike,

Mike Frysinger wrote:
> On Mon, Jun 23, 2008 at 5:42 PM, Henry Nestler wrote:
>> Have fixed. Here is the new executable. Your Netcat + tcpcopy example
>> was working:
>> http://www.henrynestler.com/colinux/testing/stable-0.7.3/20080623-slirp/colinux-slirp-net-daemon-0.7.3-2.zip
> 
> sorry for the delay.  this version indeed works fine for me with tftp.
>  thanks a ton!

Ok. Thanks back, for your very good problem descriptions :-)

For all others: Update for coLinux SLiRP daemon have moved to:
http://www.henrynestler.com/colinux/releases/0.7.3/update/

Is also available on SF file releases:
http://sourceforge.net/project/showfiles.php?group_id=98788&package_id=107317&release_id=385643

-- 
Henry N.

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Mike F. <vap...@gm...>]

On Mon, Jun 23, 2008 at 5:42 PM, Henry Nestler wrote:
> Mike Frysinger wrote:
>> On Mon, Jun 23, 2008 at 4:27 PM, Henry Nestler wrote:
>>> With rev 479/480 you pointed to a bigger set of changes.
>>> By the while I found the place where it goes wrong. Please see the
>>> source snip or:
>>> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/udp.c?revision=677&view=markup
>>>
>>> file udp.c, line 323, function udp_output()
>>>
>>> In the line 323 the source address saddr.sin_addr (192.168.x.x) is
>>> overwritten with 10.0.2.2
>>> One line before was checked the listen address (so->so_faddr).
>>> I'm afraid, there should check the source address instead? But why there
>>> is a check for broadcast? Is that a hack for a hack? It sems me, that it
>>> would better work without the lines from 322 to 326 there?
>>>
>>> Background:
>>> special_addr = 10.0.2.2 (const)
>>>
>>> All UDP sockets are listen on address 0.0.0.0, that address is set as
>>> faked address 10.0.2.2 in line 383:
>>> "so->so_faddr = alias_addr;"
>>>
>>> -----------------------------------
>>> devel/src/colinux/user/slirp/udp.c
>>>  315 int udp_output(struct socket *so, struct mbuf *m,
>>>  316                struct sockaddr_in *addr)
>>>  317
>>>  318 {
>>>  319     struct sockaddr_in saddr, daddr;
>>>  320
>>>  321     saddr = *addr;
>>>  322     if ((so->so_faddr.s_addr & htonl(0xffffff00)) ==
>>> special_addr.s_addr) {
>>>  323         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>>>  324         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
>>>  325             saddr.sin_addr.s_addr = alias_addr.s_addr;
>>>  326     }
>>>  327     daddr.sin_addr = so->so_laddr;
>>>  328     daddr.sin_port = so->so_lport;
>>>  329
>>>  330     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
>>>  331 }
>>
>> i'd like to assist in analysis, but i'm not familiar with any of the
>> colinux source base, so i cant really even make an educated guess; i'd
>> be shooting blind.  i'll gladly test any proposed changes though.
>>
>> a comment block here in the source explaining what it's supposed to be
>> doing would have been useful :/.
>
> Yes, I know. But is not from me. It was copied from some others.
> As I understand, after deep debugging with you helpful simple netcat and
> tcp example I would say, that the if condition wand to check if the
> source is from the host (localhost or the host's self ipaddress) and
> then it replaced the source from sender with faked 10.0.2.2
>
> But after the change SVN rev 479/480 the address is fix as localhost or
> bind all times to all (0.0.0.0). In that case, this can not be use for
> that test any more.
>
> Have fixed. Here is the new executable. Your Netcat + tcpcopy example
> was working:
> http://www.henrynestler.com/colinux/testing/stable-0.7.3/20080623-slirp/colinux-slirp-net-daemon-0.7.3-2.zip

sorry for the delay.  this version indeed works fine for me with tftp.
 thanks a ton!
-mike

Re: [coLinux-users] Vista SP1 - complete failure

[Michelangelo B. <mic...@gm...>]

On Tue, Jun 24, 2008 at 9:27 PM, Henry Nestler <hen...@ar...> wrote:

> Paolo Minazzi wrote:
> >> I've got a Athlon64 x2 with same bios problem (which it had not before
> last
> >> bios update). I can confirm Ubuntu 7.10 did not pass booting without
> >> acpi=off parameter.
> >> Should this help debugging I can send more data|run some test.
> >> My 2 c
> >>
> >> Michelangelo
> >
> > If I'm not wrong, acpi=off does not make any difference in colinux
> > because PowerManagement (and so APM ans ACPI) are off.
>
>
>
> Jonathan, please run "winmsd" from Windows command prompt, select
> Hardware-Ressources and IRQ from tree left side. Than "mark all" (menu
> edit) and Copy&Paste the full list of interrupts (IRQ) here. This all
> please, without running coLinux.
>
> Typicaly the Timer is on "IRQ 0". If the timer is highter as IRQ 31, we
> have some ideas.
>
> --
> Henry N.
>
Henry,
as Vista seems to lack winmsd , you can obtain the same piece of info by
running msinfo32
my 2 c
Michelangelo

Re: [coLinux-users] Vista SP1 - complete failure

[Henry N. <hen...@ar...>]

Paolo Minazzi wrote:
>> I've got a Athlon64 x2 with same bios problem (which it had not before last
>> bios update). I can confirm Ubuntu 7.10 did not pass booting without
>> acpi=off parameter.
>> Should this help debugging I can send more data|run some test.
>> My 2 c
>>
>> Michelangelo
> 
> If I'm not wrong, acpi=off does not make any difference in colinux
> because PowerManagement (and so APM ans ACPI) are off.

That's right. ACPI is off for coLinux by compile time.
I got an other suggestion from Paolo (off list), that we should follow.

I have checked a running coLinux: All interrupts from IRQ0 to IRQ31 are
forwarded to the host. Perhaps your timer is abofe IRQ 31? And what says
the "vector 0x31" there?

Jonathan, please run "winmsd" from Windows command prompt, select
Hardware-Ressources and IRQ from tree left side. Than "mark all" (menu
edit) and Copy&Paste the full list of interrupts (IRQ) here. This all
please, without running coLinux.

Typicaly the Timer is on "IRQ 0". If the timer is highter as IRQ 31, we
have some ideas.

-- 
Henry N.

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Henry N. <hen...@ar...>]

Henry Nestler wrote:
> Mike Frysinger wrote:
>> On Mon, Jun 23, 2008 at 4:27 PM, Henry Nestler wrote:
>>> With rev 479/480 you pointed to a bigger set of changes.
>>>
>>> By the while I found the place where it goes wrong. Please see the
>>> source snip or:
>>> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/udp.c?revision=677&view=markup
>>>
>>> file udp.c, line 323, function udp_output()
>>>
>>> In the line 323 the source address saddr.sin_addr (192.168.x.x) is
>>> overwritten with 10.0.2.2
>>> One line before was checked the listen address (so->so_faddr).
>>> I'm afraid, there should check the source address instead? But why there
>>> is a check for broadcast? Is that a hack for a hack? It sems me, that it
>>> would better work without the lines from 322 to 326 there?
>>>
>>> Background:
>>> special_addr = 10.0.2.2 (const)
>>>
>>> All UDP sockets are listen on address 0.0.0.0, that address is set as
>>> faked address 10.0.2.2 in line 383:
>>> "so->so_faddr = alias_addr;"
>>>
>>> -----------------------------------
>>> devel/src/colinux/user/slirp/udp.c
>>>  315 int udp_output(struct socket *so, struct mbuf *m,
>>>  316                struct sockaddr_in *addr)
>>>  317
>>>  318 {
>>>  319     struct sockaddr_in saddr, daddr;
>>>  320
>>>  321     saddr = *addr;
>>>  322     if ((so->so_faddr.s_addr & htonl(0xffffff00)) ==
>>> special_addr.s_addr) {
>>>  323         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>>>  324         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
>>>  325             saddr.sin_addr.s_addr = alias_addr.s_addr;
>>>  326     }
>>>  327     daddr.sin_addr = so->so_laddr;
>>>  328     daddr.sin_port = so->so_lport;
>>>  329
>>>  330     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
>>>  331 }
>> i'd like to assist in analysis, but i'm not familiar with any of the
>> colinux source base, so i cant really even make an educated guess; i'd
>> be shooting blind.  i'll gladly test any proposed changes though.
>>
>> a comment block here in the source explaining what it's supposed to be
>> doing would have been useful :/.
> 
> Yes, I know. But is not from me. It was copied from some others.
> As I understand, after deep debugging with you helpful simple netcat and
> tcp example I would say, that the if condition wand to check if the
> source is from the host (localhost or the host's self ipaddress) and
> then it replaced the source from sender with faked 10.0.2.2
> 
> But after the change SVN rev 479/480 the address is fix as localhost or
> bind all times to all (0.0.0.0). In that case, this can not be use for
> that test any more.
> 
> Have fixed. Here is the new executable. Your Netcat + tcpcopy example
> was working:
> http://www.henrynestler.com/colinux/testing/stable-0.7.3/20080623-slirp/colinux-slirp-net-daemon-0.7.3-2.zip
> 
> I don't know, what the broadcast address (10.0.2.255) should do there.
> Have removed. This is the new code snip:
> 
> int udp_output(struct socket *so, struct mbuf *m,
>                struct sockaddr_in *addr)
> 
> {
>     struct sockaddr_in saddr, daddr;
> 
>     saddr = *addr;
> 
>     /* Translate connections from localhost to the alias hostname */
>     if(is_localhost(saddr.sin_addr)) {
>         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>     }
> 
>     daddr.sin_addr = so->so_laddr;
>     daddr.sin_port = so->so_lport;
> 
>     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
> }
> 

I'm afraid, we are not the only, that tries to fix this. See the last 3
changes 4402, 4267 and 4259 in Qemu:
http://svn.savannah.gnu.org/viewvc/trunk/slirp/udp.c?root=qemu&view=log

-- 
Henry N.

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Henry N. <hen...@ar...>]

Mike Frysinger wrote:
> On Mon, Jun 23, 2008 at 4:27 PM, Henry Nestler wrote:
>> With rev 479/480 you pointed to a bigger set of changes.
>>
>> By the while I found the place where it goes wrong. Please see the
>> source snip or:
>> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/udp.c?revision=677&view=markup
>>
>> file udp.c, line 323, function udp_output()
>>
>> In the line 323 the source address saddr.sin_addr (192.168.x.x) is
>> overwritten with 10.0.2.2
>> One line before was checked the listen address (so->so_faddr).
>> I'm afraid, there should check the source address instead? But why there
>> is a check for broadcast? Is that a hack for a hack? It sems me, that it
>> would better work without the lines from 322 to 326 there?
>>
>> Background:
>> special_addr = 10.0.2.2 (const)
>>
>> All UDP sockets are listen on address 0.0.0.0, that address is set as
>> faked address 10.0.2.2 in line 383:
>> "so->so_faddr = alias_addr;"
>>
>> -----------------------------------
>> devel/src/colinux/user/slirp/udp.c
>>  315 int udp_output(struct socket *so, struct mbuf *m,
>>  316                struct sockaddr_in *addr)
>>  317
>>  318 {
>>  319     struct sockaddr_in saddr, daddr;
>>  320
>>  321     saddr = *addr;
>>  322     if ((so->so_faddr.s_addr & htonl(0xffffff00)) ==
>> special_addr.s_addr) {
>>  323         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>>  324         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
>>  325             saddr.sin_addr.s_addr = alias_addr.s_addr;
>>  326     }
>>  327     daddr.sin_addr = so->so_laddr;
>>  328     daddr.sin_port = so->so_lport;
>>  329
>>  330     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
>>  331 }
> 
> i'd like to assist in analysis, but i'm not familiar with any of the
> colinux source base, so i cant really even make an educated guess; i'd
> be shooting blind.  i'll gladly test any proposed changes though.
> 
> a comment block here in the source explaining what it's supposed to be
> doing would have been useful :/.

Yes, I know. But is not from me. It was copied from some others.
As I understand, after deep debugging with you helpful simple netcat and
tcp example I would say, that the if condition wand to check if the
source is from the host (localhost or the host's self ipaddress) and
then it replaced the source from sender with faked 10.0.2.2

But after the change SVN rev 479/480 the address is fix as localhost or
bind all times to all (0.0.0.0). In that case, this can not be use for
that test any more.

Have fixed. Here is the new executable. Your Netcat + tcpcopy example
was working:
http://www.henrynestler.com/colinux/testing/stable-0.7.3/20080623-slirp/colinux-slirp-net-daemon-0.7.3-2.zip

I don't know, what the broadcast address (10.0.2.255) should do there.
Have removed. This is the new code snip:

int udp_output(struct socket *so, struct mbuf *m,
               struct sockaddr_in *addr)

{
    struct sockaddr_in saddr, daddr;

    saddr = *addr;

    /* Translate connections from localhost to the alias hostname */
    if(is_localhost(saddr.sin_addr)) {
        saddr.sin_addr.s_addr = so->so_faddr.s_addr;
    }

    daddr.sin_addr = so->so_laddr;
    daddr.sin_port = so->so_lport;

    return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
}

-- 
Henry N.

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Mike F. <vap...@gm...>]

On Mon, Jun 23, 2008 at 4:27 PM, Henry Nestler wrote:
> With rev 479/480 you pointed to a bigger set of changes.
>
> By the while I found the place where it goes wrong. Please see the
> source snip or:
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/udp.c?revision=677&view=markup
>
> file udp.c, line 323, function udp_output()
>
> In the line 323 the source address saddr.sin_addr (192.168.x.x) is
> overwritten with 10.0.2.2
> One line before was checked the listen address (so->so_faddr).
> I'm afraid, there should check the source address instead? But why there
> is a check for broadcast? Is that a hack for a hack? It sems me, that it
> would better work without the lines from 322 to 326 there?
>
> Background:
> special_addr = 10.0.2.2 (const)
>
> All UDP sockets are listen on address 0.0.0.0, that address is set as
> faked address 10.0.2.2 in line 383:
> "so->so_faddr = alias_addr;"
>
> -----------------------------------
> devel/src/colinux/user/slirp/udp.c
>  315 int udp_output(struct socket *so, struct mbuf *m,
>  316                struct sockaddr_in *addr)
>  317
>  318 {
>  319     struct sockaddr_in saddr, daddr;
>  320
>  321     saddr = *addr;
>  322     if ((so->so_faddr.s_addr & htonl(0xffffff00)) ==
> special_addr.s_addr) {
>  323         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>  324         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
>  325             saddr.sin_addr.s_addr = alias_addr.s_addr;
>  326     }
>  327     daddr.sin_addr = so->so_laddr;
>  328     daddr.sin_port = so->so_lport;
>  329
>  330     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
>  331 }

i'd like to assist in analysis, but i'm not familiar with any of the
colinux source base, so i cant really even make an educated guess; i'd
be shooting blind.  i'll gladly test any proposed changes though.

a comment block here in the source explaining what it's supposed to be
doing would have been useful :/.
-mike

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Henry N. <hen...@ar...>]

Henry Nestler wrote:
> Hello Mike,
> 
> Mike Frysinger wrote:
>> On Sun, Jun 22, 2008 at 4:59 PM, Henry Nestler wrote:
>>> The difference for coLinux 0.7.1 and 0.7.3 are very small. Mostly are
>>> fixups for compiler warnings.
>>>
>>> There exist an other interesting change between versions:
>>> http://colinux.svn.sourceforge.net/viewvc/colinux?view=rev&revision=574
>> so there may be a discrepancy when i said "0.7.1".  i was given an old
>> coLinux installer and was told it was "0.7.1".  i assumed everything
>> in the package was "0.7.1"; the person before me may have taken an
>> older slirp daemon and dropped it in for this same reason.  so as to
>> make things maintainable, i started fresh with the 0.7.3 release from
>> colinux.org, hit this bug, and then copied the slirp daemon from this
>> "0.7.1" version.
>>
>> so let's just focus on the svn info i posted otherwise as that is used
>> in conjunction with vanilla 0.7.3 install without any unknown baggage.
>>  sorry for any confusion.
>> -mike
>>
> 
> With rev 479/480 you pointed to a bigger set of changes.
> 
> By the while I found the place where it goes wrong. Please see the
> source snip or:
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/udp.c?revision=677&view=markup
> 
> file udp.c, line 323, function udp_output()
> 
> In the line 323 the source address saddr.sin_addr (192.168.x.x) is
> overwritten with 10.0.2.2
> One line before was checked the listen address (so->so_faddr).
> I'm afraid, there should check the source address instead? But why there
> is a check for broadcast? Is that a hack for a hack? It sems me, that it
> would better work without the lines from 322 to 326 there?
> 
> Background:
> special_addr = 10.0.2.2 (const)

Typofix. That is correctly:
special_addr = 10.0.2.0 (const)
alias_addr = 10.0.2.2 (const)

> 
> All UDP sockets are listen on address 0.0.0.0, that address is set as
> faked address 10.0.2.2 in line 383:
> "so->so_faddr = alias_addr;"
> 
> -----------------------------------
> devel/src/colinux/user/slirp/udp.c
>   315 int udp_output(struct socket *so, struct mbuf *m,
>   316                struct sockaddr_in *addr)
>   317
>   318 {
>   319     struct sockaddr_in saddr, daddr;
>   320
>   321     saddr = *addr;
>   322     if ((so->so_faddr.s_addr & htonl(0xffffff00)) ==
> special_addr.s_addr) {
>   323         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
>   324         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
>   325             saddr.sin_addr.s_addr = alias_addr.s_addr;
>   326     }
>   327     daddr.sin_addr = so->so_laddr;
>   328     daddr.sin_port = so->so_lport;
>   329
>   330     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
>   331 }
> 

-- 
Henry N.

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Henry N. <hen...@ar...>]

Hello Mike,

Mike Frysinger wrote:
> On Sun, Jun 22, 2008 at 4:59 PM, Henry Nestler wrote:
>> The difference for coLinux 0.7.1 and 0.7.3 are very small. Mostly are
>> fixups for compiler warnings.
>>
>> There exist an other interesting change between versions:
>> http://colinux.svn.sourceforge.net/viewvc/colinux?view=rev&revision=574
> 
> so there may be a discrepancy when i said "0.7.1".  i was given an old
> coLinux installer and was told it was "0.7.1".  i assumed everything
> in the package was "0.7.1"; the person before me may have taken an
> older slirp daemon and dropped it in for this same reason.  so as to
> make things maintainable, i started fresh with the 0.7.3 release from
> colinux.org, hit this bug, and then copied the slirp daemon from this
> "0.7.1" version.
> 
> so let's just focus on the svn info i posted otherwise as that is used
> in conjunction with vanilla 0.7.3 install without any unknown baggage.
>  sorry for any confusion.
> -mike
> 

With rev 479/480 you pointed to a bigger set of changes.

By the while I found the place where it goes wrong. Please see the
source snip or:
http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/udp.c?revision=677&view=markup

file udp.c, line 323, function udp_output()

In the line 323 the source address saddr.sin_addr (192.168.x.x) is
overwritten with 10.0.2.2
One line before was checked the listen address (so->so_faddr).
I'm afraid, there should check the source address instead? But why there
is a check for broadcast? Is that a hack for a hack? It sems me, that it
would better work without the lines from 322 to 326 there?

Background:
special_addr = 10.0.2.2 (const)

All UDP sockets are listen on address 0.0.0.0, that address is set as
faked address 10.0.2.2 in line 383:
"so->so_faddr = alias_addr;"

-----------------------------------
devel/src/colinux/user/slirp/udp.c
  315 int udp_output(struct socket *so, struct mbuf *m,
  316                struct sockaddr_in *addr)
  317
  318 {
  319     struct sockaddr_in saddr, daddr;
  320
  321     saddr = *addr;
  322     if ((so->so_faddr.s_addr & htonl(0xffffff00)) ==
special_addr.s_addr) {
  323         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
  324         if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
  325             saddr.sin_addr.s_addr = alias_addr.s_addr;
  326     }
  327     daddr.sin_addr = so->so_laddr;
  328     daddr.sin_port = so->so_lport;
  329
  330     return udp_output2(so, m, &saddr, &daddr, so->so_iptos);
  331 }

-- 
Henry N.

Re: [coLinux-users] Vista SP1 - complete failure

[Paolo M. <pao...@gm...>]

> I've got a Athlon64 x2 with same bios problem (which it had not before last
> bios update). I can confirm Ubuntu 7.10 did not pass booting without
> acpi=off parameter.
> Should this help debugging I can send more data|run some test.
> My 2 c
>
> Michelangelo

If I'm not wrong, acpi=off does not make any difference in colinux
because PowerManagement (and so APM ans ACPI) are off.
But I have to check if this parameter is used in other parts of linux kernel.
Bye,
Paolo

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Mike F. <vap...@gm...>]

On Sun, Jun 22, 2008 at 4:59 PM, Henry Nestler wrote:
> The difference for coLinux 0.7.1 and 0.7.3 are very small. Mostly are
> fixups for compiler warnings.
>
> There exist an other interesting change between versions:
> http://colinux.svn.sourceforge.net/viewvc/colinux?view=rev&revision=574

so there may be a discrepancy when i said "0.7.1".  i was given an old
coLinux installer and was told it was "0.7.1".  i assumed everything
in the package was "0.7.1"; the person before me may have taken an
older slirp daemon and dropped it in for this same reason.  so as to
make things maintainable, i started fresh with the 0.7.3 release from
colinux.org, hit this bug, and then copied the slirp daemon from this
"0.7.1" version.

so let's just focus on the svn info i posted otherwise as that is used
in conjunction with vanilla 0.7.3 install without any unknown baggage.
 sorry for any confusion.
-mike

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Mike F. <vap...@gm...>]

On Sun, Jun 22, 2008 at 8:12 PM, Mike Frysinger wrote:
> On Sun, Jun 22, 2008 at 5:12 PM, Mike Frysinger wrote:
>> On Sun, Jun 22, 2008 at 4:59 PM, Henry Nestler wrote:
>>> The difference for coLinux 0.7.1 and 0.7.3 are very small. Mostly are
>>> fixups for compiler warnings.
>>>
>>> There exist an other interesting change between versions:
>>> http://colinux.svn.sourceforge.net/viewvc/colinux?view=rev&revision=574
>>>
>>> This sets the 10.0.2.2 as source for broardcasts. Perhaps somethin is
>>> wrong there? I will check it with netcat and tcpdump next times.
>>
>> i'm building the devel branch now (./configure && make) so i can go
>> back through the versions
>
> rev 479: works
> rev 480: fails

sorry, to be more specific ... i took svn branches/devel/ and built it
up.  then i reverted only branches/devel/src/colinux/user/slirp/ to
rev 479 and rebuilt the slirp daemon.  dropping just that binary into
0.7.3 and the forwarding seems to work fine.
-mike

Re: [coLinux-users] change in slirp behavior from 0.7.1 to 0.7.3 with udp forwarded ports

[Mike F. <vap...@gm...>]

On Sun, Jun 22, 2008 at 5:12 PM, Mike Frysinger wrote:
> On Sun, Jun 22, 2008 at 4:59 PM, Henry Nestler wrote:
>> The difference for coLinux 0.7.1 and 0.7.3 are very small. Mostly are
>> fixups for compiler warnings.
>>
>> There exist an other interesting change between versions:
>> http://colinux.svn.sourceforge.net/viewvc/colinux?view=rev&revision=574
>>
>> This sets the 10.0.2.2 as source for broardcasts. Perhaps somethin is
>> wrong there? I will check it with netcat and tcpdump next times.
>
> i'm building the devel branch now (./configure && make) so i can go
> back through the versions

rev 479: works
rev 480: fails
-mike