View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003348 | GNUnet | core service | public | 2014-03-26 17:16 | 2018-06-07 00:25 |
Reporter | Matthias Wachs | Assigned To | Christian Grothoff | ||
Priority | urgent | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | Git master | ||||
Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
Summary | 0003348: CORE does not notify clients about connections after restart | ||||
Description | After restarting a peer: Topology issues CONNECT requests even when peers are connected | ||||
Steps To Reproduce | Run two peers, when connected, restart one peer... | ||||
Additional Information | mwachs@fulcrum:~/coding/testbed$ gnunet-arm -c confs/c_no_nat_client.conf -s [...] Mar 26 17:14:47-429869 transport-15988 INFO We are now connected to peer `6RHK' and 1 peers in total Mar 26 17:14:47-439185 core-15989 INFO Core service of `0RKK' ready. Mar 26 17:14:47-439866 core-15989 ERROR Received connection from `6RHK'. <- Transport notifies core! Mar 26 17:14:47-439883 gnunet-daemon-topology-15985 ERROR Core told us that we are connecting to `0RKK' [..] Mar 26 17:14:47-936765 gnunet-daemon-topology-15985 ERROR Core told us that we are connecting to `6RHK' | ||||
Tags | No tags attached. | ||||
related to | 0003340 | closed | Christian Grothoff | CORE connections not established in both directions |
|
mwachs@fulcrum:~/coding/testbed$ gnunet-arm -c confs/c_no_nat_client.conf -r [...] Mar 26 17:15:02-461817 transport-16017 INFO We are now connected to peer `6RHK' and 1 peers in total Mar 26 17:15:02-481416 core-16018 INFO Core service of `0RKK' ready. Mar 26 17:15:02-482056 gnunet-daemon-topology-16014 ERROR Core told us that we are connecting to `0RKK' Mar 26 17:15:02-482174 core-16018 ERROR Received connection from `6RHK'. <- TRANSPORT NOTIFIES CORE! Mar 26 17:15:02-482458 transport-16017 INFO Received a request connect message for peer `6RHK' Mar 26 17:15:02-482492 transport-16017 INFO Blacklist allows connection attempt to peer `6RHK' Mar 26 17:15:02-482512 transport-16017 INFO Asked to connect to peer `6RHK' (state: S_CONNECTED) Mar 26 17:15:02-482525 transport-16017 INFO Ignoring request to try to connect, already connected to `6RHK'! Mar 26 17:15:02-484865 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-484963 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-485179 transport-16017 INFO Neighbour `6RHK' changed timeout Wed Mar 26 17:20:02 2014 Mar 26 17:15:02-512699 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-512793 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-966221 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-966318 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-967141 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:02-967243 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 299 s Mar 26 17:15:07-482685 transport-16017 INFO Received a request connect message for peer `6RHK' Mar 26 17:15:07-482738 transport-16017 INFO Blacklist allows connection attempt to peer `6RHK' Mar 26 17:15:07-482773 transport-16017 INFO Asked to connect to peer `6RHK' (state: S_CONNECTED) Mar 26 17:15:07-482836 transport-16017 INFO Ignoring request to try to connect, already connected to `6RHK'! Mar 26 17:15:08-101396 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 294 s Mar 26 17:15:08-101550 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 294 s Mar 26 17:15:12-487842 transport-16017 INFO Received a request connect message for peer `6RHK' Mar 26 17:15:12-487875 transport-16017 INFO Blacklist allows connection attempt to peer `6RHK' Mar 26 17:15:12-487890 transport-16017 INFO Asked to connect to peer `6RHK' (state: S_CONNECTED) Mar 26 17:15:12-487901 transport-16017 INFO Ignoring request to try to connect, already connected to `6RHK'! Mar 26 17:15:12-788043 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 289 s Mar 26 17:15:12-788188 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 289 s Mar 26 17:15:12-788841 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 289 s Mar 26 17:15:12-788933 transport-16017 INFO Master task runs for neighbour `6RHK' in state S_CONNECTED with timeout in 289 s Mar 26 17:15:17-493024 transport-16017 INFO Received a request connect message for peer `6RHK' Mar 26 17:15:17-493060 transport-16017 INFO Blacklist allows connection attempt to peer `6RHK' Mar 26 17:15:17-493075 transport-16017 INFO Asked to connect to peer `6RHK' (state: S_CONNECTED) Mar 26 17:15:17-493086 transport-16017 INFO Ignoring request to try to connect, already connected to `6RHK'! Mar 26 17:15:22-498211 transport-16017 INFO Received a request connect message for peer `6RHK' Mar 26 17:15:22-498246 transport-16017 INFO Blacklist allows connection attempt to peer `6RHK' [...] !!!But not message like: gnunet-daemon-topology-16014 Core told us that we are connecting to `6RHK' mwachs@fulcrum:~/coding/testbed$ gnunet-core -c confs/c_no_nat_client.conf Peer `6RHKBFV8GL21KM3C40GQ5D0LM43F25J693M61ME0BVNC8RLB6BU0' |
|
Perhaps related to 0003440 |
|
Looks very strongly related (duplicate!?) to 0003440, as it seems that transport is connected, but core fails to bring up the connection (doesn't matter if it is in one or both directions), and thus topology decides that it would be a good idea to tell transport to establish the connection (even though the issue is on the core level). |
|
reproduced using confs/c_bootstrap_server.conf (as always-running) and confs/c_no_nat_client.conf as restarted peer; affected seem to be both fs and topology applications, while gnunet-core -m does show the connection just fine. |
|
I believe the problem is that upon reconnect, the long-running peer does not re-transmit the typemap in a (necessarily) timely fashion, resulting in a delay until the application-level connect notification is made. Waiting for a few minutes on the restarted peers does cause the connection to show up, which supports this hypothesis. |
|
See also last comments on https://gnunet.org/content/core-peer-peer-protocol |
|
Should be fixed in SVN 33127 (was tested). |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-03-26 17:16 | Matthias Wachs | New Issue | |
2014-03-26 17:18 | Matthias Wachs | Note Added: 0008159 | |
2014-03-26 17:19 | Matthias Wachs | Additional Information Updated | |
2014-03-26 17:20 | Matthias Wachs | Note Edited: 0008159 | |
2014-03-26 17:21 | Matthias Wachs | Note Edited: 0008159 | |
2014-03-26 17:21 | Matthias Wachs | Severity | minor => major |
2014-03-26 17:22 | Matthias Wachs | Note Added: 0008160 | |
2014-04-07 11:03 | Christian Grothoff | Relationship added | related to 0003340 |
2014-04-07 11:03 | Christian Grothoff | Status | new => acknowledged |
2014-04-07 11:03 | Christian Grothoff | Product Version | => Git master |
2014-04-07 11:03 | Christian Grothoff | Target Version | => 0.11.0pre66 |
2014-04-07 11:05 | Christian Grothoff | Note Added: 0008194 | |
2014-04-10 21:53 | Christian Grothoff | Assigned To | => Christian Grothoff |
2014-04-10 21:53 | Christian Grothoff | Status | acknowledged => assigned |
2014-04-11 15:07 | Christian Grothoff | Priority | normal => high |
2014-04-22 15:46 | Christian Grothoff | Note Added: 0008263 | |
2014-04-22 15:46 | Christian Grothoff | Status | assigned => resolved |
2014-04-22 15:46 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
2014-04-22 15:46 | Christian Grothoff | Resolution | open => unable to reproduce |
2014-04-22 15:47 | Christian Grothoff | Status | resolved => assigned |
2014-04-22 15:47 | Christian Grothoff | Resolution | unable to reproduce => open |
2014-04-22 15:51 | Christian Grothoff | Priority | high => urgent |
2014-04-22 15:51 | Christian Grothoff | Reproducibility | have not tried => always |
2014-04-22 15:51 | Christian Grothoff | Note Edited: 0008263 | |
2014-04-22 16:06 | Christian Grothoff | Note Added: 0008265 | |
2014-04-22 16:13 | Christian Grothoff | Note Added: 0008266 | |
2014-04-23 13:05 | Christian Grothoff | Note Added: 0008267 | |
2014-04-23 13:05 | Christian Grothoff | Status | assigned => resolved |
2014-04-23 13:05 | Christian Grothoff | Resolution | open => fixed |
2018-06-07 00:25 | Christian Grothoff | Status | resolved => closed |