[support] Re: [Dsmip] MR not able to send BU, when move from HL to FL(ipv4 n/w)
Maheshwar Singh
singh.maheshwar72 at gmail.com
Wed Jan 7 21:37:12 JST 2009
Hi Sebastien
Thanks for the response.
After reading your previous mail, this is my current understanding:
Currently we dont need any IPv4 router advertisement daemon in IPv4 only FL.
We require only DHCP server, which will assign the ip address to the egress
interface of MR.
As mentioned by you, I verified the sequence HL--->IPv6---->IPv4. In this
sequence, the BU from MR is send successfully to HA and finally binding
management messages are exchanged. This is happening because the flag
"at_home" is set as 0, when we are moved in IPv6 network from HL and as we
move to IPv4 network from IPv6 network, the flag value still remains 0
(indicate that MR is in FL). So the BU is send successfully to HA. But
observed that the behavior is not same, when we move in IPv6 n/w from HL.
Facing some issues, the details are mentioned below:
a. Flooding of BU and BA messages
When we connect from ipv6 to ipv4 network. I see the flood of BU messages on
mip6d logs on MR side and BA messages on mip6d logs on HA side.
This behaviour is not observed when we move from HL to ipv6 network and when
we start mip6d on the ipv4 foreign link. I didn'tobserved any crash, due to
flood. But still something is going wrong, which is forcing flooding of BU
and BA. Any pointer on this.......
b. IPv4 CoA is not getting released at the time of handover
When we move from ipv4 network to ipv6 network (or HL). The Egress interface
of MR is not releasing the previous CoA. Due to which CoA in *struct
movement_event* and *struct home_addr_info* is not matching, and finally MR
is failing to send BU to HA. Mentioned below the sequence of movement.
a. HL --->IPv6------>IPv4
b. IPv4 -----> IPv6 (or HL)
Any pointer on this...........
c. Kernel crash at the time of handovers
When we move from IPv4 to IPv6 or vice-versa, the MR is crashing. This
occurs frequently if we are running some traffic from MNN. MR is not
crashing, when there is no flow of traffic from MNN. Similar problem
is mentioned by Satya in the DSMIPv4 mailing list, with the subject as:
----------> [support] Need help in kernel crash in MR.
I am not able to trace down kernel panic, as MR hangs after kernel panic.
Any pointer on this......
d. After looking into code, I think, currently we dont have code
for movement detection, when we move directly from HL to IPv4 network. But
there is code for movement detection for IPv6 traffic, which uses icmp6
handler ( md_recv_ra ), which listens for router advertisement on the egress
interface of MR. Is my assumption correct?
- Maheshwar Singh
On Tue, Jan 6, 2009 at 8:06 AM, Sebastien Decugis <sdecugis at hongo.wide.ad.jp
> wrote:
> Hello,
>
> I don't think there is such thing as a ipv4 routing advertisement. All
> you should need is a DHCP server running on the IPv4 network.
>
> I am not sure we did testing HL->IPv4. You may test the HL -> IPv6 ->
> IPv4 sequence first to check if your set-up is correct, since it's the
> most usual test sequence... Then if in that sequence everything works
> fine, we can conclude there is a bug in the case HL -> IPv4.
>
> Hope this helps,
> Sebastien.
>
> Maheshwar Singh a écrit :
> > 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 <mailto: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 <mailto: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
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Dsmip mailing list
> > Dsmip at ml.nautilus6.org
> > http://ml.nautilus6.org/mailman/listinfo/dsmip
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20090107/df6b85e0/attachment-0001.htm
More information about the Support
mailing list