[PATCH 04/25] site: Send NAKs for undecryptable data packets (msg0)

[Ian Jackson]

Packets which are not understood are supposed in general to produce
NAKs, to let the peer know that we don't have the key they were using.

However, previously this would only happen if the incoming packet had
a local site index which was not in use.  But it can happen that a
particular index value is reused by a recently restarted secnet.
Previously, in this case, data packets would simply be thrown away
undecryptable.

With this change, undecryptable data packets always generate a NAK.

This is particularly relevant for mobile sites, as it can happen that
the fixed site doesn't have an address for the mobile site - so the
association will remain stuck in a broken state until the mobile site
is also restarted.

There is still a potential problem when a site is restarted mid key
exchange.  The peer will refuse to start a new key exchange (because
of the retry timeout) and the restarted site may not know it's
necessary.  This will be dealt with in a later patch.

Signed-off-by: Ian Jackson <ijackson at chiark.greenend.org.uk>
---
 site.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/site.c b/site.c
index b995e52..5c73533 100644
--- a/site.c
+++ b/site.c
@@ -1226,6 +1226,7 @@ static bool_t site_incoming(void *sst, struct buffer_if *buf,
 			    const struct comm_addr *source)
 {
     struct site *st=sst;
+    bool_t ok=True;
 
     if (buf->size < 12) return False;
 
@@ -1295,7 +1296,7 @@ static bool_t site_incoming(void *sst, struct buffer_if *buf,
 	    }
 	    break;
 	case LABEL_MSG0:
-	    process_msg0(st,buf,source);
+	    ok=process_msg0(st,buf,source);
 	    break;
 	case LABEL_MSG1:
 	    /* Setup packet: should not have been explicitly addressed
@@ -1382,7 +1383,7 @@ static bool_t site_incoming(void *sst, struct buffer_if *buf,
 	    break;
 	}
 	BUF_FREE(buf);
-	return True;
+	return ok;
     }
 
     return False;
-- 
1.7.2.5