Bug 888274. Emit RFC5389 STUN. Accept MAPPED-ADDRESS in response regardless of what we send. r=abr

This commit is contained in:
EKR 2013-06-28 07:58:37 -07:00
parent 29dbd867f2
commit 7064953c2e
3 changed files with 20 additions and 7 deletions

View File

@ -551,7 +551,7 @@ static void nr_ice_srvrflx_start_stun_timer_cb(NR_SOCKET s, int how, void *cb_ar
/* TODO: if the response is a BINDING-ERROR-RESPONSE, then restart
* TODO: using NR_STUN_CLIENT_MODE_BINDING_REQUEST because the
* TODO: server may not have understood the 0.96-style request */
if(r=nr_stun_client_start(cand->u.srvrflx.stun, NR_STUN_CLIENT_MODE_BINDING_REQUEST_STUND_0_96, nr_ice_srvrflx_stun_finished_cb, cand))
if(r=nr_stun_client_start(cand->u.srvrflx.stun, NR_STUN_CLIENT_MODE_BINDING_REQUEST_NO_AUTH, nr_ice_srvrflx_stun_finished_cb, cand))
ABORT(r);
if(r=nr_ice_ctx_remember_id(cand->ctx, cand->u.srvrflx.stun->request))
@ -656,7 +656,7 @@ static void nr_ice_srvrflx_stun_finished_cb(NR_SOCKET sock, int how, void *cb_ar
/* OK, we should have a mapped address */
case NR_STUN_CLIENT_STATE_DONE:
/* Copy the address */
nr_transport_addr_copy(&cand->addr, &cand->u.srvrflx.stun->results.stun_binding_response_stund_0_96.mapped_addr);
nr_transport_addr_copy(&cand->addr, &cand->u.srvrflx.stun->results.stun_binding_response.mapped_addr);
nr_stun_client_ctx_destroy(&cand->u.srvrflx.stun);
cand->state=NR_ICE_CAND_STATE_INITIALIZED;
/* Execute the ready callback */

View File

@ -573,8 +573,15 @@ int nr_stun_client_process_response(nr_stun_client_ctx *ctx, UCHAR *msg, int len
break;
case NR_STUN_CLIENT_MODE_BINDING_REQUEST_NO_AUTH:
if (! nr_stun_message_has_attribute(ctx->response, NR_STUN_ATTR_XOR_MAPPED_ADDRESS, 0))
ABORT(R_BAD_DATA);
if (! nr_stun_message_has_attribute(ctx->response, NR_STUN_ATTR_XOR_MAPPED_ADDRESS, 0)) {
if (nr_stun_message_has_attribute(ctx->response, NR_STUN_ATTR_MAPPED_ADDRESS, 0)) {
/* Compensate for a bug in Google's STUN servers where they always respond with MAPPED-ADDRESS */
r_log(NR_LOG_STUN,LOG_DEBUG,"STUN-CLIENT(%s): No XOR-MAPPED-ADDRESS but MAPPED-ADDRESS. Falling back (though server is wrong).", ctx->label);
}
else {
ABORT(R_BAD_DATA);
}
}
mapped_addr = &ctx->results.stun_binding_response.mapped_addr;
break;

View File

@ -199,7 +199,12 @@ nr_stun_process_indication(nr_stun_message *ind)
return _status;
}
/* draft-ietf-behave-rfc3489bis-10.txt S 7.3.3 */
/* RFC5389 S 7.3.3, except that we *also* allow a MAPPED_ADDRESS
to compensate for a bug in Google's STUN server where it
always returns MAPPED_ADDRESS.
Mozilla bug: 888274.
*/
int
nr_stun_process_success_response(nr_stun_message *res)
{
@ -211,8 +216,9 @@ nr_stun_process_success_response(nr_stun_message *res)
#endif /* USE_STUN_PEDANTIC */
if (NR_STUN_GET_TYPE_METHOD(res->header.type) == NR_METHOD_BINDING) {
if (! nr_stun_message_has_attribute(res, NR_STUN_ATTR_XOR_MAPPED_ADDRESS, 0)) {
r_log(NR_LOG_STUN, LOG_ERR, "Missing XOR-MAPPED-ADDRESS");
if (! nr_stun_message_has_attribute(res, NR_STUN_ATTR_XOR_MAPPED_ADDRESS, 0) &&
! nr_stun_message_has_attribute(res, NR_STUN_ATTR_MAPPED_ADDRESS, 0)) {
r_log(NR_LOG_STUN, LOG_ERR, "Missing XOR-MAPPED-ADDRESS and MAPPED_ADDRESS");
ABORT(R_REJECTED);
}
}