pf(4) + fetch(1) + http://ftp.gnu.org

[Sten Daniel Soersdal]

Vlad GURDIGA wrote:
> Hello,
> 
> There is one strange thing going on with this combination. I saw this
> many times by now: when fetch(1) is trying to download something from
> http://ftp.gnu.org, it is hanging after a very small amount of data;
> sometimes on 0%. After disabling pf(4), fetch(1) is not hanging any
> more, so I guess that the problem is somewhere in my pf.conf. Here is
> it:
> 
> ---- pf.conf -- begin ---
> ext_if  = "em0"
> icmp_types="echoreq"
> 
> # don't filter on the loopback interface
> set skip on lo0
> set block-policy return
> 
> scrub all no-df random-id reassemble tcp
> 
> # setup a default deny policy
> block all
> 
> # activate spoofing protection for the internal interface.
> antispoof quick for lo0 inet
> 
> # pass tcp, udp, and icmp out on the external (Internet) interface.
> # keep state on udp and icmp and modulate state on tcp.
> pass in on $ext_if proto tcp from any to $ext_if port 65522 keep state
> 
> pass in inet proto icmp all icmp-type $icmp_types keep state
> pass out on $ext_if proto tcp all modulate state flags S/SA
> pass out on $ext_if proto {udp, icmp} all keep state
> ---- pf.conf -- end ---
> 

My guess is, your path-mtu is lower at some point between you and 
ftp.gnu.org which (may or may not) result in an icmp packet indicating 
that the packet was dropped as fragmentation was needed but DF flag was set.

it is usually possible to see via tcpdump or ethereal.
try permitting all icmp packets both ways to see.

-- 
Sten Daniel Soersdal