-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building and running on Raspberry Pi #27
Comments
What's the output of |
Thank Tim,
|
Not sure why you're seeing that error, but Go 1.7 is a few versions behind. It might be worthwhile to upgrade to Go 1.10 and then try to build grumble. |
Cancel last! Was running with Anyway, install out put gave this, is this a fail or information warnings: go get mumble.info/grumble/cmd/grumble mumble.info/grumble/cmd/grumble../pi/gocode/src/mumble.info/grumble/cmd/grumble/server.go:1457: unknown http.Server field 'IdleTimeout' in struct literal Thanks for your quick help! |
Those errors are related to the Go version. Upgrade to 1.10 and they should go away. |
OK, will try that. Installing Go on the Pi is a pain!! |
Awesome, perfect install. For anyone else going down this route, here are the instructions for GoLang 1.10 on Pi (lifted from elsewhere on Git) To install golang 1.10 (or whatever the latest version is at the time anyone is reading this):
Run Now, excuse my blatant lack of knowledge, but what next? Does this sit on top of a mumble-server install or instead? I’ve just removed a working mumble and hope for grumble to take its place! UPDATE: Following reboot, setup GOPATH Then run the following line: CD in to GOPATH/src/mumble.info/grumble/cmd/grumble and make any config changes you need before building the program: And check
|
The latter; grumble is a separate, standalone Mumble server. After starting grumble, you should be able to connect to your Pi from your Mumble client. |
I thought so... That’s it!? So simple... Where is the configuration to add my password and define port etc? |
Configuration is currently unmerged in PR #26. In the mean time, you can manually apply that patch to your local copy to enable configuration. |
Wow, look like you guys have done a lot of work, and I’ve got a lot of learning to do! I wish someone had travelled this path before me (and documented it along the way!) How do i start Grumble? |
Thanks for being a trailblazer. After building grumble ( |
Thanks - I’m getting there... but you’re definitely right about the arguments!! `go run grumble.go --help command-line-arguments./grumble.go:25:5: undefined: Args |
The You should also use |
Yep, Does |
if you passed |
Yes, did that. Can see the binary, but Worth noting |
Those errors are what I was alluding to earlier: you'll have to pass some arguments to |
Ok! Got the help text. Is there anywhere I can write this all up for the next Pi guy? |
I'd just leave it in a comment in this thread. We should hopefully get some official docs together in the future. |
Ok, well I’d be happy to help! So here’s where I’m at:
How can I set my IP or, more ideally, domain name |
You can either:
|
Ok, 26 sounds like more flexibility in the long run, but i don’t know how to merge the files in #26. I can look through the source files and find where to set the IP. |
Tried to merge the file changes on local machine and rebuild, once I fixed all my typos I’m still getting errors about a missing ini package “gopkg.in/ini.v1" from the new file_ini.go file . Do I need a template configuration in .ini format? |
The config support adds a new external dependency, so you may have to |
Thanks, I think I’ll keep an eye on the config support and d/l when it’s part of the git proper. |
The reason the default webport is 443 is because that will be required for the planned Let's Encrypt support. Websockets works fine on any port otherwise. Setting the config key The default host should work fine in most cases but if you need to set it it's the config key |
On Linux you can only bind to port 443 (really, allow ports <= 1024) as root -- unless you set a capability on the binary. See for example: Personally, I like this method: |
That looks pretty advanced. 443 isnt that much of an issue to me as I can reallocate the email port, and I’m not really sure it’s a problem. Got the script to recognise my IP now, but still have a permission denied message ( Update, 443 was in use by Apache2. Changed to 442 and rebuilt, and now: |
Hi All,
|
I don't quite understand. There should be no need to convert the generated certificate, or import it into the client - it is meant for the server. You can't disable TLS, but nothing says the certificate needs to be trusted by the client (neither the ordinary Mumble protocol on 64738 nor Websockets require this), so the generated certificates should work fine. Sorry for the vague answer. If you post the exact steps you are taking, I could probably give you a more concrete suggestion. |
hi, thanks for reply. |
The client wizard configures the user certificate. Could you please post the exact error message from the client and any relevant logs (if they exist) from Grumble? |
Ok, thinking it through, I may be launching grumble and not telling about the certificate with the correct flags! My bad. Will test later |
So the mumble client running on another Pi does now connect. Still no luck from iOS - Getting a connection refused message. Is there a Grumble log that might shed more light on this? The server running on 127.0.0.1 can still be reached externally with port forwarding cant it? I’ve not changed any port forwarding settings as it worked fine with the mumble server and we are using the same port?.. |
If you bind to 127.0.0.1 it is only accessible on the loopback interface locally. (It's strange that it is accessible from another Pi.) You have to bind to 0.0.0.0 to listen on all interfaces, which should be reachable externally with port forwarding as usual. Regarding the need to surpress certificates, maybe the mismatch from the old server certificate caused a security error on the client? I know too little about the mumble client to answer this one. |
That makes sense, I’ve gone back to 0.0.0.0 and can now accept connections internally and externally, so that’s great! Regarding the websockets, has anyone written a client to view the information that is sent from the Grumble Server via WS? I manipulated an existing page, but stuck with an ‘Error during websockets handshake: ERR_INVALID_HTTP_RESPONSE message. I think this is the last piece of the puzzle for me! Thanks again for all your help so far, I hope this helps other Pi users out! |
ERR_INVALID_HTTP_RESPONSE usually indicates you haven't attempted the TLS handshake first – make sure you use the wss:// scheme and not ws:// when connecting. (If you're trying this in a browser, you should receive a 400 bad request when connecting via https - that means the TLS layer is working.) These kinds of errors should generate Grumble log messages however. I don't know of any easy way to dump the traffic, but once the handshakes are done it's just WS messages containing the binary Mumble protocol. |
Ok, changing to wss:// changes the error code to ERR_INSECURE_RESPONSE in the browser console. Do you know what Grumble typically sends out over websockets? |
ERR_INSECURE_RESPONSE means the browser doesn't trust the certificate. Since you're using the autogenerated cert, you have to either import the server cert in the browser to make it trusted (complicated, but permanent) or connect over https in the browser window to show Chromes exception ui (fast, but temporary). I don't understand what you mean by "typically". The websocket messages only wrap the mumble protocol just like the one used over port 64738, nothing more. Grumble doesn't support any sort of RPC yet. If you want to speak the protocol in a browser I'd suggest a library like mumble-client together with mumble-client-websocket (an example built with those is mumble-web). |
I’ll look in to that Chromium on Pi seems that little bit more complicated than everything else! So, with the WebSockets, literally the only reason I’m interested is to see if I can send a message from the server to my mumble clients when a user is transmitting. I hope to display the user ID of the mumble session transmitting on all the other clients. I appreciate this may require a change to the underlying code. I’m starting to think it might be easier to change the underlying to code to simply write to a log instead, whenever anyone transmits, and use something like WebsocketD to send out the messages whilst parsing the log. I’m not looking to build a mumble web client or anything like that.... Hopefully something much simpler! |
I imported the cert and set the websocket JavaScript to connect to How can I edit the binary code to identify the user that is transmitting and send that either over websockets or to log? |
Sending extra data over WS requires substantial modifications, as it shares the ordinary mumble protocol implementation. In essence, a WS connection is equivalent to an ordinary user connecting with an ordinary mumble client -- using it for RPC-like tasks is probably more trouble than it's worth. (Unfortunately, Grumble has no RPC support at this moment.) AFAIK, the Mumble protocol has no "talking" state and the server doesn't keep track of this anyway. (Unless you try to build a hack around requesting idle time or something like that, I guess...) The hacky way closest to what you are describing would be to log the user id for every voice packet received by the server in the udp loops. I guess it would work but you would need to communicate this (quite spammy) info over some other channel. The proper way to solve this is probably modifying your client to expose the talking/silent state based on voice packets being received or not, just like the "standard" Mumble client. That should be compatible with any server speaking the Mumble protocol. |
Hey, thanks for the reply. I guess I’m trying to use the WS for something way outside what it was designed for. Fortunately my client is a GoLang implementation and does already log when the PTT is hit. I didn’t follow this up previously as I’d thought running WS on each client to tell the server something it already knows seemed an untidy way of achieving what i wanted. However, as WS is two way, I guess it’s not actually that bad! I’ll leave the server alone for now and see what can be done from the client...Thanks for all the support here, really good of you guys |
I have grumble working on a RaspberryPi3 with LetsEncrype certificates in conjunction with mumble-web, which ran on a different machine. Being new to golang, I tried to document my efforts to get this going in a somewhat hackish way: a) install golang
b) build grumble This should be working now, but we will recompile later in (g)
c) create the data directory
d) edit args.go I hardcoded the datadir to '/home/pi/.grumble' here, since it's not configurable. This may not be needed, but I wanted to start the server with sudo, which would change home to root, so that was one easy way. Also, comment out the other lines, or go will complain about unused variables and not compile. e) edit server.go Hardcode the port here. I chose 9444, and you need to open this port in your router (and maybe also 64738 to connect with a client). f) copy the keys. This could probably done in a more elegant way, but I sudo copied the keys to the .grumble directory according to this information. If you don't do this, mumble-web/Chrome will not be able to connect to grumbles web sockets.
Change MYDOMAIN to your letsencrypt domain name. Note that the clients will be able to connect, but will complain about the certificate. Maybe it would have been better to hardcode the paths to the keys in the the letsencrypt folder, I didn't try this (yet EDIT: tried it, same result). g) build You should be able to connect to yourdomain.com with a mumble client and to yourdomain.com:9444 with mumble-web. |
Hi, trying to get Grumble up and running on the Pi so I can leverage the websockets functionality.
The install
go get mumble.info/grumble/cmd/grumble
Fails on a $GOPATH not set error, even when $GOPATH is explicitly set before hand and can be seen ingo env
Could someone let me know what I’ve missed?
The text was updated successfully, but these errors were encountered: