btpand problem

[Andreas Longwitz]

Hi,

> as I said, I think 672 is a bit low, though I used 4096 for NetBSD (with a
> sysctl for runtime adjustment if necessary) and that is still potentially
> prone to error with larger packets (L2CAP MTU between 48-65535 bytes is
> valid) so I guess that requiring the application to set the buffer size is
> best practice..

I agree.

>> Now I describe another problem with my ping test, I am not sure if this
>> problem concerns btpand too. If the ICMP packet must be fragmented, then the
>> first fragment ist lost on the tap interface (and can not be found by tcpdump
>> running on this tap) if an ARP request is necessary.
>>    ping -c 1 -s 1400 panserver
>> works all the time,
>>    ping -c 1 -s 1600 panserver
>> only works if the ip address of panserver is in the arp cache.
> 
> does the ARP request get sent out?

Yes and the arp answer comes in.

>> I did nothing special with the tap interface, it is included in my
>> "cloned_interfaces" in rc.conf and opened by btpand.
>>
>> Any ideas ?
> 
> No, I confess.

My problem was a phantom ! It seems to be normal behavior in any network
and has nothing to do with btpand or tap interface. This was a little
bit suprising to me but I have checked this on several networks. An
explanation for this was given on freebsd-net some years ago titled
  Lost fragment when send to ip that need arp resolve.

Thanks again for help!

Andreas Longwitz