Falha do OS X na detecção do roteador de buraco negro da unidade de transmissão máxima do caminho (PMTU)

Falha do OS X na detecção do roteador de buraco negro da unidade de transmissão máxima do caminho (PMTU)

Tudo isso começou quando eu estava tentando baixar um podcast no meu Mac. Isso acontece no Snow Leopard e no Lion quando a interface Ethernet está configurada para usar Jumbo Frames.

prompt> curl -v -o x.mpg http://audio.wnyc.org/freakonomics_specials/freakonomics_specials041112.mp3 
* About to connect() to audio.wnyc.org port 80 (#0)
*   Trying 204.93.180.53... Local Interface en0 is ip 172.16.1.2 using address family 2
* Local port: 0
* connected
* Connected to audio.wnyc.org (204.93.180.53) port 80 (#0)
> GET /freakonomics_specials/freakonomics_specials041112.mp3 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: audio.wnyc.org
> Accept: */*
> 
OK
< Server: nginx/0.7.65
< Date: Mon, 16 Apr 2012 23:39:03 GMT
< Content-Type: audio/mpeg
< Content-Length: 42075070
< Last-Modified: Tue, 10 Apr 2012 21:15:08 GMT
< Connection: close
< Content-Disposition: attachment
< Accept-Ranges: bytes
< 
  0 40.1M    0     0    0     0      0      0 --:--:--  0:00:24 --:--:--     0^C

Os cabeçalhos funcionam bem, mas o download nunca chega a lugar nenhum. Isto é oapenasservidor web com o qual tenho esse tipo de problema, mas ainda é irritante e gostaria de ver se há uma solução além de renunciar aos jumbo frames em todos os lugares.

Determinei que posso baixar um arquivo parcial, desde que o tamanho do bloco que estou baixando seja de 1.448 bytes ou menos. Posso usar o intervalo 0-1447 ou 10000-11447, então não é a posição no arquivo, é o tamanho do pedaço. O WAN MTU no meu roteador estava configurado para 1500, então tentei reduzi-lo passo a passo até chegar a 1400 e ainda assim não fez nenhuma diferença.

Eu estava pensando que isso era um problema com a descoberta do Path MTU Black Hole porque o problema desaparece quando eu paro de usar frames jumbo na interface Ethernet. Mas tenho tudo configurado para a descoberta de buracos negros (até onde sei) e o ping não vê nenhum problema:

ping  -g1435 -G1445 204.93.180.53PING 204.93.180.53 (204.93.180.53):
(1435 ... 1445) data bytes
1443 bytes from 204.93.180.53: icmp_seq=0 ttl=51 time=69.223 ms
1444 bytes from 204.93.180.53: icmp_seq=1 ttl=51 time=75.542 ms
1445 bytes from 204.93.180.53: icmp_seq=2 ttl=51 time=72.136 ms
1446 bytes from 204.93.180.53: icmp_seq=3 ttl=51 time=73.732 ms
1447 bytes from 204.93.180.53: icmp_seq=4 ttl=51 time=72.057 ms
1448 bytes from 204.93.180.53: icmp_seq=5 ttl=51 time=73.377 ms
1449 bytes from 204.93.180.53: icmp_seq=6 ttl=51 time=71.717 ms
1450 bytes from 204.93.180.53: icmp_seq=7 ttl=51 time=73.293 ms
1451 bytes from 204.93.180.53: icmp_seq=8 ttl=51 time=71.874 ms
1452 bytes from 204.93.180.53: icmp_seq=9 ttl=51 time=73.206 ms
1453 bytes from 204.93.180.53: icmp_seq=10 ttl=51 time=71.289 ms

Na verdade, o ping funciona até 1494 bytes, embora eu acredite que o Mac conte os bytes de maneira diferente de outros *nixes. (Acho que conta como dados os 8 bytes do cabeçalho ICMP, mas não os 20 bytes do cabeçalho IP, ao contrário da maioria que não conta e alguns que contam ambos.)

Não quero abrir mão dos benefícios de desempenho dos jumbo frames na minha LAN apenas por causa deste site quebrado, mas é claro que quero meu podcast. Então, estou procurando sugestões de coisas para tentar.

Meu Mac tem 2 portas Ethernet integradas, então uma coisa que tentei foi conectar a segunda com MTU 1500 e forçar curlo uso dessa porta. Curl disse que estava usando essa porta, mas o MTU dessa porta não afetou se o download funcionava ou não. O que importava era o MTU da primeira porta Ethernet ativa. Também não sei o que isso significa.

Sugestões, alguém?

Responder1

Soluções alternativas:

  • Reduza o MTU da interface para 1500. Preferências do Sistema -> Rede, selecione a interface (por exemplo, Ethernet integrada), clique no botão Avançado..., guia Ethernet, menu suspenso MTU ou defina Configurar como Automaticamente. Isso resolve o problema, mas significa que você não pode usar Jumbo Frames na LAN (pelo menos neste computador).
  • Se fosse no Linux: use iptablespara fixar o TCP MSS apenas para este host. --set-mss 1460

Solução:

  • Corrija a configuração do servidor para diminuir o MTU ou fazer o Path MTU Discovery funcionar.

Acontece que finalmente consegui encontrar alguém com quem conversar na empresa CDN que pudesse implementar a solução, e eles baixaram o MTU e isso resolveu o problema.

informação relacionada