View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004616GNUnetnamestore servicepublic2016-08-10 23:512018-06-07 00:24
ReporterlynX Assigned ToChristian Grothoff  
PrioritynormalSeveritytweakReproducibilityalways
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004616: Long delay before a <name>.gnu VPN tunnel starts working
DescriptionThe command "telnet telnet.gnu" does work, but there's a strange delay before the connection is established…
Steps To Reproducegnunet-namestore -z master-zone -ap -t vpn -e "2 hours" -n telnet -V "6 TVV54YYR29KRDKM30ZC3014JXHDGPVT7KFQGA44CEV2YQSEVFDAG telnet"

telnet telnet.gnu
Additional InformationThis bug report was originally about a typo in the command, so the first series of notes may no longer be relevant.
TagsNo tags attached.

Activities

Christian Grothoff

2016-08-17 00:43

manager   ~0011035

Eh, did you follow the GNS setup instructions from
https://gnunet.org/gns-setup ?

lynX

2016-08-17 11:27

developer   ~0011038

No, I've read 'man gnunet-namestore'. Maybe we should add 'see also' sections to the manuals to point to the respective drupal posts. Btw, why does gnunet documentation depend on a centralized web service? I can't get used to that. It feels so wrong. Would it consume too much space to come with the software?

Christian Grothoff

2016-08-17 11:34

manager   ~0011039

Yes, it's bad. My plan is that in the medium term we should probably do what GNU says we should do, and convert the documentation from the web site to TeXinfo. But that's a _major_ task.

lynX

2016-08-20 12:11

developer   ~0011044

Last edited: 2016-08-20 16:07

 texinfo? Is it the stuff that forces people to use the 'info' command?

I made some progress. The nsswitch.conf modification redirects requests into GNS. Now I run into this message, probably because I have switched off the DHT service:

