hyperboria / bugs Goto Github PK

Compiling gives me this error:

Total build time: 58000ms.

/home/csmith/cjdns/node_build/builder.js:478
            if (err) { throw err; }
                             ^
Error: gcc -c -x cpp-output -o build_linux/switch_SwitchCore_c.o -std=c99 -Wall -Wextra -Werror -Wno-pointer-sign -pedantic -D linux=1 -Wno-unused-parameter -fomit-frame-pointer -D Log_DEBUG -g -D NumberCompress_TYPE=v3x5x8 -D Identity_CHECK=1 -D Allocator_USE_CANARIES=1 -D PARANOIA=1 -march=native -DHAS_ETH_INTERFACE=1 -fPIE -fno-stack-protector -fstack-protector-all -Wstack-protector -O3 build_linux/switch_SwitchCore_c.o.i

switch/SwitchCore.c: In function ‘SwitchCore_addInterface’:
switch/SwitchCore.c:279:12: error: loop exit may only be reached after undefined behavior [-Werror=aggressive-loop-optimizations]
         if (ifIndex == NumberCompress_INTERFACES) { return SwitchCore_addInterface_OUT_OF_SPACE; }
            ^
switch/SwitchCore.c:278:45: note: possible undefined statement is here
         if (!core->interfaces[ifIndex].iface.send) { break; }
                                             ^
cc1: all warnings being treated as errors

    at error (/home/csmith/cjdns/node_build/builder.js:52:15)
    at /home/csmith/cjdns/node_build/builder.js:115:22
    at /home/csmith/cjdns/node_build/builder.js:85:13
    at ChildProcess.<anonymous> (/home/csmith/cjdns/node_build/Semaphore.js:7:30)
    at ChildProcess.emit (events.js:98:17)
    at maybeClose (child_process.js:766:16)
    at Process.ChildProcess._handle.onexit (child_process.js:833:5)

I'm on Fedora Rawhide, 64 bit.

Running the master code a05ade4:

Assertion failure [Node.c:57] [(!Node_isAncestorOf(node, bestParent->parent))]

It took two or three days to get it. We don't have a backtrace.

(linux-armv5tel)

Running the master code a05ade4 on mips32 (cross-built) I get an OOM dump.

Applying this execution

cat oom-mips-master.txt | sed -n -e 's/.* \([a-zA-Z0-9_]*\.[ch]\:[0-9]*\) .*$/\1/p' | sort | uniq -c | sort -n

the result is:

...
    943 Message.h:75
    943 Message.h:86
    944 RouterModule.c:414
    945 RouterModule.c:581
    947 Message.h:62
    947 Message.h:63
    947 Pinger.c:116
   1065 Dict.c:95
   1775 String.c:31
   1775 String.c:39
   1888 RouterModule.c:412
   1893 UDPAddrIface.c:100
   1894 Pinger.c:106
   1894 Pinger.c:136
   1894 Pinger.c:138
   1956 Dict.c:150
   2836 PeerLink.c:50
   3785 Dict.c:166
   5444 Timeout.c:87
   5809 Dict.c:132
   6435 Allocator.c:735
   7022 InterfaceController.c:765

I can send the full OOM log if required.

Similar to beacons on ETHInterface we could do the exact same thing on UDPInterface via ff02::1 i.e. link-local multicast. Not to replace ETHInterface, but to allow peering via beacons on build targets which make it impossible or at least infeasible to use ETHInterface (e.g. Android, OS X, Windows).

Commit: dc7eaf6

~/cjdns# ./do
Initialize 2ms
Build NaCl
Creating directories
Link time optimization not supported [/tmp/jsmake-2741376c515d81d4763a:1:0: error: CPU you selected does not support x86-64 instruction set
]
randombytes/devurandom.c:1:0: error: CPU you selected does not support x86-64 instruction set

Total build time: 211ms.

/root/cjdns/build_linux/dependencies/cnacl/node_build/RandomBytes.js:13
        if (retCode) { throw new Error('failed to compile'); }
                             ^
Error: failed to compile
    at /root/cjdns/build_linux/dependencies/cnacl/node_build/RandomBytes.js:13:30
    at /root/cjdns/node_build/builder.js:85:13
    at ChildProcess.<anonymous> (/root/cjdns/node_build/Semaphore.js:7:30)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Process.ChildProcess._handle.onexit (child_process.js:802:5)

Cjdns does not compile on VPS with CPU model_name model name QEMU Virtual CPU version 1.0.
Older versions compiled fine.

Especially on space-constraint systems (think: OpenWrt routers) it is desirable to use dynamic linking to avoid unwanted (source-/binary-)code duplication.
I understand that having a libuv-fork included in cjdns makes sense when building for non-GNU systems such as Android, OSX or win32. As libuv is packaged on most GNU/Linux distributions, why not use the package instead or at least allow building with external libuv?

I also understand that djb intended NaCl to be statically linked-into projects. Furthermore, afaik the NaCl-fork included in cjdns contains some (cjdns-specific?) improvements.
However, libsodium could be used as "external NaCl".
Again, do you believe it could be feasible to optionally build against "external NaCl" (i.e. libsodium)?

@cjdelisle: I'd by thankful to read a line or two about the (supposedly good) arguments you had in mind when deciding to use static linking and maintaining your own fork of all libraries used in cjdns.

Tunneling IP or Ethernet on top of fc00::/8 can easily be accomplished using existing tunneling protocols on top of IPv6. Why re-invent the wheel?

Instead, we could draft a general-purpose tunnel broker protocol designed to run on top of cjdns as an independent service.

The protocol should allow requesting various tunnel types (IP-over-IP, IP-over-GRE, Ethernet-over-L2TPv3-over-IP, ...) to various defined target networks (ARPA-INET, ARPA-INET6, DN42, ...).
A tunnel broker may allow being queried for available tunneling methods and target networks by clients. Maybe having enumerated flags to indicate more exactly what type of connectivity you'll get (e.g. 'behind-nat', 'dhcp', 'ra', 'dhcpv6', 'upnp', 'homenet', 'mdns', ...) and maybe also WHERE in the target network you'll most likely end up (AS#, geo location, ...).

ps: I started using Ethernet-over-L2TP-over-IP and it works quite nicely :)
See https://gist.github.com/dangowrt/e65dfde190fb1fcaf05f

crypto/random/seed/LinuxRandomUuidSysctlRandomSeed.c uses sysctl.h which is not provided by musl, see https://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/ for some comments about musl and sysctl.h.
My temporary fix is to have stubs only in LinuxRandomUuidSysctlRandomSeed.c unless GLIBC is defined -- that doesn't look very clean to me and probably your cool jsbuild system got some smarter way to handle that...

I had troubles with iptunnel not working. I was getting:

1431420004 DEBUG IpTunnel.c:687 Got message with wrong address for connection

The check for addresses in IpTunnel.c is using a bad pointer cast that results in illegal memory access (unaligned). This has undefined behaviour in ARM, so the result of the prefix comparison is actually undefined.

https://github.com/hyperboria/cjdns/blob/master/tunnel/IpTunnel.c#L516-L543

Something else has to be used. Stack uint32_t variables, etc.

Sysadmins can set /proc/cpu/alignment to 'fixup' to allow the kernel handle these unaligned memory access by catching the cpu exception and fixing it to allow running broken software, but it is very slow. The default kernel alignment setting is 'ignore', so: undefined behaviour.

(@cpages)

still on current hyperboria/cjdns?branch=master as well as cjdelisle/cjdns?branch=crashey

After a while (24h+):
Assertion failure [NodeStore.c:423] [(r < Node_getReach(link->parent))]

I think that in the current state of cjdns core dumps are very valuable. We have assertion failures of weird cases that we would like to fix. A core dump allows to keep a perfect picture of the failing situation without any other overhead than the creation of a file in disk. Once we have a core dump, the cjdroute user can attach gdb to it.

