View Issue Details

IDProjectCategoryView StatusLast Update
0003348GNUnetcore servicepublic2018-06-07 00:25
ReporterMatthias Wachs Assigned ToChristian Grothoff  
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0003348: CORE does not notify clients about connections after restart
DescriptionAfter restarting a peer:
Topology issues CONNECT requests even when peers are connected
Steps To ReproduceRun two peers, when connected, restart one peer...
Additional Informationmwachs@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'

TagsNo tags attached.

Relationships

related to 0003340 closedChristian Grothoff CORE connections not established in both directions 

Activities

Matthias Wachs

2014-03-26 17:18

manager   ~0008159

Last edited: 2014-03-26 17:21

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'

Matthias Wachs

2014-03-26 17:22

manager   ~0008160

Perhaps related to 0003440

Christian Grothoff

2014-04-07 11:05

manager   ~0008194

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).

Christian Grothoff

2014-04-22 15:46

manager   ~0008263

Last edited: 2014-04-22 15:51

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.

Christian Grothoff

2014-04-22 16:06

manager   ~0008265

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.

Christian Grothoff

2014-04-22 16:13

manager   ~0008266

See also last comments on

https://gnunet.org/content/core-peer-peer-protocol

Christian Grothoff

2014-04-23 13:05

manager   ~0008267

Should be fixed in SVN 33127 (was tested).

Issue History

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