Menu
▾
▴
colinux-users
|
From: Henry N. <hen...@ar...> - 2010-08-10 20:23:08
|
On 10.08.2010 17:45, Mike Mestnik wrote: > On 8/9/2010 5:00 PM, Henry Nestler wrote: >> 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? Setting the bit 1 is in first byte a sing, that you manually control this MAC in a local network. Never of real hardware cards have set this bit. See http://en.wikipedia.org/wiki/MAC_address#Address_details -- Henry N. |
|
From: Henry N. <hen...@ar...> - 2010-08-06 00:22:05
|
On 05.08.2010 21:00, Mike Mestnik wrote:
> 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 :))
Alternatively you can change the depends with command line tool "sc":
sc config "Cooperative Linux" depend= "CoLinuxDriver/tap0801co"
--
Henry N.
|
|
From: Mike M. <mme...@na...> - 2010-08-05 20:44:05
|
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.
>
Bow to the gods of both Windows and Linux.
As you indicated every one garbed the wrong interface.
> 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
>
--
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email: mme...@na...
Web: www.nagios.com
|
|
From: Mike M. <mme...@na...> - 2010-08-09 16:40:44
|
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. -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
|
From: Henry N. <hen...@ar...> - 2010-08-03 22:44:04
|
hello Mike, On 03.08.2010 22:06, Mike Mestnik wrote: > On 8/3/2010 4:49 PM, Henry Nestler wrote: >> 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. > Can I set autostart using the installer? No. The user should run it manually at first time. If it's running good, the user can change the mode simply in service control manager. If the automatic start would crash on every boot, it is difficult for user to stop this. (with "safe mode", removing service, ...). -- Henry N. |
|
From: Mike M. <mme...@na...> - 2010-08-04 16:11:18
|
On 8/3/2010 6:43 PM, Henry Nestler wrote: > hello Mike, > > On 03.08.2010 22:06, Mike Mestnik wrote: >> On 8/3/2010 4:49 PM, Henry Nestler wrote: >>> 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. >> Can I set autostart using the installer? > > No. The user should run it manually at first time. > If it's running good, the user can change the mode simply in service > control manager. > If the automatic start would crash on every boot, it is difficult for > user to stop this. (with "safe mode", removing service, ...). > The intended audience is users who have never seen the service control manager and wouldn't understand it if they did... That and "Automation is key." -- Mike Mestnik -- Mike Mestnik Technical Team ___ Nagios Enterprises, INC. Email: mme...@na... Web: www.nagios.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X