Core dumps contain private information and are only meaningful to those who own a cjdroute binary and the source code they built it from. That usually means that you should not send them to anyone (because of the private information) and that they will be useless to anyone but you (other people don't have your cjdroute binary or the exact source code you built it from). So the main usage of core dumps is the cjdns user to be able to attach gdb to it, and then report upstream only backtraces and variable contents.

To get core dumps (in GNU/Linux) from cjdroute we need to consider a few things:

1. In a common GNU system, core dumps will be disabled.
2. After setuid(), processes usually lose the capability to dump cores.
3. With chroot/chdir to a root-owned directory, a cjdroute running as nobody will not be able to create a file in that directory.

What I use to overcome all that is:

1. Before calling cjroute, from the same shell that will call it, I allow storing any size coredumps: ulimit -c unlimited
2. I enable in the system core dumps after setuid: echo 1 > /proc/sys/fs/suid_dumpable
3. Create a directory reachable only by root, but writable by nobody. As root: mkdir ~/cjdns; chown nobody ~/cjdns
4. Make cjdroute chroot to that instead of the default /var/run. Add { "chroot": "/root/cjdns" } in the "security" cjdroute.conf list.

With that, the next time cjdroute crashes, you will see a core file there. You can attach gdb to it by running (you should not have changed the cjdroute since the core was dumped):

gdb cjdroute /root/cjdns/core

To test that the cores are dumped, you can test it by killing cjdroute with SIGABRT and checking if the core file is created:

kill -ABRT `pgrep cjdroute`

If they are not, ensure for example that cjdroute runs in the chroot path you wrote in cjdroute.conf:

$ readlink /proc/`pgrep cjdroute`/cwd
/root/cjdns

If you restart cjdroute automatically on crash, then one core dump will overwrite another. If you care about that problem you can enable the core.PID kind of filenames by enabling that: echo 1 > /proc/sys/kernel/core_uses_pid

This information about core dumps could be added to the /doc directory of cjdns.

The current timeout is set to 5 seconds.

https://github.com/hyperboria/cjdns/blob/master/client/AdminClient.c#L313

This seems too slow to allow restarting cjdns in the sheevaplug (armv5tel 1.2GHz). If the machine had enough DHT traffic, it gets too flooded on restart and 5 seconds is not enough.

I think a timeout of 10 would be enough for this case. Otherwise we have to locally patch cjdns to have reliable restarts.

As it seems common for assertions to kill cjdroute, it may be nice to print the backtrace to the log, so common reports would include a lot more detail of the crash conditions.

For glibc systems, this could be called at assertion failed time: http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

A session handshake is very heavy for architectures without curve25519 optimized code (like ARM without neon or mips). Moreover, it requires some bandwidth.

On an x86_64 node, I doing "cjdcmd-ng log | grep hello" reports at least 3 or 4 messages per second. I think that this is close to 3 or 4 handshakes per second. Doing "sessionStats | wc -l" reports ~160 sessions, 30% of them with "grep HANDSHAKE".

On a sheevaplug (armv5tel 1.2GHz) this means ~30% of CPU while idle, and similar on a 320MHz mips32 router.

I feel like these numbers are too high, given the current number of cjdns nodes. These sessions should be related to DHT questions, but I don't understand how the current hyperboria can cause 3/4 DHT operations per second in a single idle node.

Assertion failure [Node.c:57] [(!Node_isAncestorOf(node, bestParent->parent))]

I will try running cjdroute in gdb to get a backtrace if this happens again.

@tmartinx commented on 2 May 2014

Guys,

I'm playing a bit with ipTunnel and I'm seeing that cjdroute creates a wrong mask for the IPv6 address (client side of the tunnel), here is the info:

Server side of config:

{           
    "publicKey": "CLIENT_PUBKEY.k",
    "ip4Address": "192.168.1.2",
    "ip6Address": "2001:db8:4:1::2"
}           

Client side:

Logs:

1398992699 INFO Configurator.c:383 Setting beacon mode on ETHInterface to [2].
1398992699 DEBUG Configurator.c:307 Initiating IpTunnel connection to [SERVER_PUBKEY.k]
1398992709 INFO Angel.c:81 Got request to set IP
1398992709 INFO Angel.c:81 Got request to set IP

IPv4 info (mask ok - /32):

tmartins@cjdns-client-1:~$ ip -4 a s dev hyper
14: hyper: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1312 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 192.168.1.2/32 scope global hyper
       valid_lft forever preferred_lft forever

IPv6 info (mask not okay - /0 where it should be /128):

tmartins@cjdns-client-1:~$ ip -6 a s dev hyper
14: hyper: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1312 qlen 500
    inet6 2001:db8:4:1::2/0 scope global 
       valid_lft forever preferred_lft forever
    inet6 fcxx:bdb8:xxx:xxx:dfb:xxx:xxx:xxx/8 scope global 
       valid_lft forever preferred_lft forever

I'm following the "IPv4 logic" here, because the "/32" equivalent for IPv6 is "/128"...

Best,
Thiago

@cjdelisle commented on 2 May 2014

Actually the IPv6 mask is as intended, it's the IPv4 mask that's confusing. It should always be /0 because cjdns really doesn't want your OS to be trying to seek out a default gateway or handle any routing, ideally your OS would assume the entire Internet is one gigantic Ethernet zone and forward packets into the ether so cjdns will pick them up and DTRT. https://github.com/cjdelisle/cjdns/blob/master/tunnel/IpTunnel.c#L374 Thanks, Caleb

@tmartinx commented on 2 May 2014

Okay, got it!

Thank you for your clarification Caleb, I really appreciate it!

Best,
Thiago

@tmartinx commented on 4 May 2014

Hey Caleb!

Cjdns is impressive! It is doing precisely what I need!

Just for the record, right now, I have access to the "Clearnet" through my Hyperboria-Only Ubuntu Desktop, using "ipTunnel / ip6Address", I'm avoiding IPv4 where I can, take a look:

NOTE: I renamed "tun0" to "hype".

Routes:

tmartinx@ubuntu-1:~$ ip -6 route show
fc00::/8 dev hype  proto kernel  metric 256 
fe80::/64 dev wlan0  proto kernel  metric 256 
default dev hype  proto kernel  metric 256 

NOTE: "ip -4 route show" returns nothing, I like it...

Address:

tmartinx@ubuntu-1:~$ ip -6 addr show dev hype
32: hype: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1312 qlen 500
    inet6 280X:29X:X:111X::2/0 scope global 
       valid_lft forever preferred_lft forever
    inet6 fcYY:baaa8:9xxx:2bxx:dfb:xxfe:xxx:xxx/8 scope global 
       valid_lft forever preferred_lft forever

Connectivity:

tmartinx@ubuntu-1:~$ ping6 -c 1 google.com
PING google.com(2800:3f0:4001:816::1000) 56 data bytes
64 bytes from 2800:3f0:4001:816::1000: icmp_seq=1 ttl=58 time=13.5 ms

tmartinx@ubuntu-1:~$ ping6 -c 1 wiki.projectmeshnet.org
PING wiki.projectmeshnet.org(fcbf:7bbc:32e4:716:bd00:e936:c927:fc14) 56 data bytes
64 bytes from fcbf:7bbc:32e4:716:bd00:e936:c927:fc14: icmp_seq=1 ttl=64 time=531 ms

Nevertheless, I noted that, for IPv4, it is harder to achieve this setup (IPv6 is so easy), for instance, there is no default route (ip -4 route show) pointing to hype interface (even when ip4Address is active with ipTunnel), so, it doesn't work the same way as IPv6 and, since I don't care anymore about IPv4, I'll not try to figure out why... Also, I have DNS64/NAT64 at my border, so, it is not a big deal for me...

CJDNS is AWESOME!! I'll do my best to contribute with this project!

BTW, I think you can close this "issue"... Everything is working as expected.

Thank you!

Regards,
Thiago

@cjdelisle commented on 5 May 2014

IPv4 doesn't work correctly because if we just went and installed a default route, it would blow up your connection to your peer (assuming you're connected using UDPInterface over ipv4).

@tmartinx commented on 5 May 2014

Mmmm… That’s true… Within my infrastructure, I’m connecting exclusively with ETHInterface, I’m using UDPInterface only at my cjdns-border-gateways… I’ll make more tests… BTW, I think that CJDNS needs to make a if statement somewhere… Like this: 1- if only ETHInterface is being used and there is both ip4Address / ip6Address configured at the ipTunnel, then, point both default routes (IPv4 & IPv6) to Hyperboria; 2- if IPv4 UDPInterface is being used, then, do not configure default route for IPv4 (emit an alert on stdout log); 3- if IPv6 UDPInterface is being used, then, do not configure the default route for IPv6 (emit an alert on stdout log); 4- if UDPInterface is being used in a dual-stacked fashion (or something like this), then, do not configure any default route (emit an alert on stdout log). What do you think? Best! Thiago

@cjdelisle commented on 5 May 2014

I'm generally on board with this thinking, I accept the benefits of just-works over layers and perfectionism. Ideally there would be an admin API call (IpTunnel_addRouteException() ?) to decide what to do and Configurator.c would know that it was setting up a UDPInterface and it would know which addresses that interface needed to communicate with and it would create the necessary route exceptions to make sure the peers were accessible but the default route was to the tun device. This would not only satisfy your use case but would bring a lot of joy to the hearts of people who otherwise have to endlessly setup routes for VPN functionality. Somewhere I have/had the beginnings of a piece of code for setting up routes in Linux using the SO_NETLINK which is considered "the right way" (of course this is different in each OS). If you're interested in working on such a module, I'll see if I can find it. Thanks, Caleb

in a05ade4 (master):

1432430838 DEBUG NodeStore.c:748 Linking [fc7c:6025:dce5:af5b:7a3f:8343:b581:c851] with [fcbf:7bbc:32e4:0716:bd00:e936:c927:fc14] with label fragment [0000.0000.0000.001f]
1432430838 DEBUG NodeStore.c:129 link[fc7c:6025:dce5:af5b:7a3f:8343:b581:c851]->[fc24:7863:1f09:b03c:03fd:a861:96e8:038b] [0000.0000.0000.0b2f] Splitting link
1432430838 DEBUG NodeStore.c:1011 discoverLinkC( [fc24:7863:1f09:b03c:03fd:a861:96e8:038b]->[fc24:7863:1f09:b03c:03fd:a861:96e8:038b] [0000.0000.0000.0001] )

Program received signal SIGSEGV, Segmentation fault.
handleNews (node=0x0, newReach=129589530, store=0x5555557ee988) at dht/dhtcore/NodeStore.c:651
651         if (newReach < Node_getReach(node)) {
(gdb) bt
#0  handleNews (node=0x0, newReach=129589530, store=0x5555557ee988) at dht/dhtcore/NodeStore.c:651
#1  0x000055555557c2cd in NodeStore_discoverNode (nodeStore=0x5555557ee988, addr=0x19, scheme=0x7fffffffda48,
    inverseLinkEncodingFormNumber=1434722840, milliseconds=93824995490936) at dht/dhtcore/NodeStore.c:1572
#2  0x0000555555581d57 in onResponseOrTimeout (data=0xffffffffffffffff, milliseconds=28, vping=0x555555871898)
    at dht/dhtcore/RouterModule.c:514
#3  0x0000555555581b3b in callback (ping=0x555555849cd8, data=0x55555587a268) at util/Pinger.c:55
#4  Pinger_pongReceived (data=data@entry=0x55555587a268, pinger=<optimized out>) at util/Pinger.c:167
#5  0x0000555555581fc1 in handleIncoming (message=0x7fffffffdd30, vcontext=0x5555557ecd28) at dht/dhtcore/RouterModule.c:459
#6  0x0000555555573d52 in DHTModuleRegistry_handleIncoming (message=0x7fffffffdd30, registry=<optimized out>) at dht/DHTModuleRegistry.c:63
#7  0x000055555558b17d in incomingMsg (pf=<optimized out>, msg=<optimized out>) at dht/Pathfinder.c:385
#8  incomingFromEventIf (msg=0x55555584b838, eventIf=0x5555558099d8) at dht/Pathfinder.c:415
#9  0x000055555559e614 in Iface_send (msg=0x55555584b838, iface=0x555555809d08) at ./interface/Iface.h:69
#10 timeoutTrigger (vASynchronizer=0x555555809d08) at interface/ASynchronizer.c:69
#11 0x00005555555c8681 in uv__run_timers (loop=loop@entry=0x5555557eb2b0) at ../src/unix/timer.c:146
#12 0x00005555555bedd2 in uv_run (loop=0x5555557eb2b0, mode=mode@entry=UV_RUN_DEFAULT) at ../src/unix/core.c:275
#13 0x000055555555fad5 in EventBase_beginLoop (eventBase=eventBase@entry=0x5555557eb268) at util/events/libuv/EventBase.c:83
#14 0x00005555555ab9d8 in Core_main (argc=<optimized out>, argv=<optimized out>) at admin/angel/Core.c:326
#15 0x0000555555559493 in main (argc=3, argv=0x7fffffffe658) at client/cjdroute2.c:462
(gdb)

cjdroute[25549]: segfault at 38 ip 00007f4c7fcfcbe1 sp 00007fff43410210 error 4 in cjdroute[7f4c7fcda000+92000]

