[support] MR not able to send BU, when move from HL to FL(ipv4 n/w)

Maheshwar Singh singh.maheshwar72 at gmail.com
Mon Jan 5 20:36:05 JST 2009


Hi Kien

I read your mail from the mailing list, which u have replied for Rohit. It
had the subject
     *[Dsmip] Need Help in IPv4 - IPv6 Handover Support"*

I have applied the patches as mentioned by u in the mail, followed both
README. But facing issues, when I switch from HL to ipv4 FL network.
Mentioned all my details in previous two mails send to DSMIPv6 mailing
lists, with subject as:

     *[Dsmip] MR not able to send BU, when move from HL to FL(ipv4 n/w)*

I want to know that whether we need some ipv4 routing advertisement daemon,
when MR moves from HL to IPv4 only network. If yes, on what machines, do we
need to run it. Please provide some pointer. So that I can proceed
further.......

- Maheshwar Singh


On Fri, Jan 2, 2009 at 6:06 PM, Maheshwar Singh <singh.maheshwar72 at gmail.com
> wrote:

> Hi All
> Please provide some feedback on the previous mail.  Adding some more
> information, which can be helpful to knock down the issue, I am facing at my
> end.
>
> I Looked into the code and this is my observation related to the issue:
>
> When we move from HL to ipv4 FL, this is the flow of MIP code:
>
> *mn_movement_event()* ---> *mn_chk_ho_verdict()* ---> *
> mn_make_ho_verdict()* ----> *md_get_first_router()*
>
> The last routine is returning NULL as there is no entry of default router
> in the list. And if it is NULL, then the routine *mn_home_rtr_chk()* is
> not called. And the flag (*at_home* in *home_addr_info* struct) is not set
> as 0.  Flags previous value is 1, which means that we are in HL. So the
> routine *mn_move()* is not called. This is the reason movement detection
> is failing, when we move from HL to IPv4 network.
>
> In case, when we move from HL to IPv6 network, that time the routine *
> md_add_default_router()* is called, which add the entry for default router
> in list. This process is triggered, when we receive the router advertisement
> from the radvd running in IPv6 only foreign network.
>
> My doubt is, do we need some routing advertisement daemon for IPv4 traffic
> on IPv4 only FL, or need to do changes in code. Please provide some
> pointer..........
>
> - Maheshwar Singh
>   On Mon, Dec 29, 2008 at 5:17 PM, Maheshwar Singh <
> singh.maheshwar72 at gmail.com> wrote:
>
>>   Hi All
>>
>> I am new to this group and facing some issues, while moving MR from home
>> link to foreign link(ipv4 network). The MR is not sending BU to HA. When
>> seen in the mip6d logs, the movement detection code is not getting
>> triggered. But when I start the mip6d daemon( in MR) in FL(ipv4 network),
>> then MR sends the BU to HA. Attaching the mip6d logs for MR in both
>> scenario.
>>
>> a. In the logs, we see the below error messages.
>>                mip6d[4330]: Interface 7 (sit0):type 776 unsupported
>>                mip6d[4330]: Interface 9 (tunl0):type 768 unsupported
>>                mip6d[4330]: Interface 15 (sit1):type 776 unsupported
>>                mip6d[4330]: Interface 16 (tunl1):type 768 unsupported
>>
>>     Do we need some specific patch to fix the above error message. Till
>> now I have applied the following
>>     patches.
>>               1. NEPL basic patch
>>               2. umip-dsmip-20080530.tar
>>               3. umip-dsmip-v4traffic-20081021.tar
>>
>>      The linux kernel used is linux-2.6.24. Please provide some pointer to
>> proceed further.
>>
>> Regards
>> Maheshwar
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20090105/6fd624ba/attachment-0002.htm 


More information about the Support mailing list