devguardio / carrier Goto Github PK

Hello!

First off, let me say that this product is super simple and super dope. My home machine is behind a double NAT scenario and this is a fantastic solution for SSH that doesn't involve me going through a whole thing to call my ISP and setup a static IP and all that jazz.

Secondly, I'm getting an error that says "access denied: no certs left" when I try to connect from one machine to another. I'm unsure of how figure this out. I was able to connect from my first machine to itself. Any help is much appreciated!

someone putting their public into secret ="" is getting a generic InvalidAddress message that is not helpful.
throw an error instead that says its an invalid type of address

Hello.
I was trying to follow the example from https://devguard.io/intro.html
but got the following panic:

INFO 2018-11-13T20:00:40Z: carrier: established broker route 0x4e12935ce87ac6ec with oWGPeq8Bvq8XN4wudejQFpddzMvHZr9xb8QWT6WaDc9L53d
 INFO 2018-11-13T20:00:40Z: carrier::channel: settled peering with adress 34.241.72.31:8223
 INFO 2018-11-13T20:00:42Z: carrier::publisher: connect request from oWWyDvP1AxdsYuTrWZoNXY7Ehy4mYdnTeTLasspCVCmtaB1 :: [Path { ipaddr: "172.18.0.1:56273", category: Local }, Path { ipaddr: "[fe80::42:a3ff:fe5e:23e9]:56273", category: Local }, Path { ipaddr: "172.17.0.1:56273", category: Local }, Path { ipaddr: "[fe80::42:86ff:fe58:89b1]:56273", category: Local }, Path { ipaddr: "[fe80::6cf4:e7ff:fee9:43e5]:56273", category: Local }, Path { ipaddr: "10.242.9.1:56273", category: Local }, Path { ipaddr: "[fe80::f8b6:ffff:feac:273]:56273", category: Local }, Path { ipaddr: "[fe80::6854:14ff:fecf:244d]:56273", category: Local }, Path { ipaddr: "172.21.0.1:56273", category: Local }, Path { ipaddr: "[fe80::2cf8:d4ff:fe65:cdcf]:56273", category: Local }, Path { ipaddr: "[fe80::24de:87ff:fe13:4d39]:56273", category: Local }, Path { ipaddr: "10.241.1.1:56273", category: Local }, Path { ipaddr: "[fe80::bc58:daff:fef0:c4cf]:56273", category: Local }, Path { ipaddr: "[fe80::5cf9:2dff:fe48:c054]:56273", category: Local }, Path { ipaddr: "37.187.124.71:56273", category: Local }, Path { ipaddr: "[2001:41d0:a:f547::1]:56273", category: Local }, Path { ipaddr: "[fe80::222:4dff:feae:174c]:56273", category: Local }, Path { ipaddr: "172.20.0.1:56273", category: Local }, Path { ipaddr: "[fe80::b897:7dff:fe71:fb00]:56273", category: Local }, Path { ipaddr: "37.187.124.71:56273", category: Internet }] 
 INFO 2018-11-13T20:00:42Z: carrier: peer has subscribed oWkQJto5XTQrFBQCokyz8YEfnb7HRCAzCuykUdDiBBRfABV
thread 'tokio-runtime-worker-2' panicked at 'message too big 1738', core/src/transport.rs:420:9
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
 WARN 2018-11-13T20:00:55Z: carrier_core::transport: [p2p oWWyDvP1AxdsYuTrWZoNXY7Ehy4mYdnTeTLasspCVCmtaB1:5204393606951294032] connection is unrecoverable
 WARN 2018-11-13T20:00:55Z: carrier_core::transport: [p2p oWWyDvP1AxdsYuTrWZoNXY7Ehy4mYdnTeTLasspCVCmtaB1:5204393606951294032] connection is unrecoverable
 INFO 2018-11-13T20:00:55Z: carrier::channel: [p2p oWWyDvP1AxdsYuTrWZoNXY7Ehy4mYdnTeTLasspCVCmtaB1:5204393606951294032] received disconnect

This error happens on the machine that runs the axiom when I execute the command carrier shell <identity> on the other machine.

The logs of the other machine is this:

 carrier shell <identity>
 INFO 2018-11-13T20:00:43Z: carrier: established broker route 0x5b8f50357793e544 with oWGPeq8Bvq8XN4wudejQFpddzMvHZr9xb8QWT6WaDc9L53d
 INFO 2018-11-13T20:00:43Z: carrier::channel: settled peering with adress 34.241.72.31:8223
