From: Mike M. <mme...@na...> - 2010-08-02 16:40:14
Attachments:
NagiosCore.nsi
NagiosCore.conf
|
Hello everyone, I wanted to write a custom installer for Nagios running under coLinux. This worked great... although the tap adapter doesn't operate. I was wondering if I could seek some assistance from an nsis developer? I'd also wonder if this was common for networking to not function, unless you used Slirp? After researching Slirp I'm thinking it should have been my first choice. Never the less it would be grand if my first attempt could be working. I'm able to ping Windows from coLinux, but Windows dose not attempt to arp or ping back. Most odd, tcpdump under colinux shows only it's own traffic and ping replies. I'm using ipv4ll for the tap interface on the windows side and a static 169.254 address in coLinux . Attached are my config files. |
From: Mike F. <vap...@gm...> - 2010-08-02 16:56:12
|
On Mon, Aug 2, 2010 at 12:40, Mike Mestnik wrote: > I wanted to write a custom installer for Nagios running under coLinux. > This worked great... although the tap adapter doesn't operate. I was > wondering if I could seek some assistance from an nsis developer? > > I'd also wonder if this was common for networking to not function, unless > you used Slirp? > After researching Slirp I'm thinking it should have been my first choice. > > Never the less it would be grand if my first attempt could be working. > > I'm able to ping Windows from coLinux, but Windows dose not attempt to arp > or ping back. Most odd, tcpdump under colinux shows only it's own traffic > and ping replies. I'm using ipv4ll for the tap interface on the windows > side and a static 169.254 address in coLinux . checkout the NSIS installer patch ive written here: http://blackfin.uclinux.org/gf/project/bfin-colinux/scmsvn/trunk/patches/ this installer will install winpcap, the tap driver (already part of colinux), prompt the user for the desired IP addresses, and then take care of the setup for them. ive tested this under win2000/winxp/vista and know it works there. presumably it also works under win7 since it'll be close to vista, but i dont have any win7 32bit installs to test with :x. -mike -mike |
From: Mike M. <mme...@na...> - 2010-08-02 17:07:44
|
On 8/2/2010 12:55 PM, Mike Frysinger wrote: > On Mon, Aug 2, 2010 at 12:40, Mike Mestnik wrote: > >> I wanted to write a custom installer for Nagios running under coLinux. >> This worked great... although the tap adapter doesn't operate. I was >> wondering if I could seek some assistance from an nsis developer? >> >> I'd also wonder if this was common for networking to not function, unless >> you used Slirp? >> After researching Slirp I'm thinking it should have been my first choice. >> >> Never the less it would be grand if my first attempt could be working. >> >> I'm able to ping Windows from coLinux, but Windows dose not attempt to arp >> or ping back. Most odd, tcpdump under colinux shows only it's own traffic >> and ping replies. I'm using ipv4ll for the tap interface on the windows >> side and a static 169.254 address in coLinux . >> > checkout the NSIS installer patch ive written here: > http://blackfin.uclinux.org/gf/project/bfin-colinux/scmsvn/trunk/patches/ > > this installer will install winpcap, the tap driver (already part of > colinux), prompt the user for the desired IP addresses, and then take > care of the setup for them. > What was your motivation for disabling the [1]embedded winpcap installer and replacing it with an execwait? I would recommend that you Embed the putty and xming installers in the same fashion that the WinPcap installer was. 1. http://nsis.sourceforge.net/Embedding_other_installers This looks to be a vary full featured installer, but I can't determine a solution to the issue I'm reporting. For my installation "ndis > winpcap" so winpcap was removed from the install. I feel there is something wrong with the tap adapter, not sure it's an NSIS issue. > ive tested this under win2000/winxp/vista and know it works there. > presumably it also works under win7 since it'll be close to vista, but > i dont have any win7 32bit installs to test with :x. > -mike > -mike > > -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Mike F. <vap...@gm...> - 2010-08-02 17:18:48
|
On Mon, Aug 2, 2010 at 13:07, Mike Mestnik wrote: > What was your motivation for disabling the [1]embedded winpcap installer and > replacing it with an execwait? I would recommend that you Embed the putty > and xming installers in the same fashion that the WinPcap installer was. the current coLinux method involves downloading the different installers on the fly. i'm not interested in that ... my installer is one download and includes everything you'll need. and with the compression, i dont think the larger file sizes are too much bigger to really matter. if there is a way to embed the installer and use the "official" method, then i'll certainly take a look. > This looks to be a vary full featured installer, but I can't determine a > solution to the issue I'm reporting. For my installation "ndis > winpcap" > so winpcap was removed from the install. i guess i missed what you were talking about. i thought you were having problems configuring the taps between windows and colinux. i dont have a clue wrt ndis vs winpcap; sorry. -mike |
From: Mike M. <mme...@na...> - 2010-08-02 17:23:08
|
On 8/2/2010 1:18 PM, Mike Frysinger wrote: > On Mon, Aug 2, 2010 at 13:07, Mike Mestnik wrote: > >> What was your motivation for disabling the [1]embedded winpcap installer and >> replacing it with an execwait? I would recommend that you Embed the putty >> and xming installers in the same fashion that the WinPcap installer was. >> > the current coLinux method involves downloading the different > installers on the fly. i'm not interested in that ... my installer is > one download and includes everything you'll need. and with the > compression, i dont think the larger file sizes are too much bigger to > really matter. > > if there is a way to embed the installer and use the "official" > method, then i'll certainly take a look. > > >> This looks to be a vary full featured installer, but I can't determine a >> solution to the issue I'm reporting. For my installation "ndis> winpcap" >> so winpcap was removed from the install. >> > i guess i missed what you were talking about. i thought you were > having problems configuring the taps between windows and colinux. i > dont have a clue wrt ndis vs winpcap; sorry. > -mike > > That's correct I am. I'm confused, did you mean to say that wpcap could replace taps? I don't feel that wpcap is a solution and I don't feel that your patch corrects the issue I was having with taps. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Mike F. <vap...@gm...> - 2010-08-03 01:48:10
|
On Mon, Aug 2, 2010 at 13:22, Mike Mestnik wrote: > On 8/2/2010 1:18 PM, Mike Frysinger wrote: >> On Mon, Aug 2, 2010 at 13:07, Mike Mestnik wrote: >>> This looks to be a vary full featured installer, but I can't determine a >>> solution to the issue I'm reporting. For my installation "ndis> >>> winpcap" >>> so winpcap was removed from the install. >> >> i guess i missed what you were talking about. i thought you were >> having problems configuring the taps between windows and colinux. i >> dont have a clue wrt ndis vs winpcap; sorry. > > That's correct I am. I'm confused, did you mean to say that wpcap could > replace taps? I don't feel that wpcap is a solution the wiki documents that wpcap is the fastest solution. http://colinux.wikia.com/wiki/Network > and I don't feel that > your patch corrects the issue I was having with taps. the point of my patch was to show how to configure the network interfaces after they've already been created. that's all. -mike |
From: Mike M. <mme...@na...> - 2010-08-03 19:37:59
|
On 8/2/2010 9:47 PM, Mike Frysinger wrote: > On Mon, Aug 2, 2010 at 13:22, Mike Mestnik wrote: > >> On 8/2/2010 1:18 PM, Mike Frysinger wrote: >> >>> On Mon, Aug 2, 2010 at 13:07, Mike Mestnik wrote: >>> >>>> This looks to be a vary full featured installer, but I can't determine a >>>> solution to the issue I'm reporting. For my installation "ndis> >>>> winpcap" >>>> so winpcap was removed from the install. >>>> >>> i guess i missed what you were talking about. i thought you were >>> having problems configuring the taps between windows and colinux. i >>> dont have a clue wrt ndis vs winpcap; sorry. >>> >> That's correct I am. I'm confused, did you mean to say that wpcap could >> replace taps? I don't feel that wpcap is a solution >> > the wiki documents that wpcap is the fastest solution. > http://colinux.wikia.com/wiki/Network > > That may vary well be and I see the document... However WinPcap lives on-top of NDIS, so any performance impact that NDIS supplies should still exist. There is no clear documentation on what part of NDIS(driver or system) that winpcap uses, but based on it's absence in the Network Connection's screen I'd guess it uses the system API to access a driver so I don't clearly see the difference from what coLinux must do. I could completely not know what I'm talking about. >> and I don't feel that >> your patch corrects the issue I was having with taps. >> > the point of my patch was to show how to configure the network > interfaces after they've already been created. that's all. > -mike > Ahh, so I could do network configuration as part of my installer... I saw that and it looked interesting, I didn't quickly grasp how these variables were passed down to the init scripts living in a filesystem image. I can only imagine they pass through /proc/cmdline. This would not solve my issue though, the problem is post-configuration AFAIK. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Henry N. <hen...@ar...> - 2010-08-03 20:49:14
|
Hello Mike, On 02.08.2010 18:40, Mike Mestnik wrote: > I'm able to ping Windows from coLinux, but Windows dose not attempt to > arp or ping back. Most odd, tcpdump under colinux shows only it's own > traffic and ping replies. I'm using ipv4ll for the tap interface on the > windows side and a static 169.254 address in coLinux. If you are using Windows 7 or XP-SP3, then remember to allow Ping in your Windows firewall. > eth0=ndis-bridge > > # Tuntap as private network between guest and host on second linux device > eth1=tuntap,,00:18:8B:26:44:88 For testing network interfaces, you should enable only one interface. So, please disable eth0 ("ifconfig eth0 down") at the time you are testing tap on eth1. Other case you can not see the packet way right. Please start the MAC with 02: for personal use (00: is reserved for real hardware cards). And I hope, this MAC number does not exist some there in your network! Using fixed MAC in an installer is a highly risk. Every body should have its one unique MAC. It would be better to leave this option out and let coLinux set a random number. The random number will generate only ones at first start, and is stored in registry for later use. > Push "create" > Push "Nagios Core" > Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" @NagiosCore.conf --run-service "Nagios Core";autostart=1;depend=CoLinuxDriver;display=Nagios Core;description=Nagios Core Linux Service, this service manages a running instance of linux.;' > Call Service > Pop $0 ;response This part us ugly, wrong and will not run on all destinations. * Please never use "C:\Program Files\" directly! Please use the install path "$INSTDIR". * You should use the coLinux service installer. Or you should complete adding all dependensies. You are using TAP? Then should add "tap0801co". The colinux-daemon will parse your config and adds dependencies automatically, if you use such device. * You have not used full path to "NagiosCore.conf"? -- Henry N. |
From: Mike M. <mme...@na...> - 2010-08-03 21:04:55
|
On 8/3/2010 4:49 PM, Henry Nestler wrote: > Hello Mike, > > On 02.08.2010 18:40, Mike Mestnik wrote: >> I'm able to ping Windows from coLinux, but Windows dose not attempt to >> arp or ping back. Most odd, tcpdump under colinux shows only it's own >> traffic and ping replies. I'm using ipv4ll for the tap interface on the >> windows side and a static 169.254 address in coLinux. > > If you are using Windows 7 or XP-SP3, then remember to allow Ping in > your Windows firewall. > >> eth0=ndis-bridge >> >> # Tuntap as private network between guest and host on second linux >> device >> eth1=tuntap,,00:18:8B:26:44:88 > > For testing network interfaces, you should enable only one interface. > So, please disable eth0 ("ifconfig eth0 down") at the time you are > testing tap on eth1. Other case you can not see the packet way right. > > Please start the MAC with 02: for personal use (00: is reserved for > real hardware cards). And I hope, this MAC number does not exist some > there in your network! Using fixed MAC in an installer is a highly > risk. Every body should have its one unique MAC. It would be better to > leave this option out and let coLinux set a random number. The random > number will generate only ones at first start, and is stored in > registry for later use. > >> Push "create" >> Push "Nagios Core" >> Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" >> @NagiosCore.conf --run-service "Nagios >> Core";autostart=1;depend=CoLinuxDriver;display=Nagios >> Core;description=Nagios Core Linux Service, this service manages a >> running instance of linux.;' >> Call Service >> Pop $0 ;response > > This part us ugly, wrong and will not run on all destinations. > > * Please never use "C:\Program Files\" directly! Please use the > install path "$INSTDIR". Opps. > * You should use the coLinux service installer. Or you should complete > adding all dependensies. You are using TAP? Then should add > "tap0801co". The colinux-daemon will parse your config and adds > dependencies automatically, if you use such device. Yay ! :) > * You have not used full path to "NagiosCore.conf"? > Correct, in testing this didn't work. I'll try again. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Mike M. <mme...@na...> - 2010-08-03 21:06:21
|
On 8/3/2010 4:49 PM, Henry Nestler wrote: > Hello Mike, > > On 02.08.2010 18:40, Mike Mestnik wrote: >> I'm able to ping Windows from coLinux, but Windows dose not attempt to >> arp or ping back. Most odd, tcpdump under colinux shows only it's own >> traffic and ping replies. I'm using ipv4ll for the tap interface on the >> windows side and a static 169.254 address in coLinux. > > If you are using Windows 7 or XP-SP3, then remember to allow Ping in > your Windows firewall. > >> eth0=ndis-bridge >> >> # Tuntap as private network between guest and host on second linux >> device >> eth1=tuntap,,00:18:8B:26:44:88 > > For testing network interfaces, you should enable only one interface. > So, please disable eth0 ("ifconfig eth0 down") at the time you are > testing tap on eth1. Other case you can not see the packet way right. > > Please start the MAC with 02: for personal use (00: is reserved for > real hardware cards). And I hope, this MAC number does not exist some > there in your network! Using fixed MAC in an installer is a highly > risk. Every body should have its one unique MAC. It would be better to > leave this option out and let coLinux set a random number. The random > number will generate only ones at first start, and is stored in > registry for later use. > >> Push "create" >> Push "Nagios Core" >> Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" >> @NagiosCore.conf --run-service "Nagios >> Core";autostart=1;depend=CoLinuxDriver;display=Nagios >> Core;description=Nagios Core Linux Service, this service manages a >> running instance of linux.;' >> Call Service >> Pop $0 ;response > > This part us ugly, wrong and will not run on all destinations. > > * Please never use "C:\Program Files\" directly! Please use the > install path "$INSTDIR". > * You should use the coLinux service installer. Can I set autostart using the installer? The description is optional, but it's nice. > * You have not used full path to "NagiosCore.conf"? > -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Mike M. <mme...@na...> - 2010-08-03 21:19:17
|
On 8/3/2010 4:49 PM, Henry Nestler wrote: > Hello Mike, > > On 02.08.2010 18:40, Mike Mestnik wrote: >> I'm able to ping Windows from coLinux, but Windows dose not attempt to >> arp or ping back. Most odd, tcpdump under colinux shows only it's own >> traffic and ping replies. I'm using ipv4ll for the tap interface on the >> windows side and a static 169.254 address in coLinux. > > If you are using Windows 7 or XP-SP3, then remember to allow Ping in > your Windows firewall. > >> eth0=ndis-bridge >> >> # Tuntap as private network between guest and host on second linux >> device >> eth1=tuntap,,00:18:8B:26:44:88 > > For testing network interfaces, you should enable only one interface. > So, please disable eth0 ("ifconfig eth0 down") at the time you are > testing tap on eth1. Other case you can not see the packet way right. > > Please start the MAC with 02: for personal use (00: is reserved for > real hardware cards). And I hope, this MAC number does not exist some > there in your network! Using fixed MAC in an installer is a highly > risk. Every body should have its one unique MAC. It would be better to > leave this option out and let coLinux set a random number. The random > number will generate only ones at first start, and is stored in > registry for later use. > >> Push "create" >> Push "Nagios Core" >> Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" >> @NagiosCore.conf --run-service "Nagios >> Core";autostart=1;depend=CoLinuxDriver;display=Nagios >> Core;description=Nagios Core Linux Service, this service manages a >> running instance of linux.;' >> Call Service >> Pop $0 ;response > > This part us ugly, wrong and will not run on all destinations. > > * Please never use "C:\Program Files\" directly! Please use the > install path "$INSTDIR". > * You should use the coLinux service installer. Or you should complete > adding all dependensies. You are using TAP? Then should add > "tap0801co". The colinux-daemon will parse your config and adds > dependencies automatically, if you use such device. Sorry to still bother, but after looking at these resources I can't seam to discover how this would work as an array. http://nsis.sourceforge.net/NSIS_Service_Lib http://msdn.microsoft.com/en-us/library/ms682450%28VS.85%29.aspx ";depend=tap0801co,CoLinuxDriver;" is my first guess. > * You have not used full path to "NagiosCore.conf"? > -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Henry N. <hen...@ar...> - 2010-08-03 21:53:25
|
Hello Mike, On 03.08.2010 22:19, Mike Mestnik wrote: > On 8/3/2010 4:49 PM, Henry Nestler wrote: Hello Mike, >> On 02.08.2010 18:40, Mike Mestnik wrote: >>> Push "create" >>> Push "Nagios Core" >>> Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" >>> @NagiosCore.conf --run-service "Nagios >>> Core";autostart=1;depend=CoLinuxDriver;display=Nagios >>> Core;description=Nagios Core Linux Service, this service manages a >>> running instance of linux.;' >>> Call Service >>> Pop $0 ;response >> This part us ugly, wrong and will not run on all destinations. >> >> * Please never use "C:\Program Files\" directly! Please use the >> install path "$INSTDIR". >> * You should use the coLinux service installer. Or you should complete >> adding all dependensies. You are using TAP? Then should add >> "tap0801co". The colinux-daemon will parse your config and adds >> dependencies automatically, if you use such device. > Sorry to still bother, but after looking at these resources I can't seam > to discover how this would work as an array. > http://nsis.sourceforge.net/NSIS_Service_Lib > http://msdn.microsoft.com/en-us/library/ms682450%28VS.85%29.aspx > > ";depend=tap0801co,CoLinuxDriver;" > is my first guess. Think, it is not supported by this addon. The right string for dependency names in CreateService is "CoLinuxDriver\0tap0801co\0\0". The delimiter between strings is "\0" and the string termination is "\0\0". This would not work with the "StrCpy" in servicelib.nsh, I think. StrCpy would stop on first 00h. In other case, you can assume, that coLinuxDriver will faster load as the network driver. coLinuxDriver has no more other dependency. Tap driver needs a complete network being up. So, adding only "tap0801co" would be enough for delaying coLinux startup. -- Henry N. |
From: Mike M. <mme...@na...> - 2010-08-03 22:06:55
|
On 8/3/2010 5:53 PM, Henry Nestler wrote: > Hello Mike, > > On 03.08.2010 22:19, Mike Mestnik wrote: >> On 8/3/2010 4:49 PM, Henry Nestler wrote: Hello Mike, >>> On 02.08.2010 18:40, Mike Mestnik wrote: >>>> Push "create" >>>> Push "Nagios Core" >>>> Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" >>>> @NagiosCore.conf --run-service "Nagios >>>> Core";autostart=1;depend=CoLinuxDriver;display=Nagios >>>> Core;description=Nagios Core Linux Service, this service manages a >>>> running instance of linux.;' >>>> Call Service >>>> Pop $0 ;response >>> This part us ugly, wrong and will not run on all destinations. >>> >>> * Please never use "C:\Program Files\" directly! Please use the >>> install path "$INSTDIR". >>> * You should use the coLinux service installer. Or you should complete >>> adding all dependensies. You are using TAP? Then should add >>> "tap0801co". The colinux-daemon will parse your config and adds >>> dependencies automatically, if you use such device. >> Sorry to still bother, but after looking at these resources I can't seam >> to discover how this would work as an array. >> http://nsis.sourceforge.net/NSIS_Service_Lib >> http://msdn.microsoft.com/en-us/library/ms682450%28VS.85%29.aspx >> >> ";depend=tap0801co,CoLinuxDriver;" >> is my first guess. > > Think, it is not supported by this addon. > The right string for dependency names in CreateService is > "CoLinuxDriver\0tap0801co\0\0". > The delimiter between strings is "\0" and the string termination is > "\0\0". > This would not work with the "StrCpy" in servicelib.nsh, I think. > StrCpy would stop on first 00h. > > In other case, you can assume, that coLinuxDriver will faster load as > the network driver. coLinuxDriver has no more other dependency. Tap > driver needs a complete network being up. So, adding only "tap0801co" > would be enough for delaying coLinux startup. > I see, but the coLinux driver might not start at all. That and this is not sysv, it's windows, keyboard and mouse drivers are known to not load when expected, why expect anything else to function on time? This is frailly standard, it's an array of ansi strings. http://www.java2s.com/Code/C/Data-Type/Arraysofstrings.htm As you are correct StrCpy will likely not work with an C Data-Type like a string, let alone an array of C strings. NSIS is a higher level language, so this atom would need to be mapped to a higher level construct. As this whole structure is, with '\0' being replaced with ';' I'd just assumed this case too was handled... Perhaps by another interpreter, like VB... Sorry for the NSIS specific question!!! -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Mike M. <mme...@na...> - 2010-08-05 16:37:11
|
On 8/3/2010 5:53 PM, Henry Nestler wrote: > Hello Mike, > > On 03.08.2010 22:19, Mike Mestnik wrote: >> On 8/3/2010 4:49 PM, Henry Nestler wrote: Hello Mike, >>> On 02.08.2010 18:40, Mike Mestnik wrote: >>>> Push "create" >>>> Push "Nagios Core" >>>> Push 'path="C:\Program Files\Nagios Core\colinux-daemon.exe" >>>> @NagiosCore.conf --run-service "Nagios >>>> Core";autostart=1;depend=CoLinuxDriver;display=Nagios >>>> Core;description=Nagios Core Linux Service, this service manages a >>>> running instance of linux.;' >>>> Call Service >>>> Pop $0 ;response >>> This part us ugly, wrong and will not run on all destinations. >>> >>> * Please never use "C:\Program Files\" directly! Please use the >>> install path "$INSTDIR". >>> * You should use the coLinux service installer. Or you should complete >>> adding all dependensies. You are using TAP? Then should add >>> "tap0801co". The colinux-daemon will parse your config and adds >>> dependencies automatically, if you use such device. >> Sorry to still bother, but after looking at these resources I can't seam >> to discover how this would work as an array. >> http://nsis.sourceforge.net/NSIS_Service_Lib >> http://msdn.microsoft.com/en-us/library/ms682450%28VS.85%29.aspx >> >> ";depend=tap0801co,CoLinuxDriver;" >> is my first guess. > I finally got this working, using... # echo -ne 'CoLinuxDriver\0tap0801co\0\0' | hexdump -ve '4/1 " &i1 %3u," "\\\n"' System::Call "*(&i1 67, &i1 111, &i1 76, &i1 105,\ &i1 110, &i1 117, &i1 120, &i1 68,\ &i1 114, &i1 105, &i1 118, &i1 101,\ &i1 114, &i1 0, &i1 116, &i1 97,\ &i1 112, &i1 48, &i1 56, &i1 48,\ &i1 49, &i1 99, &i1 111, &i1 0,\ &i1 0) i .R1" System::Call 'advapi32::CreateServiceA(i r4, t r2, t R7, i ${SERVICE_ALL_ACCESS}, \ i R4, i R5, i 0, t R6, n, n, i $R1, $R2, $R3) i.r6' However!!! Networking still is not functional. Is there any debugging I can do? > Think, it is not supported by this addon. > The right string for dependency names in CreateService is > "CoLinuxDriver\0tap0801co\0\0". > The delimiter between strings is "\0" and the string termination is > "\0\0". > This would not work with the "StrCpy" in servicelib.nsh, I think. > StrCpy would stop on first 00h. > > In other case, you can assume, that coLinuxDriver will faster load as > the network driver. coLinuxDriver has no more other dependency. Tap > driver needs a complete network being up. So, adding only "tap0801co" > would be enough for delaying coLinux startup. > -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Henry N. <hen...@ar...> - 2010-08-05 18:27:31
|
On 05.08.2010 17:36, Mike Mestnik wrote: > I finally got this working, using... > # echo -ne 'CoLinuxDriver\0tap0801co\0\0' | hexdump -ve '4/1 "&i1 %3u," > "\\\n"' > System::Call "*(&i1 67,&i1 111,&i1 76,&i1 105,\ > &i1 110,&i1 117,&i1 120,&i1 68,\ > &i1 114,&i1 105,&i1 118,&i1 101,\ > &i1 114,&i1 0,&i1 116,&i1 97,\ > &i1 112,&i1 48,&i1 56,&i1 48,\ > &i1 49,&i1 99,&i1 111,&i1 0,\ > &i1 0) i .R1" > System::Call 'advapi32::CreateServiceA(i r4, t r2, t R7, i > ${SERVICE_ALL_ACCESS}, \ > i R4, i R5, i 0, t R6, n, > n, i $R1, $R2, $R3) i.r6' Hui, what an interesting hack :)) > 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. > 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. 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. 2. Without MAC in the config, the random MAC can trigger sometimes the udev-system to create a new ethernet number. It is no guarantee, that eth0 will come up. Sometimes it will renamed to eth2, eth3 and so on. You can see it under Linux in boot messages and in /proc/net/dev -- Henry N. |
From: Mike M. <mme...@na...> - 2010-08-05 20:00:43
|
On 8/5/2010 2:27 PM, Henry Nestler wrote: > On 05.08.2010 17:36, Mike Mestnik wrote: >> I finally got this working, using... >> # echo -ne 'CoLinuxDriver\0tap0801co\0\0' | hexdump -ve '4/1 "&i1 %3u," >> "\\\n"' >> System::Call "*(&i1 67,&i1 111,&i1 76,&i1 105,\ >> &i1 110,&i1 117,&i1 120,&i1 68,\ >> &i1 114,&i1 105,&i1 118,&i1 101,\ >> &i1 114,&i1 0,&i1 116,&i1 97,\ >> &i1 112,&i1 48,&i1 56,&i1 48,\ >> &i1 49,&i1 99,&i1 111,&i1 0,\ >> &i1 0) i .R1" >> System::Call 'advapi32::CreateServiceA(i r4, t r2, t R7, i >> ${SERVICE_ALL_ACCESS}, \ >> i R4, i R5, i 0, t R6, n, >> n, i $R1, $R2, $R3) i.r6' > > Hui, what an interesting hack :)) > >> 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? >> 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. > 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. Printing a single warning would be sufficient. 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. I'd be interested in doing this for future versions, but for now just to get something that would work some of the time would be enough. > 2. Without MAC in the config, the random MAC can trigger sometimes the > udev-system to create a new ethernet number. It is no guarantee, that > eth0 will come up. Sometimes it will renamed to eth2, eth3 and so on. > You can see it under Linux in boot messages and in /proc/net/dev > I've disabled this feature ;) -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: Henry N. <hen...@ar...> - 2010-08-05 20:49:58
|
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. 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". >>> 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. 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 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. 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. > 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". > 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. The message was printed, but user would not read it while running as service. -- Henry N. |
From: Mike M. <mme...@na...> - 2010-08-05 21:33:21
|
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 |
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. |
From: Henry N. <hen...@ar...> - 2010-08-06 00:28:26
|
On 06.08.2010 02:22, Henry Nestler wrote: > On 05.08.2010 22:31, Mike Mestnik wrote: >> ...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. Sorry, not from the colinux-daemon.exe self. I don't know why. You can see the networking daemons. Every in separate window. -- Henry N. |
From: Henry N. <hen...@ar...> - 2010-08-06 19:08:29
|
Hello Mike, a big difference between pcap-bride and ndis-bride exist inside the code for auto probing name. pcap-bridge: Checks that the interface has an IP address. ndis-bride: Does *not* check IP address. ndis simple use the first network adapter it will find. So, auto probing the name for ndis would fail in mostly all cases. On an other desktop here for me, ndis found a network card, that no longer exist, becaus I have replaced with a new card. :-( -- Henry N. |
From: Mike M. <mme...@na...> - 2010-08-09 17:21:40
|
On 8/9/2010 12:40 PM, Mike Mestnik wrote: > On 8/6/2010 3:08 PM, Henry Nestler wrote: >> Hello Mike, >> >> a big difference between pcap-bride and ndis-bride exist inside the >> code for auto probing name. >> >> pcap-bridge: Checks that the interface has an IP address. >> ndis-bride: Does *not* check IP address. ndis simple use the first >> network adapter it will find. >> >> So, auto probing the name for ndis would fail in mostly all cases. >> On an other desktop here for me, ndis found a network card, that no >> longer exist, becaus I have replaced with a new card. :-( >> > I gave tap/ndis-bridge another try renaming and specifying both names, > (tap0/eth0) and this failed. > > It may vary well work on an interface that does not have an IP > address, it's an interface that does not have link that would be a > problem. Given a system with two interfaces makes auto probing a > possibility, perhaps if there are more interfaces then there are > interface definitions it should fail. Also note all the interfaces > could be setup for DHCP... so getting the interfaces in the correct > order may not be an issue and it should not be an issue because > interface probing order is already a known issue. Perhaps instead of > a randomly generated address one should be based of the address it's > bound with, this way udev's persistent code would work as intended and > there'd be no-more need for the registry saving that's also causing > problems. > > > Given the current status I'm migrating to slirp, though I'd be > interested in testing solutions to the un-identified problem I'm having. > This is what I have on my local instance that I use day-to-day: eth0=ndis-bridge,,00:18:8B:26:42:84 eth1=tuntap,,00:18:8B:26:44:80 Every thing is fine with this, reboot and it's still all good. This makes me think it's a mistake to try and set the name and instead the real solution is to set a random address. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
From: SY <ysh...@ya...> - 2010-08-09 18:13:40
|
Hi, I'm enough. Please get me out of this mailing list, thanks a lot! ________________________________ From: Mike Mestnik <mme...@na...> Cc: col...@li... Sent: Mon, August 9, 2010 1:21:30 PM Subject: Re: [coLinux-users] Networking: NSIS installer fails to configure tap correctly. On 8/9/2010 12:40 PM, Mike Mestnik wrote: > On 8/6/2010 3:08 PM, Henry Nestler wrote: >> Hello Mike, >> >> a big difference between pcap-bride and ndis-bride exist inside the >> code for auto probing name. >> >> pcap-bridge: Checks that the interface has an IP address. >> ndis-bride: Does *not* check IP address. ndis simple use the first >> network adapter it will find. >> >> So, auto probing the name for ndis would fail in mostly all cases. >> On an other desktop here for me, ndis found a network card, that no >> longer exist, becaus I have replaced with a new card. :-( >> > I gave tap/ndis-bridge another try renaming and specifying both names, > (tap0/eth0) and this failed. > > It may vary well work on an interface that does not have an IP > address, it's an interface that does not have link that would be a > problem. Given a system with two interfaces makes auto probing a > possibility, perhaps if there are more interfaces then there are > interface definitions it should fail. Also note all the interfaces > could be setup for DHCP... so getting the interfaces in the correct > order may not be an issue and it should not be an issue because > interface probing order is already a known issue. Perhaps instead of > a randomly generated address one should be based of the address it's > bound with, this way udev's persistent code would work as intended and > there'd be no-more need for the registry saving that's also causing > problems. > > > Given the current status I'm migrating to slirp, though I'd be > interested in testing solutions to the un-identified problem I'm having. > This is what I have on my local instance that I use day-to-day: eth0=ndis-bridge,,00:18:8B:26:42:84 eth1=tuntap,,00:18:8B:26:44:80 Every thing is fine with this, reboot and it's still all good. This makes me think it's a mistake to try and set the name and instead the real solution is to set a random address. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: Henry N. <hen...@ar...> - 2010-08-09 22:00:23
|
On 09.08.2010 19:21, Mike Mestnik wrote: > On 8/9/2010 12:40 PM, Mike Mestnik wrote: >> On 8/6/2010 3:08 PM, Henry Nestler wrote: >>> Hello Mike, >>> >>> a big difference between pcap-bride and ndis-bride exist inside the >>> code for auto probing name. >>> >>> pcap-bridge: Checks that the interface has an IP address. >>> ndis-bride: Does *not* check IP address. ndis simple use the first >>> network adapter it will find. >>> >>> So, auto probing the name for ndis would fail in mostly all cases. >>> On an other desktop here for me, ndis found a network card, that no >>> longer exist, becaus I have replaced with a new card. :-( >>> >> I gave tap/ndis-bridge another try renaming and specifying both names, >> (tap0/eth0) and this failed. >> >> It may vary well work on an interface that does not have an IP >> address, it's an interface that does not have link that would be a >> problem. Given a system with two interfaces makes auto probing a >> possibility, perhaps if there are more interfaces then there are >> interface definitions it should fail. Also note all the interfaces >> could be setup for DHCP... so getting the interfaces in the correct >> order may not be an issue and it should not be an issue because >> interface probing order is already a known issue. Perhaps instead of >> a randomly generated address one should be based of the address it's >> bound with, this way udev's persistent code would work as intended and >> there'd be no-more need for the registry saving that's also causing >> problems. >> >> >> Given the current status I'm migrating to slirp, though I'd be >> interested in testing solutions to the un-identified problem I'm having. >> > This is what I have on my local instance that I use day-to-day: > eth0=ndis-bridge,,00:18:8B:26:42:84 > eth1=tuntap,,00:18:8B:26:44:80 > > Every thing is fine with this, reboot and it's still all good. This > makes me think it's a mistake to try and set the name and instead the > real solution is to set a random address. If the MAC is your problem, you would see a "eth0: no such device" in the running Linux, and the renamed part eth2 or higher in /proc/net/dev. Without given name on ndis-bridge this can work. Maybe. It depends on the sorting in your registry. But, it would not work every time on everybody machines. If you create a setup, than you should give the user a selection from the list of networkadpters and the user should enable, on which one the bridge should connected to. The list you will find under "SYSTEM\CurrentControlSet\Control\\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}", the same list ndis-bridge used for name search. For the detecting interface which has an ip address (currently only coded on "pcap-bridge"): The idea is, that pcap-bridge should automatically find the interface you currently use to the world. This interface in normal situation has an ip address at the time you starts coLinux. This makes no difference of static IP or DHCP. And last: Auto probing name for pcap-bridge or ndis-bridge is never optimal. It's an help for simple environments with single network card only. TAP-Win32 device you not need to rename, as long you only have one coLinux TAP installed. TAP-Win32 for coLinux has a special ID and will find in every cases. I hope 00:18:8B:26:42:84 is an number you have self created, and not exist on any card. Better you should start with 02, not with 00 there. 00 can be real hardware. 02 can never be a real hardware, it's defined as "controlled by user". So, 02:18:8B:26:42:84 would be be better for you. For ndis-bridge or pcap-bridge the MAC can be calculated from bounded device, maybe. But, what should do with tuntap (Win-TAP32)? This type has no reference. So, the globale rule is: If user does not set a MAC, we use ones random created MAC. There exist no problem, if the user will run only as Service or an other user will run only from command line. The problem exist only for users, that would try to run command line and the service with same root image. Typically users disable the udev for inside the image and never have a problem again (see http://colinux.wikia.com/wiki/Wubi#udev:_renamed_network_interface_eth0_to_eth2). Other users sets a MAC and also have no problems. -- Henry N. |
From: Mike M. <mme...@na...> - 2010-08-10 15:46:02
|
On 8/9/2010 5:00 PM, Henry Nestler wrote: > On 09.08.2010 19:21, Mike Mestnik wrote: >> On 8/9/2010 12:40 PM, Mike Mestnik wrote: >>> On 8/6/2010 3:08 PM, Henry Nestler wrote: >>>> Hello Mike, >>>> >>>> a big difference between pcap-bride and ndis-bride exist inside the >>>> code for auto probing name. >>>> >>>> pcap-bridge: Checks that the interface has an IP address. >>>> ndis-bride: Does *not* check IP address. ndis simple use the first >>>> network adapter it will find. >>>> >>>> So, auto probing the name for ndis would fail in mostly all cases. >>>> On an other desktop here for me, ndis found a network card, that no >>>> longer exist, becaus I have replaced with a new card. :-( >>>> >>> I gave tap/ndis-bridge another try renaming and specifying both names, >>> (tap0/eth0) and this failed. >>> >>> It may vary well work on an interface that does not have an IP >>> address, it's an interface that does not have link that would be a >>> problem. Given a system with two interfaces makes auto probing a >>> possibility, perhaps if there are more interfaces then there are >>> interface definitions it should fail. Also note all the interfaces >>> could be setup for DHCP... so getting the interfaces in the correct >>> order may not be an issue and it should not be an issue because >>> interface probing order is already a known issue. Perhaps instead of >>> a randomly generated address one should be based of the address it's >>> bound with, this way udev's persistent code would work as intended and >>> there'd be no-more need for the registry saving that's also causing >>> problems. >>> >>> >>> Given the current status I'm migrating to slirp, though I'd be >>> interested in testing solutions to the un-identified problem I'm >>> having. >>> >> This is what I have on my local instance that I use day-to-day: >> eth0=ndis-bridge,,00:18:8B:26:42:84 >> eth1=tuntap,,00:18:8B:26:44:80 >> >> Every thing is fine with this, reboot and it's still all good. This >> makes me think it's a mistake to try and set the name and instead the >> real solution is to set a random address. > > If the MAC is your problem, you would see a "eth0: no such device" in > the running Linux, and the renamed part eth2 or higher in /proc/net/dev. > I've disabled renaming in udev, this is easily correctable and you should have a howto instead of insisting the interface names will be changed automatically. Perhaps you should work with the udev ppl to implement a blacklisted range... I.E. if the mac address starts with XYZ then don't rename it ever, or rather opt it out of the persistent database... Perhaps only existing as a remark/placeholder. That's another note colinux(or linux in general) should have a system for issuing mac addresses to software cards and taps. > Without given name on ndis-bridge this can work. Maybe. It depends on > the sorting in your registry. But, it would not work every time on > everybody machines. > > If you create a setup, than you should give the user a selection from > the list of networkadpters and the user should enable, on which one > the bridge should connected to. The list you will find under > "SYSTEM\CurrentControlSet\Control\\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}", > the same list ndis-bridge used for name search. > I'll keep that in mind for future version, however automation is key. > For the detecting interface which has an ip address (currently only > coded on "pcap-bridge"): The idea is, that pcap-bridge should > automatically find the interface you currently use to the world. This > interface in normal situation has an ip address at the time you starts > coLinux. This makes no difference of static IP or DHCP. And last: Auto > probing name for pcap-bridge or ndis-bridge is never optimal. It's an > help for simple environments with single network card only. > Another senerio would have all traffic routed through colinux and thus this device would intentionally not have an address. It's not bad, but it's not good either. That is this is neither a bug nor a feature. > TAP-Win32 device you not need to rename, as long you only have one > coLinux TAP installed. TAP-Win32 for coLinux has a special ID and will > find in every cases. > > I hope 00:18:8B:26:42:84 is an number you have self created, and not > exist on any card. Better you should start with 02, not with 00 there. > 00 can be real hardware. 02 can never be a real hardware, it's defined > as "controlled by user". So, 02:18:8B:26:42:84 would be be better for > you. > My understanding is that the first 3 octets indicate the vendor, are you indicating that 02:xx:yy indicates a vendor-less address? I'm unconcerned about collisions, I'm not on a huge network and I'd wonder who is. It will *usually* be sufficient as long as it's not a copy of something else... I'm sure every one has a "one day I had two nic cards and..." story to tell there children... It'd probably start with back in my day we only had 48bits both ways... > For ndis-bridge or pcap-bridge the MAC can be calculated from bounded > device, maybe. But, what should do with tuntap (Win-TAP32)? This type > has no reference. So, the globale rule is: If user does not set a MAC, > we use ones random created MAC. There exist no problem, if the user > will run only as Service or an other user will run only from command > line. The problem exist only for users, that would try to run command > line and the service with same root image. Typically users disable the > udev for inside the image and never have a problem again (see > http://colinux.wikia.com/wiki/Wubi#udev:_renamed_network_interface_eth0_to_eth2). > Other users sets a MAC and also have no problems. > The tap has an address as well, though who assigns it and where is it stored being another mattor. I'd say it's likely not to change based on the current user, thus making it a good choice for the "where should I load this from?" question. The TAP is another device on a virtual cross over cable and it shouldn't have the same address on both ends... Though being it's a PtP connection I can't see why that would be a problem, it would be broken for software to check and broken for a transmitter to care much for the receiver's address. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |