From: Henry N. <hen...@ar...> - 2010-08-06 00:22:45
|
Hello Mike, On 05.08.2010 22:31, Mike Mestnik wrote: > On 8/5/2010 4:49 PM, Henry Nestler wrote: >> On 05.08.2010 21:00, Mike Mestnik wrote: >>> 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. Sorry, I don't know all what Windows changes for different users. If you would configure the service to run as the desktop user (not as user "service"), than it is exactly identically to the command line. Command line parser is exactly the same for both runs. Of curse the location, what Windows will response are totaly different. We use "Current User" in registry to store the random MAC. "Current User" is different betwen service and command line. So you have an other set of ramdom generated MACs. So, for running as services and from command line and you wish to have the same MAC for both start options, you should use a self created MAC for all your network interfaces and write it into config. Other differenes between command line and services are windows specifics. The main problem is that a "service" runs as other user as the desktop user. For example: Network Drive mappings are different, "C:\my files" is an other location, and so. For all these differences, you needs to use a static place in the config. For example for the drives: Don't use images on network drives or on replaceable (USB) disk. Don't use "C:\my files\...", use a path C:\coLinux, so it is all the same for all users on this machine. >> 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. It is included in Windows. ;-) Go to service-control manager and enable interaction with GUI, than you would see all the messages from colinux-daemon. >>>> 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. Setting the name of TAP-Win32 is not the problem, this you can leave blank, if you have only one TAP-Win32. Finding the name of your real Ethernet adapter for ndis-bridge is the problem. Mostly users don't mix TAP and ndis-bride (or pcap-bridge) in same config, or hav only on adapter. That is the main problem here. Yes we can add an exclude of TAP-Win32 in the ndis auto probing. It is not simple, but would be doable. Than the auto probing would hand on the next adapter that is not working, for example WLAN. Of curse we can "die" the config parser, if we find such broken combination. But we can not catch all users misconfigurations. Yes, it is unsafe, and we have changed very often the name detection (substring and so). Auto probing was added as last option for simple users. If you have only one adapter (tap, ndis or pcap), than it works. Bridging does not work out of the box, if you have more as one network adapters configured in the coLinux. So, if you use more as one, please give it a name. The same problem you would have for two or more TAP-Win32. If you have installed a second TAP-Win32, you must give the name in coLinux config. Please also remember: ndis-bridge or pcap-bridge does not work on all network cards. Some cards have problem with checksum. WLAN and WiFI cards does never work. So, bridging needs a manual configuration. You can not set it up for all users environments automatically. If you not wish to run network services inside the Linux (Samba-, FTP- or Web- server) than you should use SLiRP as outgoing network connection to the world, and tuntap locally between Windows and Linux. -- Henry N. |