broken pipe in linux?

[jbenet]

Hello! I'm considering using natty (and maybe waddell) in ipfs, which could probably be great for both projects. AFAIAC, NAT traversal using chromium's implementations is likely to be the best way going forward. And thanks for putting so much work into this!

---

Anyway, first problem. In OSX, I'm able to traverse to find my own machine, which is nice, but when I go to test nat traversal with a linux box it doesn't work.

When linux (no nat) is the server, and osx (behind nat) attempts to connect, it spits out:

// in linux (no nat)
> go run nw.go
waddell server: 162.243.[redacted]
nattywad: Waddell address changed
nattywad: Connected to Waddell!! Id is: 7266cbe8-b88e-4486-8de4-88ab4ece5cd0
nattywad: Unable to answer traversal 1298498081: write |1: broken pipe
nattywad: Unable to answer traversal 1298498081: write |1: broken pipe

// in osx (behind nat)
> go run nw.go 7266cbe8-b88e-4486-8de4-88ab4ece5cd0
waddell server: 162.243.[redacted]
attempting to connect to: 7266cbe8-b88e-4486-8de4-88ab4ece5cd0
nattywad: Configuring nat traversal client with 1 server peers
nattywad: Attempting traversal to 7266cbe8-b88e-4486-8de4-88ab4ece5cd0
nattywad: Connected to Waddell!! Id is: 128d9dd6-d162-459e-918b-5a4293597ffb

When trying to connect from linux to anything (either osx behind a nat, or another process in the same linux machine), nothing happens, it just times out. (i'll look deeper and see if your libs have logging I can turn on, but so far I think linux doesn't work yet -- i recall reading that somewhere...)

You can see my awful toy example to try and connect: https://gist.github.com/jbenet/632d9459414b996e9457

[oxtoacart]

Try setting the environment variable TRACE=true before running.

[jbenet]

Ah, great. So the webrtc code complained about packages-- seems like natty requires:

libnss3
libpulse-dev
libasound2

After installing these packages it works perfectly! ❤️ Thanks @oxtoacart and rest of @getlantern team -- this is great work!

Now, those packages, aside from libnss3, they seem to be webrtc A/V specific. It would be great not to have to depend on them (ipfs -- and i would guess lantern too -- will need to be small enough to ship as a binary + work on embedded devices).

[jbenet]

And, the script I posted works as an example on various machines. Try it out: https://gist.github.com/jbenet/632d9459414b996e9457

// launch waddell + set waddellAddr in nw.go 
// (I'll write a simpler example for you later with this as a param)
> waddell

> go run nw.go
waddell server: <waddellAddr>
nattywad: Waddell address changed
nattywad: Connected to Waddell!! Id is: 64f979a4-9acd-4b8b-9d37-bea055a4245a

// in another terminal run another instance with the server's id as a param
> go run nw.go 64f979a4-9acd-4b8b-9d37-bea055a4245a
waddell server: <waddellAddr>
attempting to connect to: 64f979a4-9acd-4b8b-9d37-bea055a4245a
nattywad: Configuring nat traversal client with 1 server peers
nattywad: Attempting traversal to 64f979a4-9acd-4b8b-9d37-bea055a4245a
nattywad: Connected to Waddell!! Id is: 7ced5bbf-0359-434a-b693-594e54892749
Traversal Succeeded: &{|64f979a4-9acd-4b8b-9d37-bea055a4245a %!s(bool=true) %!s(bool=true)  1.354291478s}
Peer Country: %!s(<nil>)
Peer ID: 64f979a4-9acd-4b8b-9d37-bea055a4245a
client connected 104.236.32.22:50855 to 67.180.23.75:53527

// now you can type in both terminals like in netcat (enter sends)

I'll give you a cleaner waddell-netcat later.

[jbenet]

Here-- this may help future users: https://github.com/jbenet/go-netcatnat/

[myleshorton]

Ha! Sweet. Thanks @jbenet

[atavism]

Thanks, @jbenet! Awesome to see the project you've already put together that uses natty! Our next step is to actually remove the unnecessary dependencies you mentioned, which should result in the final binary size being significantly smaller.

[oxtoacart]

Very cool! I might be inclined to hold off on the announcement until we've put the beta flashlight out with natty, seen how it does and worked out any major bugs that come up. I don't think it has to be perfect before we announce, but I think it could stand to have some more testing first.

[teamlantern]

Yeah I think that makes sense to hold off for a second to harden it a bit,
but overall looking great.

Seems like we're pretty much ready to build this huh? I guess the build
process itself will need to copy over the executables, although maybe
they're all embedded with byteexec is that right?

On Thu, Nov 6, 2014 at 12:30 PM, oxtoacart notifications@github.com wrote:

Very cool! I might be inclined to hold off on the announcement until we've
put the beta flashlight out with natty, seen how it does and worked out any
major bugs that come up. I don't think it has to be perfect before we
announce, but I think it could stand to have some more testing first.

—
Reply to this email directly or view it on GitHub
#1 (comment).

President
Brave New Software Project, Inc.
https://www.getlantern.org
pgp A998 2B6E EF1C 373E 723F A813 045D A255 901A FD89

[jbenet]

Hey @oxtoacart @atavism @teamlantern @myleshorton -- we (ipfs team, cc @whyrusleeping) can probably help with some stuff. Things like removing extraneous webrtc a/v, reducing binary size, adding arm arch, etc. Probably not right now, but over coming weeks. Feel free to come hang out at freenode/#ipfs and discuss.

(also, very close to natty: jbenet/random-ideas#13)

[jbenet]

(and, not sure if you're doing this now, but whatever you embed and byteexec should definitely include a digital signature that's verified before executing. otherwise it's an easy to exploit vector)

[whyrusleeping]

I would love to work on writing code to replace the binary hulk of code. Has any work been done towards that end?

[atavism]

Thanks, guys! Right now, as you probably noticed, natty requires a full WebRTC checkout. This was done so that we're always able to build against the latest release, specifically the most recent version that appears in chromium. This is why we're using depot_tools, and specifically ninja, in the natty build process. Obviously, this increases the complexity and inflates the size of the resultant binaries, but it keeps us synchronized. That said, @whyrusleeping, yeah--I've done a bit to strip out the dependencies and simplify the build process. Mostly it's all about removing the audio and video libs as you surmised. I'm going to publish an updated README soon with details. Our initial goal was just to get natty working on every platform. Have you guys done a lot of work with WebRTC? Would definitely love to hear what you've been working on, any pointers you have, and possible collaboration. Feel free to shoot us an e-mail at bns-ops@googlegroups.com to chat more about it?

[oxtoacart]

@myleshorton I still need to finish the work on enabling/disabling stat reporting per the user's preference, but after that we could do a build (probably late tomorrow morning). I don't think the installer needs to do anything to copy executables, byteexec should just take care of that (unless the flashlight process wouldn't have permissions to write to the AppData/equivalent folders, which I don't think is an issue).

[jbenet]

@atavism great -- do you guys do irc (freenode/#ipfs) or +hangouts? we could discuss more realtime.

[oxtoacart]

I think a more realtime discussion would be great! We're in the middle of preparing our first release of flashlight and Lantern that uses natty, but that'll hopefully be out the door tomorrow. If all goes well, perhaps we can shoot for talking sometime late next week?

[jbenet]

Sure, sounds great. Will ping in a few days. Good luck! keep up the good work