https://github.com/hyperboria/cjdns/blob/master/dht/dhtcore/NodeStore.c#L1070

discoverLinkC (store=store@entry=0x7f6d86335b78, closestKnown=closestKnown@entry=0x7f6d86379368, 
    pathKnownParentChild=<optimized out>, child=child@entry=0x7f6d863ab848, discoveredPath=21814, 
    inverseLinkEncodingFormNumber=0) at dht/dhtcore/NodeStore.c:1070
1070                parent = closest->child;
(gdb) 

When I run ./do, I get this output:

### Installing node.js (you can bypass this step by manually installing node.js v0.8.15 or newer)


==> Downloading http://nodejs.org/dist/v0.10.24/node-v0.10.24-linux-x86.tar.gz with wget... DONE!
==> Verifying the checksum of the downloaded archive... DONE!
==> Extracting the downloaded archive... DONE!

Initialize 7ms
Copy dependencies
Compiler supports link time optimization
Build NaCl
Creating directories
Getting system type
System is [x86_AVX]
Total build time: 2748ms.

/home/cjdns/cjdns/build_linux/dependencies/cnacl/node_build/make.js:72
    throw new Error("build with no premade plan, TODO: generate one");
          ^
Error: build with no premade plan, TODO: generate one
    at getPlan (/home/cjdns/cjdns/build_linux/dependencies/cnacl/node_build/make.js:72:11)
    at /home/cjdns/cjdns/build_linux/dependencies/cnacl/node_build/make.js:134:18
    at /home/cjdns/cjdns/build_linux/dependencies/cnacl/node_build/AbiName.js:11:5
    at /home/cjdns/cjdns/node_build/builder.js:85:13
    at ChildProcess.<anonymous> (/home/cjdns/cjdns/node_build/Semaphore.js:7:30)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Process.ChildProcess._handle.onexit (child_process.js:802:5)

I was thinking about how to improve assimilation of existing non-cjdns networks. What I mean by that is to keep the number of non-cjdns-hops between two users of the same cjdns network (e.g. hypeboria) as low as possible, given that this is a desirable for some hosts under some circumstances.

