On Tue, Feb 20, 2018 at 12:25 AM, Kevin Cernekee <cernekee at gmail.com> wrote: > From: Nikos Mavrogiannopoulos <nmav at redhat.com> > > This allows keeping track of clients which have their DTLS > stream come from a different IP location than their CSTP > stream. > > Relates #61 > --- > src/main.c | 3 ++ > src/main.h | 7 ++++- > src/proc-search.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++----- > src/proc-search.h | 1 + > 4 files changed, 90 insertions(+), 8 deletions(-) > > > V1->V2: > > - Use a dedicated hash table for the DTLS IPs. Storing (dtls_hash, proc) > pairs in the db_ip table stops working once the htable code has to > call double_table() and then invoke the rehash() callback to recompute > the keys. > > - Write a proc_table_update_dtls_ip() function that keeps the DTLS > connection info up-to-date, in case the IP changes. > > - Clean up length comparisons in local_ip_cmp(). > > - Removed "total++" (not sure where this is used?) > > This IP -> proc_st mapping still relies heavily on guesswork, and it will > break if there are multiple clients behind the same IP. Is there a > standard way to notify a DTLS client that it is out of sync and needs to > redo the handshake? Merely dropping the unrecognized packets leads to > a poor user experience as it causes the VPN session to enter a "living > dead" state. Unfortunately not. We cannot "close" a udp connection. Hopefully in the future we will have some way to add an identifier into the DTLS stream. My main concern with that patch is that we have no way to test whether it works or not. Any ideas? regards, Nikos
