Summary

  • O rascunho RADEXT propõe padronizar o pacote RADIUS Protocol-Error, Code 52, introduzido experimentalmente pela RFC 7930. O registro da IANA ainda aponta para a RFC antiga.
  • Toda resposta desse tipo deve carregar Error-Cause e Original-Packet-Code. O código original separa solicitações diferentes que compartilham o mesmo Identifier.
  • A mensagem vale por um salto. Ao receber causas 502 ou 505, o proxy deve considerar outra conexão ou destino e fica proibido de repetir pela conexão que acabou de falhar.

Quem opera acesso conhece o suspense de uma solicitação RADIUS sem resposta. O relógio expira, mas a ausência de pacote não explica se o servidor está lento, se a solicitação tinha defeito ou se um proxy adiante perdeu seu próximo salto. O equipamento de acesso aplica sua regra de repetição. Sob falha, centenas de clientes podem transformar a mesma suposição em carga adicional sobre o trecho já problemático.

O Code 52 permite uma notícia mais precisa: a solicitação chegou e o servidor não conseguiu processá-la. O texto lista pedidos de autenticação, contabilidade, alteração de autorização e desconexão. Uma gravação contábil malsucedida pode produzir um erro de processamento em vez de um recibo enganoso. Uma falha de protocolo durante o login pode ser exposta sem atribuir ao assinante uma recusa que o servidor não decidiu. A RFC 7930 registrou esse pacote em 2016 como experimental; a nova minuta procura definir seu uso mais amplo.

O diagnóstico traz duas peças indispensáveis. Error-Cause identifica a razão. Original-Packet-Code informa qual tipo de solicitação gerou a resposta. O Identifier RADIUS pode repetir-se em tipos de pedido distintos; seu número sozinho não basta para relacionar erro e operação. A resposta copia o Identifier original, e o cliente deve descartar um código original que não corresponda a pedido pendente. Uma mensagem tecnicamente válida associada à autenticação errada pode iniciar a repetição errada e produzir uma explicação falsa ao usuário.

O defeito da conexão pertence a quem a controla

A seção 4 define Protocol-Error como pacote de salto em salto. O proxy que o recebe precisa examinar a causa, sem encaminhar o pacote recebido automaticamente. A conexão até o servidor seguinte é responsabilidade do proxy. O equipamento de acesso mantém a relação com o proxy. Um erro surgido entre esses dois destinos exige uma decisão no ponto que conhece ambos.

As causas 502, Request Not Routable (Proxy), e 505, Other Proxy Processing Error, indicam falha na rede de proxies segundo a minuta. Nesse caso, o proxy deveria repetir a solicitação em outra conexão para o mesmo destino ou escolher destino diferente. A conexão que gerou o erro está vedada para essa repetição. É uma regra pequena com consequência grande: repetir imediatamente no caminho quebrado transforma automação em tráfego inútil. A especificação não fecha toda a política de failover; orçamento de tentativas, tempo máximo e ordem dos caminhos continuam escolhas operacionais.

Para as demais causas, o proxy deveria interpretar que a origem do erro é o servidor de destino e enviar ao próprio cliente um novo Protocol-Error com a causa recebida. Esse pacote novo registra uma ação do proxy, depois de avaliar o resultado de baixo. Um log útil deve encadear solicitação inicial, erro do próximo salto, decisão de encaminhamento e resposta final observada pelo equipamento de acesso. O pacote de erro marca uma falha de processamento; o resultado do login ou da contabilidade exige o registro final da operação.

Trechos sobre migração, negociação e seleção exata de respostas ainda aparecem como TBD. As fontes oficiais não trazem um teste real passando por dois proxies. Um ensaio controlado deveria guardar tipo e Identifier da solicitação, causa recebida, conexão abandonada, novo caminho e resultado no equipamento de acesso. Isso mostraria se o comportamento proposto funciona entre implementações diferentes.

Minuta RADEXT · Registro Datatracker · RFC 7930 · IANA RADIUS