[hipl-users] Re: HIP moblity / multihoming

  • From: Miika Komu <mkomu@xxxxxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Sun, 02 May 2010 13:16:41 +0300

On 04/28/2010 03:24 PM, Daniel Migault wrote:

Hi Daniel,

sorry for late response.

I tried mobility with IPv6 and I couldn't repeat your problem. With vanilla wireshark, the rule is ip.proto == 139 and you probably want to use the any interface. We have also some binaries with HIP support and the filtering rule is just "hip" with them:

http://hipl.hiit.fi/hipl/contrib/wireshark/

From your logs, I understood that base exchange was successful (did you observe this with wireshark?). The the mobile node (MN) sends UPDATE messages but never receives any responses from the corresponding node (CN). However, it is unclear to me whether the packet was dropped at the MN or did CN actually receive the packet? Did you check this wireshark also at the MN?

The usual suspects are as follows:

* Firewall rule blocking hipd
  * iptables -L -n
  * ip6tables -L -n
* SElinux blocking hipd
  * check /etc/selinux/config
* Does the used address pair have actual connectivity?
  - ping6 -I <source_ip> <dest_ip>
  - ip -6 route show
* Hipfw crashed at the MN or CN after the base exchange?
  - ps axu|grep hipfw
* Hipd crashed at the MN or CN after the base exchange?
  - ps axu|grep hipd

If you suspect that hipfw is blocking (or access controlling) HITs, you can safely shut it off with /etc/init.d/hipfw stop. If you shut it off using some other way, please make sure it leaves no residual rules (which basically block all HIP packets).

Hi,

To test mobility and multihoming  set configured the hipd_conf file with :
    - locator off
    - shotgun off

We also set debug all to have a clearer view of what is being done. We
provide the output in the attached file. When an IP address is added, an
UPDATE message is formed. The HIP state machine seems to consider that
it has sent the message, but we don't see that message in wireshark
captures nor we detect it at the other end.

 From our understanding, it seems that the packet may not send the
UPDATE message or tat the message is dropped before being sent on the
wire. Maybe we did not configure properly the hipfw? We have attached
the output files of hipd and hipfw.

Regards,

Daniel

On Tue, Apr 27, 2010 at 2:03 PM, Miika Komu <miika.komu@xxxxxxx
<mailto:miika.komu@xxxxxxx>> wrote:

    On 04/27/2010 02:35 PM, Daniel Migault wrote:

    Hi Daniel,


        Hi,

        We are currently using HIPL with version 1.0.6-6. That is to say
        the one
        from the repository.
        We are testing mobility and multihoming performance of HIP.

        We have a multihomed peer with three interfaces, and we would
        like this
        peer to set a HIP connection with those three different IP
        addresses. In
        the hipd_conf file, we set the options to locator on and shotgun
        off. We
        expected to see some UPDATE message with LOCATOR payloads inside but
        could not catch any with wireshark version 1.3.3. We took the
        one from
        the INFRAHIP website.


    "hipconf locator on" is not currently not supported. I recommend
    turning this off as it is in the default configuration.


        When we added one new interface, no UPDATE message was sent, and
        when
        the active interface is removed, we have no handover.


    Strange, there should be a handover after the active interface is
    removed. Please try without locator support.


        It seems that we have not activated the UPDATE message. I
        remember that
        in previous version of HIPL there were in the hipd_conf file the
        options
        handover soft | hard. Those options are still documented in the
        hipconf
        command line, but does not work anymore. Do you know how can we
        activate
        handover mechanisms with the current HIPL?


    The hard and soft options are not functional at the moment.


        We also tried to set the shotgun option on. We expected that when
        initiating the connection with the three interfaces we would
        have three
        HIP BEX. We see three I1, R1, and I2 messages but only one R2.
        However
        even on the channel where the BEX has been completed, our ftp
        does not
        send data.  Do you know if this option can work with a regular FTP
        client server?
        Maybe that could help,  we can see TCP_SYN, but no TCP_ACK from the
        server, and the server has been started. So it seems the
        messages does
        not reach the TCP layer.


    Shotgun sends the I1 message using all possible combinations. It
    does not trigger multiple base exchanges.

    The reason why shotgun is disabled at the moment is that it does not
    work with mobility yet.


        One last question is do you know if that 's possible to modify the
        puzzle difficulty from the hipconf file?


    /etc/hip/hipd_config:
    set puzzle all <new_value>




--
Daniel Migault
Orange Labs / Security Lab
+33 (0) 1 45 29 60 52
+33 (0) 6 70 72 69 58


Other related posts: