About wireless D-link DWL-G650 A1card installation.
Try to use the drivers from the http://madwifi.org/ project. Your card has a Wireless LAN chipset from Atheros, that's why it is not supported by prism drivers. Good luck. Nikita ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: About wireless D-link DWL-G650 A1card installation.
On 2006-04-13 20:19, Nik <[EMAIL PROTECTED]> wrote: > Try to use the drivers from the http://madwifi.org/ project. > Your card has a Wireless LAN chipset from Atheros, that's why > it is not supported by prism drivers. FWIW, A DWL-AG650 (HW ver: B2) works fine with `if_ath' on CURRENT here. I'm not sure how much of the support for Atheros cards has been backported to 6.X by Sam Leffler though... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: About wireless D-link DWL-G650 A1card installation.
Giorgos Keramidas wrote: On 2006-04-13 20:19, Nik <[EMAIL PROTECTED]> wrote: Try to use the drivers from the http://madwifi.org/ project. Your card has a Wireless LAN chipset from Atheros, that's why it is not supported by prism drivers. FWIW, A DWL-AG650 (HW ver: B2) works fine with `if_ath' on CURRENT here. I'm not sure how much of the support for Atheros cards has been backported to 6.X by Sam Leffler though... releng6 and head are in sync except for minor nits. All current shipping pci/cardbus cards except for those based on the pre-11n mimo chip are supported (and that chip will never be supported except w/ ndis). Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: About wireless D-link DWL-G650 A1card installation.
On 2006-04-13 12:12, Sam Leffler <[EMAIL PROTECTED]> wrote: >Giorgos Keramidas wrote: >>On 2006-04-13 20:19, Nik <[EMAIL PROTECTED]> wrote: >>>Try to use the drivers from the http://madwifi.org/ project. >>>Your card has a Wireless LAN chipset from Atheros, that's why >>>it is not supported by prism drivers. >> >> FWIW, >> >> A DWL-AG650 (HW ver: B2) works fine with `if_ath' on CURRENT here. >> I'm not sure how much of the support for Atheros cards has been >> backported to 6.X by Sam Leffler though... > > releng6 and head are in sync except for minor nits. All current > shipping pci/cardbus cards except for those based on the pre-11n mimo > chip are supported (and that chip will never be supported except w/ ndis). Thanks! This is amazing to know :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcpdump and ipsec
On Tue, 11 Apr 2006, Bjoern A. Zeeb wrote: > On Tue, 11 Apr 2006, Kelly Yancey wrote: > > Hi, > > > On Sun, 2 Apr 2006, Dmitry Pryanishnikov wrote: > > > >> On Sun, 2 Apr 2006, Bjoern A. Zeeb wrote: > Why not? IMHO it will be very useful feature: think about e.g. traffic > shaping for several different networks which are routed via the same > ipsec tunnel. Without the enc0, you can only shape them together, e.g.: > >>> > >>> why not shaping on the internal interface in case this is a gateway? > >>> You know src and dst there too. > >> > >> Gateway can also contain sources of traffic, and we should be able > >> to shape all outgoing or incoming traffic (not only transit packets, > >> but also locally-originated). > >> > >>> The only difference enc0 makes is for host-only-setups or if you want > >>> to see all your unencrpyted ipsec traffic on a gateway in one place. > >> > >> It seems to me that it's also useful for general traffic > >> shaping/accounting/filtering purposes. > >> > > I agree 100%. At work, we implemented the enc interface for FreeBSD > > 4.7 and 4.10 along with extending the divert interface such that we > > could perform filtering and NAT on packets after tunnel decapsulation. > > you know you can do this with what's in there already w/o enc(4)? > At least I have been doing it for more than two years now with 5.x > and greater. Actually this mail will get to you via such a setup. > Really? We aren't likely to move our product to 5.x or 6.x, but I'm curious: how are you performing NAT on your tunnelled traffic? If we were just talking about filtering, I would assume you were referring to the "ipsec" rule (which was introduced circa 4.9, hence not available when we implemented the enc interface on 4.7). However, I cannot figure out for the life of me how one would perform NAT on packets *inside* the IPsec tunnel without the enc interface. For example, the only pfil hook in the packet output path is is ip_output *after* IPsec encapsulation has occurred. Perhaps I'm missing something. > > > Just because one person doesn't have a use for the enc interface, does > > not mean that no one does. > > agreed. > > good arguments for example would also be that filtering IPSec traffic > with pf would becomen possible easily as long as there is no such > thing like the ipsec flag in ipfw... > I'm really looking forward to hearing how you are diverting traffic to natd before IPsec encapsulation. Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED],FreeBSD.org} - [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
