Vlad GURDIGA wrote:

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

---- pf.conf -- begin ---
ext_if  = "em0"

# 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
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to