[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] NAT library (Was: towards gnunet 0.9.x)

From: Milan Bouchet-Valat
Subject: [GNUnet-developers] NAT library (Was: towards gnunet 0.9.x)
Date: Thu, 10 Sep 2009 19:22:26 +0200


I've worked a little on the NAT front, and I've come to something that
basically builds. Now, I need to rework most of the generic code around
UPnP and NAT-PMP actual implementations, since Transmission was working
on a very different basis than ours. But there are a few things that I
don't really understand (see below).

Le dimanche 31 mai 2009 à 12:31 -0600, Christian Grothoff a écrit :
> No, we don't need that type of centralization: we now support having 
> *multiple* IP addresses.  This is required for proper IPv6 support anyway.  
> So 
> all that will really happen is that the UPnP/PMP library should allow us to 
> register a callback which will be called whenever there is an external IP 
> address to be added to (or removed from) our IP list.  I've thought about it 
> a 
> bit more and here is what I'm thinking of for the API right now:
> // add_remove: YES: add, NO: remove
> // addr: see man 2 bind
> void (*GNUNET_NAT_AddressCallback)(void *cls, int add_remove, 
>                                     const struct sockaddr *addr,
>                                     socklen_t addrlen)
> struct GNUNET_NAT_Handle;
> struct GNUNET_NAT_Handle *
> GNUNET_NAT_register (struct GNUNET_SCHEDULER_Handle *sched,
>                                 struct GNUNET_CONFIGURATION_Handle *cfg,
>                                const struct sockaddr *addr, socklen_t addrlen,
>                              GNUNET_NAT_AddressCallback callback, 
>                              void *callback_cls);
> void
> GNUNET_NAT_unregister (struct GNUNET_NAT_Handle *h);
> Calling "register" is asking for the given IP address (which can be v4 or v6) 
> to be made available "more globally" (mapped by the NAT box).  If such a 
> "more 
> global" address becomes available, the callback should be invoked with the 
> address other peers should bind to.  If the mapping changes, the callback 
> would be called with "NO" (on the old address) and then "YES" on the updated 
> address.
>From what I know of UPnP and NAT-PMP, I understand that you cannot
choose the addresses (nor internal nor external) for which the
redirection is performed: the internal address we used to send the
request will be used for internal redirection, and the external address
is chosen by the NAT box. So we can't take a sockaddr, but merely a port
number. Moreover, isn't NAT kind of obsolete on IPv6? My knowledge in
this realm is very limited, though.

> Note that "register" could be called on a range of IP addresses (,
>  ::1, and ports (2086, 1080, ...).  The NAT could would have to 
> decide if that address was somehow "mappable" (and do nothing if not) and for 
> those that are do the right thing.
You mean called several times, once for each address/port? That means we
need a GNUNET_NAT_Handler_Init() function, and then pass the struct to
register(). But I can't see how we could pass addresses, as I said

Other than that, I could not find the cron jobs API that was in GNUnet
0.8. I'd need some kind of timers to regularly check that the NAT is
still working. I'd also need a basic list support if we want to use
several ports, though I can use a custom singly-linked list if nothing


reply via email to

[Prev in Thread] Current Thread [Next in Thread]