RAET is not IPv6 friendly

[sjorge]

Description of Issue/Question

While debugging for another issue I tried RAET but it fails very early on due to me having IPv6: True in my master and minion config.

Traceback (most recent call last):
  File "/opt/salt/bin/salt-master", line 25, in <module>
    salt_master()
  File "/opt/salt/lib/python2.7/site-packages/salt/scripts.py", line 47, in salt_master
    master.start()
  File "/opt/salt/lib/python2.7/site-packages/salt/cli/daemons.py", line 207, in start
    self.master.start()
  File "/opt/salt/lib/python2.7/site-packages/salt/daemons/flo/__init__.py", line 100, in start
    consolepath=consolepath,
  File "/opt/salt/lib/python2.7/site-packages/ioflo/app/run.py", line 138, in run
    skedder.run()
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/skedding.py", line 273, in run
    status = tasker.runner.send(tasker.desire)
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/framing.py", line 630, in makeRunner
    self.enterAll() #activates, resets .done state also .desire may change here
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/framing.py", line 411, in enterAll
    self.enter(self.actives)
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/framing.py", line 423, in enter
    frame.enter()
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/framing.py", line 1244, in enter
    act() #call entryAction
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/acting.py", line 99, in __call__
    return (self.actor(**self.parms))
  File "/opt/salt/lib/python2.7/site-packages/ioflo/base/acting.py", line 526, in __call__
    return self.action(**kwa)
  File "/opt/salt/lib/python2.7/site-packages/salt/daemons/flo/core.py", line 315, in action
    bufcnt=bufcnt)
  File "/opt/salt/lib/python2.7/site-packages/raet/road/stacking.py", line 140, in __init__
    prikey=prikey, )
  File "/opt/salt/lib/python2.7/site-packages/raet/road/estating.py", line 195, in __init__
    super(LocalEstate, self).__init__( **kwa)
  File "/opt/salt/lib/python2.7/site-packages/raet/road/estating.py", line 61, in __init__
    host = socket.gethostbyname(host)
socket.gaierror: [Errno 7] no address for the specified node name

The value of host (after more debugging) is '::' so the IPv6 equivalent of 0.0.0.0, but socket.gethostbyname is not IPv6 ready unless you set it up to be so.

Setup

Any working setup with IPv6 enabled.

Steps to Reproduce Issue

I hit this using salt so probably the easiest to reproduce it that way: Setup salt-master and salt-minion, switch to IPv6 and check it still works with ZeroMQ over IPv6. Then switch to RAET.

Versions Report

Salt Version:
           Salt: 2016.3.0rc1-112-g1af2e41

Dependency Versions:
         Jinja2: 2.8
       M2Crypto: 0.22
           Mako: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.4.1
         Python: 2.7.11 (default, Mar 18 2016, 13:38:08)
           RAET: 0.6.5
        Tornado: 4.3
            ZMQ: 4.1.3
           cffi: Not Installed
       cherrypy: 3.8.0
       dateutil: 2.4.0
          gitdb: 0.6.4
      gitpython: 1.0.2
          ioflo: 1.5.1
        libgit2: Not Installed
        libnacl: 1.4.4
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: 2.0.2
          smmap: 0.9.0
        timelib: 0.2.4

System Versions:
           dist:
        machine: i86pc
        release: 5.11
         system: SunOS
        version: Not Installed

[SmithSamuelM]

We need to use socket.getaddrinfo(host, port, family=0, type=0, proto=0, flags=0) for IPV6 hosts and then parse out the host address from the returned list. Thanks for the bug notice.

[evelineraine]

I have salt master crashing under the same conditions.

Stack trace is identical, but the error is different: socket.gaierror: [Errno -9] Address family for hostname not supported

Versions:

Salt Version:
           Salt: 2016.3.2

Dependency Versions:
          ioflo: 1.5.5
         Jinja2: 2.8
        libnacl: 1.4.5
       pycrypto: 2.6.1
         Python: 2.7.11 (default, Jul  8 2016, 19:56:24)
         PyYAML: 3.11
          PyZMQ: 15.4.0
           RAET: 0.6.5
        Tornado: 4.4.1
            ZMQ: 4.1.5

System Versions:
           dist: fedora 23 Twenty Three
        machine: armv7l
        release: 4.4.15-400.19cf227.bcm2709.fc23.armv7hl
         system: Linux
        version: FedBerry 23 Twenty Three

[kyrias]

Any ETA on this?

[revellion]

Any activity?

[sjorge]

When I was building 2016.11.0 for SmartOS I give this another go, with the same result. So I don't think anything changed.

[revellion]

I just hit this issue today when evaluating RAET in my lab which is IPv6 enabled. And it seems the issue still exists as you said @sjorge

So for IPv6 ZeroMQ is still preferred above RAET for now i guess?.

[kyrias]

Essentially, RAET is dead and the TCP transport is the future.

[SmithSamuelM]

Submitted pull request with fix. Please verify.

7a2b6fd923ced621ea46b18b98d126d55d760053 aaa0c5f4b811cc6c9a13c44fe6dde8755b619ee1

