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

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

  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.