> 	do you have control over the pop server?  if so, try taking tcpdump
> 	on both sides and compare the outputs.  i guess there's a intermediate
> 	device (NAT router?) which is damaging packets.

Ok, sorry for not providing enough details.

I found a better example for the failure, and it's reproduceable. Maybe it
is a bug in the IPFilter version in -current (I seem to recall this worked
until one or two weeks ago, but then I've been constantly changing my pppoe
setup and realy am not sure anymore).

First the network details:

  [ISP]----<DSL>---[DSL-Modem]--<PPPoE>-----[NAT]-------[Client]
                                           ^     ^     ^
                                           |     |     |
                                           |     |     tlp0, MTU 1500
                                           |     |
                                           |    ep0, MTU 1500
                                           |
                                          ne0<->pppoe0, MTU 1492

Both NAT and Client are running NetBSD/i386 -current (kernel source from
a cvs update less than 12 hours ago).

NAT (for the moment) does not use any filter rules, and the obvious ipnat
setup:

map pppoe0 192.168.150.0/24 -> 0/32 proxy port ftp ftp/tcp
map pppoe0 192.168.150.0/24 -> 0/32 portmap tcp/udp 43000:49999
map pppoe0 192.168.150.0/24 -> 0/32

Now for the test case: doing 

   ftp -a ftp.netbsd.org

on NAT works (see tcpdump attached), doing the same on Client doesn't work,
it stops midway in the banner message and then times out (see second tcpdump
attached below). I have PMTU discovery off on NAT and on on Client (can't
remember why, NAT is a quite new default config, and I probably turned it on
on Client for testing some time ago). But all combinations of
net.inet.ip.mtudisc on both machines do not make any difference. 

Time to file a PR?


Martin