ERROR 2018-11-13T20:01:06Z: carrier: connect RPC ended before receiving any headers

Am I missing something ? I'm using carrier v0.6

Hello,
while building the Rust-High-Level-Api with cargo following error shows up:
error[E0061]: this function takes 4 arguments but 3 arguments were supplied
--> src/error.rs:26:17
|
26 | err::to_str(self.as_mut_ptr(), s.as_mut_ptr(), s.len());
| ^^^^^^^^^^^ ----------------- -------------- ------- supplied 3 arguments
| |
| expected 4 arguments

error: aborting due to previous error; 6 warnings emitted

I fixed it by replacing the line with the following
err::to_str(self.as_mut_ptr(), self.0.len(), s.as_mut_ptr(), s.len()); since i guessed it needs the pointer and the len of the internal byte vector.

Related question: Is the Rust-Api up to date and are there any instructions on how to use it?

there's a design flaw that if the first connect response is lost, the parties do not agree on connection state. the responder will reject any handshake because it assumes it's a DUP , but the initiator cannot distinguish receive loss from transmit loss and will just keep spamming handshakes.

we should probably spam HS even faster and reset the state inbetween attempts. Current rtt assumptions are very conservative, so we can fit several resets in the same timeout window

while i personally think exit is the correct recovery strategy, some users have a more specific systemd config with restart delay.

They might also treat a non zero exit as error that raises alerts.

Mid term we should probably do teardown/restart inside conduit.
Long term we should actually be able to recover from broker loss (for example in scaling event) without tearing down p2p connections.

request to open source devguard ring。

1. instructions for conduit are unclear. customer copied the [publish] section including the header, instead of creating a [subscribe] section. that is because http://book.devguard.io/quickstart/shadows.html doesnt mention [subscribe] at all

2. when doing that, conduit will respawn threads in a loop with no indication of whats wrong

Hey it's me again,
while testing the previous ticket, I found a bug in the documentation on https://devguard.io/intro.html. It's only marginal but might confuse new users.
After starting up the axiom service (should I call it service?) with the blue shadow address and the green identity in accept, I go to a different machine and should use the green identity.
In fact, I should go to the green-identity-machine and connect to my thing by entering its identity.

Maybe you can color-code the $ signs as well, to show on which machine we should run the commands.
Again, thx for color-coding the identities and shadow addresses.

Hi,

while trying to update openwrt firmware over ota, I getting the following error:

[WRN] carrier::pq BUG: bucket 21 has f->typ == 0
[WRN] carrier::pq BUG: bucket 22 has f->typ == 0
[WRN] carrier::pq BUG: bucket 23 has f->typ == 0
[WRN] carrier::pq BUG: bucket 24 has f->typ == 0
[WRN] carrier::pq BUG: bucket 25 has f->typ == 0
[WRN] carrier::pq BUG: bucket 26 has f->typ == 0
[WRN] carrier::pq BUG: bucket 27 has f->typ == 0
[WRN] carrier::pq BUG: bucket 28 has f->typ == 0
[ERR] carrier::channel [11123959467116558162] connection is dead
[WRN] carrier::connect connect closed
channel.go:185: unexpected unlink
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x4713f3a]

runtime stack:
runtime.throw(0x4a024a5, 0x2a)
/usr/local/Cellar/go/1.15.7_1/libexec/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
/usr/local/Cellar/go/1.15.7_1/libexec/src/runtime/signal_unix.go:726 +0x48c

