Opened 3 years ago
Last modified 3 years ago
#1362 closed Bug / Defect
Assertion failed at socket.c: 2719 (buf_defined(&sb->next)) caused by duplicate CN — at Version 4
Reported by: | tct | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.5.0 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | tct, plaisthos |
Description (last modified by )
Ref: https://forums.openvpn.net/viewtopic.php?f=4&t=31444
Using duplicate CNs on a server which does not define --duplicate-cn
causes ASSERT on the client.
Change History (4)
comment:1 Changed 3 years ago by
Cc: | tct added |
---|
comment:2 Changed 3 years ago by
Cc: | plaisthos added |
---|
Note: See
TracTickets for help on using
tickets.
The log is not verbose enough to see what is going on (this seems to be "default verb", not "verb 4").
From what I could see, this is the *client* crashing, if someone else connects to the same *server* with a duplicate CN. Which does not make any sense at all, as the client wouldn't even see "the other" client.
Now, if the server sends a client exit message, *and* this is sort of being misparsed, or triggering something that is new on 2.5.0, this would start to make sense - but lots of guesswork.
It would be really really good to have a) the full client and server config (without secret material, of course) and b) a client log with
verb 4
.I *guess* this is related to TCP, and the server cuts the TCP connection in an unfriendly way, so when the client tries to get the next message out of the stream buffer, there is none. But the code really should handle that, otherwise we'd have many more reports about "my TCP session was broken, and then openvpn died".
Since I do not have much time, I'm not going to chase this unless I have more logs.