finally I found some time and had a closer look at that problem.
Bruce A. Mah --> m0n0wall (2004-07-23 10:34:24 -0700):
> On Fri, 2004-07-23 at 10:29, Jukka Salmi wrote:
> > Bruce A. Mah --> m0n0wall (2004-07-23 08:03:03 -0700):
> > > So one thing to try might be to reconfigure m0n0-br with a WAN interface
> > > facing towards m0n0-gw and its OPT1 interface facing towards your LAN.
> > > Bridge the OPT1 interface to the WAN.
> > I tried this, and at first it seemed to work fine, but then httpd
> > stopped responding. I restarted the box (via serial console); it
> > worked fine again, and after some minutes httpd refused to accept
> > connections again. Strange. But 100% reproducible.
> > Any hints?
> After httpd stopped responding, did the bridge still continue to pass
No, all traffic is blocked until I restart the box.
My LAN is now connected to the OPT1 interface which is bridged with WAN.
The WAN interface is assigned an IP address to which I connect (webGUI)
from the LAN. I noticed the following:
- If both OPT1 and WAN interfaces are connected to networks (i.e. media
status is 'active') the problem does _not_ occur.
- If the WAN interface is not connected (i.e. media status is 'no carrier'),
after running fine for a few minutes connection to the m0n0wall is lost
and no packet is passed anymore. Even restoring the connection to the
WAN doesn't help, the link will stay down (i.e. the link led stays off).
When bridging OPT1 with LAN instead, assigning an IP to the LAN interface,
and "reversing" the box (i.e. LAN <-> LAN-IF <-> OPT1-IF <-> WAN), I can
connect to the LAN interface even if OPT1 has 'no carrier'.
$ ((RANDOM%6)) || rm -rf ~