Imagine a DHT service which could run on top of fc00::/8 where people may publish their wish for peering over non-cjdns networks. If there was such a thing, I'd publish a public key and some information (e.g. 'ARPA-INET6', AS#, address prefix) of some-but-not-all of my hosts there. It should be queryable in a way that allows clients to find potential cjdns peers close to their own network location on a specific non-cjdns-(inter)network, ideally inside the same AS (i.e. define hash-buckets well, file peering-info-tuple for AS# and various descending IP-prefix-lengths)
An other way to know about potential peers around me may be scanning for cjdns beacons on radio interfaces -- currently sending beacons implies that peering is possible for anyone capable of receiving the beacon without authentication. However, imagine a new type of beasons could be introduced to merely announce the presence of a cjdns node, but still require authentication to actually peer with that node (that may sound awkward, but keep on reading, you'll understand...)

Now imagine a protocol allowing others to request temporary peering credentials over cjdns. They are already connected to me over a cjdns network, but routing may take unnecessary detours which could be avoided. Thus they queried the DHT or scanned for beacons on a radio interface in order to find more peers close to them and found me. They request peering credentials and given that attitude and resources allow, they'll receive an IP-address, port, peering password and lease-time. People with dynamic ARPA-IP-addresses (e.g. cable or DSL users) would typically offer lower lease-times and limit the number of opportunistic peers to something rather low. Boxes in data-centres having static addresses would typically offer longer lease-times to avoid unnessesary noise when allowing a quite high number of opportunistic peers.

I'm totally aware that this may or may not be desirable, thus it should be configurable, similar to how beaconing is configurable on Ethernet interfaces:

0 : no opportunistic peering
1 : query DHT for peers, but do not publish peering info
2 : publish peering info and query DHT for peers

This could be an independent services running on top of fc00::/8 and using cjdroute's admin interface to add and remove peering credentials. I'm not sure whether it should be independent only because it could be...

@ksnieck wrote some code for this here: https://github.com/ksnieck/cjdns/tree/osxeth

It probably needs a refresh, and I remember them saying it crashed under load.

If you do ./tools/traceroute [self_cjdns_ip] the cjdns server will crash with following error in logs:

Assertion failure [NodeStore.c:631] [(Node_getBestParent(node) && node != store->pub.selfNode)]

System: Debian
Kernel: 2.6/OpenVM
Verson: Newest/ 3311d30

Attempted banned syscall number [1073741864] see doc/Seccomp.md for more information

Disallowed Syscall

Core exited with status [0], signal [6]

@tmartinx commented on 26 Mar 2014

Guys!

After reading the "nat-gateway.md" (https://github.com/cjdelisle/cjdns/blob/master/doc/nat-gateway.md) an idea just popup in my mind... Which is:

Instead of relying on this NAT66 thing, to share one cjdns router with my "private IPv6 subnet", I'm wondering here, why not publish my "IPv6 private subnet" to the entire cjdns network?

I mean, for example:

Behind my Hyperboria IPv6 address "fca8:b13e:41d3:3882:ab5a:d783:b920:633e" (cjdns instance), I have the following IPv6 private subnet: "fd9d:037d:2d95:6c4b::/64". So, as I said before, I would like to, somehow, publish my "fd9d:037d:2d95:6c4b::/64" private subnet to the entire Hyperboria, that way, if someone connected to it, tries to reach "fd9d:037d:2d95:6c4b::/64", the Hyperboria global network "will know" that this subnet is BEHIND the router "fca8:b13e:41d3:3882:ab5a:d783:b920:633e"!

And voialá! No need for NAT66!

What do you guys thinks about this idea?!

If it is doable, we can think later, in a mechanism that will not allow conflicts, subnet hijacking or routing table bloating (like external lookups or something else)...

I have lots more ideas, if this proposal works!! Like for example, deploy cjdns directly on a Neutron IPv6 router (from OpenStack project), this way, each tenant of my Cloud Computing environment, will be part of Hyperboria network without any effort!

BTW, sorry if this isn't the right place to talk about those kind of things...

Cheers!
Thiago

@Downchuck commented on 28 Mar 2014

Thiago, I like the idea but you can't gloss over this one: "conflicts, subnet hijacking".

Seems to me that you're talking about something like DNS, with any non fc::0 resulting in something like a DNS lookup. I'd opt to re-use the trust semantics of cjdns -- in this case, I'd only trust mappings/routing as reported by nodes I'm directly connected to.

http://wiki.projectmeshnet.org/DNS#Current_state_of_DNS_on_Hyperboria

@tmartinx commented on 28 Mar 2014

Charles, I agree but, I also trust in a second decentralized database, called "Blockchain", I think that we can use the Namecoin, which is globally reachable, open source decentralized key/value registration and transfer system, as a place to host "cjdns routing info data by demand". Namecoin can also be used as a much more safer DNS. What do you think?! BTW, I'm glad you liked it! Tks! Cheers! Thiago

@t128 commented on 8 Apr 2014

But i dont want to expose my private network. The only reason for exposing a host to publicity is when it is a server. In this case i can just run cjdns directly on it. Also i can use a firewall to filter "bad" packets with nat.

ok, after rereading your text: it would be something like nat + exposure of your private net. I just dont see an advantage in this approach.

@tmartinx commented on 9 Apr 2014

Well, I think you don't understand my idea...

I agree, I'm thinking about running cjdns directly on a host that needs it, no problem with that, BTW...

But, NAT isn't a firewall, I never like this workaround called "NAT", and NAT66 is even worse. Need a firewall, use the filter table. :-P

No, I did not said "nat + exposure of your private net", nothing like that, my approach does NOT use any kind of NAT. It is pure routing, of course, to avoid NAT in first place. People should use the filter table to make its security polices.

Yes, I'm against NAT and I proposing this precisely to not make use of it.

From behind my cjdns router, I have a IPv6 network, that can be reachable from anywhere, people just need to know the route (again, no NAT). I build my firewall using the "filter" table, so, it will be protected anyway.

Cheers!
Thiago

@Wolf480pl commented on 9 May 2014

I too don't like NAT. It was supposed to be gone with IPv6, wasn't it? Everyone was supposed to have a /48 or /56 prefix so that they can have several /64 subnets...

What would happen if cjdns only used first 64 bits of the public key hash for the first half of the IPv6 address, and the other half was be left to user, so that everyone had a /64 subnet? Would that cause many collisions?

Anyway, I guess it's too late to change it, it would break all the existing networks.

@nolith commented on 1 Aug 2014

Hi guys, I'm running a wireless community network node in Italy, which if part of the ninux.org network.
We are using OLSR for internal routing and BGP over a tinc vpn with the other cities.

Yesterday I read about cjdns and hyperboria and I liked the idea. I was thinking of how to propose it to my community when I realized that this will require to run the cjdns on every machine :(

I'm with @tmartinx and @Wolf480pl, NAT was a necessary evil in IPv4 networks, but in IPv6 we need pure routing.

@cjdelisle commented on 1 Aug 2014

How do you imagine that working? One cjdns node has hundreds or thousands of IPv6 addresses and hands them out using DHCPv6 ?

@nolith commented on 1 Aug 2014

On 2014-08-01 09:27, Caleb James DeLisle wrote: How do you imagine that working? One cjdns node has hundreds or thousands of IPv6 addresses and hands them out using DHCPv6 ?

Radvd will be enough. Usually we have some wifi antennas on the rooftop which are connected to an openwrt router. We run olsrd on that and we bridge the wifi card to a tagged VLAN on the ethernet. So we have a taggeg interface for each antenna on the openwrt router. There we will be able to install the cjdn which will announce a /64 with radvd (which is already in place). In Rome they are using public IPv6 because the have found a free bpg peering, in Florence we are using ULA, in other cities are using tunnel broker. We have a network, scattered across Italy, of about 300 installations. But every node has a LAN which is announced via OLSR. End-To-End connection is a key value of our mesh network. --- Alessio "nolith" il sapere umano appartiene al mondo. GPG 440C5437

@cjdelisle commented on 1 Aug 2014

Ok, you want public addresses (not fc00/8) and you want to announce them with radvd and use cjdns to forward the traffic inside of your network. Take a look at this: https://github.com/cjdelisle/cjdns/tree/master/tunnel Each cjdns node will still have an fc00::/8 address for management purposes and without nat, you will not be able to expose your users to hyperboria (and packets from user-to-user will always go to the PoP) but this should resolve your use case of getting people on the internet.

@nolith commented on 1 Aug 2014

On 2014-08-01 10:24, Caleb James DeLisle wrote: [...] Each cjdns node will still have an fc00::/8 address for management purposes and without nat, you will not be able to expose your users to hyperboria (and packets from user-to-user will always go to the PoP) but this should resolve your use case of getting people on the internet.

No, I was just explaining you the whole scenario, but my idea is to be part of the hyperboria network, I think that in our network hyperboria and our mixed public/private addressing will coexists nicely. The whole idea behind cjdns is amazing and I would like to be part of it, but requiring to install it on every device will be a problem. Given the way we (ninux.org) but also others community network like freifunk, funkfeuer, guifi, wlan slowenija and awmn are used to deploy their networks, I fully support the idea of routing a /64 behind each cjdns router. So, I'll try as soon as possible to find some hyperboria peering over UDP to gain some experience about cjdns, but I cannot foresee a wide adoption whiteout a final prefix announcing to the home LAN.

@cjdelisle commented on 1 Aug 2014

Technically it's not possible to route a /64 in the hyperboria network because no matter how much you patch your cjdns nodes, the other nodes will look at your packets and if the double-sha512 of your public key doesn't match the ipv6, the packet is dropped so you would have to start your own network. The reason why we didn't elect to have some "routing room" in the ipv6 space during early design is because if nodes only relied on the first 64 bits matching, it would not take very long to collide someone's ipv6 and hijack their ip address.

@jedahan commented on 1 Aug 2014

Why not rely on the first 96 bits, or 112 bits? Is that still too easy to make collisions?

@cjdelisle commented on 1 Aug 2014

every bit removed makes it twice as easy to collide an ip and the people I talked to thought that 120 was a little bit scary in the long term. Maybe 116 would have been ok, you should have talked to us 2 years ago.

@nolith commented on 1 Aug 2014

@jedahan in IPv6 prefix smaller than /64 are prohibited (on RFC, not technically) only /128 is allowed.

@jedahan commented on 1 Aug 2014

So if I understand right, the reason we care about collisions is because people are self-assigning (algorithmically) ipv6 addresses. The benefit is no central service controlling address assignments, the drawback is we still have to NAT.

If we want no collision, self-assigned, cryptographically secure, no NAT ipv6 addressing & routing, we would need to:

a. ignore the /64 RFC to allow /12 prefixing (not a big deal imo)
b. rewrite the rules for matching the first 116 bits instead of entire address (should not be painful?)
c. have everyone who has peered have to re-peer (by far, the most painful part)

Being this is super alpha, I think some level of 'breakage' in the form of having to regenerate keys should be fine. As long as its announced ahead of time, and theres a well-documented way to migrate.

The medium and long-term benefits of killing NAT could really help adoption, and eventually the strength of the network, if i'm understanding things correctly.

If all of this was debated ad nauseum 2 years ago, and there are any logs, I would love to read them to get a deeper understanding and appreciation of the decisions made.

@Wolf480pl commented on 1 Aug 2014

To help avoid collisions you could also increase the difficulty of finding a good key. Right now there are 8 bits that need to be brute-forced (the fc/8 prefix), right? How bad would it be to add another 8?

@cjdelisle commented on 2 Aug 2014

256 times as hard for finding one. 65535 times as hard for finding all of them.

@t128 commented on 4 Aug 2014

This helps only against brute force attacks (128 bits to brute force vs. 128bit real range) but not against "random collisions" (112 bits vs. 128bit real range). Also it would make key-gen for every one harder.

@Arceliar commented on 8 Aug 2014

I don't think increasing the fixed prefix size will do much to the collision rate. Finding a collision means getting all 128 bits to match. Adding an extra 8 bits would make address generation 256x longer, and also make collisions 256x more common among valid addresses (since they now only need to match on the 112 free bits, and the rest are fixed).

Now, since the address is from a truncated hash, you could put requirements on bits we chop off (e.g. bits 129-136 must all be 0s), which would allow you to increase the time it takes to generate keys without increasing chance of collisions. But that would require people to generate new addresses and re-peer...

@jedahan commented on 8 Aug 2014

ohhhh that's a clever solution, Arceliar. +1

@lgierth commented on 8 Aug 2014

One issue I'm seeing with non-NAT routing to addresses outside of fc00::/8 is that we lose the end-to-end crypto guarantees, or am I missing something? What's the point of routing outside of fc00::/8 if the destination doesn't speak cjdns, and we lose all the benefits?

@vadipp commented on 9 Aug 2014

This thread mentions the need of re-peering. If I change my private key and IPv6, why will I have to re-peer? I might as well use the same connection info as before, right?

@kpcyrd commented on 9 Aug 2014

@vadipp re-peering is necessary if we change the criteria which address is considered valid and which one isn't. Old addresses will be considered invalid and therefore need to be replaced. This is a discussion about a possible future change, though.

@Arceliar +1. We can change the code for address generation without enforcing this criteria, yet, so we can slowly migrate without breaking the network.

@Arceliar commented on 17 Aug 2014

More thoughts on increasing address generation difficulty.

Another option would be to take another byte of the address (probably the byte immediately after 0xfc), and require that this byte equal the number of leading zero bits in the truncated part of the hash (beginning on bit 129).

That would make address generation 9 bits harder in the easiest case (8 bits in the address + exactly 0 leading zero bits), but allows people to extend the effective size of their address for the purpose of avoiding collisions. The truely paranoid could require an extra ~20 zero bits to increase the difficulty of a collision by a factor of ~1 million. Or just let it run for a week and then pick the best address found in that time.

Note that I'm not advocating that non-cjdns machines be given routable addresses, just trying to think of ways to mitigate the address collision problem if subnetting was ever allowed. I personally think it's a bad idea to do it any way outlined above. A better approach would be to have a cjdns router to assign its 1 and only address to another machine and just forward traffic. Then you could just run 1 instance of cjdns per client machine on your network. No need to change anything in the protocol. Not sure if it's already possible to set something like this up or not (I imagine so, but I don't know how... maybe some magic iptables command?).

@Arceliar commented on 2 Sep 2014

Followup on this. Had another thought.

It would also be possible to slightly change the address generation formula to simplify what I said in the previous post. Instead of the first 128 bits of a sha512, it could be first 128 bits with the first 16 overwritten by fcXX where, XX is the number of 0's following the address. (Or the first 112 bits prefixed with fcXX, or fc for the first bits and XX for the last, or whatever).

This would also have the side-effect of making valid address generation ~256x faster, if there's any incentive to do that.

IPv6s would change, but old keys would remain valid, so I think it would eliminate the need to re-peer. Paranoid users could brute force keys with lots of 0s following the address, to make it a bit more secure, if that's their thing.

@krattai commented on 4 Sep 2014

Just to chime in on NAT66, radvd, and external / internal traffic flow.

I'm not a fan of NAT, not much else to say about that. But, the alternative is being able to handle proper subnets, routing and possible BGP on the host system. This can be an issue for those who don't know how.. or shouldn't manage this, because they think they know how. ;)

Which then takes us to radvd vs DHCP, which is generally the simple solution in the NAT configuration above. radvd exposes the MAC address of the NIC. NOT a good thing from a security persecutive. So NATed router with an internal DHCPv6d on the inside is the more appropriate option, again because sometimes those that think they know how, shouldn't.

The word of this paragraph is "multi-home". IPv6 has integrated multihome, so a host can properly route to destination depending on which path (cjdns or non-cjdns) routes properly.

Not sure if this post provides any new insight or thought, but wanted to put it forward.

@cjdelisle commented on 23 Sep 2014

After some discussion we thought of a solution which might resolve your issue.

The problem is that right now you can't use any trick addressing without 100% of hyperboria dropping your packets, in effect this is like a feature request to change the rules of bitcoin, it only works after everyone updates.

A secondary problem is that whatever bits you use for your own purposes reduce the security against collisions (see also: Birthday Paradox)

I'm imagining you running some sort of ISP and wanting to provide people with both internet access and hyperboria access... In this case, you will likely be issuing a /64 of publicly routable IPv6 addresses to each node to which clients connect. Then clients will be issued individual IPv6 addresses from that /64.

I also have a public IPv6 address allocated to my laptop through cjdns/IPTunnel but if I were to communicate with you, the traffic would go out of my IPTunnel gateway, across the clearnet and back into your IPTunnel gateway (even if we were right next to eachother!)

What would you think of a way that we can "announce" our IPv6 (and IPv4) addresses to one another and bind them to the cjdns keys of the corresponding node?

Certainly your users would not be able to reach all of hyperboria but they would be able to reach anyone in hyperboria who participates in the publically-routable-IPv6 business.

Was https://github.com/cjdelisle/cjdns/issues/629

@mildred commented on 14 Aug 2014

Hi,

I'm opening this issue to discuss anycast. if and how it could be implemented. The main use case I'm thinking about is for advertising a P2P service. To bootstrap a P2P network that would run on top of cjdns, new nodes could find seeds by contacting a well-known anycast address.

A cjdns client could have multiple IP addresses. (this could be implemented using two cjdns instances chained together). Anycast address would be address which private key has been made public. Multiple nodes could register it on the cjdns network at the same time, and packets should arrive to one (or more) of these addresses.

@kpcyrd commented on 14 Aug 2014

I propose we aggree on special use addresses, that are discarded if they are accidentally generated.

Next, we can brute addresses in fc00:c457::/32 for dht peers. Those peers are for bootstrapping P2P networks and it's assumed they run a bootstrapping server. You can discover bootstrapping addresses by dumping the routing table.

@mildred commented on 14 Aug 2014

Do we really need special addresses? Why couldn't it work for any address?

@kpcyrd commented on 14 Aug 2014

It would work for any address, but it'd be easier to probe only those addresses that match a special pattern. They'd "announce" this torrent-tracker-like service using their address. It's not really anycast, but it'd allow to bootstrap P2P networks without any central systems.

I think public private keys would defeat the friend-to-friend trust system :)

I'm not sure what happens if multiple peers try to join the network using the same address. I doubt this works, but I've never tried it.

@cjdelisle commented on 21 Aug 2014

I'm not sure what happens if multiple peers try to join the network using the same address. I doubt this works, but I've never tried it.

I'm not 100% sure how this behaves (in the real world) but the desired behavior if a private key is installed on multiple machines is to have working anycast.

@Arceliar commented on 2 Sep 2014

I'm not 100% sure how this behaves (in the real world), but the desired behavior if a private key is installed on multiple machines is to not break the network.

Because the NodeStore identifies nodes based on IPv6, it would probably get horribly confused about who is a child of which node.

Suppose we're node A, we have node N with peer P in our store, and we discover a new node N' (same key/ipv6) with peer Q behind the same director as P. We can't distinguish N from N' (afaik), so we would be unable to correctly determine which N/N' to route through if we wanted to contact node P/Q.

@mildred commented on 2 Sep 2014

What is sure is that anycast nodes (nodes sharing the same key pair) can't participate in routing as they cannot be identified uniquely. A good practice for such nodes would be to restrict their peers to 1 only. Perhaps we should test this on the network...

@Arceliar commented on 5 Sep 2014

I think the anycast nodes would still be required to forward traffic (because of the DHT), so limiting them to 1 peer probably wouldn't fix the problem (but it may make the problem less severe).

I think the "right" solution would be to identify peers in the nodestore by something other than the key used to generate the IP address. Then you can have unique nodes, which happen to have the same IP, without breaking the node store. Maybe generate a second key, who'se only purpose is to distinghish between different anycast nodes.

@lgierth commented on 13 May 2014

I'll have a stack dump as soon as I find the GDB command... need to also compile an OpenWRT with GDB.

root@OpenWrt:~# /etc/init.d/cjdns start
1399952811 INFO cjdroute2.c:541 Cjdns ARM 32-bit LittleEndian linux +seccomp
1399952811 INFO cjdroute2.c:545 Checking for running instance...
1399952811 DEBUG AdminClient.c:349 Connecting to [127.0.0.1:11234]
1399952811 DEBUG UDPAddrInterface.c:289 Bound to address [0.0.0.0:57446]
1399952811 INFO cjdroute2.c:571 Forking angel to background.
1399952811 DEBUG Pipe.c:135 Buffering a message
1399952811 INFO RandomSeed.c:42 Attempting to seed random number generator
1399952811 INFO RandomSeed.c:50 Trying random seed [/dev/urandom] Success
1399952811 INFO RandomSeed.c:56 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Failed
1399952811 INFO RandomSeed.c:50 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
1399952811 INFO RandomSeed.c:64 Seeding random number generator succeeded with [2] sources
1399952811 DEBUG Pipe.c:232 Pipe [/tmp/cjdns_pipe_client-angel-pt8g5nzbcztuyn1bl9knk14j51jw3t] established connection
1399952811 DEBUG Pipe.c:254 Sending buffered message
1399952811 DEBUG AngelInit.c:180 Getting pre-configuration from client
1399952811 DEBUG Pipe.c:232 Pipe [/tmp/cjdns_pipe_client-angel-pt8g5nzbcztuyn1bl9knk14j51jw3t] established connection
1399952811 DEBUG AngelInit.c:184 Finished getting pre-configuration from client
1399952811 INFO AngelInit.c:215 Initializing core [/usr/sbin/cjdroute]
1399952811 DEBUG AngelInit.c:219 Sending pre-configuration to core.
1399952811 DEBUG Pipe.c:135 Buffering a message
1399952811 INFO RandomSeed.c:42 Attempting to seed random number generator
1399952811 INFO RandomSeed.c:50 Trying random seed [/dev/urandom] Success
1399952811 INFO RandomSeed.c:56 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Failed
1399952811 INFO RandomSeed.c:50 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
1399952811 INFO RandomSeed.c:64 Seeding random number generator succeeded with [2] sources
1399952811 INFO LibuvEntropyProvider.c:59 Taking clock samples every [1000]ms for random generator
1399952811 DEBUG Pipe.c:232 Pipe [/tmp/cjdns_pipe_69rhp4cspxhwgx9yt16v7hxcx063qu] established connection
1399952811 DEBUG Pipe.c:254 Sending buffered message
1399952811 DEBUG Pipe.c:232 Pipe [/tmp/cjdns_pipe_69rhp4cspxhwgx9yt16v7hxcx063qu] established connection
1399952811 DEBUG UDPAddrInterface.c:250 Binding to address [127.0.0.1:11234]
1399952811 DEBUG UDPAddrInterface.c:289 Bound to address [127.0.0.1:11234]
1399952811 DEBUG Hermes.c:180 Sending [64] bytes to angel [d5:error4:none5:admind4:bind15:127.0.0.1:11234e4:txid8:00000000e].
1399952811 DEBUG AdminClient.c:349 Connecting to [127.0.0.1:11234]
1399952811 DEBUG UDPAddrInterface.c:289 Bound to address [0.0.0.0:42717]
1399952811 INFO Configurator.c:126 Checking authorized password 0.
1399952811 INFO Configurator.c:147 Adding authorized password #[0] for user [password [0]].
1399952811 CRITICAL Configurator.c:103 Got error [Seccomp.c:296 prctl(PR_SET_SECCOMP) -> [Invalid argument]] calling [Security_dropPermissions]
1399952811 CRITICAL Configurator.c:54 enable Log_LEVEL=KEYS to see message content.
1399952812 INFO Angel.c:43 Got request to exit
1399952817 CRITICAL Configurator.c:66 Failed to stop the core.
1399952817 CRITICAL Configurator.c:68 Aborting.

@cjdelisle commented on 13 May 2014

probably kernel version is too old but you still have seccomp header files. uname -a

@lgierth commented on 17 May 2014

Haven't found the time to look into this yet, meanwhile I'm disabling SecComp as a workaround: Seccomp_NO=1 ./do

@lgierth commented on 24 Sep 2014

Collecting possibly useful findings:

• lkml: ARM seccomp filters and EABI/OABI
• lkml: ARM audit, seccomp, etc are broken wrt OABI syscalls (follow-up of ^)
• lkddb: CONFIG_OABI_COMPAT

@lgierth commented 21 days ago

Some progress in OpenWrt:

• https://lists.openwrt.org/pipermail/openwrt-devel/2015-February/031297.html
• https://dev.openwrt.org/changeset/43888

output from ./do

### Installing node.js (you can bypass this step by manually installing node.js v0.8.15 or newer
)


