On Mon, Sep 19, 2005 at 03:13:33PM -0300, Vinicius Pavanelli Vianna wrote: > > I tried to disable pf (pfctl -d) and it continues to loss packets <...> > The count on in and out are different because the pf is blocking some > packets
(?) those seem to contradict one another., just a typo? > didn't resolve the packet lost i begin to suspect something on the > bridge code, as i don't see any error on the interface. welp.. you could turn the bridge off and then run binat in pf, or perhaps split the subnet. i could see two ways to do this, one being kinda hackish and perhaps outright wrong, but i believe either would work. 1) hackish: ( this would work, but involves a lot of ugly crap and proxy-arp, so i decided to not even bring it up because i don't want people to yell and puke at me ). 2) assuming the ISP and you have both chosen IPs from the beginning of the subnet, have your ISP change their iface to you to be a /26 instead of a /25. so, if they're .1/25, ask them to be .1/26. then change the subnet mask on your end to match a /26 also ( 255.255.255.192 ). so assume you're 200.xx.xx.2 netmask 0xffffffc0; have them now static route 200.xx.xx.64/26 to 200.xx.xx.2. if you and the ISP are high IPs, ( eg, .125, .126 ), sure, doesn't matter, just make sure you're both in the same subnet, and then in the next paragraph, use the lower subnet for the lan instead of the higher: this will make it so that you still get what amounts to the same /25, but can put the lower /26 on the external iface and the upper /26 on your internal iface. so then take an IP from the .64/26 and put it on the internal em(4) card, renumber any hosts behind that as needed, and try to see if you still have the same packet loss ( assuming you have changed nothing thus far other than the IP subnetting ). if you have the IPs setup that way, you can remove the bridge from existance and rely on normal net.inet.ip.forwarding=1. > but the big problem is that some packets doesn't get even on the > interface, my setup is like "add em0 add em1 up" on bridgename.bridge0 i checked the thread again but didn't see it mentioned. where are you losing the packets? are you losing packets on the link between ISP<->You or You<->YourLan ? if you're losing them on ISP<->You, is that to the other end of the external iface, ( eg, whatever you put for a default gateway on your bridge box, their end of your /25 ) or to some other host beyond that? > i also enabled STP as my ISP told me it would help > their redundancy. STP on a bridge seems like a Good Thing, but i don't think the ISP side of it is going to matter much... i mean.. if they require people to have the customer side of the link be either A) one single host or B) something running spanning tree, then yeah, it seems logical, but if not (eg - they do not make a certain requirement of what you attach to their link), i would wager that spanning tree is not going to be part of the solution to your problem. in other words, if they're not running STP-aware bridges between the interface that is their side of your /25 and the cable hitting your side of your /25, you running spanning tree isn't going to mean dick for them. for now, the "check autoneg/speed-duplex settings" seems to be a good place to start. make each physical link agree (autoneg or forced) on both ends, if they don't already. if that doesn't pan out, consider trying the 1x/25-> 2x/26 thing i mention above. ps - given the dmesg you showed, the performance of pf is likely to not be part of the question. smells like something else is happening here. jared -- [ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]