Among other things, more control -- including an easy way to cut off bandwidth
hogs and abusers -- and a walled garden that is better able to hijack browsers
(the one in pfsense often fails). We actually have quite a few things we'd like
to implement. More offlist if you'd like.
--Brett Glass
What kind of features?
Just out of curiosity, cause i made some fixes to it and am curious
what can be added more!?
On Sat, May 16, 2009 at 5:11 AM, Brett Glass wrote:
> Unfortunately, the pfsense captive portal lacks many of the features that we
> need and has also had problems in some of our te
Unfortunately, the pfsense captive portal lacks many of the
features that we need and has also had problems in some of our
tests. We need the ability to "roll our own" rather than a canned
solution, which is why we'd like to make sure that we can implement
this via IPFW.
--Brett
At 01:39 AM
On Thu, 14 May 2009, Brett Glass wrote:
> At 12:17 AM 5/14/2009, Ian Smith wrote:
>
> >You can use fixed leases with MAC specified in dhcp for that,
>
> This lets you assign specific addresses to machines with specific MAC
> addresses. But it doesn't inhibit MAC address "cloning," and th
Hi Brett,
I think what you are looking for is called captive portal.
You can look at pfsense - http://doc.pfsense.org/index.php/Category:Captive_Portal
which comes with such solution into it.
On May 14, 2009, at 1:29 AM, Brett Glass wrote:
At 03:38 PM 5/13/2009, Christian Brueffer wrote:
On (13/05/2009 13:29), Brett Glass wrote:
> At 01:07 PM 5/13/2009, Andrew Thompson wrote:
>
> >This has been implemented as part of Gleb Kurtsov's 2008 SoC project.
> >http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering
> >
> >It has not been committed yet but I beleieve is ready to go
On Wed, 13 May 2009, Brett Glass wrote:
> I need to find a way to do "MAC address locking" in FreeBSD -- that is, to
> ensure that only a machine with a particular MAC address can use a particular
> IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are
> "stuck" on one layer: r
At 12:17 AM 5/14/2009, Ian Smith wrote:
>You can use fixed leases with MAC specified in dhcp for that,
This lets you assign specific addresses to machines with specific MAC
addresses. But it doesn't inhibit MAC address "cloning," and the DHCP server
cannot force a machine to use a specific IP
On Wed, May 13, 2009 at 10:48:02AM -0600, Brett Glass wrote:
> I need to find a way to do "MAC address locking" in FreeBSD -- that
> is, to ensure that only a machine with a particular MAC address can
> use a particular IP address. Unfortunately, it appears that rules
> in FreeBSD's IPFW are "s
Brett, you can grab the specific "bulk" change to an earlier -current from here:
svn diff -r 186068:186069
http://svn.freebsd.org/base/projects/l2filter >
/tmp/l2filter-186069.diff
There aren't any bugfix commits in that branch after that; they're all
merge-from-head and arpv2/routetable work mer
There's one big SVN commit - r186069.
There's a couple of "merge from head" commits and an arpv2/routetable
tidyup commit.
This is all against -current though. I'm going to see how cleanly the
patch applies to 7.2-release and if it works at all.
Adrian
_
At 03:38 PM 5/13/2009, Christian Brueffer wrote:
Sounds like wlan_acl(4) may be of interest to you.
Unfortunately, wlan_acl(4) is only useful if one wants to ban users
from the network, which these venues will rarely want to do except
to block an abuser.
Rather, they'll want the equipment
On Wed, May 13, 2009 at 01:03:20PM -0600, Brett Glass wrote:
> Stefan:
>
> You are correct: This is not real security. In fact, I would argue that it's
> not security at all.
>
> But many businesses that have to maintain hotspots -- especially some hotel
> chains -- are "allergic" to any sort
On May 13, 2009, at 12:29 PM, Brett Glass wrote:
It has not been committed yet but I beleieve is ready to go in, you
can
find the code on the svn branch
http://svn.freebsd.org/viewvc/base/projects/l2filter/
How does one generate a diff between this code and, say, 7.1-RELEASE
or 7.2-RELEASE
At 01:14 PM 5/13/2009, Stefan Lambrev wrote:
Not that I understand how "knowing" mac address is easier for
customers then wpa2 password ;)
Most customers would not recognize a WPA2 password if it bit them.
;-) Also, many older operating systems and Wi-Fi cards do not
support WPA at all. (For
At 01:07 PM 5/13/2009, Andrew Thompson wrote:
This has been implemented as part of Gleb Kurtsov's 2008 SoC project.
http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering
It has not been committed yet but I beleieve is ready to go in, you can
find the code on the svn branch
http://svn.f
On Wed, May 13, 2009 at 10:48:02AM -0600, Brett Glass wrote:
> I need to find a way to do "MAC address locking" in FreeBSD -- that is, to
> ensure that only a machine with a particular MAC address can use a
> particular IP address. Unfortunately, it appears that rules in FreeBSD's
> IPFW are "st
Hi,
On May 13, 2009, at 10:03 PM, Brett Glass wrote:
Stefan:
You are correct: This is not real security. In fact, I would argue
that it's not security at all.
But many businesses that have to maintain hotspots -- especially
some hotel chains -- are "allergic" to any sort of serious secur
Stefan:
You are correct: This is not real security. In fact, I would argue that it's
not security at all.
But many businesses that have to maintain hotspots -- especially some hotel
chains -- are "allergic" to any sort of serious security. This is because a
small but vocal subset of their cus
Hi,
apr -S (or -s) is not helping?
Have in mind that this is not a real security as it's very easy to
change your MAC.
On May 13, 2009, at 7:48 PM, Brett Glass wrote:
I need to find a way to do "MAC address locking" in FreeBSD -- that
is, to ensure that only a machine with a particular MAC
I need to find a way to do "MAC address locking" in FreeBSD -- that
is, to ensure that only a machine with a particular MAC address can
use a particular IP address. Unfortunately, it appears that rules
in FreeBSD's IPFW are "stuck" on one layer: rules that look at
Layer 2 information in a packe
21 matches
Mail list logo