==> Downloading http://nodejs.org/dist/v0.10.24/node-v0.10.24-linux-arm-pi.tar.gz with wget... D
ONE!
==> Verifying the checksum of the downloaded archive... DONE!
==> Extracting the downloaded archive... DONE!

Initialize 10ms
Copy dependencies
Link time optimization not supported [cc1: error: bad value (native) for -march switch
]
Build NaCl
Creating directories
cc1: error: bad value (native) for -march switch

Total build time: 3553ms.

/root/testing/cjdns/build_linux/dependencies/cnacl/node_build/RandomBytes.js:13
        if (retCode) { throw new Error('failed to compile'); }
                             ^
Error: failed to compile
    at /root/testing/cjdns/build_linux/dependencies/cnacl/node_build/RandomBytes.js:13:30
    at /root/testing/cjdns/node_build/builder.js:85:13
    at ChildProcess.<anonymous> (/root/testing/cjdns/node_build/Semaphore.js:7:30)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)
    at Socket.EventEmitter.emit (events.js:95:17)
    at Pipe.close (net.js:466:12)
./do  4.91s user 3.23s system 117% cpu 6.906 total

/proc/cpuinfo

Processor       : ARMv7 Processor rev 4 (v7l)
processor       : 0
BogoMIPS        : 2004.17

processor       : 1
BogoMIPS        : 2011.05

Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva id
ivt 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 4

Hardware        : sun7i
Revision        : 0000
Serial          : 0702b4b4544948488048566616516605

I'm really not so much into this whole JavaScript story, someone please give a hand here:

/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:231
            throw err;
                  ^
ReferenceError: __FILE__ is not defined
Content: [ return '"'+__FILE__.substring(__FILE__.lastIndexOf('/')+1)+'"'; ]
    at Function.eval (eval at <anonymous> (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:213:24), <anonymous>:3:13)
    at /usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:221:22
    at Object.ret.nThen (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_modules/nthen/lib/nthen.js:32:21)
    at nThen (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_modules/nthen/lib/nthen.js:63:16)
    at execJs (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:209:5)
    at /usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:269:9
    at Object.ret.nThen (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_modules/nthen/lib/nthen.js:32:21)
    at nThen (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_modules/nthen/lib/nthen.js:63:16)
    at preprocessBlock (/usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:265:5)
    at /usr/src/openwrt/build_dir/target-arm_mpcore_musl-1.1.7_eabi/cjdns-2303ce6585f62f7e8d3cdb1983c0c8e08385ea68/node_build/builder.js:310:13

It crashes each time I try to send ETHInterface_beginConnection command via admin port.
When I send command without password:
Assertion failure [InterfaceController.c:805] [(password)]
And with password:
Assertion failure [UDPAddrIface.c:115] [(ss.addr.addrLen == context->pub.generic.addr->addrLen)]
Looks like that asserton from InterfaceController.c is the same as in this bug report.

This is x86_64-linux, without any tun device. Running 78e1348.

Happens after less than 10 minutes of running, usually.

Program received signal SIGSEGV, Segmentation fault.
0x00007f026815c159 in Iface_next ()
(gdb) bt
#0  0x00007f026815c159 in Iface_next ()
#1  0x00007f026815c9cb in sendToTunIf ()
#2  0x00007f026815cd38 in incomingFromUpperDistributorIf ()
#3  0x00007f026815b703 in Iface_send ()
#4  0x00007f026815b852 in Iface_next ()
#5  0x00007f026815bc0d in incomingFromSessionManagerIf ()
#6  0x00007f026815a331 in Iface_send ()
#7  0x00007f026815a480 in Iface_next ()
#8  0x00007f026815b043 in incomingFromSessionManagerIf ()
#9  0x00007f02681547a8 in Iface_send ()
#10 0x00007f02681548f7 in Iface_next ()
#11 0x00007f026815656c in incomingFromSwitchIf ()
#12 0x00007f0268159a09 in Iface_send ()
#13 0x00007f0268159b58 in Iface_next ()
#14 0x00007f0268159e41 in incomingFromSwitchIf ()
#15 0x00007f026813fdd4 in Iface_send ()
#16 0x00007f026813ff23 in Iface_next ()
#17 0x00007f026814111f in receiveMessage ()
#18 0x00007f0268144242 in Iface_send ()
#19 0x00007f0268144391 in Iface_next ()
#20 0x00007f0268145e74 in receivedPostCryptoAuth ()
#21 0x00007f0268147026 in handleIncomingFromWire ()
#22 0x00007f026813c51e in Iface_send ()
#23 0x00007f026813cd80 in incoming ()
#24 0x00007f02681aaa07 in uv__udp_recvmsg () at ../src/unix/udp.c:219
#25 0x00007f02681aa7f8 in uv__udp_io () at ../src/unix/udp.c:157
#26 0x00007f02681abcc7 in uv__io_poll () at ../src/unix/linux-core.c:271
#27 0x00007f026819b6d0 in uv_run () at ../src/unix/core.c:284
#28 0x00007f0268104608 in EventBase_beginLoop ()
#29 0x00007f026815ed34 in Core_main ()
#30 0x00007f0268166df3 in main ()