goroutine 1 [syscall]:
runtime.cgocall(0x470e990, 0xc00095da68, 0x0)
/usr/local/Cellar/go/1.15.7_1/libexec/src/runtime/cgocall.go:133 +0x5b fp=0xc00095da38 sp=0xc00095da00 pc=0x40078fb
github.com/devguardio/carrier/go._Cfunc_io_write_bytes(0x0, 0x10008200, 0xc000836a38, 0xc000836a50, 0x0)
_cgo_gotypes.go:2694 +0x4d fp=0xc00095da68 sp=0xc00095da38 pc=0x4108c8d
github.com/devguardio/carrier/go.(*Endpoint).Wakeup.func1(0xc000853d40, 0xc000011d20, 0xc000836a38, 0x2, 0x2, 0xc000836a50, 0x40dc3a0)
/Users/runner/work/carrier/carrier/go/endpoint.go:216 +0x91 fp=0xc00095dab0 sp=0xc00095da68 pc=0x4119751
github.com/devguardio/carrier/go.(*Endpoint).Wakeup(0xc000853d40, 0x0, 0x0)
/Users/runner/work/carrier/carrier/go/endpoint.go:216 +0xea fp=0xc00095db20 sp=0xc00095dab0 pc=0x4110e0a
github.com/devguardio/carrier/go.(*Stream).SendRaw(0xc00091c3f0, 0xc0008cf000, 0x1f4, 0x1f4, 0x1f4, 0x0)
/Users/runner/work/carrier/carrier/go/channel.go:379 +0x48 fp=0xc00095dbd0 sp=0xc00095db20 pc=0x410e5a8
github.com/devguardio/carrier/cli/src.init.3.func2(0xc00091a840, 0xc00091c360, 0x3, 0x3)
/Users/runner/work/carrier/carrier/cli/src/sft.go:152 +0x885 fp=0xc00095dd90 sp=0xc00095dbd0 pc=0x470a085
github.com/spf13/cobra.(*Command).execute(0xc00091a840, 0xc00091c2d0, 0x3, 0x3, 0xc00091a840, 0xc00091c2d0)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:854 +0x2c2 fp=0xc00095de68 sp=0xc00095dd90 pc=0x41effa2
github.com/spf13/cobra.(*Command).ExecuteC(0x4f9a480, 0xc00081ff60, 0x1, 0x1)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:958 +0x375 fp=0xc00095df40 sp=0xc00095de68 pc=0x41f0cd5
github.com/spf13/cobra.(*Command).Execute(...)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:895
github.com/devguardio/carrier/cli/src.Main()
/Users/runner/work/carrier/carrier/cli/src/main.go:48 +0x171 fp=0xc00095df78 sp=0xc00095df40 pc=0x4705151
main.main()
/Users/runner/work/carrier/carrier/cli/main.go:10 +0x25 fp=0xc00095df88 sp=0xc00095df78 pc=0x470dac5
runtime.main()
/usr/local/Cellar/go/1.15.7_1/libexec/src/runtime/proc.go:204 +0x209 fp=0xc00095dfe0 sp=0xc00095df88 pc=0x403bdc9
runtime.goexit()
/usr/local/Cellar/go/1.15.7_1/libexec/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc00095dfe8 sp=0xc00095dfe0 pc=0x406e901

goroutine 22 [chan receive]:
github.com/devguardio/carrier/go.(*Channel).ded(0xc00086e560)
/Users/runner/work/carrier/carrier/go/channel.go:56 +0x52
github.com/devguardio/carrier/go.Connect.func3.1(0xc000853d40, 0xc00086e560)
/Users/runner/work/carrier/carrier/go/channel.go:145 +0x4b
github.com/devguardio/carrier/go.Connect.func3(0xc000853d40, 0xc00086e560, 0xc000010800)
/Users/runner/work/carrier/carrier/go/channel.go:186 +0x419
created by github.com/devguardio/carrier/go.Connect
/Users/runner/work/carrier/carrier/go/channel.go:140 +0x52c

goroutine 24 [select]:
github.com/cheggaaa/pb/v3.(*ProgressBar).writer(0xc000932000, 0xc00003c8a0)
/Users/runner/go/pkg/mod/github.com/cheggaaa/pb/[email protected]/pb.go:173 +0xc5
created by github.com/cheggaaa/pb/v3.(*ProgressBar).Start
/Users/runner/go/pkg/mod/github.com/cheggaaa/pb/[email protected]/pb.go:167 +0x1e8

Related question: Is there a limitation on the file size, or am I missing something? Transferring small files (few kb) with " carrier fs push [flags]" works.

Thanks in advance.

that would really help with our daily struggle in the terminal

when an identity is accidentally reused for multiple conduits, the conduit subscribe threads will exit and respawn without any error message, leaving the user guessing what happened.

"stupid file transfer" push is really not complete without its stupid brother pull, is it?
Would be helpful for a lot of things.

