On Thu, Aug 13, 2009 at 1:12 AM, Lee Sharp<leesharp at hal dash pc dot org> wrote:
> Chris Buechler wrote:
>> On Wed, Aug 12, 2009 at 10:39 PM, Lee Sharp<leesharp at hal dash pc dot org> wrote:
>>> Chris Buechler wrote:
>>>> In addition to the filtering behavior change Manuel mentioned, the
>>>> check to only allow one bridged interface has been removed. You can
>>>> bridge multiple interfaces together, including in multiple groups. The
>>>> GUI is functionally no different than before, if_bridge just allows
>>>> more bridging possibilities, and the back end is changed to
>>>> accommodate this.
>>> Does this mean that bridging and captive portal are no longer mutually
>> No. CP must still be served from an IP on that particular interface.
>> Bridged interfaces don't have IPs.
> If I have CP on LAN, can I bridge Opt1 and WAN? You can not enable both
> bridging abd CP with 1.2x, which is why I ask...
Oh! I wasn't aware of the check was that tight. That check was changed
long ago in pfSense (it won't let you enable CP on a bridged interface
with no IP, but it will for any inside interface with an IP), I never
realized it existed in its current fashion. I'm not sure how that will
impact m0n0wall-specific things. After a cursory test, it works for me
when setup in the manner you describe. I have OPT1 bridged to WAN, and
CP on LAN. Try uploading this:
using exec.php, then run:
mv /tmp/m0n0services_captiveportal.php /usr/local/www/services_captiveportal.php
chmod +x /usr/local/www/services_captiveportal.php
Enable CP on an internal interface with an IP, and see if/how it works.
That has no input validation at all, if it works for you, I'll port
pfSense's input validation so you can enable CP on any inside
interface with an IP and get it committed for 1.3.