Sorry for the lack of some src line numbers/files. I don't know the reason.

@cjdelisle commented on 2 Feb

UDPInterface-over-IPTunnel causes fantastically horrible problems.

Running on 738df10 and doing a traceroute of any IPv6 address using the admin API errors with a timeout and then cjdroute aborts failing the assertion [NodeStore.c:616] [(bp && bp != store->selfLink)].

A stack trace follows.

GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cjdroute...done.
Starting program: /usr/bin/cjdroute < cjdroute.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New process 28738]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
process 28738 is executing new program: /usr/bin/cjdroute
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New process 28744]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
process 28744 is executing new program: /usr/bin/cjdroute
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
1425685275 INFO RandomSeed.c:42 Attempting to seed random number generator
1425685275 INFO RandomSeed.c:50 Trying random seed [/dev/urandom] Success
1425685275 INFO RandomSeed.c:56 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Failed
1425685275 INFO RandomSeed.c:50 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
1425685275 INFO RandomSeed.c:64 Seeding random number generator succeeded with [2] sources
1425685275 INFO LibuvEntropyProvider.c:59 Taking clock samples every [1000]ms for random generator
1425685275 DEBUG Pipe.c:231 Pipe [/tmp/cjdns_pipe_furrxbsplh0gwk58xj7yubz9u79ruv] established connection
1425685275 DEBUG UDPAddrIface.c:255 Binding to address [127.0.0.1:11234]
1425685275 DEBUG UDPAddrIface.c:294 Bound to address [127.0.0.1:11234]
1425685275 DEBUG Hermes.c:151 Sending [64] bytes to angel


Assertion failure [NodeStore.c:616] [(bp && bp != store->selfLink)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7fad700 (LWP 28744)]
0x00007ffff76464b7 in raise () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7ffff7fad700 (LWP 28744)):
#0  0x00007ffff76464b7 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff764788a in abort () from /usr/lib/libc.so.6
#2  0x000055555555986b in Assert_failure (format=format@entry=0x5555555dbb60 "Assertion failure [%s:%d] [%s]\n") at util/Assert.c:32
#3  0x000055555558c07e in handleBadNews (store=0x55555580d358, newReach=3758096383, node=0x55555580d418) at dht/dhtcore/NodeStore.c:616
#4  handleNews (node=node@entry=0x55555580d418, newReach=newReach@entry=3758096383, store=store@entry=0x55555580d358) at dht/dhtcore/NodeStore.c:635
#5  0x0000555555592897 in NodeStore_pathTimeout (nodeStore=0x55555580d358, path=<optimized out>) at dht/dhtcore/NodeStore.c:2254
#6  0x0000555555594251 in onTimeout (pctx=0x5555558b42b8, milliseconds=24800) at dht/dhtcore/RouterModule.c:429
#7  onResponseOrTimeout (data=<optimized out>, milliseconds=24800, vping=0x5555558b42b8) at dht/dhtcore/RouterModule.c:472
#8  0x000055555557330c in callback (ping=0x555555895a38, data=0x0) at util/Pinger.c:55
#9  timeoutCallback (vping=0x555555895a38) at util/Pinger.c:74
#10 0x00005555555d8231 in uv__run_timers (loop=loop@entry=0x5555557fb2b0) at ../src/unix/timer.c:146
#11 0x00005555555ce9a2 in uv_run (loop=0x5555557fb2b0, mode=mode@entry=UV_RUN_DEFAULT) at ../src/unix/core.c:275
#12 0x000055555555dec5 in EventBase_beginLoop (eventBase=eventBase@entry=0x5555557fb268) at util/events/libuv/EventBase.c:83
#13 0x00005555555b1776 in Core_main (argc=<optimized out>, argv=0x7fffffffebb8) at admin/angel/Core.c:373
#14 0x00005555555b6baa in main (argc=3, argv=0x7fffffffebb8) at admin/angel/cjdroute2.c:408
1425685275 INFO RandomSeed.c:42 Attempting to seed random number generator
1425685275 INFO RandomSeed.c:50 Trying random seed [/dev/urandom] Success
1425685275 INFO RandomSeed.c:56 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Failed
1425685275 INFO RandomSeed.c:50 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
1425685275 INFO RandomSeed.c:64 Seeding random number generator succeeded with [2] sources
1425685275 DEBUG AngelInit.c:152 Getting pre-configuration from client
1425685275 DEBUG Pipe.c:231 Pipe [/tmp/cjdns_pipe_client-angel-9ffsqb1h0t6p0h8mklxc2nck91pgfn] established connection
1425685275 DEBUG AngelInit.c:156 Finished getting pre-configuration from client
1425685275 INFO AngelInit.c:183 Initializing core [/usr/bin/cjdroute]
1425685275 DEBUG AngelInit.c:187 Sending pre-configuration to core.
1425685275 DEBUG Pipe.c:134 Buffering a message
1425685275 DEBUG Pipe.c:231 Pipe [/tmp/cjdns_pipe_furrxbsplh0gwk58xj7yubz9u79ruv] established connection
1425685275 DEBUG Pipe.c:253 Sending buffered message
1425685275 DEBUG AngelInit.c:210 Angel_start()
1425685274 INFO cjdroute2.c:513 Cjdns AMD64 64-bit LittleEndian linux +seccomp
1425685274 INFO cjdroute2.c:517 Checking for running instance...
1425685274 DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
1425685274 DEBUG UDPAddrIface.c:294 Bound to address [0.0.0.0:34613]
1425685274 INFO cjdroute2.c:543 Forking angel to background.
1425685274 DEBUG Pipe.c:134 Buffering a message
1425685274 DEBUG cjdroute2.c:580 Sent [192] bytes to angel process
1425685275 DEBUG Pipe.c:231 Pipe [/tmp/cjdns_pipe_client-angel-9ffsqb1h0t6p0h8mklxc2nck91pgfn] established connection
1425685275 DEBUG Pipe.c:253 Sending buffered message
1425685275 DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
1425685275 DEBUG UDPAddrIface.c:294 Bound to address [0.0.0.0:45882]
1425685275 INFO Configurator.c:438 Setting up ETHInterface [0].
1425685275 INFO Configurator.c:441 Binding to device [adhoc0].
1425685275 INFO Configurator.c:383 Setting beacon mode on ETHInterface to [2].
1425685275 INFO Configurator.c:455 ETHInterface should connect to a specific node.

cjdelisle#816 added a "peerName" field, I tired using it and it resulted in following crash:

DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
INFO Configurator.c:135 Checking authorized password 0.
INFO Configurator.c:135 Checking authorized password 1.
INFO Configurator.c:135 Checking authorized password 2.
INFO Configurator.c:135 Checking authorized password 3.
INFO Configurator.c:157 Adding authorized password #[0] for user [PWN].
INFO Configurator.c:165   This connection password restricted to [fc15:76ce:f283:b87d:1f60:ca1c:9859:a641] only.
INFO Configurator.c:157 Adding authorized password #[1] for user [dangranos].
INFO Configurator.c:157 Adding authorized password #[2] for user [vm1].
INFO Configurator.c:165   This connection password restricted to [fcf6:73c:f33f:cd7f:2f7b:40d1:3244:a0d1] only.
INFO Configurator.c:157 Adding authorized password #[3] for user [elwisp].
KEYS Configurator.c:210 Attempting to connect to node [104.200.29.163:53053].
KEYS Configurator.c:210 Attempting to connect to node [108.61.252.169:57869].
KEYS Configurator.c:210 Attempting to connect to node [104.131.71.243:29501].
KEYS Configurator.c:210 Attempting to connect to node [mahmud.berlinmesh.net:12196].
CRITICAL Configurator.c:97 Failed to make function call [Timed out waiting for a response], error: [UDPInterface_beginConnection]

See e.g. http://buildbot.openwrt.org:8010/broken_packages/octeon/cjdns/compile.txt
The Ubiquiti Edge Router Lite based on the octeon SoC is a very promissing target for cjdns imho...

Just starting cjdroute, it crashes.

It may be relevant that I'm running a cjdroute 1) as non-root and 2) without tun interface.

(gdb) bt
#0  incomingFromUpperDistributorIf () at ./interface/Iface.h:106
#1  0x00007f33c3d0f85d in incomingFromSessionManagerIf () at ./interface/Iface.h:70
#2  0x00007f33c3d0e30c in Iface_next () at ./interface/Iface.h:70
#3  0x00007f33c3d0a71e in incomingFromSwitchIf () at ./interface/Iface.h:70
#4  0x00007f33c3d0e114 in incomingFromSwitchIf () at ./interface/Iface.h:70
#5  0x00007f33c3cd16f0 in receiveMessage () at ./interface/Iface.h:70
#6  0x00007f33c3cd769b in receivedPostCryptoAuth () at ./interface/Iface.h:70
#7  0x00007f33c3cd7dce in handleIncomingFromWire () at net/InterfaceController.c:685
#8  0x00007f33c3cc2235 in incoming () at ./interface/Iface.h:70
#9  0x00007f33c3d35b83 in uv__udp_io () at ../src/unix/udp.c:219
#10 0x00007f33c3d36cf7 in uv__io_poll () at ../src/unix/linux-core.c:271
#11 0x00007f33c3d2c077 in uv_run () at ../src/unix/core.c:284
#12 0x00007f33c3cbd606 in EventBase_beginLoop ()
#13 0x00007f33c3d11aae in Core_main () at admin/angel/Core.c:373
#14 0x00007f33c3cb87d6 in main () at admin/angel/cjdroute2.c:419

