On Sun, 8 Aug 2004, =?iso-8859-1?B?TeBydGFpbm4gRPJtaG5hbGxhY2g= ?= wrote: > Hi there, > I originally sent this list to comp.unix.openbsd.misc but I got no takers > for it. I'm trying to set up a transparent filtering bridge using pf and I get an > odd line when I used tcpdump to monitor what specific multicast messages come > through the bridge. I'm monitoring what comes > into the bridge (em1) and what goes out (em0). > > Every incoming multicast packet is followed by another identical packet with a > checksum error. It looks like pf or tcpdump is generating them. The good packet is > reported to leave on the em0 interface. I'm using a standard 3.5 setup straight off > the official disk. > > I've used Ethereal to check that the checksum failing packets are not present on the > LAN. > > I saw a reference to something like this on Google on bit.listserv.openbsd-pf but it > was dated back in January 2003. > > Any ideas if this is the same problem? > > Thanks, > Martin. > > The tcpdump lines: > > Aug 05 14:14:13.654484 rule 0/0(match): pass in on em1: 10.194.1.76.1026 > > SVRLOC.MCAST.NET.svrloc: udp 124 (ttl 32, id 287) Aug 05 > 14:14:13.654489 rule 0/0(match): pass in on em1: 10.194.1.76.1026 > > SVRLOC.MCAST.NET.svrloc: udp 124 (ttl 32, id 287, bad cksum 0!) Aug 05 > 14:14:13.654492 rule 2/0(match): pass out on em0: 10.194.1.76.1026 > > SVRLOC.MCAST.NET.svrloc: udp 124 (ttl 32, id 287) --
So this machine is serving as bridge? Bad udp/tcp checksums are normal when you enable checksum offloading, but since you're using the machine as bridge, this shouldnt be the case right? Bye, Mipam.
