Patchwork listens on IPv6 but advertises IPv4 address

[PragmaticCypher]

On a dual stack network, Patchwork seems to be listening on [::]:8008 but advertises on the IPv4 stack instead.

System: Slackware64 14.2

[christianbundy]

Sorry this is causing trouble for you, networking can be a pain.

Could you run the latest commit from master and post the config that's being output to the console? It should give us more details about the network

[PragmaticCypher]

{
  "path": "[private]",
  "party": true,
  "timeout": 0,
  "pub": true,
  "local": true,
  "friends": {
    "dunbar": 150,
    "hops": 2
  },
  "gossip": {
    "connections": 3,
    "autoPopulate": false
  },
  "connections": {
    "outgoing": {
      "net": [
        {
          "transform": "shs"
        }
      ]
    },
    "incoming": {
      "net": [
        {
          "host": "::",
          "port": 8008,
          "scope": [
            "device",
            "local",
            "public"
          ],
          "transform": "shs"
        }
      ],
      "ws": [
        {
          "host": "::",
          "port": 8989,
          "scope": [
            "device",
            "local",
            "public"
          ],
          "transform": "shs"
        }
      ],
      "unix": [
        {
          "scope": "device",
          "transform": "noauth"
        }
      ]
    }
  },
  "timers": {
    "connection": 0,
    "reconnect": 5000,
    "ping": 300000,
    "handshake": 5000
  },
  "caps": {
    "shs": "[private]",
    "sign": null
  },
  "master": [],
  "logging": {
    "level": "notice"
  },
  "port": 8008,
  "blobsPort": 8989,
  "server": true,
  "_": [],
  "host": "::",
  "ws": {
    "host": "::",
    "port": 8989,
    "scope": [
      "device",
      "local",
      "public"
    ],
    "transform": "shs"
  },
  "keys": {
    "curve": "ed25519",
    "public": "[private]",
    "private": null,
    "id": "[private]"
  },
  "remote": "[private]"
}

[cryptix]

my patchbay from master also does this so i guess the issue lies more in the direction of multiserver/getAddress? the src ip address of the broadcast packets is the ipv4 one it is listening on btw.

[christianbundy]

Maybe relevant: I have a PR open that would have us explicitly bind to each address, which reduces the amount of multiserver/getAddress magic: ssbc/multiserver#42.

Also relevant: a PR to switch us back to IPv4 by default: ssbc/ssb-config#47.

[christianbundy]

I've pushed a new branch to Patchwork called use-ipv4 that uses the code from this PR, any chance it resolves this issue?

[PragmaticCypher]

Hi @christianbundy, this seems to work 👍. However there is another port being listened on by the app on [::]:8989 which is inconsistent with what's being done here.

bash-4.3$ netstat -ltp
...
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 *:8008                  *:*                     LISTEN      3214/default_app.as
tcp6       0      0 [::]:8989               [::]:*                  LISTEN      3214/default_app.as

[cryptix]

8989 is the default for ssb-ws

[christianbundy]

@PragmaticCypher Thanks for that! I was able to reproduce the issue locally and merged a fix into multiserver 3.3.2. Here's what I'm seeing now:

$ netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8989            0.0.0.0:*               LISTEN      20289/default_app.a 
tcp        0      0 127.0.0.1:7718          0.0.0.0:*               LISTEN      20313/node          
tcp        0      0 0.0.0.0:8008            0.0.0.0:*               LISTEN      20289/default_app.a 

Once this PR is merged the problem should be resolved. 👍

[PragmaticCypher]

I was patching Patchwork v3.11.6 with these changes, and npm is notifying me there's 3 high vulnerabilites. Should this be a concern?

[christianbundy]

I'm not sure, could you run npm audit and open an issue if they seem like a problem? My main priority is getting a new release from master, I haven't touched the v3.11 branch at all.

[brasilikum]

I seem to have the exact opposite problem.

See also here: https://gitlab.com/staltz/manyverse/issues/374

This is the output of Wireshark.