[SmithSamuelM]

https://github.com/saltstack/raet/pull/76

[SmithSamuelM]

kyrias

If TCP was the future Google wouldn't be trying to replace it with QUIC, a UDP protocol. https://www.chromium.org/quic

Also

Heres a good explanation of why UDP can be much better than TCP

https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/#comment-41520

RAET is mature and in two years has uncovered a handful of bugs. This one being one of those. :(

[geotom]

SmithSamuelM

I am planning to use raet in my own private project. I really wonder about the status of the project after reading comments like "Essentially, RAET is dead". Is this just a laconic comment of a dissapointed user or is raet a thing of the past? Would be nice to hear more about its future or a roadmap...

[SmithSamuelM]

It is definitely not dead. IPV6 support was recently added. RAET is being actively used in the Sovrin.org open identity system and is also used in SaltStack. RAET is a stable production protocol so does not need to be updated on a regular basis. While there are some features we would like to add there have not been any compelling use cases to add them. The IPV6 support was the only significant bug fix needed.

[SmithSamuelM]

Because I am no longer at SaltStack, I do not maintain or commit issues. You might have to bug the SaltStack people to clean up the issue list.

[sjorge]

Oops I totally missed this, I should probably look into this again.

Getting a different error now:

[ERROR   ] An un-handled exception was caught by salt's global exception handler:
AttributeError: 'module' object has no attribute 'AsyncRAETPubChannel'
Traceback (most recent call last):
  File "/opt/local/bin/salt-call", line 11, in <module>
    salt_call()
  File "/opt/local/lib/python2.7/site-packages/salt/scripts.py", line 379, in salt_call
    client.run()
  File "/opt/local/lib/python2.7/site-packages/salt/cli/call.py", line 48, in run
    caller = salt.cli.caller.Caller.factory(self.config)
  File "/opt/local/lib/python2.7/site-packages/salt/cli/caller.py", line 81, in factory
    return RAETCaller(opts, **kwargs)
  File "/opt/local/lib/python2.7/site-packages/salt/cli/caller.py", line 340, in __init__
    super(RAETCaller, self).__init__(opts)
  File "/opt/local/lib/python2.7/site-packages/salt/cli/caller.py", line 102, in __init__
    self.minion = salt.minion.SMinion(opts)
  File "/opt/local/lib/python2.7/site-packages/salt/minion.py", line 666, in __init__
    lambda: self.eval_master(self.opts, failed=True)
  File "/opt/local/lib/python2.7/site-packages/tornado/ioloop.py", line 453, in run_sync
    return future_cell[0].result()
  File "/opt/local/lib/python2.7/site-packages/tornado/concurrent.py", line 232, in result
    raise_exc_info(self._exc_info)
  File "/opt/local/lib/python2.7/site-packages/tornado/gen.py", line 282, in wrapper
    yielded = next(result)
  File "/opt/local/lib/python2.7/site-packages/salt/minion.py", line 634, in eval_master
    pub_channel = salt.transport.client.AsyncPubChannel.factory(self.opts, **factory_kwargs)
  File "/opt/local/lib/python2.7/site-packages/salt/transport/client.py", line 171, in factory
    return salt.transport.raet.AsyncRAETPubChannel(opts, **kwargs)
AttributeError: 'module' object has no attribute 'AsyncRAETPubChannel'
Traceback (most recent call last):
  File "/opt/local/bin/salt-call", line 11, in <module>
    salt_call()
  File "/opt/local/lib/python2.7/site-packages/salt/scripts.py", line 379, in salt_call
    client.run()
  File "/opt/local/lib/python2.7/site-packages/salt/cli/call.py", line 48, in run
    caller = salt.cli.caller.Caller.factory(self.config)
  File "/opt/local/lib/python2.7/site-packages/salt/cli/caller.py", line 81, in factory
    return RAETCaller(opts, **kwargs)
  File "/opt/local/lib/python2.7/site-packages/salt/cli/caller.py", line 340, in __init__
    super(RAETCaller, self).__init__(opts)
  File "/opt/local/lib/python2.7/site-packages/salt/cli/caller.py", line 102, in __init__
    self.minion = salt.minion.SMinion(opts)
  File "/opt/local/lib/python2.7/site-packages/salt/minion.py", line 666, in __init__
    lambda: self.eval_master(self.opts, failed=True)
  File "/opt/local/lib/python2.7/site-packages/tornado/ioloop.py", line 453, in run_sync
    return future_cell[0].result()
  File "/opt/local/lib/python2.7/site-packages/tornado/concurrent.py", line 232, in result
    raise_exc_info(self._exc_info)
  File "/opt/local/lib/python2.7/site-packages/tornado/gen.py", line 282, in wrapper
    yielded = next(result)
  File "/opt/local/lib/python2.7/site-packages/salt/minion.py", line 634, in eval_master
    pub_channel = salt.transport.client.AsyncPubChannel.factory(self.opts, **factory_kwargs)
  File "/opt/local/lib/python2.7/site-packages/salt/transport/client.py", line 171, in factory
    return salt.transport.raet.AsyncRAETPubChannel(opts, **kwargs)
AttributeError: 'module' object has no attribute 'AsyncRAETPubChannel'
[cronos :: sjorge][/salt/config]
[!]$ pip list
[cronos :: sjorge][/salt/config]
[!]$ salt --versions-report
Salt Version:
           Salt: 2016.11.4

Dependency Versions:
           cffi: 1.9.1
       cherrypy: unknown
       dateutil: 2.5.3
      docker-py: Not Installed
          gitdb: 2.0.0
      gitpython: 2.1.1
          ioflo: 1.6.7
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: 1.5.0
       M2Crypto: 0.22
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.12 (default, Dec 31 2016, 10:50:46)
   python-gnupg: 2.2.0
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: 0.6.6
          smmap: 0.9.0
        timelib: 0.2.4
        Tornado: 4.3
            ZMQ: 4.1.4

System Versions:
           dist:
        machine: i86pc
        release: 5.11
         system: SunOS
        version: Not Installed```

This is with transport set to raet and ipv6 to true.

[geotom]

SmithSamuelM

Thanks for your feedback! I will have a look into raet as I like it from what I read so far. Is there any good starting point beside the few examples that are shipped with? Sovrinn seems to be based on Plenum, but so far after a very short look I haven't found any RAET code beside comments and lines like this: "Not needed in ZStack, remove once raet is removed".

[SmithSamuelM]

Plenum just imports RAET so there is no RAET code. Sovrin is building agent services that are HTTPS based. At one time they looked at using RAET but decided to go HTTPS for their agent services. Frankly RAET worked enabled them to get up and running quickly but they want to build web based services so they are planning on some NodeJs stuff. Its still not clear. Anyway if you like Python and want something that works and has the scalability of UDP the RAET is a good choice. If like most people you see the world through TCP/IP eyes then RAET is not such a good choice.

[geotom]

For me its not so much about UDP or TCP and scalability at the moment, but I like the signed messages via libsodium and the architecture so far laid out in the documentation (road, lanes, estates) which seems to fit my (still) rather small project. I have found plenty of other frameworks and its hard to decide - I search for something lightweight, with a strong security builtin (no TLS/SSH as extra layer) and targeting a similar architecture with several nodes with local event buses/workers for subtasks.

[SmithSamuelM]

What many do not appreciate is how hard it is to get the initial key exchange correct without exposing security flaws. Many just punt. RAET is carefully designed from that respect with a modular key exchange protocol that extends CurveCP to support Peer-to-peer networks not just client-server. Its one of those gotchas that gets overlooked when people are selecting protocols and despite my best efforts, is usually not considered as important, until someone finds out they have to reinvent the wheel when they select a protocol that does not do the key exchange well. Ed22519 keys use a Diffie-Hellman key exchange. So we made it so one could Join that way. While Curve-cp exchanges encryption keys. RAET also exchanges the signing keys and by default signs everything. Sign after encrypt for ultimate security.

[kyrias]

@wandth Missed your comment until now, but it wasn't really a "laconic comment of a disappointed user", it was just me being aware of the fact that Salt was planning on deprecating RAET even back then and not really having any plans on working on it, and they've now finally announced the actual deprecation of RAET in Salt, and it will be removed in Neon.

[geotom]

Thx for the update @kyrias! I'm too slowly moving on with my own playground projects and REAT still is something I wanted to look into. Unfortunately it seems rather unused at nowadays, which is not a good sign in my eyes. Nevertheless I haven't found a similar protocol with the same things advertised, so I wonder what ultimately lead for instance at Saltstack to drop it, or what are the alternatives (Beside Node.js or any other web communication). I thought 0MQ caused certain reliability problems in high load scenarios, so why an alternative isn't needed any more?

I'm still a bit confused and probably will abstract the messaging in my project so I could substitute REAT with 0MQ or something else in the future.

[revellion]

Isn't TCP transport supposed to be the replacement?

Den lör 7 apr. 2018 11:10Thomas Wanderer notifications@github.com skrev:

Thx for the update @kyrias https://github.com/kyrias! I'm too slowly moving on with my own playground projects and REAT still is something I wanted to look into. Unfortunately it seems rather unused at nowadays, which is not a good sign in my eyes. Nevertheless I haven't found a similar protocol with the same things advertised, so I wonder what ultimately lead for instance at Saltstack to drop it, or what are the alternatives (Beside Node.js or any other web communication). I thought 0MQ caused certain reliability problems in high load scenarios, so why an alternative isn't needed any more?

I'm still a bit confused and probably will abstract the messaging in my project so I could substitute REAT with 0MQ or something else in the future.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/saltstack/raet/issues/74#issuecomment-379454993, or mute the thread https://github.com/notifications/unsubscribe-auth/ALekUlGtKBYFO3wNo3Mz7-tePFAIIAaBks5tmIJugaJpZM4H5Am3 .

[geotom]

Ok, just saw. So simple msgpack via TCP sockets. Would love to hear more if there is any future of REAT or who actually still uses it + shared experience.

[SmithSamuelM]

This should be closed as RAET supports IPV6