Hi All, Is there really nobody else than Darren out there who has the expertise and some minutes of time to have a look at the two attached very short packets to find out why ipfilter declares one of the packets as < bad >?
Thank you in advance for any help. Harald --- Follows the message history: On Sun, Nov 08, 2009 at 01:53:48PM -0800, Darren Reed wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Harald Weis wrote: > | My ''very secure inclusive type of firewall'' works as expected behind > | Free's freebox, but not behind Nerim's SpeedTouch. Both boxes are > | configured as routers. > | Nerim's DNS's respond with bad packets like so: > | 08/10/2009 11:27:27.898288 fxp0 @0:25 b 62.4.16.70,53 -> 10.0.0.28,62317 > | PR udp len 20 395 IN bad > | 08/10/2009 11:27:32.897670 fxp0 @0:25 b 62.4.17.69,53 -> 10.0.0.28,59923 > | PR udp len 20 395 IN bad > | > | Evidently, the packets get blocked by the very last rule: > | block in log first quick on $oif all > | > | I cannot find out the meaning of ''bad'' and what it responsible for it. > > Unfortunately it can mean more than one thing... > although the list is not very long for UDP packets. > > Are you able to use tcpdump for those packets? > > Something like: > > tcpdump -vvv -i fxp0 src port 53 Sorry Darren, for the big delay. The only reason is that the problem is not at this location. Tcpdump is working fine. I've run tcpdump -A -vvv -i fxp0 -w tcpdump.outN src port 53 , where N=2 when firewall is transparent, and N=4 when firewall is on. Thus, launching ``ping -c 3 www.google.fr'' generates the two attached files tcpdump.out2 and tcpdump.out4. I must admit that I am presently quite unable to analyse the output of ``hd tcpdump.out4''... Could you please be so kind and have a look at it? Thank you in advance, Harald
tcpdump.out2
Description: Binary data
tcpdump.out4
Description: Binary data