0000   ff ff ff ff ff ff 6c 40 08 a0 04 54 08 00 45 00   ......l@...T..E.
0010   00 6f c8 c9 00 00 40 11 f1 00 c0 a8 00 0c ff ff   .o....@.........
0020   ff ff 1f 48 1f 48 00 5b b6 0b 6e 65 74 3a 66 65   ...H.H.[..net:fe
0030   38 30 3a 3a 31 63 34 62 3a 39 39 36 31 3a 63 65   80::1c4b:9961:ce
0040   36 62 3a 64 30 62 36 3a 38 30 30 38 7e 73 68 73   6b:d0b6:8008~shs
0050   3a 43 45 49 78 4d 2f 72 6a 6f 39 6b 4b 59 54 75   :CEIxM/rjo9kKYTu
0060   6e 42 54 7a 5a 47 38 2f 53 56 34 39 64 47 4d 37   nBTzZG8/SV49dGM7
0070   4d 63 43 46 47 35 4e 5a 6d 38 30 49 3d            McCFG5NZm80I=

I tried to start ssb-server start --host [my-ipv4-addreess] but it does not seem to have any effect.
It seems my router is advertising ipv6 but Manyverse does not seem to work with it.

[christianbundy]

Which version of Patchwork? If possible, it would be helpful if you could verify whether this is a problem in master (or the latest prerelease). Thanks for your help debugging!

[PragmaticCypher]

It may be easier to use netcat to check the advertisements ;)

ncat -u -l -p 8008

or

nc -u -l -p 8008

[brasilikum]

@christianbundy On the contrary, I have to thank you for working on this great project!

I was on the latest version. I built from master and the problem seems to persist.

@PragmaticCypher I have nc installed on mac but I cannot seem to get it to work. Wireshark might be overpowered but it works ;-)

[christianbundy]

@brasilikum

Re-reading your comment, I think you'll need to edit ~/.ssb/config to set your host. Check out the ssb-config documentation, I think you'll add a host property so that your config file looks something like:

{ 
  "incoming": {
    "net": [{ "scope": "device", "transform": "noauth", "port": 8009, "host": "your-ipv4-host-here" }]
  },
  "outgoing": {
    "net": [{ "transform": "shs" }]
  }
}

If that doesn't work, please create an issue in either the ssb-server or ssb-config repos. Good luck!

[christianbundy]

To be explicit: I think the --host option is deprecated and may work differently than expected. Patchwork should output some logs to the terminal with your config options, so it would be great to include that if you create a bug report.

[brasilikum]

Ok, so running master with the following config:

  1 {
  2   "incoming": {
  3     "net": [{ "scope": "device", "transform": "noauth", "port": 8009, "host": "192.168.99.181" }]
  4   },
  5   "outgoing": {
  6     "net": [{ "transform": "shs" }]
  7   },
  8   "plugins": {
  9     "ssb-device-address": true,
 10     "ssb-identities": true,
 11     "ssb-peer-invites": true
 12   },
 13   "host": "192.168.99.181"
 14 }

returns the following output:

     }
    ]
  },
  "outgoing": {
    "net": [
      {
        "transform": "shs"
      }
    ]
  },
  "plugins": {
    "ssb-device-address": true,
    "ssb-identities": true,
    "ssb-peer-invites": true
  },
  "host": "192.168.99.181",
  "_": [],
  "configs": [
    "/Users/georg/.ssb/config"
  ],
  "config": "/Users/georg/.ssb/config",
  "ws": {
    "host": "192.168.99.181",
    "port": 8989,
    "scope": [
      "device",
      "local",
      "public"
    ],
    "transform": "shs"
  },
  "keys": {
    "curve": "ed25519",
    "public": "CEIxM/rjo9kKYTunBTzZG8/SV49dGM7McCFG5NZm80I=.ed25519",
    "private": null,
    "id": "@CEIxM/rjo9kKYTunBTzZG8/SV49dGM7McCFG5NZm80I=.ed25519"
  },
  "remote": "unix:/Users/georg/.ssb/socket:~noauth:CEIxM/rjo9kKYTunBTzZG8/SV49dGM7McCFG5NZm80I="
}

Wireshark tells me the multicasts have not changed.

[christianbundy]

Oops, it looks like I forgot to add connections as a top-level property and I copied the wrong config. Try this instead:

{
  "connections": {
    "incoming": {
      "net": [{ "port": 8008, "scope": "public", "transform": "shs", "host": "192.168.99.181" }]
    },
    "outgoing": {
      "net": [{ "transform": "shs" }]
    }
  },
  "plugins": {
    "ssb-device-address": true,
    "ssb-identities": true,
    "ssb-peer-invites": true
  },
  "host": "192.168.99.181"
}

If that doesn't work, please create an issue in either the ssb-server or ssb-config repos.

[brasilikum]

Ok, thanks for the effort anyway, I will open the issue on those repos.

[brasilikum]

It works for me on the latest master without any config file

[christianbundy]

Woop! This should be resolved by ssbc/multiserver#48, here's what I'm seeing in master:

net:192.168.0.109:8008~shs:+oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=
net:fce2:9811:4862:81a7:bb08:91d6:2e41:d220:8008~shs:+oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=
ws://192.168.0.109:8989~shs:+oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=
ws://[fce2:9811:4862:81a7:bb08:91d6:2e41:d220]:8989~shs:+oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=

Please let me know if you still have any issues!