Merge lp:~cviethen/hipl/pisa-pairing into lp:hipl
Status: | Needs review |
---|---|
Proposed branch: | lp:~cviethen/hipl/pisa-pairing |
Merge into: | lp:hipl |
Diff against target: |
330 lines (+207/-2) 6 files modified
hipd/netdev.c (+99/-0) hipd/netdev.h (+1/-0) hipd/user.c (+4/-0) lib/core/builder.c (+1/-0) lib/core/conf.c (+101/-2) lib/core/icomm.h (+1/-0) |
To merge this branch: | bzr merge lp:~cviethen/hipl/pisa-pairing |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stefan Götz (community) | Needs Fixing | ||
Miika Komu | Needs Fixing | ||
René Hummen | Pending | ||
Review via email: mp+63577@code.launchpad.net |
Description of the change
This implements a command "hipconf pair <ip-address | hostname>" (in case a hostname is given, it will be resolved to an IP address before getting passed to hipd).
This causes the local hipd to attempt an opportunistic base exchange towards the given IP (i.e., leaving the destination HIT open).
The idea is to use this for a pairing scenario for the PiSA project: users would connect their mobile device to their trust point locally (say, by cable), engage "hipconf pair <ip-address-
Thanks!
Unmerged revisions
- 5952. By Christoph Viethen
-
Add "hipconf pair <ip or hostname>" command, an appropriate user message,
and the necessary code in hipd (hipd/netdev.c:hip_netdev_ pair()) to establish
the following pairing mechanism:With only the destination IP specified by the user, send an I1 message there
with an unspecified destination HIT (opportunistic mode), causing a base
exchange. As a result, a host association between the two nodes is
created, enabling this information to be used for pairing two nodes (PiSA
project).
I have few comments.
1. The "pair" is somewhat misleading, I think it can be mixex with HIT-IP mapping which has a different hipconf command. I think "bex", "trigger" or something else could be more relevant to RFC5201 terminology.
2. The functionality is not modular enough. I would add the HIT as an option for triggering the bex (to trigger a normal base exchange).
The biggest problem is however:
3. The functionality what this does is largely redundant with "hipconf add server". It could be piggypacked based on this functionality with a "do not register anything" extra parameter. Note this would not prevent having a different "hipconf foobar" option (this last comment is about code reuse, not syntax).