1251214 - R_WOULDBLOCK can cause STUN client failure in nr_stun_client_send_request

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect)

Description

[Byron Campen [:bwc]]

Any failure in the call to nr_socket_sendto (including R_WOULDBLOCK) causes permanent failure in the STUN ctx. I'm pretty sure this is not what we want.

Comment 1

[Byron Campen [:bwc]]

Attachment: MozReview Request: Bug 1251214: Ignore R_WOULDBLOCK in nr_stun_client_send_request

Review commit: https://reviewboard.mozilla.org/r/36647/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/36647/

Comment 2

[Eric Rescorla (:ekr)]

Comment on attachment 8723639 [details]
MozReview Request: Bug 1251214: Ignore R_WOULDBLOCK in nr_stun_client_send_request

https://reviewboard.mozilla.org/r/36647/#review33267

::: media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.c:387
(Diff revision 1)
> -    if(r=nr_socket_sendto(ctx->sock, ctx->request->buffer, ctx->request->length, 0, &ctx->peer_addr))
> +    if(r=nr_socket_sendto(ctx->sock, ctx->request->buffer, ctx->request->length, 0, &ctx->peer_addr)) {
> +      if (r != R_WOULDBLOCK) {
> -      ABORT(r);
> +        ABORT(r);
> +      }
> +      r_log(NR_LOG_STUN,LOG_WARNING,"STUN-CLIENT(%s): nr_socket_sendto blocked, treating as dropped packet",ctx->label);
> +    }
>  

Yes this seems fine. Though note that UDP sockets don't block so this was reasonable behavior pre-TCP

Comment 3

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fa9d263db1dc

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fa9d263db1dc