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 chegam bem, mas o download nunca chega a lugar nenhum. Este é o servidor da Web somente com o qual tenho esse tipo de problema, mas ainda é irritante e gostaria de ver se há uma correção diferente de renomear quadros jumbo em todos os lugares.
Eu determinei que posso fazer o download de um arquivo parcial, desde que o tamanho do pedaço que estou baixando seja de 1448 bytes ou menos. Eu posso usar o intervalo 0-1447 ou 10000-11447, então não é a posição no arquivo, é o tamanho do pedaço. A WAN MTU no meu roteador foi configurada para 1500, então eu tentei reduzi-la em etapas até que cheguei a 1400 e ainda não fazia nenhuma diferença.
Eu estava pensando que isso era um problema com a descoberta do MTU Black Hole do Path porque o problema desaparece quando eu paro de usar quadros jumbo na interface ethernet. Mas eu tenho tudo configurado para a descoberta de buraco negro (tanto quanto eu posso dizer) e ping não vê qualquer 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 dos outros * nixes. (Eu 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 dos que não contam e alguns que contam os dois.)
Eu não quero desistir dos benefícios de desempenho de quadros jumbo na minha LAN apenas para este site quebrado, mas é claro que eu quero o meu podcast. Então, estou procurando sugestões de coisas para tentar.
Meu Mac tem 2 portas ethernet embutidas, então uma coisa que tentei foi conectar o segundo com MTU 1500 e forçar curl a usar essa porta. Curl disse que estava usando essa porta, mas o MTU dessa porta não teve efeito sobre se o download funcionava ou não. Foi o MTU da primeira porta Ethernet ativa que importava. Eu também não sei o que isso significa.
Sugestões, alguém?