Re: Reliable PCI wifi cards, and layer 7 filtering
On 2/10/2011 5:23 PM, Joe Holden wrote: On 10/02/2011 15:56, Jeremy Chadwick wrote: (I was considering cross-posting this to freebsd-pf but decided against it, instead starting here first. Please keep me CC'd as I'm not subscribed to freebsd-net) I'm looking into the possibility of using my home FreeBSD box as my home firewall/NAT box, to replace my Linksys E2000 router (which runs Linux, specifically the TomatoUSB firmware). I plan on using pf for the NAT and firewall layer. ipfw will not be used (I have long since moved away from it). I've got solutions for everything except two items: 1) Wireless hardware support - What consumer PCI cards are known to be reliable and have good support on FreeBSD? It looks like anything that relies on ath(4) might be a good choice, but I'm not sure what specific chipset is considered decent/worthwhile, or if there's a specific model of card from Vendor X(tm) which works great. - The card and driver need to support both 802.11b and 802.11g simultaneously. 802.11n (for the future) would also be good. - Driver or OS needs 128-bit WEP -- this is not a joke, I really do have devices which do not do WPA or WPA2. - MAC address filtering is needed too, but it looks like that's already available (looking at ifconfig(8) man page). 2) Layer 7 filtering - Specifically, the ability to block outbound packets in real-time which contain certain data in the TCP data portion of the packet. - More details: there are some HTTP-based requests which some software I use on XP submits to a server pool to return some ads. Filtering by IP address isn't possible since the A records of the FQDN often change. The software in question does not honour system proxy settings, so use of a proxy (Apache, squid, etc.) as a solution will not work. - I filter based on GET parameters or the HTTP: Host header. Thus, the matching mechanism doesn't need regex; simple substring matches (e.g. strcasestr()) would work fine. - Linux has kernel modules called ipt_web and xt_web which can do exactly this. They return TCP RST to the client which submit the packet, and never forwarding the original packet out the WAN. There is 'ipfw-classifyd' which has been somewhat improved by the pfsense team in order to support pf - I don't have the exact url to hand, but IIRC it is hosted on googlecode somewhere. It's in git at rcs.pfsense.org in the tools repo. Note divert + PF in FreeBSD is also specific to patches we use that aren't in stock FreeBSD yet, you can easily apply those to RELENG_8_1 though. Kernel patches are also in the tools repo. All of it's BSD licensed, you're welcome to grab whatever you want to use. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154667: [fxp] link stage change on multicast join/leave
Old Synopsis: link stage change on multicast join/leave (fxp) New Synopsis: [fxp] link stage change on multicast join/leave Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 11 03:15:17 UTC 2011 Responsible-Changed-Why: reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=154667 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Reliable PCI wifi cards, and layer 7 filtering
On Thu, Feb 10, 2011 at 5:23 PM, Joe Holden wrote: > On 10/02/2011 15:56, Jeremy Chadwick wrote: > There is 'ipfw-classifyd' which has been somewhat improved by the pfsense > team in order to support pf - I don't have the exact url to hand, but IIRC > it is hosted on googlecode somewhere. > > It does what you describe, uses regex to match payload. Hi, Our custom code is held here: https://rcs.pfsense.org/projects/pfsense-tools Simply check out the tools repo and inside pfPorts/ you will find all our goodies including ipfw-classifyd. Hope this helps! Scott ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Reliable PCI wifi cards, and layer 7 filtering
On 10/02/2011 15:56, Jeremy Chadwick wrote: (I was considering cross-posting this to freebsd-pf but decided against it, instead starting here first. Please keep me CC'd as I'm not subscribed to freebsd-net) I'm looking into the possibility of using my home FreeBSD box as my home firewall/NAT box, to replace my Linksys E2000 router (which runs Linux, specifically the TomatoUSB firmware). I plan on using pf for the NAT and firewall layer. ipfw will not be used (I have long since moved away from it). I've got solutions for everything except two items: 1) Wireless hardware support - What consumer PCI cards are known to be reliable and have good support on FreeBSD? It looks like anything that relies on ath(4) might be a good choice, but I'm not sure what specific chipset is considered decent/worthwhile, or if there's a specific model of card from Vendor X(tm) which works great. - The card and driver need to support both 802.11b and 802.11g simultaneously. 802.11n (for the future) would also be good. - Driver or OS needs 128-bit WEP -- this is not a joke, I really do have devices which do not do WPA or WPA2. - MAC address filtering is needed too, but it looks like that's already available (looking at ifconfig(8) man page). 2) Layer 7 filtering - Specifically, the ability to block outbound packets in real-time which contain certain data in the TCP data portion of the packet. - More details: there are some HTTP-based requests which some software I use on XP submits to a server pool to return some ads. Filtering by IP address isn't possible since the A records of the FQDN often change. The software in question does not honour system proxy settings, so use of a proxy (Apache, squid, etc.) as a solution will not work. - I filter based on GET parameters or the HTTP: Host header. Thus, the matching mechanism doesn't need regex; simple substring matches (e.g. strcasestr()) would work fine. - Linux has kernel modules called ipt_web and xt_web which can do exactly this. They return TCP RST to the client which submit the packet, and never forwarding the original packet out the WAN. There is 'ipfw-classifyd' which has been somewhat improved by the pfsense team in order to support pf - I don't have the exact url to hand, but IIRC it is hosted on googlecode somewhere. It does what you describe, uses regex to match payload. HTH Item #2 above seems to be the kicker. Is there anything in the works regarding such a capability? I'd be more than happy to test out code or whatever. Thanks, J ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cannot set mtu > 1500 on em0 optical Gig-E
Ahem, its our OLDEST 1G part, it was ancient when I took this job 5 years
ago :)
And the code is working according to spec, jumbos are not supported on the
device,
that's not the same as saying its not possible.
We only have one or two of these devices laying around, and I get a chuckle
any
time I've asked to use one to repro something, adapters aren't that
expensive,
time to think about an upgrade :)
Jack
On Thu, Feb 10, 2011 at 2:04 PM, Jay Borkenhagen wrote:
> Jack Vogel writes:
> > Thanks Sergey :)
> >
> [...]
> > >
> > > Hmm.. Did jumbo frames really work on these cards for you? Intel
> > > claims: "Adapters based on the Intel® 82542 and 82573V/E
> > > controller do not support Jumbo Frames. These correspond to the
> > > following product names:
> > >
> > >* Intel® PRO/1000 Gigabit Server Adapter
> > >* Intel® PRO/1000 PM Network Connection "
> > >
> > > As seen from code, the behavior was changed to match the
> > > description ("keep old 82542 from using jumbo frames") and merged
> > > to 6-STABLE before 6.3.
> > >
>
>
> Well, I've got tcpdumps showing DF-bit-set pings succeeding to and
> from such a NIC with MTU >> 1500, on a box running 6.2-RELEASE.
> (pciconf data below.) In this particular case I have MTU=4470, which
> is really good enough for what I need, and DF pings succeed up to
> 'ping -s 4442'
>
> Maybe Intel thought they couldn't handle MTUs approaching 9k, or maybe
> they had problems approaching linerate -- neither of which are
> concerns in my application...
>
>
> em0@pci0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03
> hdr=0x00
>vendor = 'Intel Corporation'
>device = '82542 Gigabit Ethernet Controller'
>class= network
>subclass = ethernet
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cannot set mtu > 1500 on em0 optical Gig-E
Jack Vogel writes:
> Thanks Sergey :)
>
[...]
> >
> > Hmm.. Did jumbo frames really work on these cards for you? Intel
> > claims: "Adapters based on the Intel® 82542 and 82573V/E
> > controller do not support Jumbo Frames. These correspond to the
> > following product names:
> >
> >* Intel® PRO/1000 Gigabit Server Adapter
> >* Intel® PRO/1000 PM Network Connection "
> >
> > As seen from code, the behavior was changed to match the
> > description ("keep old 82542 from using jumbo frames") and merged
> > to 6-STABLE before 6.3.
> >
Well, I've got tcpdumps showing DF-bit-set pings succeeding to and
from such a NIC with MTU >> 1500, on a box running 6.2-RELEASE.
(pciconf data below.) In this particular case I have MTU=4470, which
is really good enough for what I need, and DF pings succeed up to
'ping -s 4442'
Maybe Intel thought they couldn't handle MTUs approaching 9k, or maybe
they had problems approaching linerate -- neither of which are
concerns in my application...
em0@pci0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82542 Gigabit Ethernet Controller'
class= network
subclass = ethernet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cannot set mtu > 1500 on em0 optical Gig-E
Thanks Sergey :)
Jack
On Thu, Feb 10, 2011 at 12:28 PM, Sergey Kandaurov wrote:
> On 10 February 2011 21:49, Jay Borkenhagen wrote:
> > Hi,
> >
> > For quite a while now it appears that mtu on my gigabit ethernet fiber
> > em0 cards cannot be configured higher than the default 1500 bytes.
> >
> > Here's what I get when I attempt to set it lower and higher on a brand
> > new 8.2-RC3 box:
> >
> > ===
> > sandbox# uname -v
> > FreeBSD 8.2-RC3 #0: Sun Jan 30 06:52:51 UTC 2011
> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
> > sandbox#
> >
> > sandbox# ifconfig em0
> > em0: flags=8843 metric 0 mtu 1500
> > options=18
> > ether 00:d0:b7:7c:f8:01
> > inet 10.1.2.3 netmask 0xff00 broadcast 10.1.2.255
> > media: Ethernet autoselect
> > status: no carrier
> > sandbox# ifconfig em0 mtu 1499
> > sandbox# ifconfig em0 | grep mtu
> > em0: flags=8843 metric 0 mtu 1499
> > sandbox# ifconfig em0 mtu 1501
> > ifconfig: ioctl (set mtu): Invalid argument
> > sandbox# ifconfig em0 | grep mtu
> > em0: flags=8843 metric 0 mtu 1499
> > sandbox# ifconfig em0 mtu 1500
> > sandbox# ifconfig em0 | grep mtu
> > em0: flags=8843 metric 0 mtu 1500
> > sandbox#
> >
> > sandbox# pciconf -lv | sed -n '/em0@/,/em1/p'
> > em0@pci0:0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03
> hdr=0x00
> >vendor = 'Intel Corporation'
> >device = '82542 Gigabit Ethernet Controller'
> >class = network
> >subclass = ethernet
> > em1@pci0:0:4:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03
> hdr=0x00
> > sandbox#
> >
> > ===
> >
> > However, back in the 6.2 days it allowed it:
> >
> > ===
> >
> > [jayb@cactus ~]$ uname -v
> > FreeBSD 6.2-PRERELEASE #0: Tue Dec 26 16:53:18 EST 2006
> r...@cactus.iplabs.att.com:/usr/obj/usr/src/sys/CACTUS
> > [jayb@cactus ~]$
> >
> > [jayb@cactus ~]$ ifconfig em0
> > em0: flags=8843 mtu 1500
> > options=8
> > inet 10.0.1.152 netmask 0xfffc broadcast 10.0.1.155
> > ether 00:90:27:e3:0a:67
> > media: Ethernet autoselect
> > status: no carrier
> > [jayb@cactus ~]$
> >
> > [jayb@cactus ~]$ sudo ifconfig em0 mtu 9000
> > [jayb@cactus ~]$ ifconfig em0 | grep mtu
> > em0: flags=8843 mtu 9000
> > [jayb@cactus ~]$
> >
> > [jayb@cactus ~]$ pciconf -lv | sed -n '/em0@/,/none0@/p'
> > em0@pci0:2:0:class=0x02 card=0x10008086 chip=0x10008086 rev=0x02
> hdr=0x00
> >vendor = 'Intel Corporation'
> >device = '82542 Gigabit Ethernet Controller'
> >class= network
> >subclass = ethernet
> > none0@pci0:4:0: class=0x088000 card=0x0767101e chip=0x9063101e rev=0x04
> hdr=0x00
> > [jayb@cactus ~]$
> >
>
> Hmm.. Did jumbo frames really work on these cards for you? Intel claims:
> "Adapters based on the Intel® 82542 and 82573V/E controller do not
> support Jumbo Frames. These correspond to the following product names:
>
>* Intel® PRO/1000 Gigabit Server Adapter
>* Intel® PRO/1000 PM Network Connection "
>
> As seen from code, the behavior was changed to match the description ("keep
> old 82542 from using jumbo frames") and merged to 6-STABLE before 6.3.
>
> --
> wbr,
> pluknet
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154591: [msk] [panic] if_msk driver causes kernel panic (fatal trap while in kernel mode)
2011/2/10 : > By chance are you using VIMAGE > enabled kernel? No, I used the default amd64/conf/GENERIC from current trunk. -- Robert Millan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]
The following reply was made to PR kern/127050; it has been noted by GNATS. From: Jacek Zapala To: bug-follo...@freebsd.org, maddo...@maddog2k.net Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Date: Mon, 07 Feb 2011 14:30:21 +0100 Bug is still present in 8.0. I have found that system joins multicast group only for the first address. For example: for address :::x::110:166 it joins ff02:1::1:ff10:166 as shown by netstat -ia (where it listens for example for neighbour solicitation messages), but for the second address assigned to the same carp4 interface it does not join another group. It works if I chose the second address with the same last 3 bytes as the first address - because it falls to the same multicast group. Regards, Jacek ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cannot set mtu > 1500 on em0 optical Gig-E
On 10 February 2011 21:49, Jay Borkenhagen wrote:
> Hi,
>
> For quite a while now it appears that mtu on my gigabit ethernet fiber
> em0 cards cannot be configured higher than the default 1500 bytes.
>
> Here's what I get when I attempt to set it lower and higher on a brand
> new 8.2-RC3 box:
>
> ===
> sandbox# uname -v
> FreeBSD 8.2-RC3 #0: Sun Jan 30 06:52:51 UTC 2011
> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
> sandbox#
>
> sandbox# ifconfig em0
> em0: flags=8843 metric 0 mtu 1500
> options=18
> ether 00:d0:b7:7c:f8:01
> inet 10.1.2.3 netmask 0xff00 broadcast 10.1.2.255
> media: Ethernet autoselect
> status: no carrier
> sandbox# ifconfig em0 mtu 1499
> sandbox# ifconfig em0 | grep mtu
> em0: flags=8843 metric 0 mtu 1499
> sandbox# ifconfig em0 mtu 1501
> ifconfig: ioctl (set mtu): Invalid argument
> sandbox# ifconfig em0 | grep mtu
> em0: flags=8843 metric 0 mtu 1499
> sandbox# ifconfig em0 mtu 1500
> sandbox# ifconfig em0 | grep mtu
> em0: flags=8843 metric 0 mtu 1500
> sandbox#
>
> sandbox# pciconf -lv | sed -n '/em0@/,/em1/p'
> em0@pci0:0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03
> hdr=0x00
> vendor = 'Intel Corporation'
> device = '82542 Gigabit Ethernet Controller'
> class = network
> subclass = ethernet
> em1@pci0:0:4:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03
> hdr=0x00
> sandbox#
>
> ===
>
> However, back in the 6.2 days it allowed it:
>
> ===
>
> [jayb@cactus ~]$ uname -v
> FreeBSD 6.2-PRERELEASE #0: Tue Dec 26 16:53:18 EST 2006
> r...@cactus.iplabs.att.com:/usr/obj/usr/src/sys/CACTUS
> [jayb@cactus ~]$
>
> [jayb@cactus ~]$ ifconfig em0
> em0: flags=8843 mtu 1500
> options=8
> inet 10.0.1.152 netmask 0xfffc broadcast 10.0.1.155
> ether 00:90:27:e3:0a:67
> media: Ethernet autoselect
> status: no carrier
> [jayb@cactus ~]$
>
> [jayb@cactus ~]$ sudo ifconfig em0 mtu 9000
> [jayb@cactus ~]$ ifconfig em0 | grep mtu
> em0: flags=8843 mtu 9000
> [jayb@cactus ~]$
>
> [jayb@cactus ~]$ pciconf -lv | sed -n '/em0@/,/none0@/p'
> em0@pci0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x02
> hdr=0x00
> vendor = 'Intel Corporation'
> device = '82542 Gigabit Ethernet Controller'
> class = network
> subclass = ethernet
> none0@pci0:4:0: class=0x088000 card=0x0767101e chip=0x9063101e rev=0x04
> hdr=0x00
> [jayb@cactus ~]$
>
Hmm.. Did jumbo frames really work on these cards for you? Intel claims:
"Adapters based on the Intel® 82542 and 82573V/E controller do not
support Jumbo Frames. These correspond to the following product names:
* Intel® PRO/1000 Gigabit Server Adapter
* Intel® PRO/1000 PM Network Connection "
As seen from code, the behavior was changed to match the description ("keep
old 82542 from using jumbo frames") and merged to 6-STABLE before 6.3.
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Reliable PCI wifi cards, and layer 7 filtering
On Thu, Feb 10, 2011 at 12:06:20PM -0500, Boris Kochergin wrote:
> On 02/10/11 10:56, Jeremy Chadwick wrote:
> >(I was considering cross-posting this to freebsd-pf but decided against
> >it, instead starting here first. Please keep me CC'd as I'm not
> >subscribed to freebsd-net)
> >
> >I'm looking into the possibility of using my home FreeBSD box as my home
> >firewall/NAT box, to replace my Linksys E2000 router (which runs Linux,
> >specifically the TomatoUSB firmware).
> >
> >I plan on using pf for the NAT and firewall layer. ipfw will not be
> >used (I have long since moved away from it). I've got solutions for
> >everything except two items:
> >
> >1) Wireless hardware support
> >- What consumer PCI cards are known to be reliable and have good
> > support on FreeBSD? It looks like anything that relies on ath(4)
> > might be a good choice, but I'm not sure what specific chipset is
> > considered decent/worthwhile, or if there's a specific model of
> > card from Vendor X(tm) which works great.
>
> I have a ton of Atheros 5212s deployed as access points. They are
> solid. Some field-tested implementations:
>
> - Netgear WPN311NAR
> - D-Link WDA-2320
Thank you very much -- exactly the kind of answer I was hoping for.
Sadly, neither of these products are manufactured and have been EOL'd
per the vendors. This doesn't sound like a wise purchase (for me
anyway). See below however.
> >- The card and driver need to support both 802.11b and 802.11g
> > simultaneously. 802.11n (for the future) would also be good.
>
> Simultaneous 802.11b and 802.11g works, but the 5212 chipset does
> not support 802.11n.
This helps a lot, thank you!
I dug around and it looks like the D-Link DWA-547 uses the AR5416
chipset, which is supported per ath(4)'s man page. This card also
offers 802.11n, but I'm not too focused on that at this point.
There's also the D-Link DWA-552 which uses the AR5416, but I see on some
Mac forums people are getting very frustrated with it (who knows what
the driver on OS X is like compared to FreeBSDs though; I imagine ours
is much more reliable). Anyway, getting 802.11b and 802.11g working
would be a fantastic start. I imagine if I have issues with the 802.11n
piece (when I get there) I can talk to Adrian about it.
> >- Driver or OS needs 128-bit WEP -- this is not a joke, I really do
> > have devices which do not do WPA or WPA2.
>
> This works.
>
> >- MAC address filtering is needed too, but it looks like that's
> > already available (looking at ifconfig(8) man page).
>
> Indeed.
Awesome. Perfect.
> >2) Layer 7 filtering
> {snipping your response -- but thank you VERY MUCH for it}
As it turns out, I realised I can solve this in an indirect way: by
simply using a different piece of software that doesn't pull in the ads.
The software I'm referring to is Yahoo Messenger and Windows Live, by
the way. By switching to Miranda IM, I can avoid all of this. Pshew!
Time for me to make some hardware purchases and give things a shot.
Today so far has been super horrible for me (fighting with my landlord
and neighbours over stupid stuff, resulting in my loss of sleep, and
some family matters), so the above information is surprisingly a very
positive moment for me.
I'll probably blog about my experience migrating from the E2000 to
FreeBSD. It'll be a learning experience for sure, but a fun one. First
time I've ever delved into the wireless AP world too...
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
cannot set mtu > 1500 on em0 optical Gig-E
Hi, For quite a while now it appears that mtu on my gigabit ethernet fiber em0 cards cannot be configured higher than the default 1500 bytes. Here's what I get when I attempt to set it lower and higher on a brand new 8.2-RC3 box: === sandbox# uname -v FreeBSD 8.2-RC3 #0: Sun Jan 30 06:52:51 UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sandbox# sandbox# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=18 ether 00:d0:b7:7c:f8:01 inet 10.1.2.3 netmask 0xff00 broadcast 10.1.2.255 media: Ethernet autoselect status: no carrier sandbox# ifconfig em0 mtu 1499 sandbox# ifconfig em0 | grep mtu em0: flags=8843 metric 0 mtu 1499 sandbox# ifconfig em0 mtu 1501 ifconfig: ioctl (set mtu): Invalid argument sandbox# ifconfig em0 | grep mtu em0: flags=8843 metric 0 mtu 1499 sandbox# ifconfig em0 mtu 1500 sandbox# ifconfig em0 | grep mtu em0: flags=8843 metric 0 mtu 1500 sandbox# sandbox# pciconf -lv | sed -n '/em0@/,/em1/p' em0@pci0:0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci0:0:4:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 sandbox# === However, back in the 6.2 days it allowed it: === [jayb@cactus ~]$ uname -v FreeBSD 6.2-PRERELEASE #0: Tue Dec 26 16:53:18 EST 2006 r...@cactus.iplabs.att.com:/usr/obj/usr/src/sys/CACTUS [jayb@cactus ~]$ [jayb@cactus ~]$ ifconfig em0 em0: flags=8843 mtu 1500 options=8 inet 10.0.1.152 netmask 0xfffc broadcast 10.0.1.155 ether 00:90:27:e3:0a:67 media: Ethernet autoselect status: no carrier [jayb@cactus ~]$ [jayb@cactus ~]$ sudo ifconfig em0 mtu 9000 [jayb@cactus ~]$ ifconfig em0 | grep mtu em0: flags=8843 mtu 9000 [jayb@cactus ~]$ [jayb@cactus ~]$ pciconf -lv | sed -n '/em0@/,/none0@/p' em0@pci0:2:0:class=0x02 card=0x10008086 chip=0x10008086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class= network subclass = ethernet none0@pci0:4:0: class=0x088000 card=0x0767101e chip=0x9063101e rev=0x04 hdr=0x00 [jayb@cactus ~]$ === Can this be made to work again? Thanks. Jay B. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154591: [msk] [panic] if_msk driver causes kernel panic (fatal trap while in kernel mode)
Synopsis: [msk] [panic] if_msk driver causes kernel panic (fatal trap while in kernel mode) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Feb 10 18:41:33 UTC 2011 State-Changed-Why: It seems there are two issues here. o Station address read by driver was ff:ff:ff:ff:ff:ff o PHY attach failure triggered panic I have no idea for the first issue. It seems you have 88E8056 Yukon Ultra controller which is known to have several stability issues with msk(4). Due to lack of hardware I was not able to track down the root cause of the issues. However I can't reproduce the panic on my box when I patched the driver to fail attaching a PHY. By chance are you using VIMAGE enabled kernel? If yes, how about removing VIMAGE in your configuration and test again? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Feb 10 18:41:33 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=154591 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Reliable PCI wifi cards, and layer 7 filtering
2011/2/10 Jeremy Chadwick [skip...] > I plan on using pf for the NAT and firewall layer. ipfw will not be > used (I have long since moved away from it). I've got solutions for > everything except two items: > > 1) Wireless hardware support > - What consumer PCI cards are known to be reliable and have good > support on FreeBSD? > [skip..] I' suggest to use PCI-mPCI adaptor and Wistron Neweb Atheros based cards. It is good for an AP. Use together with FreeBSD 8.1 or later. 2) Layer 7 filtering > > [skip...] I suppose you can use pf+squid as transparent filtering proxy ? I believe not much changed since that post: http://lists.freebsd.org/pipermail/freebsd-pf/2005-August/001450.html Item #2 above seems to be the kicker. Is there anything in the works > regarding such a capability? I'd be more than happy to test out code or > whatever. > > //batcilla ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Reliable PCI wifi cards, and layer 7 filtering
(I was considering cross-posting this to freebsd-pf but decided against it, instead starting here first. Please keep me CC'd as I'm not subscribed to freebsd-net) I'm looking into the possibility of using my home FreeBSD box as my home firewall/NAT box, to replace my Linksys E2000 router (which runs Linux, specifically the TomatoUSB firmware). I plan on using pf for the NAT and firewall layer. ipfw will not be used (I have long since moved away from it). I've got solutions for everything except two items: 1) Wireless hardware support - What consumer PCI cards are known to be reliable and have good support on FreeBSD? It looks like anything that relies on ath(4) might be a good choice, but I'm not sure what specific chipset is considered decent/worthwhile, or if there's a specific model of card from Vendor X(tm) which works great. - The card and driver need to support both 802.11b and 802.11g simultaneously. 802.11n (for the future) would also be good. - Driver or OS needs 128-bit WEP -- this is not a joke, I really do have devices which do not do WPA or WPA2. - MAC address filtering is needed too, but it looks like that's already available (looking at ifconfig(8) man page). 2) Layer 7 filtering - Specifically, the ability to block outbound packets in real-time which contain certain data in the TCP data portion of the packet. - More details: there are some HTTP-based requests which some software I use on XP submits to a server pool to return some ads. Filtering by IP address isn't possible since the A records of the FQDN often change. The software in question does not honour system proxy settings, so use of a proxy (Apache, squid, etc.) as a solution will not work. - I filter based on GET parameters or the HTTP: Host header. Thus, the matching mechanism doesn't need regex; simple substring matches (e.g. strcasestr()) would work fine. - Linux has kernel modules called ipt_web and xt_web which can do exactly this. They return TCP RST to the client which submit the packet, and never forwarding the original packet out the WAN. Item #2 above seems to be the kicker. Is there anything in the works regarding such a capability? I'd be more than happy to test out code or whatever. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: route messages from NDP
09.02.2011 17:56, Sergey Matveychuk wrote:
[skipped]
DST is IPv6 address, IFP and IFA I don't care and GATEWAY section is empty.
Let's see why:
$1 = {sdl_len = 54 '6', sdl_family = 18 '\022', sdl_index = 8, sdl_type
= 135 '\207', sdl_nlen = 0 '\0',
sdl_alen = 0 '\0', sdl_slen = 0 '\0', sdl_data = '\0' }
family is AF_LINK (18), it's a correct one. But sdl_alen, sdl_data are
zeros.
I forget to mention it's for 7.3-STABLE.
Looks like L2 (ARP/NDP) entries don't generate routing message at all
for 8.x+. It's seems a feature ARP-rewritting project. Am I right?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 80211s HWMP problem
On Thu, Feb 10, 2011 at 12:09 PM, Bernhard Schmidt wrote: > On Thursday, February 10, 2011 11:42:05 Monthadar Al Jaberi wrote: >> Okej, I run all four scenarios: >> >> 0->2 OK, but the first "ping -c 1" got lost >> 1->3 OK, >> 2->0 OK, >> 3->1 FAIL, works after "ping -c 1" 1->2 >> >> looks like path is built correct in one way only? :S > > I have no clue about the mesh code.. but, that smells like there are a > few frames discard which are supposed to fill the ARP table. Can I talk > you into dumping frames on the interfaces to figure out where those > discards happen? please :) > >> On Thu, Feb 10, 2011 at 11:19 AM, Bernhard Schmidt > wrote: >> > On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: >> >> Hej, wanna check if anyone encountered this problem: >> >> I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) >> >> >> >> But I cant ping from 3 to 0, or 0 to 3, without first ping between >> >> the nodes to fill the hwmp route tables. >> > >> > Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes >> > works though? >> > >> > -- >> > Bernhard > > -- > Bernhard > -- //Monthadar Al Jaberi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 80211s HWMP problem
On Thursday, February 10, 2011 11:42:05 Monthadar Al Jaberi wrote: > Okej, I run all four scenarios: > > 0->2 OK, but the first "ping -c 1" got lost > 1->3 OK, > 2->0 OK, > 3->1 FAIL, works after "ping -c 1" 1->2 > > looks like path is built correct in one way only? :S I have no clue about the mesh code.. but, that smells like there are a few frames discard which are supposed to fill the ARP table. Can I talk you into dumping frames on the interfaces to figure out where those discards happen? > On Thu, Feb 10, 2011 at 11:19 AM, Bernhard Schmidt wrote: > > On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: > >> Hej, wanna check if anyone encountered this problem: > >> I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) > >> > >> But I cant ping from 3 to 0, or 0 to 3, without first ping between > >> the nodes to fill the hwmp route tables. > > > > Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes > > works though? > > > > -- > > Bernhard -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 80211s HWMP problem
Okej, I run all four scenarios: 0->2 OK, but the first "ping -c 1" got lost 1->3 OK, 2->0 OK, 3->1 FAIL, works after "ping -c 1" 1->2 looks like path is built correct in one way only? :S On Thu, Feb 10, 2011 at 11:19 AM, Bernhard Schmidt wrote: > On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: >> Hej, wanna check if anyone encountered this problem: >> I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) >> >> But I cant ping from 3 to 0, or 0 to 3, without first ping between >> the nodes to fill the hwmp route tables. > > Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes works > though? > > -- > Bernhard > -- //Monthadar Al Jaberi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 80211s HWMP problem
On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: > Hej, wanna check if anyone encountered this problem: > I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) > > But I cant ping from 3 to 0, or 0 to 3, without first ping between > the nodes to fill the hwmp route tables. Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes works though? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
80211s HWMP problem
Hej, wanna check if anyone encountered this problem: I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) But I cant ping from 3 to 0, or 0 to 3, without first ping between the nodes to fill the hwmp route tables. This is hwmp+mesh debug output from one of the edge nodes when running "ping -c 1" wlan0: [00:15:6d:67:21:67] (fmt null) wlan0: [00:15:6d:67:21:67] (fmt null) wlan0: [00:15:6d:67:21:67] received PREQ, source 00:15:6d:65:fe:b2 wlan0: [00:15:6d:67:21:67] reply to 00:15:6d:65:fe:b2 wlan0: [00:15:6d:67:21:67] (fmt null) wlan0: [00:15:6d:65:fe:b2] start path discovery (src ) wlan0: [ff:ff:ff:ff:ff:ff] (fmt null) wlan0: [00:15:6d:67:21:67] (fmt null) wlan0: [00:15:6d:67:21:67] received PREP from 00:15:6d:67:21:67 wlan0: [00:15:6d:67:21:67] propagate PREP from 00:15:6d:67:21:67 wlan0: [ff:ff:ff:ff:ff:ff] (fmt null) wlan0: [00:15:6d:67:21:67] discard PREP for 00:15:6d:67:21:67, wrong seqno 6 != 22 br -- //Monthadar Al Jaberi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
