Re: [coLinux-users] Networking: NSIS installer fails to configure tap correctly.

[Mike M. <mme...@na...>]

On 8/5/2010 4:49 PM, Henry Nestler wrote:
>  On 05.08.2010 21:00, Mike Mestnik wrote:
>> On 8/5/2010 2:27 PM, Henry Nestler wrote:
>>>
>>>> However!!! Networking still is not functional.
>>>> Is there any debugging I can do?
>>> Use -v 3 as option for colinux-daemon, run it on command line (not as
>>> service) and read successfull all messages from network daemon.
>>>
>>> For more debugging disable eth0 under Linux ("ifconfig eth0 down) and
>>> watch, that the ping goes truely over eth1. On Windows site you can
>>> use Wireshark for watching the packets on TAP-Win32 adapter.
>>>
>>> You are using IP address with 169.254, I assume you have not set an IP
>>> address on windows side of TAP. So, you must wait very long time after
>>> start, before the device is ready. A better alternate would be to set
>>> a fixed IP address for the TAP on both ends (Linux  and Windows).
>>>
>>> Check the IP adress on both sides and verify, that the address masked
>>> with netmask matched the same network on both sides. Typicalle you
>>> must use the same netmask on both sides and the starting numbers
>>> should be the same (169.254.x.x) for both ends.
>>>
>> I'll try some of these, thank you.
>> ...What would I do if every thing works file when running as an 
>> application?
>
> Add a MAC in coLinux config, than running from command line and as 
> service are identical fro the network issue.
I got that logically these SHOULD be identical.  The truth seems as 
thought these are vary different.  Firstly you asked to run as an 
application and not as a service, so things sound different and look 
different.  Then there is the huge difference from being a service VS 
being an application, this surely will interject differences.  Finally 
the parameters passed are different, meaning logically these are 
different as different code paths are used.

Thus testing as a service is a far cry from testing as an application, 
especially when you already are dealing with something that DOESN'T.  
DOESN'T i.m.h.o. usually outweighs any SHOULD CAN MAY or WILL.

> If you leave blank the MAC, then coLinux use a random MAC, and this 
> number is different between the running from command line and running 
> as service.
>
> Next step would be to use "colinux-daemon --install-service ..." and 
> run it. You will have no differences.
> Of curse the image files you have created should be writable for the 
> Windows account "Service".
>
Great, there is a method of testing...  Though it removes a variable I 
don't feel it will always satisfy the issue here.

...You should make debugging while running as a service as easy as 
debugging while running as an application.
>
>>>> eth0=ndis-bridge
>>>> eth1=tuntap,,00:18:8B:26:44:88
>>> Without MAC and without name of your real ethernet card you would have
>>> two problems.
>> The MAC should be that of the emulated card... correct?  Having this
>> match the physical device would sound like ruin.
>
> Yes, the MAC is for the guest - the Linux side.
> And, to never matching a real adapter it should start with 02, not 
> with 00.
>
>>> 1. On startup the ndis-bride can attach to the TAP-Win32. That is a
>>> loopback to coLinux self. To solve this, you should add the name of
>>> real Ethernet card.
>> Please add code to prevent this, only bind to a TAP-Win32 device if it's
>> the only device or if it was specified by name.
>
> This is not possible. The rule for empty name is: Using the first 
> adapter, that has a link connection. 
I don't see this at all.  If you can choose the first connection based 
on weather it has or has-not link you can choose not to choose a 
connection based on it's other qualities, like the name of it's driver.
> The ndis does not know what network card is your choice. The 
> ndis-daemon is a separate daemon, that does not know some about the other
If you don't know then do nothing, perhaps a bug in ndis.  I see this, 
but it should avoid potentially broken configs.
> coLinux network daemons. You can have WLAN cards, cable cards, VPN 
> (also TAP-Win32).
> If ndis should not use the first that it will find, then set a name 
> into the config.
>
Better this read "If you have to use a VPN connection you must set a 
name into the config.  However for most users it's safe to leave this 
blank."

Currently it's vary unsafe to leave it blank and the docs don't point 
out that it's mandatory.  So if you can't fix this bug then make the 
name required and die if it's not set.

> Other case you can sort the network order under Windows, so the 
> TAP-Win32 is not the first. This is of curse nothing for your installer.
>
I don't get this?  If I could set the name of the TAP connection that 
would be great.  Adding this stuff to the installer is one fix, but ti's 
just the same as an installer telling the user to move files around and 
set registry keys...  Just not an optimal solution, better to fix this 
"once" in ndis or colinux instead of having every installer deal with it.

>> Printing a single warning would be sufficient.
>
> In the start of colinux-daemon you can see the automatic detected 
> network adapter name. A'm afraid nobody will read this, because a 
> fresh installed TAP driver has the name "Local Area Network (2)", and 
> this is often misunderstood from similar name "Local Area Network" for 
> real Ethernet card. That is, why we say: "Please rename the name of 
> your TAP adapter into something other name, for example "TAP coLinux".
>
I can see the difference two or even 4 bytes appended to the end of a 
string can make, but I'll keep that in mind for my documentation.

>> The reason it's all blank is because this is an installer...
>> Should work wherever it's installed to.  I did see some code to assist
>> in network configuration(on this list), but I'm unsure if it corrected
>> these issues.
>
> Auto-find the right bridge will only work, if you have only one 
> Ethernet adapter running at one time, and no tuntap configured in 
> coLinux config.
For multi-homed systems we only care to get on A network...  Getting on 
the network is something every application on a multi-homed system has 
an issue with and the admin knows that...  We need not try and make his 
task more difficult by trying to do it for him.

As suggested the TAP issue should be something corrected, weather or not 
it's correctable with out removing existing features.

> The message was printed, but user would not read it while running as 
> service.
>
I see that now, should be moved to dmsg output or pollute the cmdline 
with something.

-- 
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email:  mme...@na...
Web:    www.nagios.com