How to find memory leaks: https://github.com/hyperboria/cjdns/blob/master/doc/debugging_memory_leaks.md
Full allocator snapshot: https://ezcrypt.it/1PAn#vsqJLdtrJWPqOLZHwHbPXFVK

  | Pinger.c:106 [1296] bytes
  | | RouterModule.c:412 [5176] bytes
  | | | UDPAddrIface.c:100 [64] bytes at [0x7fad97dac7e0]
  | | | UDPAddrIface.c:100 [64] bytes at [0x7fad97dac740]
  | | | Message.h:86 [88] bytes at [0x7fad97af1a30]
  | | | Message.h:75 [2104] bytes at [0x7fad97d69d50]
  | | | Dict.c:132 [72] bytes at [0x7fad97af19e0]
  | | | Dict.c:150 [64] bytes at [0x7fad97af1990]
  | | | Dict.c:132 [72] bytes at [0x7fad97af1940]
  | | | Dict.c:166 [64] bytes at [0x7fad97ae9d50]
  | | | Dict.c:132 [72] bytes at [0x7fad97ae9d00]
  | | | Dict.c:150 [64] bytes at [0x7fad97ae9f90]
  | | | RouterModule.c:414 [104] bytes at [0x7fad97ae9c90]
  | | | Message.h:63 [88] bytes at [0x7fad97ae9c30]
  | | | Message.h:62 [2096] bytes at [0x7fad97d58170]
  | | | RouterModule.c:412 [160] bytes at [0x7fad97ae9ee0]
  | | Timeout.c:84 [488] bytes
  | | | Allocator.c:709 [104] bytes at [0x7fad97df8c70]
  | | | Timeout.c:85 [224] bytes at [0x7fad97df8b80]
  | | | Timeout.c:84 [160] bytes at [0x7fad979397e0]
  | | Timeout.c:84 [488] bytes
  | |   Allocator.c:709 [104] bytes at [0x7fad97d24630]
  | |   Timeout.c:85 [224] bytes at [0x7fad97de1cb0]
  | |   Timeout.c:84 [160] bytes at [0x7fad97989ec0]
  | | Dict.c:132 [72] bytes at [0x7fad97ae9e90]
  | | Dict.c:166 [64] bytes at [0x7fad97ae9e40]
  | | Dict.c:132 [72] bytes at [0x7fad97989f70]
  | | Dict.c:166 [64] bytes at [0x7fad97908630]
  | | String.c:39 [64] bytes at [0x7fad979085e0]
  | | String.c:31 [64] bytes at [0x7fad97de1da0]
  | | Dict.c:132 [72] bytes at [0x7fad97d0aca0]
  | | Dict.c:166 [64] bytes at [0x7fad97d0ac50]
  | | Dict.c:95 [56] bytes at [0x7fad97d0d500]
  | | RouterModule.c:581 [176] bytes at [0x7fad97d0ab90]
  | | Allocator.c:709 [104] bytes at [0x7fad97b092c0]
  | | String.c:39 [64] bytes at [0x7fad97dfa5e0]
  | | String.c:31 [64] bytes at [0x7fad97dfa590]
  | | Pinger.c:116 [136] bytes at [0x7fad97d108b0]
  | | Pinger.c:106 [160] bytes at [0x7fad97d10800]

Running crashey 80cb9c0 in x86_64-linux, without tun device, after two days I got:

Assertion failure [NodeStore.c:419] [(r < Node_getReach(link->parent) && r != 0)]

Used this guide to build on Debian 8: https://github.com/hyperboria/cjdns/blob/master/doc/install/windows.md

C:\>cjdroute --nobg < cjdroute.conf
1437493720 INFO cjdroute2.c:580 Cjdns i386 win32
1437493720 INFO cjdroute2.c:584 Checking for running instance...
1437493720 DEBUG UDPAddrIface.c:294 Bound to address [0.0.0.0:57532]
1437493720 DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
1437493720 DEBUG Pipe.c:134 Buffering a message
1437493720 DEBUG cjdroute2.c:629 Sent [140] bytes to core
1437493720 INFO RandomSeed.c:42 Attempting to seed random number generator
1437493720 INFO RandomSeed.c:50 Trying random seed [RtlGenRandom() (Windows)] Success
1437493720 INFO RandomSeed.c:64 Seeding random number generator succeeded with [1] sources
1437493720 INFO LibuvEntropyProvider.c:59 Taking clock samples every [1000]ms for random generator
1437493720 DEBUG 437493720 DEBUG Pipe.cC:231 ore.cPipe [\\.\pipe\cjdns_pipe_client-core-727uzv1ypnz8lyv7s4kwgvvyr4xjrm] established connection:1256 437493720 DEBUG GPipe.cetting pre-configuration from client:1253 Sending buffered message
1437493720 DEBUG Pipe.c:231 Pipe [\\.\pipe\cjdns_pipe_client-core-727uzv1ypnz8lyv7s4kwgvvyr4xjrm] established connection
1437493720 DEBUG Core.c:259 Finished getting pre-configuration from client
1437493720 DEBUG UDPAddrIface.c:255 Binding to address [127.0.0.1:11234]
1437493720 DEBUG UDPAddrIface.c:294 Bound to address [127.0.0.1:11234]
1437493720 DEBUG UDPAddrIface.c:294 Bound to address [0.0.0.0:57533]
1437493720 DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
1437493720 INFO Configurator.c:135 Checking authorized password 0.
1437493720 INFO Configurator.c:157 Adding authorized password #[0] for user [password [0]].
ОК.

1437493721 CRITICAL Configurator.c:107 Got error [Not supported on windows] calling [Security_getUser]
1437493721 CRITICAL Configurator.c:57 enable Log_LEVEL=KEYS to see message content.
1437493721 CRITICAL Configurator.c:71 Aborting.

C:\>

It'd be really nice if we could get an API call to get the public key of the node that the call is made to.

@kpcyrd commented on 25 Dec 2014

ohai,

first, I'm well aware that cjdns is a friend to friend network. Anyway, I don't think the current challenge to get into the network (asking on irc) is hard enough to keep advisories outside, but is keeping potential users and devs away who don't want to socially interact until they decided to contribute to the community.

I've seen the open nodes have been shutdown because they centralize the network, but I propose a different approach.

Implement a bootstrapping mechanism that would connect to open routers. Those routers publish their public legacy ip and announce that they accept empty connect passwords. This is done via various torrent trackers with a cjdns specific hash. The clients are then able to receive those router addresses and connect to them.

The reasons I've found to use the connect password are:

• You want to build a private network that isn't part of hyperboria
• You don't want everybody to leech your limited traffic
• Afaik the current implementation doesn't allow probing for cjdns without a valid password

The tor project has proven that there are relay operators out there who are willing to donate lots of bandwidth and don't worry about it's ip address being exposen.

This would improve cjdns speed by offering an optional two hop route that might be faster than the existing cjdns network. Also, we might bypass the blackhole routing issue that nobody is working on.

If you care about resilience or are afraid about malicious routers trying to learn your public ip, you'd create routes like we're doing now.

If you flag your router as open router you'd expect greater traffic and we have good routes for heavier cjdns usage without crunching all the cheap vpsen out there.

Both, announcing as an open router and connecting to public routers is opt-in.

We should consider to

• Adopt the open net policy
• Freeze the spec
• Check if there are major bugs and fix them
• Get an implementation packaged in distros
• Get an android app into the stores
• Get network-manager-cjdns preinstalled on distros

I think we need hyperboria too much to keep it in semi-public testing any longer. I've talked to a lot of people who didn't want to deploy it because it's too hard for the average user to take advantage of it.

@iShift commented on 2 Jan

ahh, Open Routers with auto discover and auto configuration, good old idea, but how i know @cjdelisle don't think so.

@atommixz commented on 3 Jan

I think, we can use DHT trackerless for this.

@kpcyrd commented on 3 Jan

cjd told me there's been a discussion about this on irc which I've missed. I'm currently semi available on irc since I have flaky routes to the network. Please express your opinion in here if you want me to read it. You can also email me any time if you take the the email address of any of my commits.

@iShift If I paraphrase somebody (not sure if I'm allowed to quote him on the clearnet) on irc

• hyperboria is not an anonymous network
• it's a private one
• we know who you are
• but we don't know what you're doing

It's fun to stick to the strict definition of the term darknet, but I think this is more of a burden instead of an advantage. Social interaction sucks. I think we need to cut this out. It's something the dn42 folks are doing because their technology requires it.

I am aware that we're reducing the anonymity to the level of torrents, but the pirates out there already figured out how to solve this problem.

The only reason I haven't started implementing yet, is, because this would open up the network. I'd like to have kind of a consensus decision on this. (oh, one sec, I have an idea)

@atommixz I'm currently thinking about an approach that'd link to a torrent library (without actually linking it into cjdns, completely sandboxed). Then we'd use whatever works for us.

@kpcyrd commented on 3 Jan

https://github.com/kpcyrd/consensus-cjdns-opennet

@cschmittiey commented on 3 Jan

I agree that there's a problem with getting into hyperboria. We want contributors, but the people asking for peers don't know how to contribute, and most people don't want to dive into CJDNS right off the bat, without getting a feel if the work is worth it. And let's be real, testing cjdns locally with only 2-3 peers isn't quite as exciting as Hyperboria, so it's harder to find potential contributors.

So I think this is a good push, but I also think that we still need to find a way to "know your peers." That's one of Hyperboria's redeeming qualities, is that your peers are usually your friends or acquaintances. There needs to be a better way to know your peers, especially if we're going to use empty connect passwords.

@GratefulTony commented on 3 Jan

I have been following this project for a long time, and would love to see the network grow. I agree that the current "application process" is limiting the size of the network, but it is also clear to me that the cjdns infrastructure is missing some serious functionality that precludes its use as a general-purpose network. Currently, the routing infrastructure simply doesn't provision much for dealing with abusive peers, and "punts", so to speak, the issue to social reputation. I am not currently on Hyperboria, though I was invited, because I think we shouldn't get too comfortable with the infrastructure as it exists. cjdns needs better QOS management etc. if it will ever be a real, general purpose network! I have long lobbied for bitcoin for bandwidth, or bandwidth for bandwidth to be incorporated at a low level, but I agree that cjdns is still far too "alpha" to worry about that right now... So: don't open Hyperboria until it is ready to deal with all the nasties the real internet can. $0.02

@willeponken commented on 3 Jan

• Adopt the open net policy - Should be discussed a bit more
• Freeze the spec - I'm all for this, but I suppose that was already on the roadmap
• Check if there are major bugs and fix them - Yes
• Get an implementation packaged in distros - Yes
• Get an android app into the stores - Atleast a working app with a GUI (is there any?)
• Get network-manager-cjdns preinstalled on distros - Yes

All this is in order of priority right? The last one is pretty far fetched 😉

@wfleurant commented on 4 Jan

I think this is a great idea. I am going to mark this accordingly here: https://github.com/kpcyrd/consensus-cjdns-opennet

I could not understand the 'reasons' given why this is not a great idea. Just ping this issue/question off the hypeirc chan if you would like to experience some of these opinions/philosophies for your self.

We should all be striving for an open-darknet not a closed-darknet.

Never speculate, only measure.
Measure twice, cut once.

@ansuz commented on 4 Jan

I've been working on diagnosing why we're having routing problems, and building tools in nodejs to help gather info. When we run into the black hole routing problem, we need table dumps from both concerned nodes. So far I've been limited to waiting for black holes to pop up between my own nodes, or occasionally getting a bug report from someone else.

An open net is great in principle, but at this point every unattended node on the net is just another dead end in terms of gathering information for debugging.

I'd be fine with public peers if:

• those who used them kept their nodes up to date OR
• if the public node operator had some way of dropping old nodes AND
• if those users were also able to offer table dumps or other info.

So far that hasn't been the case.

I'd be much more open to arguments premised on methods of adding/removing peers that would address these issues. Ideological arguments aren't getting us anywhere.

@wobbol commented on 5 Jan

I am with ansus on making it real easy for people to give the project debug information.
This project desperately needs "field data" feedback on very recent "dev builds"
I think the best solution would be to have each passwordless client connecting to the open nodes to the verify that they are on the most recent build then proceed with connecting to the network.

The thing that should be considered most of all IMO is getting the users of the network onboard with keeping their router software up to date
to convince the masses that it is a good idea to stay up to date the project should:

• make it easy
• make it informative(non-trivial change logs)
• provide examples and implications of not having a homogenous network(past examples, current examples, future examples)
  • These examples should not even hint at the fear mongering tactics that malware cleaners love to employ.
  • People get used to those kinds of messages (personally I uninstall software that treats me like I am 5.)

@benhylau commented on 13 Jan

@willeponken This Android app with UI is happening here WIP

Would actually like some input from everyone interested

@kpcyrd commented on 13 Jan

I'm dumping my latest ideas, you're all permitted to call me nuts:
Allow every application to manage their own peer set

A config value, on by defaults, that enables an anonymous api to add peers and remove the peers they've added. That'd be incredible useful for applications targeting end users who've never heard about peering. Or irc.

Every application is able to get the ipv4, ipv6 and cjdns ip anyway, so there's no privacy leak in this one.

I kinda think this is bad for routing, so we probably need the next one for this.
Add leaf nodes that don't participate in routing

Not every device should participate in routing. I'm not sure if this is possible, but it I think this would be good for routing and we can start pushing more traffic because everybody who can't push a lot of traffic probably shouldn't be part of a backbone anyway.
Hardcode compatible versions

Hyperboria is the test network but it's not useful for testing if everybody is running a different version. If you're running a version that is too old, you'll automatically drop out of the network.
Sacrifice pseudonymity for connectivity

Enable internet autopeering by default. A flag in --genconf disables this behavior. No more social interaction required, yey. If you prefer friend2friend pseudonymity you just enable the flag to disable this and only add peers you trust.
cjdns.js

Compile cjdns to javascript and add a websocket transport to run cjdns in the browser (Yes, I am this crazy). That'd allow tor2web-like access to cjdns networks. It's not really secure (it's not trying to be that in the first place), but it'd allow information to be free.
The vote

I'm considering forking the network but I don't think routing is going to work if you're connected to two networks bigger than your nodestore. You'd have to choose between network A and network B.

internet auto-peering and cjdns.js would be the point anybody can access hyperboria without going through the approval process. Excuse my strong opinion but do we really think our adversaries can't "I can haz peer" on irc? Unpeering doesn't work anyway. If you don't believe me, checkout how cjdns upgrade is going.

@iShift commented on 13 Jan

cjdns.js - bad idea, it is not made for that, cjdns is L2 solution

@kpcyrd commented on 13 Jan

cjdns.js would be a leaf node that doesn't do routing

@jedahan commented on 13 Jan

no harm in trying it out
i thought bittorrent in the webbrowser was c-c-c-crazy until peer5 showed up
thinking of cjdns.js at the application layer could still be useful

@iShift commented on 13 Jan

@jedahan bitorrent in webbrowser is webtorrent https://github.com/feross/webtorrent how cjdns at application layer can be useful ?

@kpcyrd commented on 13 Jan

@iShift cjdns.js is a layer2 over layer7 tunnel, kind of like UDPInterface.c is a layer2 over layer4 tunnel.

@iShift commented on 13 Jan

@kpcyrd encapsulated... so - no broadcast, no auto-zero-config...

@kpcyrd commented on 14 Jan

The public peers wiki page appeared again, so I'm taking this as a "go ahead".

I need some time to actually implement this, help appreciated.

https://github.com/kpcyrd/yrd

@iShift commented on 14 Jan

@kpcyrd what is this?

@kpcyrd commented on 14 Jan

basically cjdcmd-ng-ng. I want to add some extra stuff, like optional public peer discovery and an easier and more unified cjdns deployment.

File interface/UDPInterface_admin.c function beginConnection

} else if (Sockaddr_getFamily(&ss.addr) != Sockaddr_getFamily(ctx->udpIf->addr)) {

It cheks address family against last added UDPInterface and not the interface specified by interfaceNumber argument. When adding an IPv6 peer to an IPv6 interface it fails with "different address type than this socket is bound to." if the last added interface was IPv4, and vice versa.

Assertion failure [NodeStore.c:630] [(Node_getBestParent(node) && node != store->pub.selfNode)]

The space of IPv6 is enormous and in future many applications might require they own, unique IPv6 address. As any end user in the Internet is (in theory) going to get /64 subnet I propose that we create our own subnet protocol.

Proposition:

• size of subnet: /120: This gives 255 addresses routed to one node.
• address format: fcxx:xxxx:xxxx:xxxx:xxxx:xxxx:0000:0000
• by digging such address you are given fcxx:xxxx:xxxx:xxxx:xxxx:xxxx:0000:0000/120 subnet.
• this addresses have one out of 2^32 (4.2e+9) chance of being generated which gives about 100 days of digging to create one such address (on one 8 core i7) which is quite reasonable.

Before establishment of connection cjdns would check and if address has form fcxx:xxxx:xxxx:xxxx:xxxx:xxxx:0000:00yy it would establish connection with fcxx:xxxx:xxxx:xxxx:xxxx:xxxx:0000:0000 instead. One byte field would have to be sent (I don't know if it is possible to send it only on establishment or it needs to be every packet).

This would allow for creation of internal networks directly visible from cjdns or servicing HTTP or different without use of vhosts.

Skipping fcxx:xxxx:xxxx:xxxx:xxxx:xxxx:0000:00yy in case of key generation would also be added.

See http://buildbot.openwrt.org:8010/broken_packages/arm64/cjdns/compile.txt

I am forced to disable --march=native, as described here.

I have been asked to create an issue in this repository for further assistance.

I've compiled gcc 4.8.4 three times (successfully) now, with different compiler options and such.

Once compiling begins, it seems everything works until tests fail:

Running test Beacon_test                                                           565.667 ms
Running test CryptoAddress_test                                                    23.285 ms
Running test printIp_test                                                          8.400 ms
Running test CryptoAuth_test                                                       3885.240 ms
Running test CryptoAuth_unit_testTest failed.
Expected 0000000101641c99f7719f5780000000a693a9fd3f0e27e81ab1100b57b372594c2adca8671f1fdd050383c91e7d56ec2336c09739fa8e91d8dc5bec63e8fad07
4bee22a90642a6ba8555be84c5e35970c5270e8f31f2a5978e0fbdee454288297568f25a3fc2801aa707d954c78eccb970bcc8cb26867e9dbf0c9d6ef1b3f2724e7e550

Got 0000000101641c99f7719f5780000000a693a9fd3f0e27e81ab1100b57b372590bd0acf201041cc2050383c91e7d56ec2336c09739fa8e91d8dc5bec63e8fad07
4bee22a90642a6b8ce204a91fee8f6c2cf462b53bf74e4aa1c2b2b44a36b59a667e2a7cc4e2555b5e35e2291b81202708d475f5885d93a2ace902b988c776b5b760b612

The good news is that with my new gcc, my abiname is successfully interpreted:

System is [ppc64]
Using premade plan at [node_build/plans/ppc64_plan.json]

where it used to say ppc32.

Maybe someone with more knowledge could give me some suggestions? Thanks.

References

1. cjdelisle#763

Trying to build win32 binaries using x86_64-w64-mingw32-gcc 4.9.2 on Archlinux:

/usr/src/cjdns/node_build/builder.js:478
            if (err) { throw err; }
                             ^
Error: gcc -c -x cpp-output -o build_win32/memory_Allocator_c.o -std=c99 -Wall -Wextra -Werror -Wno-pointer-sign -pedantic -D win32=1 -Wno-unused-parameter -fomit-frame-pointer -D Log_DEBUG -g -D NumberCompress_TYPE=v3x5x8 -D Identity_CHECK=1 -D Allocator_USE_CANARIES=1 -D PARANOIA=1 -Wno-format -O3 build_win32/memory_Allocator_c.o.i

memory/Allocator.c: In function ‘Allocator__realloc’:
memory/Allocator.c:551:64: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
     if (context->rootAlloc->spaceAvailable + origLoc->pub.size < realSize) {
                                                                ^
cc1: all warnings being treated as errors

    at error (/usr/src/cjdns/node_build/builder.js:52:15)
    at /usr/src/cjdns/node_build/builder.js:115:22
    at /usr/src/cjdns/node_build/builder.js:85:13
    at ChildProcess.<anonymous> (/usr/src/cjdns/node_build/Semaphore.js:7:30)
    at ChildProcess.emit (events.js:110:17)
    at maybeClose (child_process.js:1015:16)
    at Socket.<anonymous> (child_process.js:1183:11)
    at Socket.emit (events.js:107:17)
    at Pipe.close (net.js:485:12)

real    1m22.580s
user    3m1.400s
sys 0m14.507s

I started playing around with the admin interface, which I haven't done in a while, and I found I could trigger crashes by calling certain functions.

[ansuz@blackbox tools]$ ./cexec "RouterModule_getPeers('0000.0000.0000.0001',10000,'0000.0000.0000.0001')"
/home/ansuz/code/cjdns/tools/cexec:35
        if (err) { throw err; }
                         ^
Error: timeout after 10000ms
    at null._onTimeout (/home/ansuz/code/cjdns/contrib/nodejs/cjdnsadmin/cjdnsadmin.js:27:18)
    at Timer.listOnTimeout (timers.js:110:15)

In addition to the timeout error, I get this assertion failure.

Assertion failure [RouterModule.c:557] [(addr->path != 1)]

I'm going to keep on looking into this, and try out the other functions in RouterModule, but maybe other people can look into it as well.