On Mon, 26 Mar 2007, Jesús Rojo Martínez wrote: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.
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. 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.
Base exchange is triggered from hip_netdev_handle_acquire, hip_send_i1. The receiving of packets is handled through hip_receive_control_packet which call receive_i1, receive_i2, etc depending on the received packet type. The "receive" functions just make some checks to the packet and the packet is actually handled in hip_handle_xx. The handle functions call hip_create_xx functions which create the response packet and shoot it to the network.
You need some checks in the "send_i1"/"create" or "handle" functions in order to append the certificate to an outgoing packet or handle the certificate from an incoming packet. The choice of outgoing packet depends on which packet (i1, r1, i2, r2) you want to add the packet. You should also choose at which point to append the certificate (before or after signature, probably former).
R1 packets are precreated in hip_create_r1. You cannot append the certificate "on-the-fly", at least before a signature!
Please make yourself familiar with the builder.c functions. You can and should use the build_param_xx functions to append new parameters (certificate) to messages in order to avoid silly programming errors. Please also use the hip_get_param_xx functions for parsing and getting a pointer to the certificate.
The certificate parameter was vaguely defined at least in doc/drafts/draft-ietf-hip-base-06.txt. You might wanna check it out.
Hi!!, Thanks! This sounds to me like what I'm looking for... more or less ;-) Actually I'm interested in the HIP_PARAM_CERT (a TLV which carries a Certificate, I guess :D). What I want to do, is to send a Cert TLV when a base exchange (or update signaling) triggers (maybe I'll even need to trigger it, if that is possible). So, what can I do that with the hipconf tool? (or just programming by myself, sending that option to the daemon?). And as important as the previous question, how can I get that Certificate in the receiving side? (Can I ask the daemon in some way? Again, with the hipconf tool or programming a request to the daemon). Do I need to change something in the HIP daemon in ordet to get this? (I don't hope so... :S). Thanks a lot again! :) On 3/26/07, Miika Komu <miika@xxxxxx> wrote:On Wed, 21 Mar 2007, Jesús Rojo Martínez wrote: > Hi!, > > Still around here... :P > Now I'm wondering what HIPL does with TLV payloads... if it receives some > TLV, does the daemon/someone make something with it? Could anyone request > it? > And even the user/hipd/someone can set a TLV to go in the base exchange or > in some signaling... Sorry for the long response time, I was in IETF last week. We use HIP TLV format both for internal (process <-> hipd) and external (hipd <-> hipd) communications in order to use a single parser/builder. For example, you can set some option using hipconf and it will create some (global) state in hipd. Then, you can e.g. add new parameters according to the state to base exchange when base exchange is triggered. -- Miika Komu http://www.iki.fi/miika/-- Jesús Rojo Martínez. Human Resources responsible BEST Stockholm - Kungliga Tekniska Högskolan BEST - Board of European Students of Technology (www.BEST.eu.org) e-mail: jrojomartinez@xxxxxxxxx phone: +46704369273 MSN: jrojomartinez@xxxxxxx
-- Miika Komu http://www.iki.fi/miika/
