[hipl-users] Re: What does HIPL with TLV payloads?
- From: Miika Komu <miika@xxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Tue, 27 Mar 2007 18:03:58 +0300 (EEST)
On Tue, 27 Mar 2007, Jesús Rojo Martínez wrote:
Hi!!,
Thanks!! Wow... Now I see it much clearer.
Just some little doubts left...
hipconf can be used for setting system level options. System level here
means that it applies to the whole system. You can use the native API to
set application specific options, but maybe that is not what you want to
do.
Actually yes, it's what I want to do: application specific. So, I should
use the native API.
(Even more, each application will most probably have a different HIT).
The API is documented here:
http://www.niksula.cs.hut.fi/~mkomu/docs/f17-komu.pdf
http://gaijin.iki.fi/hipl/hip-native-api-final.pdf
It is not up-to-date with the latest draft:
http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt
but I don't think it is a big problem. You may want to to peek also to
this document (which has not been implemented yet):
http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt
For configuring the certificate in the hipconf, you need to add a new
parameter like "add cert <file>" and implement it. Then you push the
parameter to hipd similary as in other implemented options.
Since I'll use the native API to push the certificate to the daemon, and
as I already have seen (and you said in the last mail) I should use the
hip_build_param_xx to build the certificate parameter.
But about the "msg", should I define at least some actions (or "msg type")
for the CERTs?... (Then I know I have to allocate memory for the msg and
initate it with hip_msg_init, then build the CERT parameter contents and
header... but which header?).
And to send later that message (push it to the daemon), as I've seen, is
with "hip_send_daemon_info_wrapper", right?
Yes, you need a new type for CERT and action handlers. You probably want
to extend setmyeid() or setpeereid() functions, or create your own
wrappers. Unfortunately, I don't have the time to guide you through all of
the details, so you just need to get your hands dirty with the code :)
In hipd (user.c) you have to implement a handler to the certificate and
store it
somewhere in the hipd. If you want the certificate to be applied to all
hip connections, a global variable should be fine.
Since I want a different certificate for each connection... (probably just
for each local HIT... although I will possibly need to store the received
certificates as well for each remote HIT... if it's not too much memory
consuming): Where do you recommend me to store it?
Either in hadb or in a new global variable in hipd. hadb contains
"connection" specific information.
(I guess there are some databases for the associations, right? Can it be
useful for me? Some space there where I can store the cert? And for each HIT
instead of associations?)
hidb contains the local private public key pairs, hadb contains state
information about peers.
Base exchange is triggered from hip_netdev_handle_acquire.
Mmm, so can I call that function from "my programme" so the base exchange
is triggered? And does it return immediately or when the base exchange is
completed? What is the its parameter "msg"?
hip_netdev_handle_acquire is called by the kernel. It will return as soon
as the i1 is sent.
What about if there is an already established connection? (How can I know
that? And then, How can I trigger the update signaling instead?)
You can know it because there is hadb entry. Update signalling is
triggered by changes the address of the host.
Just some doubt in my mind... When receiving the certificate, once I get
it in hip_handle_xx, How can I "send" it to my programme? Can I do it in
some way through the trigger call? (when returning from
hip_netdev_handle_acquire or the update signaling, if they return when it is
completed). Any other way?
Probably you want to do a getsockopt call in the application using the
PF_HIP socket. The hip kernel socket handler should then request the
certificate from the hip daemon.
Thanks again for everything. Your last mail was really good explained :D
Regards,
You are welcome. Please familiarize yourself with gdb, gdbxx or ddd. This
way, you can go trough the details of the code which I don't have time to
explain.
--
Miika Komu http://www.iki.fi/miika/
Other related posts:
