zerotier transport via ad-hoch networks

[0-8-15]

NNG & Platform details.

nng master a of Feb. 14th

Expected Behavior

Join zerotier ad-hoc and complete req/rep example from manual page.

Actual Behavior

The connecting side runs into timeout.

Steps to Reproduce

$ nngcat -v --zt-home zt-f19c5682ee --listen zt://*.ff1d131d13000000:7443 --rep --data 42 --quoted

$ nngcat  -v --connect zt://f19c5682ee.ff1d131d13000000:7443  --req --data pardon --quoted

[gdamore]

I haven't tested ZT in quite a long time. I believe the ZeroTier folks have substantially changed their product, and perhaps also the protocol, such that I'm no longer certain that the product works as it did originally. I'll have to invest cycles to research.

ZT was a commercially sponsored effort, and the commercial sponsor for that is no longer directly sponsoring my work on it -- which is part of why it's fallen by the wayside.

[janjaapbos]

Last time I checked ZT worked ok, a couple of weeks ago. You will probably need the open pull request for zt transport.

On Sun, 1 Mar 2020, 21:27 gdamore, notifications@github.com wrote:

I haven't tested ZT in quite a long time. I believe the ZeroTier folks have substantially changed their product, and perhaps also the protocol, such that I'm no longer certain that the product works as it did originally. I'll have to invest cycles to research.

ZT was a commercially sponsored effort, and the commercial sponsor for that is no longer directly sponsoring my work on it -- which is part of why it's fallen by the wayside.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nanomsg/nng/issues/1214?email_source=notifications&email_token=AAQEQCCTC2JCZVSTKN7ZZ33RFLALXA5CNFSM4K7F4352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNJ4FI#issuecomment-593141269, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQEQCCUWWHMTNMR4KSEHALRFLALXANCNFSM4K7F435Q .

[janjaapbos]

Actually, the pull request should not be needed for the transport to work. It just adds extra functionality.

The issue is that ad-hoc networks do not allow the ethernet frame type used by the nng zerotier transport.

See from the ZeroTier manual: Ad-hoc networks are public (no access control) networks that have no network controller. Instead their configuration and other credentials are generated locally. Ad-hoc networks permit only IPv6 UDP and TCP unicast traffic (no multicast or broadcast) using 6plane format NDP-emulated IPv6 addresses. In addition an ad-hoc network ID encodes an IP port range. UDP packets and TCP SYN (connection open) packets are only allowed to desintation ports within the encoded range.

[janjaapbos]

So the zerotier network rule should e.g. include: accept ethertype 0x0901;

This cannot be done for ad-hoc networks.

[janjaapbos]

I verified this works. The zerotier network rules are:

drop not ethertype 0x0901 ; accept;

[0-8-15]

On Sun, 01 Mar 2020 14:50:25 -0800 janjaapbos notifications@github.com wrote:

Last time I checked ZT worked ok, a couple of weeks ago. You will probably need the open pull request for zt transport.

I would do so, if I have a patch to submit.

Right now need help to locate the issue.

Things work with the network in tests/zt.c and fail for Ad-Hoc networks.

On Sun, 1 Mar 2020, 21:27 gdamore, notifications@github.com wrote:

I haven't tested ZT in quite a long time. I believe the ZeroTier folks have substantially changed their product, and perhaps also the protocol, such that I'm no longer certain that the product works as it did originally. I'll have to invest cycles to research.

Looks like recent ZT might give licensing issues.

The ZT people seem to be busy porting everything to Go. Likely they will never return to the C++ thingy. Much in contrast to the nng code base, I found zerotier code rather incomprehensible.

Thus ZT is probably stable now. So to speak. ;-)

Maybe it's worth to go back before the license change, fork it and fix things ourself. Avoiding the license issue.

ZT was a commercially sponsored effort, and the commercial sponsor for that is no longer directly sponsoring my work on it -- which is part of why it's fallen by the wayside.

I understand. However right now, ZT gets two things done I need:

• address management: route traffic to public keys.
• penetrate NATs

There is little I need from zerotier: just route one single port. Preferably P2P. Hence my focus on ad-hoc networks.

Maybe there is a better solution for my usecase?

Otherwise - no matter how slow it is - I'd see ZT support as big plus for nng. (In fact libzt not working was, what brought me to try nng.)

[0-8-15]

@janjaapbos wrote:

I verified this works. The zerotier network rules are: #

Allow only NNG Ethernet frames.

# drop not ethertype 0x0901 ;

Accept anything else. This is required since default is 'drop'.

accept;

I struggle to understand your comments.

Are you efficiently saying, that you know how to "patch" either nanomsg_nng or zerotier to make some kind of connection work? (Just for testing/verification.)

Or is this

So the zerotier network rule should e.g. include: accept ethertype 0x0901;

This cannot be done for ad-hoc networks.

saying "choose one: either nng or ad-hoc networks".

As I'm looking at the issue at hand, I could live -- at least for now/development -- with an approach looking like an ad-hoc network transmitting/expecting (/to_be_patched/) ethernet frames or something like that.

[janjaapbos]

See my earlier response:

The issue is that ad-hoc networks do not allow the ethernet frame type used by the nng zerotier transport.

See from the ZeroTier manual: Ad-hoc networks are public (no access control) networks that have no network controller. Instead their configuration and other credentials are generated locally. Ad-hoc networks permit only IPv6 UDP and TCP unicast traffic (no multicast or broadcast) using 6plane format NDP-emulated IPv6 addresses. In addition an ad-hoc network ID encodes an IP port range. UDP packets and TCP SYN (connection open) packets are only allowed to desintation ports within the encoded range.

[gdamore]

I think the only way to fix this is to move to using 6PLANE packets instead. That will be a rewrite of the transport.