If memory serves me right, Bostjan Hojkar wrote:
> The problem i encountered with bridge code right now was this:
> When using DHCP & bridge, the router option in DHCP gets set to IP of
> m0n0wall box, which is wrong. We need a router option via WebGUI for DHCP.
> And while at it, a line with "add this into dhcpd.conf (use at own risk
> :))". That would solve 2 subnets for DHCP request and probably any more
> future requests on that part.
If you want a m0n0wall to serve DHCP to a bridged interface, I think
this is a configuration that it wasn't originally designed for. I can
think of some circumstances where you might want this, though. Hmmm...
> BTW1: WAN interface don't need IP since it's bridged.. But u could use it to
> specify WAN subnet (i.e. IPs that u expect to come in via WAN interface) -
> for filtering rules for example.
Well, your WAN interface needs an IP address if you want the m0n0wall
box itself to be able to do DNS resolution, time synchronization, or
anything requiring access to the rest of the Internet.
> BTW2: How can i enable shell access on console? :) I Unpacked m0n0wall on
> disk manualy to have full filesystem on /dev/ad2s1(c), and i want a shell to
> be able to modify everything on-the-fly without reconstructing mfsroot over
> and over...
There is no such thing as shell access on a m0n0wall box. Modifying
files on a live m0n0wall box is probably not feasible, if for no other
reason than m0n0wall does not include a text editor or, in fact, many
common FreeBSD commands. This is a Good Thing (TM).
Automating the re-packing of mfsroot is fairly simple.
> BTW3: With filtering bridge and using trafic shapper, shoudn't there be
> net.link.ether.bridge_ipfw=1 set? I did a quick grep on /etc and /etc/inc
> files and i didn't notice it.
m0n0wall uses IPFilter, not IPFW, for packet filtering. You want to
look for net.link.ether.bridge_ipf.