Normally not,

But why would you use a CP in bridged mode?

A pcap of the issue (at client side) and an independent test-case with a
m0n0wall (not pfsense) is somewhat required. Since PFsense CP and M0n0wall
CP are not 100% identical (different webserver, some code changes to adapt
to the webserver VAR etc)

PS An Login OK at the radius side doesn't always mean that a user is getting
accepted. I've seen situations before where a nas still got a RADIUS
Access-Reject packet although the log stated Login OK. Which radius server
are you using?

Kind Regards,

J.

> -----Oorspronkelijk bericht-----
> Van: Tim Roberts [mailto:pfsense at dsslink dot net]
> Verzonden: zondag 11 februari 2007 21:46
> Aan: Jonathan De Graeve
> Onderwerp: Re: [m0n0wall] Captive Portal Refresh issue
> 
> sorry, i sent you a "book" a second ago and didnt see you replied to this
> off the list. Thanks! Also, we tested this weird loop login gg with IE 7,
> IE
> 6 and Firefox 2.0. Thye all behaved the same way. Will Captive Portal work
> in bridge mode with Monowall?
> ----- Original Message -----
> From: "Jonathan De Graeve" <m0n0wall at esstec dot be>
> To: "'Tim Roberts'" <pfsense at dsslink dot net>; <m0n0wall at lists dot m0n0 dot ch>
> Sent: Sunday, February 11, 2007 3:30 PM
> Subject: RE: [m0n0wall] Captive Portal Refresh issue
> 
> 
> >>
> >> Here is the basics of our portal config:
> >>
> >> No Idle timeout
> >> No Hardtimeout
> >> Max Concurrent Connections (we have tried 0 for none, 16, and left
> blank)
> >> Authentication - Radius
> >
> >
> >> Re-Authenticate connected users every minute (then at someones
> >> suggestion,
> >> manually coded this to 360 seconds)
> > There is a 'hidden' config.xml option, you don't have to hardcode it to
> > change it.
> >
> > I'm not sure if its the same issue but I had something similar using
> > radius
> > mac-authentication and mozilla-based browsers.
> >
> > This got fixed something later in the 1.2x tree.
> >
> > It would be nice if you could sent me a clientlevel networktrace
> > (preferably
> > pcap style)
> >
> > This should give some understanding on what is going on.
> >
> > I'll check with Scott which m0n0wall CP version they're using since
> there
> > are some fixes in the current svn. (scott, if you read this ;) )
> >
> > My second suggestion is to try a M0n0wall, it shouldn't be a problem if
> > you're only using it as a CP.
> >
> > Following m0n0wall versions are considered to be stable CP wise :
> > 1.22,1.23b1
> >
> >> All else defaults.
> >>
> >> On another note (in case this is a resource issue), we are using the
> re-
> >> auth feature because we are providing 24x7 service and dont want to
> >> restrict the users service. However, since we use DHCP, when the
> clients
> >> get a new IP, they are forced to login anyways again. Well, this will
> >> work
> >> for us fine if that is how it is to work by design. Can you confirm
> that
> >> please? If a user does not pay their bill, we wanted it to cut off
> their
> >> service asap. If that has to transpire 24 hours later (after a DHCP
> >> renew), that is fine by use and maybe will help this issue if its
> >> resource
> >> related. I ran a top on all the boxes and showed the CPU bored to death
> >> at
> >> 99% idle. These are p4-2.4GHZ / 512MB / 80GB SATA150 Dell boxes.
> >
> > A m0n0wall is definitely being able to handle more then 15user
> > connections.
> > I've heard about handling 90-100users so 15should work ;)
> >
> > Kind Regards,
> >
> > Jonathan
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >