View Single Post

   
  #1 (permalink)  
Old 02-16-2008, 08:11 AM
ngolo
 
Posts: n/a
Default Bridging pf firewall not reliable

Hi,

I have been trying to use reliably OpenBSD with pf has a firewall for
our school for several years, through several OpenBSD releases (3.5 to
4.2) and arch.

We always come up with a complete hang in the trafic, about once every
week, that need console intervention.

Pf is used in bridging (stealth) mode.

With hme on sparc and OpenBSD 3.7, the error is on the network driver
which is overflooded in some way. Either a Receive FIFO overflow or a
tag error during receive:


hme1: status=20<RFIFO>
hme0: status=20<RFIFO>
hme1: status=200000<RXT>

One can find these status in the hmereg.h file:

/src/sys/dev/ic/hmereg.h

#define HME_SEB_STAT_RFIFOVF 0x00000020 /* rx fifo overflow */
#define HME_SEB_STAT_RXTERR 0x00200000 /* tag error during rx dma */

The IF with this errors stops sending trafic until reset with ifconfig
down/up or until a complete reboot.


( the same hang happened with vge driver on i86 with OpenBSD 3.7. With
OpenBSD 4.2, the os drops into the debugger somewhere in the vge driver...)


I understand the trafic is high and there might be more packet than the
IF can handle, but is there a way not to block the interface by catching
the overflow and react otherwise by droping the packet, and still be
functioning ?

When too much packet go down to a computer's IF-kernel, it just drops
them and the higher protocols use their own mechanisms to recover.


I do not know what to do now, since we need a firewall cheap and in
stealth/bridging mode.

Which code in the kernel catches the IF error ? Is this an interrupt
launchd and caught somewhere ?


Any ideas appreciated: good experience with other driver, completely
other fw that can work in bridging mode, etc...


Many thanks


Regards

François Tamone

n@d.c
where n=t, d=eig, c=ch
Reply With Quote