> Christoph Viethen has proposed merging lp:~cviethen/hipl/pisa-pairing-tng into lp:hipl.
Useful functionality, nice const correctness & docs, btw.

What happened to the unit test requirement? Does it still exist? Just
asking because there are no unit tests for the newly introduced functions...

>  /**
> + * This function searches for a <tt> struct hip_hadb_state </tt> entry from the
> + * @c hadb_hit by the given tuple (source hit, dest. ip, dest. port).
> + *
> + * This is useful to find a host association when the opposite HIT is not
> + * (yet) known, in particular in the opportunistic base exchange case.
> + *
> + * @param  src_hit  pointer to source HIT
> + * @param  dst_ip   pointer to destination IP address
> + * @param  dst_port destination UDP port number (host byte order) (may be 0)
> + * @return          a pointer to a matching host association, or NULL if
> + *                  a matching host association was not found.
> + */
> +struct hip_hadb_state *hip_hadb_find_by_srchit_destip_port(hip_hit_t *src_hit,
> +                                                           const struct in6_addr *dst_ip,
> +                                                           in_port_t dst_port)

documentation: how does the function behave when being passed NULL
pointers? Since the resulting hip_hadb_state object is returned by
reference, what about memory management? Does the caller need to
de-allocate this object or is he allowed to? Is the caller free to
modify this object?

robustness: as many objects as possible, including in6_addr and HIT
objects, should be passed by value to avoid memory management issues.

> +{
> +    LHASH_NODE            *item, *aux;
> +    struct hip_hadb_state *tmp;
> +    int                    i;
> +
> +    list_for_each_safe(item, aux, hadb_hit, i)
> +    {
> +        tmp = list_entry(item);
> +        if (ipv6_addr_cmp(&tmp->hit_our, src_hit)) {
> +            continue;
> +        } else if (!ipv6_addr_cmp(&tmp->peer_addr, dst_ip)) {
> +            if (tmp->peer_udp_port == dst_port) {
> +                return tmp;
> +            } else {
> +                continue;
> +            }
> +        } else {
> +            continue;
> +        }
> +    }
> +    return NULL;
> +}

style: where possible, functions should only have a single point of exit
in order to keep their control flow simple and intuitive. I suggest to
store the result of the search in a local variable which is initialized
to NULL and which is returned at the end of the function.

>  /**
> + * Gets called in case of an intended opportunistic base exchange - checks
> + * first whether a host association is already established, and won't perform
> + * the base exchange if so.
> + *
> + * If no host association exists, proceeds to pass everything through to
> + * hip_netdev_trigger_bex_msg().
> + *
> + * @param  msg  the message from hipconf
> + * @return zero on success and non-zero on error
> + */
> +int hip_netdev_trigger_opp_bex_msg(const struct hip_common *const msg)

documentation: again, mention what happens to the msg object in terms of
memory allocation, in particular in the case of an error. Of course,
this function has the same interface as dozens of others, but this kind
of documentation is essential, at least to me .

Nice work!

Stefan