NewSTUNConn() doesn't work with UDP net.Conn

[cacggghp]

Your environment.

v4.1.4

What did you do?

conn := net.Dial("udp", turnaddr)
turnConn := turn.NewSTUNConn(conn)

What did you expect?

Connection being able to send and recieve STUN packets

What happened?

Recieving packets doesn't work

[JoTurk]

@cacggghp hello 👋 can you share more details? test environment? how did you test it?

[cacggghp]

@cacggghp hello 👋 can you share more details? test environment? how did you test it?

Like here: https://github.com/pion/turn/blob/master/examples/turn-client/udp/main.go but using net.Dial and turn.NewSTUNConn instead of net.ListenPacket

[JoTurk]

@cacggghp oh, it makes sense, NewSTUNConn expects a stream transport (TCP/TLS/DTLS). I patched the example a bit to show how you can use it with custom dial (DialUDP because we need a packetConn).

What is your use case anyway?

udp-client-dial.patch

[cacggghp]

@JoTurk I just have a flag to choose between tcp and udp, and I thought net.Dial would work for both. You probably should write in description of NewSTUNConn that it expects a stream. By the way, STUN is a datagram protocol, why would the parsing function break on udp? Aren't STUN messages independent of each other?

I'm making a dtls encrypted TURN vpn.

[JoTurk]

NewSTUNConn takes a net.Conn and re-expose it as a PakcetConn, by framing STUN messages with a length header, this is used for transports with no datagram boundaries. it's unnecessary for UDP and it will cause many problems with handling of address-ports.
And it's described here https://pkg.go.dev/github.com/pion/turn/v4#STUNConn

We're doing v5 soon. Maybe we should make this more explicit, clear?

CC: @Sean-Der @rg0now