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

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

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