View Issue Details

IDProjectCategoryView StatusLast Update
0004611GNUnetcadet servicepublic2018-06-07 00:24
ReporterlynXAssigned ToBart Polot 
Status closedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004611: Unexpected behaviors when closing a listen port
DescriptionI rate this minor/low priority since I cannot think of any application where this cannot be circumvented, so this is not a biggie.

In the past, the gnunet-cadet CLI tool would allow several connections to answer on a listen port, mix the output of those in a non-distinguishable way and only send back to the first one, while also producing failed assertion repots.

The updated CLI tool impedes further connections. First I tried to do it the clean way by closing the listen port after the circuit has been created, but unexpected side effects were:

1. GNUNET_CADET_close_port() makes the already established channel dysfunctional.

2. New channels would still be forwarded to the application and get caught by an assertion in cadet_api.c, that is due to the lack of an actual implementation of handle_port_close() in local.c.

So now I simply make the CLI bail out.
Additional InformationI am considering to somehow support multiple channels in a predictable way, but each incoming connect deserves to receive full attention - this doesn't match the usability of stdin which by definition is only one. netcat hasn't solved this UX dilemma, either. If you want it nice and simple with stdin, then you must close the listen port to avoid accepting further connections. The alternative would be to fire up a server process for each incoming channel, akin to inetd.
TagsNo tags attached.



2017-02-07 23:41

developer   ~0011702

Thanks for writing a new GNUNET_CADET_close_port() function.
Closing now works as expected and multiple circuits can be accepted on the same port by launching multiple 'gnunet-cadet -o' instances.

Issue History

Date Modified Username Field Change
2016-08-09 12:52 lynX New Issue
2016-08-09 12:52 lynX Status new => assigned
2016-08-09 12:52 lynX Assigned To => Bart Polot
2016-08-10 14:07 Christian Grothoff Severity minor => major
2016-09-22 20:11 Christian Grothoff Target Version => 0.11.0pre66
2017-02-07 23:41 lynX Note Added: 0011702
2017-02-07 23:42 lynX Status assigned => resolved
2017-02-07 23:42 lynX Resolution open => fixed
2017-02-07 23:42 lynX Fixed in Version => SVN HEAD
2018-06-05 22:27 Christian Grothoff Fixed in Version SVN HEAD => 0.11.0pre66
2018-06-07 00:24 Christian Grothoff Status resolved => closed