Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
x/net/websocket: can't connect to WS server on ARM (raspberry pi), test passes #5812
I wrote a small HTML5 chat you can find under https://github.com/ProjectU2672/recyclingDepot/tree/7d5edc76955115b9fffcb4204c1a2a31a7ed2329 , backed by go and your websocket package. It works perfectly on my amd64 machine, but if I open http://raspberry-host:12345, the chat won't connect over websocket, while the actual HTTP connection works. go test code.google.com/p/go.net/websocket passes in 0.5 sec. What steps will reproduce the problem? 1. on a Raspberry Pi running arch linux ARM and the latest go version, run git clone https://github.com/ProjectU2672/recyclingDepot.git && cd recyclingDepot && git checkout 7d5edc7 2. go run wsecho.go 3. point your browser to the Pi on port 12345 What is the expected output? A chat connecting over websocket What do you see instead? A chat failing to connect over websocket Which compiler are you using (5g, 6g, 8g, gccgo)? 5g Which operating system are you using? Arch Linux ARM Which version are you using? (run 'go version') go version go1.1.1 linux/arm Please provide any additional information below. On the raspberry pi "go test code.google.com/p/go.net/websocket" passes in 0.5 sec.
You have a garbage in your js code: var ws = new WebSocket(location.href.replace(/^http/, "ws").replace(/\/*$/, "/echo"))//, ["proto1", "proto2"]); I would recommend, first ask such questions in the ML. https://groups.google.com/forum/#!forum/golang-nuts
The error handling in that sample is all messed up. There are several cases where the error is handled, then execution continues with incorrect data. I suggest that the reason behaviour differs between your arm and amd64 hosts is related to the different networking configuration. I'd like to suggest that you move this discussion to the mailing list. If a bug is discovered then we can open a new issue for it when a better test case is available.
Status changed to WaitingForReply.