I get a lot of these in my log, especially when I am moving lots of traffic across the vpn: Sep 20 10:45:11 titan tinc.tdvpns[16152]: Got late or replayed packet from holden (xx.yy.zz.ww port 655), seqno 37609, last received 37610 (sequence numbers displayed generally differ by only one) What exactly is this trying to say? Surely this doesn't simply mean that the udp packets arrived in a slightly different order than they were sent? UDP specifically doesn't guarantee that packets will arrive in the same order. And in practice, over the internet, packet reordering is often a reality. If this is the sole cause and meaning of this message, is there a way to disable it other than commenting it out in the code? I realize this message can probably also warn of a replay attack, but I assume if the code can detect this enough to log it, it can also protect itself against it? I'm using tinc 1.0.2 Thanks Jason
On Mon, Sep 20, 2004 at 10:53:07AM -0700, Jason wrote:> I get a lot of these in my log, especially when I am moving lots of traffic > across the vpn: > > Sep 20 10:45:11 titan tinc.tdvpns[16152]: Got late or replayed packet from > holden (xx.yy.zz.ww port 655), seqno 37609, last received 37610 > > (sequence numbers displayed generally differ by only one)[...] You just found a bug! It is fixed in the Subversion repository. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20040920/17c72a4f/attachment.pgp
On Mon, 20 Sep 2004, Guus Sliepen wrote:> On Mon, Sep 20, 2004 at 10:53:07AM -0700, Jason wrote: > > > I get a lot of these in my log, especially when I am moving lots of traffic > > across the vpn: > > > > Sep 20 10:45:11 titan tinc.tdvpns[16152]: Got late or replayed packet from > > holden (xx.yy.zz.ww port 655), seqno 37609, last received 37610 > > > > (sequence numbers displayed generally differ by only one) > [...] > > You just found a bug! It is fixed in the Subversion repository.Great, thanks. Is it a simple enough fix that you could post a diff against 1.0.2, or do you consider the version in the respository to be at least as stable as 1.0.2? Jason