Aug 20 11:56:30-386764 gns-20399 DEBUG Resolution failed for `telnet' in zone AGF4X2TPXR2AHAEM2J3PQBCDMQD8XXV6FEA7J9ACFPJV1FE5M0Y0 (DHT lookup not permitted by configuration)

How can I let GNS look up *local* aliases without needing to participate in the worldwide DHT? Is DHT client functionality separated from the server functionality?

No wait, from the source code I can tell that it *did* try to make a local look-up. The problem is probably elsewhere: the command that was supposed to create the telnet.gnu entry failed silently.

gnunet-namestore -L DEBUG -z master-zone -ap -t vpn -e "2 hours" -n telnet -v "6 TVV54YYR29KRDKM30ZC3014JXHDGPVT7KFQGA44CEV2YQSEVFDAG telnet"
gnunet-namestore v0.10.1 svn-r37587
Makefile:142: recipe for target 'names' failed
make: *** [names] Error 1

That is indeed very impractical that a gnunet CLI tool is allowed to die without an error message, not even on debug level. I just read the entire gnunet-namestore.c file and couldn't find anything wrong about it. According to gdb it isn't getting to run() at all, something goes bad during option parsing.

What about .zkey? Can't I just use .zkey instead?

Side question regarding gnunet-dns-proxy, does it support any kind of proxy chaining? Can it pass things to Tor if they cannot be produced in gnunet?

lynX

2016-08-20 16:23

developer   ~0011045

Last edited: 2016-08-20 18:37

 gdb says, the last thing gnunet-namestore did before GNUNET_PROGRAM_run() returned != GNUNET_OK was this:

    for (i=0;i<s/8;i++)
      base[i] = baadfood;
    GNUNET_memcpy (&base[s/8], &baadfood, s % 8);

That looks like test code to me, why is it running on my production compile?
And here's what it did before that:

228 ret = GNUNET_GETOPT_run (binaryName, allopts, (unsigned int) argc, argv);
229 if ((GNUNET_OK > ret) ||
(gdb) s
228 ret = GNUNET_GETOPT_run (binaryName, allopts, (unsigned int) argc, argv);
(gdb)
229 if ((GNUNET_OK > ret) ||
(gdb)
232 GNUNET_free (allopts);

So it passed the following part of code twice. On the first round it was
successful, on the second it bailed out:

  ret = GNUNET_GETOPT_run (binaryName, allopts, (unsigned int) argc, argv);
  if ((GNUNET_OK > ret) ||
      (GNUNET_OK != GNUNET_log_setup (lpfx, loglev, logfile)))
  {
    GNUNET_free (allopts);
    GNUNET_free (lpfx);
    goto cleanup;
  }

By the way, in https://gnunet.org/automatic-shortening-gnu-name-system
I don't understand where it says how I would be able to activate that
automatic shortening thing (in case I want to try it out).

By the way, I needed eagle eyes to find https://gnunet.org/gnunet-dns-setup
linked under a non-underlined "here" on https://gnunet.org/gns-setup. I
recommend to follow Aaron Swartz's https://www.w3.org/QA/Tips/noClickHere
guidelines (although people used to say that since 1993 ;)). Then again,
had I navigated up, I would have found it. So no big deal.

Christian Grothoff

2016-08-20 22:58

manager   ~0011046

A few answers:
1) texinfo supports compiling to 'info', but can also generate manuals in HTML, TeX, PDF and other formats. texinfo combines LaTeX-like commands with Info-like document structure.

2) BAADFOOD is *not* test code, but a security measure to make use-after-free's more deadly (unaligned, likely non-heap access, not easily controlled by an attacker) and thus slightly less likely to be exploitable -- and also more obvious.

lynX

2016-08-21 13:23

developer   ~0011047

Upping urgency and severity. At first I expected to be doing something wrong, but the behaviour of the command stops me from progressing.

Christian Grothoff

2016-08-21 13:34

manager   ~0011048

Ack on urgency, but have another deadline today to address first. Will try to find time Monday.

lynX

2016-08-21 13:36

developer   ~0011049

Found the bug. Over the course of rewriting the command, -V had turned into -v. When replaced with -V the command executes. Now it fails at the next step, which I don't know yet.

> telnet telnet.gnu
Trying 1234:0:4903:9ceb:bf0d:964f:ca1a:c7e5...
telnet: connect to address 1234:0:4903:9ceb:bf0d:964f:ca1a:c7e5: Connection timed out

lynX

2016-08-21 16:46

developer   ~0011053

Last edited: 2016-08-21 17:33

 Hours later, the same telnet telnet.gnu acts differently. It freezes for several minutes, then suddenly the connection is established – a bidirectional tunnel with low latency. So the question remaining is… what could be causing this initial delay?

Another thing, it is a bit unpractical that each name only activates one internet service, so I tried to do this:

gnunet-namestore -L DEBUG -z master-zone -ap -t vpn -e "12 hours" -n www.lynX -V "6 TVV54YYR29KRDKM30ZC3014JXHDGPVT7KFQGA44CEV2YQSEVFDAG http"

which is indeed added to the namestore database, but telnet www.lynX.gnu 80 does not resolve.

Christian Grothoff

2016-08-21 16:51

manager   ~0011054

Both DHT and CADET might need some time to warm up?

lynX

2016-08-21 20:40

developer   ~0011055

It happens every time, even if another telnet is already up and interactive.

Christian Grothoff

2016-08-21 20:49

manager   ~0011056

Odd, we *used to* have a problem with always dropping the first SYN, but I thought I had fixed that. How long is the delay? I'd check with wireshark/tcpdump to see if/when the first SYN arrives and after how long the kernel retries.

Christian Grothoff

2016-08-22 16:54

manager   ~0011058

I've done some testing and fixed a major bug that had crept in with VPN exits to services (i.e. if you have a ".gnunet" section in your configuration to run an EXIT to a local service). Basically, we failed to open the CADET port...

With that fixed, I'm not sure what exactly I should be testing. Also, the bug report now seems to mix like a dozen different things, maybe you could file separate bug reports for separate issues?

Issue History

Date Modified Username Field Change
2016-08-10 23:51 lynX New Issue
2016-08-10 23:56 lynX Steps to Reproduce Updated
2016-08-11 00:02 lynX Severity block => trivial
2016-08-11 00:02 lynX Description Updated
2016-08-11 00:02 lynX Steps to Reproduce Updated
2016-08-17 00:43 Christian Grothoff Note Added: 0011035
2016-08-17 11:27 lynX Note Added: 0011038
2016-08-17 11:34 Christian Grothoff Note Added: 0011039
2016-08-20 12:11 lynX Note Added: 0011044
2016-08-20 12:12 lynX Note Edited: 0011044
2016-08-20 12:21 lynX Note Edited: 0011044
2016-08-20 12:33 lynX Note Edited: 0011044
2016-08-20 13:25 lynX Note Edited: 0011044
2016-08-20 16:07 lynX Note Edited: 0011044
2016-08-20 16:23 lynX Note Added: 0011045
2016-08-20 18:37 lynX Note Edited: 0011045
2016-08-20 22:58 Christian Grothoff Note Added: 0011046
2016-08-21 13:23 lynX Note Added: 0011047
2016-08-21 13:23 lynX Priority high => urgent
2016-08-21 13:23 lynX Severity trivial => block
2016-08-21 13:34 Christian Grothoff Note Added: 0011048
2016-08-21 13:34 Christian Grothoff Assigned To => Christian Grothoff
2016-08-21 13:34 Christian Grothoff Status new => assigned
2016-08-21 13:36 lynX Note Added: 0011049
2016-08-21 16:46 lynX Note Added: 0011053
2016-08-21 16:46 lynX Priority urgent => normal
2016-08-21 16:46 lynX Severity block => tweak
2016-08-21 16:46 lynX Description Updated
2016-08-21 16:46 lynX Steps to Reproduce Updated
2016-08-21 16:51 Christian Grothoff Note Added: 0011054
2016-08-21 17:33 lynX Note Edited: 0011053
2016-08-21 20:40 lynX Note Added: 0011055
2016-08-21 20:45 lynX Summary I failed to set up a <name>.gnu for a VPN tunnel… => Long delay before a <name>.gnu VPN tunnel starts working
2016-08-21 20:45 lynX Description Updated
2016-08-21 20:45 lynX Steps to Reproduce Updated
2016-08-21 20:45 lynX Additional Information Updated
2016-08-21 20:49 Christian Grothoff Note Added: 0011056
2016-08-22 16:54 Christian Grothoff Note Added: 0011058
2016-09-22 20:14 Christian Grothoff Status assigned => resolved
2016-09-22 20:14 Christian Grothoff Fixed in Version => 0.11.0pre66
2016-09-22 20:14 Christian Grothoff Resolution open => fixed
2016-09-22 20:15 Christian Grothoff Target Version => 0.11.0pre66
2016-09-22 20:15 Christian Grothoff Steps to Reproduce Updated
2018-06-07 00:24 Christian Grothoff Status resolved => closed