• push, ota and shell should return non-zero on failure
• shell should allow executing a remote command directly, similar to ssh

Hey,
I just pulled the armv7hf from the releases page and ran it, but it crashed with an "Segmentation fault". There were no other messages.

Can you add some instructions on compiling it on your own (even if it is no fun on a slow Raspi)?
Thx

I just tried the carrier on my laptop via a mobile internet connection. During the very simple first tests (http://book.devguard.io/quickstart/discovery.html) the carrier 0.10.1-9-g537d710-dirty-DlRJeeQ44h itself reports a "BUG". ;)

Terminal 1:
'''
$ carrier publish
[INFO carrier::endpoint] carrier identity: oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5 version: 0.10.1-9-g537d710-dirty-DlRJeeQ44h
[INFO carrier::endpoint] attempting udp connection with 5.9.122.66:8443
[INFO carrier::endpoint] attempting udp connection with 5.9.156.3:8443
[INFO carrier::endpoint] attempting udp connection with 88.198.32.218:8443
[INFO carrier::endpoint] established connection with broker oWSs6CqSoPT8nU9QUiMC1L6n88h8sxFJG2iYn13qs45Hvfd
[INFO carrier::endpoint] pubres: [:status = 200, ]
[INFO carrier::publisher] incomming oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5
[INFO carrier::publisher::shell] shell stream constructed
[ERROR carrier::publisher::shell] EIO: I/O error
[INFO carrier::publisher::shell] shell stream deconstructed
[WARN carrier::channel] BUG outqueue_bytes is less than the frame we just dequeued
[WARN carrier::channel] [8600874234052071436::oWSs6CqSoPT8nU9QUiMC1L6n88h8sxFJG2iYn13qs45Hvfd] retransmission timeout (retransmit 1 frames, in flight: 0) at 145497
[WARN carrier::channel] [oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5::1321139338533813004] retransmission timeout (retransmit 1 frames, in flight: 0) at 93500
[WARN carrier::channel] [oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5::1321139338533813004] retransmission timeout (retransmit 1 frames, in flight: 0) at 93900
[WARN carrier::channel] [oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5::1321139338533813004] retransmission timeout (retransmit 1 frames, in flight: 0) at 94701
[INFO carrier::publisher] incomming oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5
[WARN carrier::channel] [oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5::1321139338533813004] retransmission timeout (retransmit 1 frames, in flight: 0) at 96301
[WARN carrier::channel] BUG outqueue_bytes is less than the frame we just dequeued
[WARN carrier::channel] [oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5::1321139338533813004] retransmission timeout (retransmit 1 frames, in flight: 0) at 99504
[WARN carrier::channel] [oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5::1321139338533813004] connection is unrecoverable
[WARN carrier::channel] BUG outqueue_bytes is less than the frame we just dequeued
'''

Terminal 2:
'''
$ carrier discovery oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5
[INFO carrier::endpoint] carrier identity: oXFGmSydejDvvMJkp1XZQrE1781b9r9CWJdus2e1i4ysjm5 version: 0.10.1-9-g537d710-dirty-DlRJeeQ44h
[INFO carrier::endpoint] attempting udp connection with 88.198.32.218:8443
[INFO carrier::endpoint] attempting udp connection with 5.9.156.3:8443
[INFO carrier::endpoint] attempting udp connection with 5.9.122.66:8443
[INFO carrier::endpoint] attempting tcp connection with 88.198.32.218:123
[INFO carrier::endpoint] established connection with broker oWSs6CqSoPT8nU9QUiMC1L6n88h8sxFJG2iYn13qs45Hvfd
[:status = 200, ]
DiscoveryResponse {
carrier_revision: 82,
carrier_build_id: "0.10.1-9-g537d710-dirty-DlRJeeQ44h",
application: "carrier-cli",
application_version: "0.10.1-9-g537d710-dirty-DlRJeeQ44h",
paths: [
"/v0/shell",
"/v0/tcp",
"/v2/carrier.sysinfo.v1/sysinfo",
"/v0/sft",
],
}
'''

the current sharding algorithm has no concept of geolocation.
If two peers in the US or Asia need a proxy, we still route them through FRA

• require shadow on connect, so we can move entire shadows to regions atomically without requiring cross-region pubsub broadcast.
• shadows need to be staked, and one of the properties of the stake can be a region.

#8