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
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
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,
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
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
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
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
The following reply was made to PR kern/129508; it has been noted by GNATS.
From: Boris Kochergin
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related
to SVN commit 178025)
Date: Wed, 13 May 2009 15:38:47 -0400
As a workaround, lowering
The following reply was made to PR kern/127528; it has been noted by GNATS.
From: "Seth Mos"
To: bug-follo...@freebsd.org, seth@xs4all.nl
Cc:
Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned
by the process.
Date: Wed, 13 May 2009 21:58:40 +0200 (CEST)
Hi the
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
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
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
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
_
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
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
The following reply was made to PR kern/127528; it has been noted by GNATS.
From: Chris Buechler
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned
by the process.
Date: Wed, 13 May 2009 23:08:05 -0400
A brief addition to Se
Hi,
I did full system rebuild from freshly csup'ped sources. Everything went
smooth as usual, but after reboot network card did not get configured via
DHCP. There were four lines logged on console/in syslog:
dhclient[822]: re0: not found
dhclient[822]: exiting
dhclient[823]: connection closed
d
I have committed the patch, please update your source and
give it a try.
Thanks,
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Milan Obuch
Sent: Wed 5/13/2009 10:03 PM
To: freebsd-net@freebsd.org
Subject: Weird dhclient behavior after today's rebuild
Hi,
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, 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
20 matches
Mail list logo
