go-stun
go-stun copied to clipboard
ccding
Doesn't work with some servers
For example google ones:
stun.l.google.com:19302 stun1.l.google.com:19302 stun2.l.google.com:19302 stun3.l.google.com:19302 stun4.l.google.com:19302
Test1 fails with "No changed address." error. Any idea what could be wrong?
I'm still getting the error "Server error: no changed address." using the google servers.
EDIT: Google servers seem to have changed their port. But when using Port 19305 the returned *Host is nil.
@xiang90
My Code:
func minimalExample() { stunClient := stun.NewClient() stunClient.SetServerHost("stun1.l.google.com", 19305) _, host, err := stunClient.Discover()
if err != nil {
log.Println(err)
return
}
if host == nil {
log.Println("no host")
return
}
}
Output is: 2016/08/20 22:33:27 no host
I think there is a bug in the Google servers. In test2, we send a request to the server with flag of changing IP and port. But the received packet is from the original IP and port (not changed).
Let me know if you think it is not Google servers' bug and have any hints to me. Thanks.
Sorry I messed up this bug with another one. Please ignore the above comment. See below:
In the test1 response from Google servers, it doesn't provide a changedAddr attribute, which is required by RFC3489. I think this is a bug in Google servers. I think the previous fix is incorrect.
@ccding @xiang90
I tried to debug this a bit more. Now I think 19302 seems to be the correct port for googles stun servers. Requests to 19305 don't give any response in wireshark:
So it's even stranger the lib doesn't return an error but a nil host.
Requests to 19302 do get a response from google:
Output of my testing code is in that case:
2016/08/21 20:39:26 Server error: no changed address.
What I meant was that, the response doesn't include a CHANGED-ADDRESS field, which is required by RFC (see https://tools.ietf.org/html/rfc3489#section-11.2.3)
Actually I was looking for a stun library working with in-the-wild-servers, even if they don't respect the RFC ;-)
If a server doesn't follow RFC, how can I understand its response given the fact that the server itself doesn't provide any documentation? I'd suggest you to use this server stun.ekiga.net:3478
The reason RFC requires this filed is that we need this CHANGED-ADDRESS field to perform the next step test. If it doesn't exist, I cannot perform the next step. Therefore I have to report an error.
@ccding @chrikoch I think we want to accept the patch if it makes go-stun more adoptive to the wild. However, the patch itself needs to be well documented and isolated to make it clear that it exists for the purpose of one wild deployed service.
@chrikoch Do you want to help on this? Thank you!
It cannot be more adoptive to the wild.
-
There is another bug in google servers: in test2, when I request to change IP and port, the server doesn't change it. If I don't report error in CHANGED-ADDRESS, the error of not changing IP and port will be reported later.
-
If the NAT is not sym. UPD firewall or open Internet, by RFC, I have to perform another test: send packet to the CHANGED-ADDRESS specified in test1. Given the CHANGED-ADDRESS is not specified in test1, I don't know where to send the packet. The CHANGED-ADDRESS error will be reported anyway.
I don't think there is a bug in the google servers. Obviously they're using STUN from RFC 5389, which obsoletes RFC 3489 (which seems to be implemented in go-stun). The CHANGED-ADDRESS was removed from STUN:
"[...] CHANGED-ADDRESS, that have been removed from this specification"
See: https://tools.ietf.org/html/rfc5389#section-12
Perhaps this is the wrong issue, but when I run the tool behind a mobile network I always hit the Server error: response IP/port errors. I've tried many servers, and ones that work behind normal home networks.
@ccding do you know where in the spec the fact that it returns from a diff ip/port that it invalidates the algo?
