search for: key_changed

Hi, After I changed one host to TunnelServer mode, logging from tinc start to have below messaging coming, is this a normal behavior, because in my /hosts folder I don’t have B, but A received the regular symmetric key update for B? Got KEY_CHANGED from A (x.x.x.x port 655) origin B which does not exist

...the initial KEX packet gets dropped) then the other node will continue sending packets with the wrong key, and therefore trigger a SPTPS failure followed by a clean restart. It would actually recover faster than using a timeout :) >> The legacy protocol doesn't have that problem because KEY_CHANGED is a >> broadcast message - meaning it can't really get lost. > > Actually, it can just as well, although it is very unlikely to happen > that a broadcast message can get lost, and even less likely that this > happens right when a KEY_CHANGED message gets sent. That's int...

...y investigation. Apparently, the reason why tinc is complaining about the invalid length seems to be that tinc is expecting to receive a KEX message (65 bytes) but is actually receiving a SIG message (64 bytes). Looking at the log, I managed to reconstruct the following sequence of events: * -> KEY_CHANGED ake_kobol -> KEX sharuruzure_izure -> KEX sharuruzure_sandy -> KEX ake_kobol <- KEX ake_kobol -> SIG ake_kobol <- SIG ake_kobol -> ACK sharuruzure_sandy <- KEX sharuruzure_sandy -> SIG sharuruzure_sandy <- SIG sharuruzure_sandy -> ACK sharuruzure_izure <- SIG = C...

...even know of > yet. And the code is much simpler than trying to implement full-blown > packet loss/reorder detection in SPTPS code, I think. Yes, having the ability to restart after getting stuck is certainly desirable. > >> The legacy protocol doesn't have that problem because KEY_CHANGED is a > >> broadcast message - meaning it can't really get lost. > > > > Actually, it can just as well, although it is very unlikely to happen > > that a broadcast message can get lost, and even less likely that this > > happens right when a KEY_CHANGED message g...

...zy. > This is not so much of an issue for initial SPTPS negotiation because > the handshake is restarted after a 10-second timeout, but there is no > such timeout for key regeneration, Indeed, such a timeout should be added. > The legacy protocol doesn't have that problem because KEY_CHANGED is a > broadcast message - meaning it can't really get lost. Actually, it can just as well, although it is very unlikely to happen that a broadcast message can get lost, and even less likely that this happens right when a KEY_CHANGED message gets sent. > I believe there is yet another,...

...pfsense201 (PFSENSE201-PUBLICIP port 655) 2018-03-15 22:57:31 tinc.NETNAME[871]: Read packet of 74 bytes from Linux tun/tap device (tun mode) 2018-03-15 22:57:31 tinc.NETNAME[871]: Sending packet of 74 bytes to pfsense201 (PFSENSE201-PUBLICIP port 655) 2018-03-15 22:57:35 tinc.NETNAME[871]: Got KEY_CHANGED from pfsense201 (PFSENSE201-PUBLICIP port 45305): 14 247954dd pfsense29 2018-03-15 22:57:35 tinc.NETNAME[871]: Forwarding KEY_CHANGED from pfsense201 (PFSENSE201-PUBLICIP port 45305): 14 247954dd pfsense29 2018-03-15 22:57:36 tinc.NETNAME[871]: Read packet of 74 bytes from Linux tun/tap device (t...

Hi Team, I admit that I am not familiar with Tinc very well, but have Tinc running at approximately 20 sites and functioning as a mesh vpn/network. I am having issues adding an additional site as it will not communicate with the rest. I have taken the firmware of one and flashed it on another router to make it duplicate and then tested it working but when I change the hostname, and IP to what we