View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002361 | GNUnet | transport service | public | 2012-05-16 14:17 | 2012-06-02 19:15 |
| Reporter | Matthias Wachs | Assigned To | Matthias Wachs | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.9.3 | ||||
| Summary | 0002361: External protocol violation detected at plugin_transport_tcp.c:1899 | ||||
| Description | TCP gets data without welcome; looks like this: May 16 14:04:56-360322 transport-tcp-15589 ERROR Received unexpected 16 bytes of type 376 from `[2001:bf0:c001:30:ea9a:8fff:feca:700a]:60048' May 16 14:04:56-360539 transport-15589 WARNING External protocol violation detected at plugin_transport_tcp.c:1899. Somehow, the "disconnect" message that we're sending if a session goes down arrives at the other peer without even a welcome first. I'm totally not sure how this happens, as TCP is supposed to ALWAYS send a WELCOME first. Now, "both" peers might be tearing down a session, so I see two possible sources here: (a) receiver internally "forgot" about the welcome on the TCP stream and then still continues to read, or (b) sender TCP re-establishes a fresh session for DISCONNECT (bad) and then messes up the queueing, sending disconnect first (worse). I also looked at the code and as you said, (b, part 2) does not seem to be the case, so I suspect (a) is happening right now. (a) should also not be possible, as we should stop reading... But MAYBE it is one of these MST-issues, where we have ALREADY read the bytes (into the server-mst buffer), then "disconnect" (remove session from hashmap) and are still on the stack with a task that will call us again with the disco message. | ||||
| Tags | No tags attached. | ||||
|
|
Just to be sure: Type 376 is #define GNUNET_MESSAGE_TYPE_TRANSPORT_SESSION_CONNECT_ACK 376 and not a disconnect message.... Occurs with multiple message types, so also GNUNET_MESSAGE_TYPE_TRANSPORT_SESSION_CONNECT 375 |
|
|
Seems to be fixed with solving memory corruption in 0002374 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-05-16 14:17 | Matthias Wachs | New Issue | |
| 2012-05-16 14:17 | Matthias Wachs | Status | new => assigned |
| 2012-05-16 14:17 | Matthias Wachs | Assigned To | => Matthias Wachs |
| 2012-05-16 18:58 | Christian Grothoff | Product Version | => Git master |
| 2012-05-16 18:58 | Christian Grothoff | Target Version | => 0.9.3 |
| 2012-05-21 13:52 | Matthias Wachs | Note Added: 0005928 | |
| 2012-05-21 15:19 | Matthias Wachs | Note Edited: 0005928 | |
| 2012-05-25 16:09 | Matthias Wachs | Note Added: 0005946 | |
| 2012-05-25 16:09 | Matthias Wachs | Status | assigned => resolved |
| 2012-05-25 16:09 | Matthias Wachs | Resolution | open => fixed |
| 2012-06-02 19:15 | Christian Grothoff | Status | resolved => closed |
