Hello,
Yes, I have already found the cause of my problem - it is the network card I used (or maybe the
driver used). In the MIPL sources (movement.c, rtnl.c) I have found that the handover is triggered
by NETLINK message of type RTM_NEWLINK, which is send when the kernel (or network driver) realized
that something has changed on the link (e.g. cable is connected).
Problem with my card is that it is very lazy - the message about change on the interface is sent
after very long time - up to 30 seconds. Some other network devices (especially some PCMCIA or USB
wireless cards) send this message immediately after they have connected/disconnected to the AP, but
they do not change the link status in the message - the link is always UP and RUNNING, even if it is
not connected - so mipd don't realize any change.
Currently we are working on some solution, but maybe we'll just buy some more reliable network cards
;-).
Regards,
Michal
Jong-Hyouk Lee wrote:
Dear colleague.
Did you solve the problem which the handover time takes too long? I
think that you shoul check your wireless bandwith becuase in my case
handover time takes about 3-7 seconds normally. However, in your case,
it was too long.
Also, when the network has high traffic, the handover time should be
late. I am not sure this reply helps you.
Cheers.
On 7/25/06, *Michal Martinek* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thank you very much Benjamin, it really helped me.
I haven't experienced the priorization of the interface connected
directly to the home network to
the other, as you described, but for me it is much better without
it, so I am satisfied :-).
The only problem I have now is that the handover between the
interfaces takes too long (between 5
and 20 seconds). I have lessened the interval for Router
Adverisements (1s Min, 3s Max), set the
MnRouterProbes to 0 (previously it was 1), but nothing helped. Do
you have any other hints?
Regards,
Michal
Benjamin Thery wrote:
> Hello Michal,
>
> See my answers below.
>
> Michal Martinek wrote:
>
>> Hello all,
>>
>> I have installed and run MIPL 2.0.2 on our testbed and everything
>> works fine:
>>
>> Our testbed architecture is similar to the one pictured in the MIPL
>> HOWTO, except that everything is wired, addresses are global and HA
>> serves also as the home router (R). We also use CN as a part of the
>> Home subnet. Everything run on Fedora Core 5, kernel 2.6.16.22
<http://2.6.16.22>
>> (patched where necessary).
>>
>> I made some handover tests with the "default" configuration and
>> everything worked as I expected. Now I tried to use MN with two
>> interfaces to see what functionality it can provide to us, but I
>> wasn't able to run it properly. I think, that I don't fully
understand
>> how should it work. So I have some questions to this:
>>
>> 1) When I create two "Interface" records and two "HomeLink"
records in
>> the mip6d.conf, does it create two different MNs or just one using
>> both interfaces?
>
>
> If you have one HA and want to use two interfaces you should
write two
> "Interface" records but only one "HomeLink" record.
> You will have one MN using both interfaces.
>
> If you want to define more than one Home Address for your mobile
node,
> you can add more "MnHomeLink" record. (but according to the
scenario you
> describe I understand it is not what you want).
>
>
>> 2) What addresses should be written in the "HomeAddress" sections in
>> the MnHomelink records for each interface? Can I use the same
>> addresses even if the "real" interface addresses are different?
>
>
> As stated above, you only have to write one MnHomeLink record.
> (MnHomeLink see mip6d.conf manpage)
>
>
>> 3) Is it possible to use these two interfaces for "lazy" MN
handover
>> like this?:
>> a) eth0 is connected to the Home Network, eth1 is disconnected
>> b) eth1 connects to the visited network
>> c) eth0 disconnects from the home network
>> e) communication with CN is not disrupted, but now goes
through the
>> eth1
>
>
> Yes, this should work. I tested similar scenarii here with success.
>
> Note that mip6d always prefer the home link over the foreign link (at
> least it's the behavior I observed). Thus, even if you put a higher
> preference on interface eth1, in the case you describe, mip6d will
> switch to eth1 only when eth0 is disconnected.
> If you re-connect eth0 later (and keep eth1 connected), mip6d will
> switch automatically to eth0 (Home Link is preferred).
> If both interfaces are connected to foreign networks, mip6d will
choose
> the one if the higher preference in the configuration file, and
switch
> if necessary.
>
> Regards,
> Benjamin
>
>>
>> Thanks in advance for any answer.
>>
>> Regards,
>>
>> Michal
>>
>> _______________________________________________
>> mipl mailing list
>> [email protected] <mailto:[email protected]>
>> http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
>>
>
>
_______________________________________________
mipl mailing list
[email protected] <mailto:[email protected]>
http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.
#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
_______________________________________________
mipl mailing list
[email protected]
http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
