Hi Miika,
In my circumstance, I want to manually initiate update process, to avoid the
waiting time it takes for hip to discover the local address has changed. It is
around 20 second in my test, a little too long for me.
I am trying to achieve a faster peer update.
Following the two functions you mentioned, I found them in the update module.
* trigger_update_for_all_peers()
* update_maintenance()
On Mar 30, 2015, at 7:14 AM, Miika Komu <mkomu@xxxxxxxxx> wrote:
Hi Lingyuan,
On 03/28/2015 04:56 AM, Lingyuan He wrote:
Hi,
I am helping with a research project at my college, which is about
network interface handover. I am currently looking into HIPL, my goal
is to allow it to provide seamless IP handover base on interface
preference.
I have some question on how HIPL works with local addresses. I was
told this list is the better place to ask.
1 - I know in netdev.c keeps track of a hash table of local address,
and it is initialized when hipd starts, but I don't really see the
table being updated (in case an interface become available or
unavailable. Am I missing something?
breakpoint hip_netdev_event() and you should should see update_address_list()
being invoked when you type e.g.
ip addr 3ffe::100/64 dev ethXXX
Please note that some addresses get filtered.
2 - I think hip_select_source_address() is where a new outcoming
packet gets the source IP, is that true? And I think what the
function do is to always query the current routing table and get the
default interface and IP, is that true? In other words, is the source
IP always the most current default one?
source ip will be always what you get with "ip route get PEER_IP".
3 - for a ongoing hip communication (server and client), if client
suddenly use a different explicit IP (after handover), will the
communication continue to work? Or is there a way actually to notify
the other node (server) the new IP being use? Can someone point to me
any important function and files in the source code related to this?
When ever a (client or server) host detects a change in its address, it sends
its new locators to all of its associated peers after a small delay. This
occurs in:
* trigger_update_for_all_peers()
* update_maintenance()
