Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth
Synopsis: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Sun Aug 30 19:03:26 UTC 2009 Responsible-Changed-Why: I'll handle this http://www.freebsd.org/cgi/query-pr.cgi?pr=138331 ___ 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: Strange network issue in freebsd 8
Hi, Is this problem still happening? Cheers Sam On 24/01/2010 2:16 PM, Sherin George wrote: Hello, I am facing some sort of strange network issue in a freebsd server occasionally. OS: FreeBSD 8.0-RELEASE - amd64 Now, I have updated to FreeBSD 8.0-RELEASE-p2 The servers loses network connection once in a few days. I logged into console and verified that network is up. I even restarted network service using following command. /etc/rc.d/netif restart Still, it didn't fix. I checked /var/log/messages, but I am not getting any clue. == Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad0 finished. Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN Jan 23 02:20:02 myserver kernel: em0: link state changed to UP Jan 23 02:29:58 myserver reboot: rebooted by root Jan 23 02:29:58 myserver syslogd: exiting on signal 15 Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD Project. Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 23 02:31:31 myserver kernel: The Regents of the University of California. All rights reserved. Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 Jan 23 02:31:31 myserver kernel: r...@mason.cse.buffalo.edu: /usr/obj/usr/src/sys/GENERIC Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 == Network, TCP stack all were up. It was pinging gateway even. But, traceroute was not going beyond gateway. I believe the issue is not related to anything outside server since a reboot always fixes the issue. I will be grateful for any advice that can help me in troubleshooting this problem. -- Best Regards, Sherin ___ 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: Strange network issue in freebsd 8
that s why I 've been so in doubt using freebsd AMD64 release. On 28/01/2010 1:05 PM, Sherin George wrote: Hello Sam, The problem happened today again. I am getting this message on traceroute === traceroute: findsaddr: write: No such process When running a ping to 8.8.8.8, it says following. === ping: sendto: No route to host Please see the result of "netstat -rn" command. myserver# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaultXXX.XXX.XXX.241 UGS62 209247em0 127.0.0.1 link#3 UH 00lo0 XXX.XXX.XXX.240/29 link#1 U 00em0 XXX.XXX.XXX.242 link#1 UHS 00lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#3U lo0 fe80::1%lo0 link#3UHS lo0 ff01:3::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 = Note: I have replaced first three octets. I have checked netstat -m also. It is also not showing any problem. Could anyone please help me to sort out this issue. -- Thanks, Sherin On Thu, Jan 28, 2010 at 6:29 AM, sam wrote: Hi, Is this problem still happening? Cheers Sam On 24/01/2010 2:16 PM, Sherin George wrote: Hello, I am facing some sort of strange network issue in a freebsd server occasionally. OS: FreeBSD 8.0-RELEASE - amd64 Now, I have updated to FreeBSD 8.0-RELEASE-p2 The servers loses network connection once in a few days. I logged into console and verified that network is up. I even restarted network service using following command. /etc/rc.d/netif restart Still, it didn't fix. I checked /var/log/messages, but I am not getting any clue. == Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad0 finished. Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN Jan 23 02:20:02 myserver kernel: em0: link state changed to UP Jan 23 02:29:58 myserver reboot: rebooted by root Jan 23 02:29:58 myserver syslogd: exiting on signal 15 Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD Project. Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 23 02:31:31 myserver kernel: The Regents of the University of California. All rights reserved. Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 Jan 23 02:31:31 myserver kernel: r...@mason.cse.buffalo.edu: /usr/obj/usr/src/sys/GENERIC Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 == Network, TCP stack all were up. It was pinging gateway even. But, traceroute was not going beyond gateway. I believe the issue is not related to anything outside server since a reboot always fixes the issue. I will be grateful for any advice that can help me in troubleshooting this problem. -- Best Regards, Sherin ___ 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" ___ 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: TCP westwood
Can you incorporate its protocol into freebsd kernel? it is currently applicable to freebsd 4.4. See below. http://www.cs.ucla.edu/NRL/hpi/tcpw/implementation.html On 1/02/2010 9:49 AM, Jerry Toung wrote: Hello list, my employer is asking me to implement westwood, this is most likely happen on 8.0. before I start, I'd like to know for what reason it hasn't been done in the main tree? is it that no one has had time, or it only work in a lab environment? may be too many changes in the stack and it's not trivial? etc... Does any one out there has patch they can share? would the project be interested in a patch if I do this? thanks in advance. Jerry ___ 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/125906: [vap] second hostap interface (wlan1) unable to send traffic
Synopsis: [vap] second hostap interface (wlan1) unable to send traffic Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Thu Jul 24 05:21:31 UTC 2008 Responsible-Changed-Why: I promised to look at this http://www.freebsd.org/cgi/query-pr.cgi?pr=125906 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/125914: [ath] [panic] ath driver causes kernel panic in 7-STABLE
Synopsis: [ath] [panic] ath driver causes kernel panic in 7-STABLE State-Changed-From-To: open->feedback State-Changed-By: sam State-Changed-When: Thu Jul 24 05:22:10 UTC 2008 State-Changed-Why: need network setup information and information on how to reproduce the problem The line number pointed at indicates you are doing tx fragmentation which is highly unlikely--either that or your code does not match the kernel. Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Thu Jul 24 05:22:10 UTC 2008 Responsible-Changed-Why: need network setup information and information on how to reproduce the problem The line number pointed at indicates you are doing tx fragmentation which is highly unlikely--either that or your code does not match the kernel. http://www.freebsd.org/cgi/query-pr.cgi?pr=125914 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
The following reply was made to PR kern/124127; it has been noted by GNATS. From: sam <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Thu, 31 Jul 2008 16:00:19 +0400 --- Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering --- --- Jul 29 23:18:28 moon3 kernel: mskc0: port 0xdf00-0xdfff mem 0xdeefc000-0xdeef irq 16 at device 0.0 on pci2 Jul 29 23:18:28 moon3 kernel: msk0: on mskc0 Jul 29 23:18:28 moon3 kernel: miibus0: on msk0 --- --- FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 15:00:14 MSD 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MOON3 i386 --- I confirm this problem. /Vladimir Ermakov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/129022: [ath] ath cannot connect using WEP
Synopsis: [ath] ath cannot connect using WEP Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Fri Nov 28 18:13:53 UTC 2008 Responsible-Changed-Why: didn't know this existed; will check http://www.freebsd.org/cgi/query-pr.cgi?pr=129022 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/133178: [lagg] [wlan] lagg with wlan laggpport does not work
Synopsis: [lagg] [wlan] lagg with wlan laggpport does not work Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Sun Mar 29 17:19:47 UTC 2009 Responsible-Changed-Why: take responsibility http://www.freebsd.org/cgi/query-pr.cgi?pr=133178 ___ 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/132715: [lagg] [panic] Panic when creating vlan's on lagg interface
Synopsis: [lagg] [panic] Panic when creating vlan's on lagg interface Responsible-Changed-From-To: freebsd-net->jfv Responsible-Changed-By: sam Responsible-Changed-When: Thu Jul 9 15:22:48 UTC 2009 Responsible-Changed-Why: this is really a driver issue http://www.freebsd.org/cgi/query-pr.cgi?pr=132715 ___ 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/121063: [ath]: High wireless traffic on ATH causes high tx failed 'cuz FIFO underrun
Synopsis: [ath]: High wireless traffic on ATH causes high tx failed 'cuz FIFO underrun Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Mon Feb 25 17:18:49 UTC 2008 Responsible-Changed-Why: assign to the correct person http://www.freebsd.org/cgi/query-pr.cgi?pr=121063 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121061: [ath] [panic] panic while ejecting ath(4)-adapter during shutdown
Synopsis: [ath] [panic] panic while ejecting ath(4)-adapter during shutdown Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Mon Feb 25 17:19:23 UTC 2008 Responsible-Changed-Why: assign to the correct person http://www.freebsd.org/cgi/query-pr.cgi?pr=121061 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121720: [wpi] wpi doesnt work if kernel has options SCHED_ULE
Synopsis: [wpi] wpi doesnt work if kernel has options SCHED_ULE Responsible-Changed-From-To: freebsd-net->thompsa Responsible-Changed-By: sam Responsible-Changed-When: Tue Mar 18 21:54:31 UTC 2008 Responsible-Changed-Why: Hand to Andrew as he's been working on this driver. FWIW my guess is this is preemption causing problems with the questionable locking that used to be done by the driver. I think Andrew's recent round of changes eliminated that stuff. http://www.freebsd.org/cgi/query-pr.cgi?pr=121720 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/123552: [ath] [panic] kernel panic during network activity on ath0
Synopsis: [ath] [panic] kernel panic during network activity on ath0 State-Changed-From-To: open->feedback State-Changed-By: sam State-Changed-When: Fri May 9 17:10:24 UTC 2008 State-Changed-Why: need system and network configuration at a minimum Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Fri May 9 17:10:24 UTC 2008 Responsible-Changed-Why: need system and network configuration at a minimum; e.g. provide a dmesg and the output of ifconfig http://www.freebsd.org/cgi/query-pr.cgi?pr=123552 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use
The following reply was made to PR kern/157410; it has been noted by GNATS. From: Sam Bowne To: bug-follo...@freebsd.org Cc: Subject: Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use Date: Mon, 30 May 2011 19:16:20 -0700 --bcaec51a7ff262ecc004a488fdf6 Content-Type: text/plain; charset=ISO-8859-1 OpenBSD is not vulnerable, so it could probably be fixed by porting code from there. --bcaec51a7ff262ecc004a488fdf6 Content-Type: text/html; charset=ISO-8859-1 OpenBSD is not vulnerable, so it could probably be fixed by porting code from there. --bcaec51a7ff262ecc004a488fdf6-- ___ 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: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth
The following reply was made to PR bin/138331; it has been noted by GNATS. From: Sam Leffler To: bug-follo...@freebsd.org, sshutdow...@gmail.com Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Date: Sun, 30 Aug 2009 10:28:47 -0700 You appear to say this problem does not entirely stop traffic from flowing. Please provide a debug wpa_supplicant log that shows a complete session (i.e. a log with -d and/or -dd). Why do you set eapol_version=1. Is this really needed? What is your AP make/model? Note also that country=RU is ignored on freebsd. Sam ___ 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: toggle short / long preamble with hostapd
Sin wrote: Hello, Does anyone know how to enable short preamble in 7-STABLE ? I'm using ath with hostapd in ap mode. It seems there was an option in hostapd.conf, but this is not in FreeBSD's /usr/share/examples/hostapd/hostapd.conf The missing hostapd.conf option was found in google: # Short Preamble # This parameter can be used to enable optional use of short preamble for # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network performance. # This applies only to IEEE 802.11b-compatible networks and this should only be # enabled if the local hardware supports use of short preamble. If any of the # associated STAs do not support short preamble, use of short preamble will be # disabled (and enabled when such STAs disassociate) dynamically. # 0 = do not allow use of short preamble (default) # 1 = allow use of short preamble #preamble=1 my version of hostapd is " v0.5.10 " - I was not able to set this option On freebsd hostapd is _purely_ an authenticator; to configure 802.11 parameters you use ifconfig. hostapd.conf: interface=ath0 #preamble=1 debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=private wpa=1 wpa_passphrase=apassword wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rc.conf: hostapd_enable="YES" ifconfig_ath0="mode 11g hidessid mediaopt hostap" ifconfig ath0: ath0: flags=8943 metric 0 mtu 1500 ether 00:17:9a:4c:e7:83 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid dtimperiod 1 In ap mode you should not manually configure preamble; it should be selected according to the associated stations. What are you trying to accomplish? Sam ___ 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: toggle short / long preamble with hostapd
If I understand correctly you say that you have stations associated to a FreeBSD 7 ap operating in 11g and pings between the clients are slow. This occurred w/ the Dlink AP you're trying to replace until you manually forced short preamble. If I've got it right then this doesn't make sense as the ap should be using short preamble unless there are non-ERP stations on the channel. You can trace the status of short/long preamble with: wlandebug +assoc (you should get console msgs that when stations associate that indicate whether protection is enabled). I believe you'll also get the same info with: ifconfig wlan0 list sta on the ap. All this applies to 8.x; I've long since forgotten how things work on 7.x and I'd recommend that if you're doing a new install you use 8.0 and not 7.x. In general forcing short preamble should not have the effect you describe; just the opposite. If you want to figure out what's really going on then try to turn off stations that might be interfering (if possible). Otherwise you might try moving to a different channel to avoid whatever station is interfering. Another possibility is one or both stations are in power save mode and there's a bug in the RELENG_7 ap support; wlandebug +power might help for that. I can look at adding a knob to force short/long preamble. It would go into HEAD though and can't promise to backport to RELENG_7. Sam Sin wrote: Sam, Basically I have a dlink WBR-1310 thats in bridge mode connected to my current BSD router ( 6.3) I'm trying to replace this 1310 product with FreeBSD 7. The last problem i'm dealing with is poor preformance. When I use my current BSD 7 setup it works, but ping times from client to another or even to the access point are bad. 100 - 400ms round trip.I had this exact problem with the 1310. The fix was to change from long to short preable. Been fine ever since. I used three computers to prove this before emailing. Just swapping the 1310 for the 7-STABLE corrects this. The 1310 uses g only mode with short preamble getting less then 5ms ping times to each client and host and vice-versa I realize that hostapd.conf is just for the encryption. However ifconfig and ath man pages do not talk about this setting. - Original Message - From: "Sam Leffler" To: "Sin" Cc: Sent: Wednesday, September 02, 2009 11:16 AM Subject: Re: toggle short / long preamble with hostapd Sin wrote: Hello, Does anyone know how to enable short preamble in 7-STABLE ? I'm using ath with hostapd in ap mode. It seems there was an option in hostapd.conf, but this is not in FreeBSD's /usr/share/examples/hostapd/hostapd.conf The missing hostapd.conf option was found in google: # Short Preamble # This parameter can be used to enable optional use of short preamble for # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network performance. # This applies only to IEEE 802.11b-compatible networks and this should only be # enabled if the local hardware supports use of short preamble. If any of the # associated STAs do not support short preamble, use of short preamble will be # disabled (and enabled when such STAs disassociate) dynamically. # 0 = do not allow use of short preamble (default) # 1 = allow use of short preamble #preamble=1 my version of hostapd is " v0.5.10 " - I was not able to set this option On freebsd hostapd is _purely_ an authenticator; to configure 802.11 parameters you use ifconfig. hostapd.conf: interface=ath0 #preamble=1 debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=private wpa=1 wpa_passphrase=apassword wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rc.conf: hostapd_enable="YES" ifconfig_ath0="mode 11g hidessid mediaopt hostap" ifconfig ath0: ath0: flags=8943 metric 0 mtu 1500 ether 00:17:9a:4c:e7:83 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid dtimperiod 1 In ap mode you should not manually configure preamble; it should be selected according to the associated stations. What are you trying to accomplish? Sam ___ 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: kmem_map too small panics with Soekris/Atheros access point [ath rate control]
Boris Kochergin wrote: > Stef Walter wrote: >> Boris Kochergin wrote: >> > I, too, recall the days when you had multiple rate-control algorithms to > choose from, but that doesn't appear to be the case anymore. As a > workaround, I wrote a little script that checks if that part of the > driver is using more than 200 KiB of memory and run it every minute via > cron. It seems to be doing its job so far: You can still select the ath rate control module. Static kernel config is unchanged; for modules you must export ATH_RATE=onoe or similar (check modules/ath/Makefile). Please file a PR if this does not work. Sam ___ 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: low ath speed on 8.0-RC1
Denis Shaposhnikov wrote: > Hello, > > On Tue, 22 Sep 2009 11:43:31 -0500 > Stef Walter wrote: > >>> I see also it periodically changes "media:" between OFDM/54Mbps and >>> OFDM/48Mbps. >> That's normal behavior. ath_rate_sample is finding the OFDM speed at >> which traffic flows best. > > May be do you know why I'm getting normal speed (2Mb/s) for some time > after using "ifconfig bssid ..." command only? When you set the bssid you reset the state of the tx rate control code and that probably resets the tx rate to 24M. Sam ___ 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: wpa_supplicant signal quality vs level
David Horn wrote: > I have noticed that 'wpa_cli scan_results' always reported a signal > level of 0 for every bssid found during a scan. I found this a bit > odd (especially since ifconfig wlan0 list scan reported good signal > level data) > > FreeBSD 8.0-RC1 r197417 amd64 > > Looking at the /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c > source, I found: > > in wpa_driver_bsd_get_scan_results() > > wsr->qual = sr->isr_rssi; > wsr->level = 0; /* XXX? */ > > This hardcodes the signal level to 0, and sets the signal quality to > the rssi value. > > Looking around at the source, it seems that wpa_supplicant does not > ever use the quality variable, but instead looks at the level variable > in wpa_scan_result_compar (). Correct. There is no notion of signal _quality_ in freebsd because it's a nebulous value defined by each vendor using a heuristic algorithm that reflects their idea of what "good" is. Because various parts of the code use qual to compare the signal strength of stations we use the one suitable value we do have. > > In an attempt to try to figure out what signal level vs signal quality > in wpa_supplicant context means, I found this: > http://lists.shmoo.com/pipermail/hostap/2006-December/014831.html, and > a feb-2009 change to scan_helpers.c (which drivers_freebsd.c seems to > be partially based upon) > http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=e1b525c3560614cc56c85b7d060f540900c4da34 > > So, it seems that some wpa_supplicant drivers use quality, and some > use level. Since quality(wsr->qual) does not seem to be used in > current wpa_supplicant in freebsd, should it instead look like ?: > (attached as an SVN diff with some debug as well) > > wsr->ssid_len = sr->isr_ssid_len; > wsr->freq = sr->isr_freq; > wsr->noise = sr->isr_noise; > - wsr->qual = sr->isr_rssi; > - wsr->level = 0; /* XXX? */ > + wsr->qual = 0; /* XXX? */ > + wsr->level = sr->isr_rssi; > wsr->caps = sr->isr_capinfo; > wsr->maxrate = getmaxrate(sr->isr_rates, sr->isr_nrates); > vp = ((u_int8_t *)sr) + sr->isr_ie_off; > > > Should we just set qual to 0, or should we set qual to > rssi/rssi_max*100 (if we can determine rssi_max for a particular wlan > interface) > > In any case, do you want me to file a PR on this ? I believe this issue is purely cosmetic in that you see 0's in the scan results display. If you want to fill that data in with something be my guest but unless the values correspond to the data actually used to make decision it's just going to cause confusion. It might be simpler to just strip the value from the scan results print out. Sam ___ 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: low ath speed on 8.0-RC1
Denis Shaposhnikov wrote: > Hello, > > On Thu, 24 Sep 2009 19:46:41 -0700 > Sam Leffler wrote: > >>> May be do you know why I'm getting normal speed (2Mb/s) for some >>> time after using "ifconfig bssid ..." command only? >> When you set the bssid you reset the state of the tx rate control code >> and that probably resets the tx rate to 24M. > > Does it possible to disable tx rate control and lock wlan0 on > OFDM/54Mbps? Think it isn't right tha I have only 900K of transfer speed > without using of bssid command. The bssid cmd is unrelated to your low tx rate; this is a byproduct of (apparent) poor communication conditions. All the cmd does is reset state so the tx rate is yanked back to 24M from which it falls again to where the rate control code believes is the right value. For setting a fixed tx rate man ifconfig. If you want to explore look at enabling tx rate control msgs with wlandebug rate and/or look at sysctl dev.ath.0.sample_stats=-1. Sam ___ 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: low ath speed on 8.0-RC1
Stef Walter wrote: > Denis Shaposhnikov wrote: >> Hello, >> >> On Thu, 24 Sep 2009 19:46:41 -0700 >> Sam Leffler wrote: >> >>>> May be do you know why I'm getting normal speed (2Mb/s) for some >>>> time after using "ifconfig bssid ..." command only? >>> When you set the bssid you reset the state of the tx rate control code >>> and that probably resets the tx rate to 24M. >> Does it possible to disable tx rate control and lock wlan0 on >> OFDM/54Mbps? Think it isn't right tha I have only 900K of transfer speed >> without using of bssid command. > > Off the top of my head: > > ifconfig ath0 media OFDM/54Mbps Not on 8.0 and later; man ifconfig for ucastrate. Sam ___ 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: uath under FreeBSD 8.0-STABLE
Steven Friedrich wrote: On Thursday 24 December 2009 05:09:42 pm Weongyo Jeong wrote: OK. It looks weird idProduct didn't be decreased 1 after loading the firmware. And what I'd like to see is the *full* result of the following steps: 1. plugs in your USB device. 2. run commands as follows: # kldload if_uath # dmesg | tail # uathload -v -d /dev/ugen4.3 # dmesg | tail In a theory, after loading the firmware normally the device which at the moment idProduct is 0x4251 is detached and reseted then it should be reattached with idProduct(0x4250). regards, Weongyo Jeong Opps, I'm sorry, the reply I just sent ws wrong because once you've used uathload, you have to unplugplug the device before you can run it again. So here it is: Load firmware ar5523.bin (builtin) to /dev/ugen4.3 send block 0: 147368 bytes remaining : data... : wait for ack...flags=0x14 total=149416 <...snip...> The device should detach and be re-enumerated w/ a different device id that the driver attaches to. Hard to say why it does not. uathload should be automatically run by devd but it appears the devd rules file I did got lost (don't see it in the tree). Sam ___ 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 for Sun Fire X4250
Hi, This server is built with Xeon cpu processor, Intel based. Can FreeBSD 8+ fully compatible with this server like those ordinary Intel i386 machine? Thanks SW ___ 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: freebsd for Sun Fire X4250
Hi Gavin, The reason I want to stick with i386 is because about few years ago when I tried AMD release of FreeBSD, it didn't have the same level of proficiency as i386 release of FreeBSD - packagThat was my impression at that time. I hope it has changed in this years. Is there any major installation difference between AMD (64) and i386 release of FreeBSD (8.0)? Thank you for your answers. Sam On Tue, Jan 12, 2010 at 10:05 AM, Gavin Atkinson wrote: > On Mon, 11 Jan 2010, Sam Wun wrote: >> This server is built with Xeon cpu processor, Intel based. >> Can FreeBSD 8+ fully compatible with this server like those ordinary >> Intel i386 machine? > > Although it's hard to say (the Sun website doesn't realy give enough spec > details), I'd be surprised if it doesn't work. FreeBSD runs very nicely > on every Intel- and amd64-based Sun machine I've tried it on. > > You'll almost certainly want to use the FreeBSD amd64 release rather than > i386, and I'd probably recommend 8.0-RELEASE, although 7.2 should work > fine. > > By the way, this is the wrong list for questions like this: if you have > any others, you're probably best off directing them to > freebsd-questi...@freebsd.org > > Gavin > ___ 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: A-MPDU transmission in net80211 on FreeBSD 8
Alexander Egorenkov wrote:
Sorry, i posted the wrong comment.
Here is the comment which i don't understand:
/*
* NB: don't assign a sequence # to potential
* aggregates; we expect this happens at the
* point the frame comes off any aggregation q
* as otherwise we may introduce holes in the
* BA sequence space and/or make window accouting
* more difficult.
*
* XXX may want to control this with a driver
* capability; this may also change when we pull
* aggregation up into net80211
*/
Thanks.
What is unclear?
Sam
On Wed, Jan 27, 2010 at 8:04 PM, Alexander Egorenkov <
egore...@googlemail.com> wrote:
Hi,
i'm implementing a device driver for a 802.11n NIC under FreeBSD 8
und experimented with A-MPDU transmission. I looked into net80211 code
and there is some code which implements this feature but it worked not very
well for me.
I noticed e.g. that sequence numbers are not assigned to A-MPDU frames
and found this comment in file ieee80211_output.c :
/*
* Check if A-MPDU tx aggregation is setup or if we
* should try to enable it. The sta must be associated
* with HT and A-MPDU enabled for use. When the policy
* routine decides we should enable A-MPDU we issue an
* ADDBA request and wait for a reply. The frame being
* encapsulated will go out w/o using A-MPDU, or possibly
* it might be collected by the driver and held/retransmit.
* The default ic_ampdu_enable routine handles staggering
* ADDBA requests in case the receiver NAK's us or we are
* otherwise unable to establish a BA stream.
*/
Can somebody elaborate this description to me please.
Thanks.
ALex.
___
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: A-MPDU transmission in net80211 on FreeBSD 8
Alexander Egorenkov wrote: Why doesn't 802.11 stack assign sequence numbers to A-MPDU frames ? Because if net80211 does the assignment it may be wrong. As the comment says, if tx aggregation causes frames to be q'd above the h/w then by the time they are sent OTA the pre-assigned seq# may be invalidated by other frames going out ahead of it. When sequence numbers are not assigned to A-MPDU frames, then BA doesn't work with my AP. I tried to assign sequence numbers to A-MPDU frames in my device driver and then BAs worked with my AP. That is what the comment says to do. And what is meant by aggregation queue ? Where is that queue anf how do i use it ? The aggregation q is the mechanism used to hold frames waiting for additional frames to aggregated into an A-MSDU/A-MPDU. The queue is typically wherever the aggregation work is done. Some devices do this in h/w, others require the host handle this. When done in the host it can be done in the driver or above. The intent has always been to have net80211 implement tx aggregation that a driver can fallback on but I never did the work. All the 11n drivers I've done have either handled tx aggregation in h/w or in the driver. Thanks. On Sun, Jan 31, 2010 at 4:43 AM, Sam Leffler <mailto:s...@errno.com>> wrote: Alexander Egorenkov wrote: Sorry, i posted the wrong comment. Here is the comment which i don't understand: /* * NB: don't assign a sequence # to potential * aggregates; we expect this happens at the * point the frame comes off any aggregation q * as otherwise we may introduce holes in the * BA sequence space and/or make window accouting * more difficult. * * XXX may want to control this with a driver * capability; this may also change when we pull * aggregation up into net80211 */ Thanks. What is unclear? Sam On Wed, Jan 27, 2010 at 8:04 PM, Alexander Egorenkov < egore...@googlemail.com <mailto:egore...@googlemail.com>> wrote: Hi, i'm implementing a device driver for a 802.11n NIC under FreeBSD 8 und experimented with A-MPDU transmission. I looked into net80211 code and there is some code which implements this feature but it worked not very well for me. I noticed e.g. that sequence numbers are not assigned to A-MPDU frames and found this comment in file ieee80211_output.c : /* * Check if A-MPDU tx aggregation is setup or if we * should try to enable it. The sta must be associated * with HT and A-MPDU enabled for use. When the policy * routine decides we should enable A-MPDU we issue an * ADDBA request and wait for a reply. The frame being * encapsulated will go out w/o using A-MPDU, or possibly * it might be collected by the driver and held/retransmit. * The default ic_ampdu_enable routine handles staggering * ADDBA requests in case the receiver NAK's us or we are * otherwise unable to establish a BA stream. */ Can somebody elaborate this description to me please. Thanks. ALex. ___ freebsd-net@freebsd.org <mailto: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 <mailto: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: Strange network issue in freebsd 8
great work. Thanks On Tue, Feb 2, 2010 at 3:46 PM, Li, Qing wrote: > Just an update on this issue and to letting you know your > report is not ignored. > > I have been working with Sherin George offline and we have > Been pulling information off Sherin's server box. > > The box becomes unresponsive after about 4 days. The routing > table is fine is properly accessed. The ARP table is properly accessed. > Through packet capture, the packets seem to flow into the driver but > appear > to be stuck somewhere after the driver handoff. The device stats do not > show > any link related errors. The device is "em". > > Initially I was suspecting the flow-table module, but after disabling > the flow-table lookup and various experiments, the problem points to L2 > (after ether_output). > > According to Sherin, the box will regain network connectivity after > some time. > > At this point I am thinking about creating a special debug build and > run it in Sherin's environment. > > -- Qing > > > >> -Original Message- >> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- >> n...@freebsd.org] On Behalf Of Kenneth Hilmersson >> Sent: Friday, January 29, 2010 1:46 PM >> To: freebsd-net@freebsd.org >> Subject: Strange network issue in freebsd 8 >> >> > The servers loses network connection once in a few days. I logged >> into >> > console and verified that network is up. I even restarted network >> service >> > using following command. >> > >> > /etc/rc.d/netif restart >> > >> > Still, it didn't fix. >> > >> > I checked /var/log/messages, but I am not getting any clue. >> >> >> I see exactly the same thing. My network dies after a couple of days > in >> the same manner. >> >> My friend have problems with different network cards in 8.0: >> em, msk, age locks up and with sis the network performance drops to >> 0.1kbps after awhile. >> >> >> BR >> Kenneth >> ___ >> 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" > ___ 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: HT rate set in net80211 not changeable for STA
Alexander Egorenkov wrote:
And is any API in planning that would make it possible to change the
advertised HT rate set by STA during run time and not at compile time ? E.g.
ieee80211_set_ht_rateset :-)
On Sat, Feb 6, 2010 at 3:44 PM, Rui Paulo wrote:
On 6 Feb 2010, at 08:28, Alexander Egorenkov wrote:
Hi,
the HT rate set advertized by a STA is hardcoded in net80211
and the maximum MCS is 15, but my device also supports MCS32 (HT
duplicate
mode).
Is there a possibility to change the HT rates set advertized by a STA
except changing
the code and recompiling net80211 stack ?
Not really.
The advertised rate set should be initially set according to the
capabilities of the device. There were no devices > 2x2 when I wrote
the code so MCS15 is the max. To support such devices you need to do
more than just grow the rateset.
Making the rate set user-controllable would be ok to add but probably
used only for testing.
Sam
___
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: Software TKIP group rekeying and phase1 issue
Bernhard Schmidt wrote:
Hi,
When hostapd triggers rekeying of the group key, wpa_supplicant successfully
sets the correct new key. On first use of the new key tkip_mixing_phase1()
should be applied before decrypting any frames, tkip_decrypt() does this as
if (iv32 != (u32)(key->wk_keyrsc[tid] >> 16) || !ctx->rx_phase1_done) {
tkip_mixing_phase1(ctx->rx_ttak, key->wk_key,
wh->i_addr2, iv32);
ctx->rx_phase1_done = 1;
}
But, after a rekeying event, neither of this condition match, especially as
rx_phase1_done is no longer zero, therefore tkip_mixing_phase1() isn't called
which leads to dropped frames with "TKIP ICV mismatch on decrypt" messages.
A working solution for that is to set rx_phase1_done to zero inside
tkip_setkey(). I'm not sure whether that is the best solution or if it is
better to set/reset the wk_keyrsc sequence, at least this diff works for me
and few other over at the Forums.
Index: sys/net80211/ieee80211_crypto_tkip.c
===
--- sys/net80211/ieee80211_crypto_tkip.c(revision 203242)
+++ sys/net80211/ieee80211_crypto_tkip.c(working copy)
@@ -144,6 +144,8 @@ tkip_setkey(struct ieee80211_key *k)
return 0;
}
k->wk_keytsc = 1;/* TSC starts at 1 */
+ if (k->wk_flags & IEEE80211_KEY_GROUP)
+ ctx->rx_phase1_done = 0;
return 1;
}
Reseting this flag in setkey looks right but why only for group keys? I
don't think you want to reset the keyrsc unless instructed; if I recall
a new RSC may be sent down by the authenticator when plumbing a key--but
it's been a while since I looked at this.
Have you looked at other implementations?
Sam
___
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: HT rate set in net80211 not changeable for STA
Alexander Egorenkov wrote: On Sat, Feb 6, 2010 at 10:52 PM, Sam Leffler <mailto:s...@errno.com>> wrote: The advertised rate set should be initially set according to the capabilities of the device. There were no devices > 2x2 when I wrote the code so MCS15 is the max. To support such devices you need to do more than just grow the rateset. But my device is a 2T2R device and supports MCS32 (HT duplicate mode). MCS32 is special; as you indicate it forces duplicate signal on the upper and lower channels in HT40. There is no support for MCS32 in net80211. Sam ___ 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: A-MPDU transmission in net80211 on FreeBSD 8
That's great to hear. I take it this is HT20? I believe you can get
40-60 Mb/s @ MCS15 w/o AMPDU and 80-100 Mb/s w/ AMPDU. In HT40 I've
gotten 160-180 Mb/s for TCP netperf (5GHz) and 220+ Mb/s for
unidirectional streams (netperf -t UDP_STREAM). Note that once you get
to these higher rates things like TCP window sizes become important and
doing things like TSO in s/w can give noticeable speed boosts.
Sam
Alexander Egorenkov wrote:
Hi,
thanks for your help, I implemented A-MPDU Tx in my Ralink driver now
and it works very good.
I have average Tx rate about 4.5~5 MBytes/s now :-) The Ralink chip that
i have implements the frame queue in hardware so i had only to assign
sequence numbers, set BA window size and MPDU density and it worked,
lucky me :-)
Alex.
On Sun, Jan 31, 2010 at 8:20 PM, Sam Leffler <mailto:s...@errno.com>> wrote:
Alexander Egorenkov wrote:
Why doesn't 802.11 stack assign sequence numbers to A-MPDU frames ?
Because if net80211 does the assignment it may be wrong. As the
comment says, if tx aggregation causes frames to be q'd above the
h/w then by the time they are sent OTA the pre-assigned seq# may be
invalidated by other frames going out ahead of it.
When sequence numbers are not assigned to A-MPDU frames, then BA
doesn't work with my AP.
I tried to assign sequence numbers to A-MPDU frames in my device
driver and then BAs worked
with my AP.
That is what the comment says to do.
And what is meant by aggregation queue ? Where is that queue anf
how do i use it ?
The aggregation q is the mechanism used to hold frames waiting for
additional frames to aggregated into an A-MSDU/A-MPDU. The queue is
typically wherever the aggregation work is done. Some devices do
this in h/w, others require the host handle this. When done in the
host it can be done in the driver or above. The intent has always
been to have net80211 implement tx aggregation that a driver can
fallback on but I never did the work. All the 11n drivers I've done
have either handled tx aggregation in h/w or in the driver.
Thanks.
On Sun, Jan 31, 2010 at 4:43 AM, Sam Leffler mailto:s...@errno.com> <mailto:s...@errno.com
<mailto:s...@errno.com>>> wrote:
Alexander Egorenkov wrote:
Sorry, i posted the wrong comment.
Here is the comment which i don't understand:
/*
* NB: don't assign a sequence # to potential
* aggregates; we expect this happens at the
* point the frame comes off any aggregation q
* as otherwise we may introduce holes in the
* BA sequence space and/or make window accouting
* more difficult.
*
* XXX may want to control this with a driver
* capability; this may also change when we pull
* aggregation up into net80211
*/
Thanks.
What is unclear?
Sam
On Wed, Jan 27, 2010 at 8:04 PM, Alexander Egorenkov <
egore...@googlemail.com <mailto:egore...@googlemail.com>
<mailto:egore...@googlemail.com
<mailto:egore...@googlemail.com>>> wrote:
Hi,
i'm implementing a device driver for a 802.11n NIC under
FreeBSD 8
und experimented with A-MPDU transmission. I looked into
net80211 code
and there is some code which implements this feature
but it
worked not very
well for me.
I noticed e.g. that sequence numbers are not assigned to
A-MPDU frames
and found this comment in file ieee80211_output.c :
/*
* Check if A-MPDU tx aggregation is setup or
if we
* should try to enable it. The sta must be
associated
* with HT and A-MPDU enabled for use. When
the policy
* routine decides we should enable A-MPDU we
issue an
* ADDBA request and wait for a reply. The
frame being
* encapsulated will go out w/o using A-MPDU,
or possibly
* it might be collected by the driver and
held/retransmit.
* The default ic_ampdu_enable routine handles
staggering
* ADDBA requests in case the receiver N
Re: net80211 and PPI header
Alexander Egorenkov wrote: What exactly do you need? We should be able to extend radiotap. 1. Not only one RSSI but for every antenna (also in dBm) 2. HT greenfield/HT mixed indicator 4. Number of spatial streams (STBC) 3. A-MPDU support (MPDU density, A-MPDU reassembly) The most important one is A-MPDU support, i think. Wireshark supports PPI header and can handle A-MPDUs very nicely. That's it for now :-) I discussed integrating PPI w/ radiotap back when I did the existing 11n support but never got anywhere (>3 years ago?). The PPI stuff was done under contract to Intel and the folks involved never contacted anyone about doing it within radiotap instead. It looked entirely possible to leverage the PPI decoder in wireshark to handle AMPDU reassembly from the radiotap decoder but I never got to it. As to the other state Greenfield was nonexistent (and unclear if it'd make it out of draft status) when I did stuff or I'd have reserved a bit for it. The # of streams can be implied from the MCS unless I misunderstand. I do want the per-antenna/chain state (rssi, nf, evm) but was looking for things to stabilize before adding to radiotap--each device/driver exports different data and I wanted something that was enough of a superset to handle the most devices. Adopting PPI data structures would be reasonable. I would prefer to not emit PPI but instead augment radiotap. We've standardized on radiotap for 802.11 and all the drivers now use it (or should use it). I'll leave it to others to deal w/ the politics of the radiotap noobs; the technical details of doing this are straightforward. Sam ___ 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: Missing WME information element causes problems with 802.11n
Alexander Egorenkov wrote:
I have encountered a problem with a 802.11n router Belkin F5D8631au.
The beacon and association response frames sent by this router do not
contain
WME information element although 802.11n mode is enabled. These frames
contain
HT capability IE and HT info. Because WME IE is missing in association
responses,
the net80211 stack does not set IEEE80211_NODE_QOS flag
(See ieee80211_sta.c:sta_recv_mgmt:IEEE80211_FC0_SUBTYPE_ASSOC_RESP).
But the flag IEEE80211_NODE_HT is set because the frame contains HT
capability and HT info.
So, because IEEE80211_NODE_QOS is not set, all outgoing DATA frames sent to
the Belkin AP
do not contain QoS field in the 802.11 frame header. And it causes problems
with the Belkin AP.
Is the QoS not mandatory for 802.11n mode ?
Why is QoS enabled only if an WME IE is found in association response ?
Would it be not right to enable QoS also if HT mode is enabled but no WME IE
was found ?
The WME ie is mandatory; these routers are non compliant. We can
probably hack net80211 to auto-enable WME if an HTCAP ie is present but
that is a total hack. Were the HT ie's using the IEEE codes or the
Vendor OUI codes? It could be this is old Broadcom code--at one point
Broadcom intentionally didn't advertise WME. If this is the legacy HT
stuff then perhaps we can add the auto-enable conditional on the legacy
HT support.
Sam
___
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: Setting HT capabilities in net80211
Alexander Egorenkov wrote:
Currently there is no possibility to set some HT capabilities in e.g. an
association request frame.
The function ieee80211_add_htcap_body in ieee80211_ht.c simply sets some HT
capabilities to zero.
For example, there is no way to set HT extended capabilities which i need
for my 802.11n device driver.
I could of course patch the function on my system and recompile the kernel
but it would be really nice
to have official support of extended HT capabilities (and all other HT caps)
in net80211. The header file
ieee80211.h defines the necessary HT capability constants but they are not
used in net80211 to
set extended HT capabilities in association request frames.
Can you be more specific? The current code dynamically sets those
capabilities that can be changed and the others are fixed according to
the capabilities of the hw/driver. Of course patches are always
welcome; what's there reflects what was needed for the projects I worked on.
Sam
___
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: max_linkhdr defaults to 16, too short ?
On Apr 20, 2010, at 5:55 PM, Luigi Rizzo wrote: On Tue, Apr 20, 2010 at 07:28:45PM +0200, Luigi Rizzo wrote: just noticed that sys/kern/uipc_domain.c still sets max_linkhdr=16 as a default. The value is often used to reserve head space in mbufs for the MAC header. As such, 16 is too short for systems that make use of vlans, and the effect might be that we would need additional mbuf entries or at least move stuff down as the vlan tag is added. Any objection to bumping the default to 20 ? forgot to mention: max_linkhdr is available as a sysctl, kern.max_linkhdr , but other than that, there is no code in sys/ that sets the value, so systems are stuck at 16 unless users override the default. We need a coherent way to handle max_linkhdr. I hacked it in net80211 to insure bridged 802.11 frames have sufficient contiguous space in the mbufs but never did something like define an api and generate events/callbacks on changes. Last I looked doing this right was non- trivial. Sam ___ 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"
autom4te: not found - please help.
Hi, With FreeBSD 8.1 RC1, Can anyone tell me how to resolve the following error from building cyrus-sasl2? configure: creating ./config.status autom4te --language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh > libltdl/config/ltmain.in autom4te: not found *** Error code 127 Stop in /usr/ports/devel/libtool22/work/libtool-2.2.6b. *** Error code 1 Stop in /usr/ports/devel/libtool22. *** Error code 1 Stop in /usr/ports/security/cyrus-sasl2. *** Error code 1 Thanks S ___ 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: autom4te: not found in FreeBSD 8.1RC1 - please help.
Hi, With FreeBSD 8.1 RC1, I got the following error when building cyrus-sasl2 in the Ports: configure: creating ./config.status autom4te --language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh libltdl/config/ltmain.in autom4te: not found *** Error code 127 Can anyone tell me how to resolve this problem? Your help is very much appreciated. Thanks Sam ___ 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: autom4te: not found - please help.
Since this is a fresh installed 8.1, I just found that there is no perl in the system. But there is also error when building perl, shown as below: Cleaning current config before rebuilding Makefile... make -f Makefile.old clean > /dev/null 2>&1 ../../miniperl "-I../../lib" "-I../../lib" Makefile.PL "INSTALLDIRS=perl" "INSTALLMAN3DIR=none" "PERL_CORE=1" "LIBPERL_A=libperl.so" Writing Makefile for DynaLoader ==> Your Makefile has been rebuilt. <== ==> Please rerun the make command. <== false *** Error code 1 Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader. make config failed, continuing anyway... Makefile out-of-date with respect to Makefile.PL Cleaning current config before rebuilding Makefile... make -f Makefile.old clean > /dev/null 2>&1 ../../miniperl "-I../../lib" "-I../../lib" Makefile.PL "INSTALLDIRS=perl" "INSTALLMAN3DIR=none" "PERL_CORE=1" "LIBPERL_A=libperl.so" Writing Makefile for DynaLoader ==> Your Makefile has been rebuilt. <== ==> Please rerun the make command. <== false *** Error code 1 Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader. *** Error code 1 Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9. *** Error code 1 Stop in /usr/ports/lang/perl5.8. *** Error code 1 Stop in /usr/ports/lang/perl5.8. I have followed what it told and rerun make command, it still generated this error. Thanks Sam On Fri, Jun 18, 2010 at 10:06 PM, Sam Wun wrote: > Hi, > > With FreeBSD 8.1 RC1, > Can anyone tell me how to resolve the following error from building > cyrus-sasl2? > > configure: creating ./config.status > autom4te --language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh >> libltdl/config/ltmain.in > autom4te: not found > *** Error code 127 > > Stop in /usr/ports/devel/libtool22/work/libtool-2.2.6b. > *** Error code 1 > > Stop in /usr/ports/devel/libtool22. > *** Error code 1 > > Stop in /usr/ports/security/cyrus-sasl2. > *** Error code 1 > > Thanks > S > ___ 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: FreeBSD NAT-T patch integration
Larry Baird wrote: And how do I know that it works ? Well, when it doesn't work, I do know it, quite quickly most of the time ! I have to chime in here. I did most of the initial porting of the NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every line of code during this process. I found no security problems during the port. Like Yvan, my company uses the NAT-T patches commercially. Like he says, if it had problems, we would hear about it. If the patches don't get commited, I highly suspect Yvan or myself would try to keep the patches up todate. So far I have done FAST_IPSEC pacthes for FreeBSD 4,5,6. Yvan did 7 and 8 by himself. Keeping up gets to be a pain after a while. I do plan to look at the FreeBSD 7 patches soon, but it sure would be nice to see it commited. This whole issue seems ridiculous. I've been trying to get the NAT-T patches committed for a while but since I'm not setup to do any IPSEC testing have deferred to others. If we need to break a logjam I'll pitch in. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge turns off checksum offload of members?
Andrew Thompson wrote: On Tue, Jul 01, 2008 at 12:51:42PM +0300, Stefan Lambrev wrote: Hi, May be a stupid questions, but: 1) There are zero matches of IFCAP_TOE in kernel sources .. there is not support for TOE in 7.0, but may be this is work in progress for 8-current? Yes, its in current only. Just remove IFCAP_TOE. 2) In #define BRIDGE_IFCAPS_MASK (IFCAP_TOE|IFCAP_TSO|IFCAP_TXCSUM) - TOE should be repleaced with RXCSUM or just removed? 3) Why RX is never checked? In my case this doesn't matter because em turn off both TX and RX if only one is disabled, but probably there is a hardware, that can separate them e.g. RX disabled while TX enabled? Rx does not matter, whatever isnt offloaded in hardware is just computed locally such as checking the cksum. Its Tx that messes up the bridge, if a outgoing packet is generated locally on an interface that has Tx offloading, it may actaully be sent out a different bridge member that does not have that capability. This would cause it to be sent with an invalid checksum for instance. The bridge used to just disable Tx offloading but this patch you are testing makes sure each feature is supported by all members. 4) I'm not sure why bridge should not work with two interfaces one of which support TX and the other does not? At least if I turn on checksum offload only on one of the interfaces the bridge is still working ... Andrew Thompson wrote: - cut - This patch should do that, are you able to test it Stefan? cheers, Andrew P.S. I saw very good results with netisr2 on a kernel from p4 before few months .. are there any patches flying around so I can test them with 7-STABLE? :) This issue has come up before. Handling checksum offload in the bridge for devices that are not capable is not a big deal and is important for performance. TSO likewise should be done but we're missing a generic TSO support routine to do that (I believe, netbsd has one and linux has a GSO mechanism). Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/124753: net80211 discards power-save queue packets early
Sepherosa Ziehau wrote: On Thu, Jun 19, 2008 at 6:30 PM, <[EMAIL PROTECTED]> wrote: Synopsis: net80211 discards power-save queue packets early Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Jun 19 10:29:47 UTC 2008 Responsible-Changed-Why: reassign to networking team. http://www.freebsd.org/cgi/query-pr.cgi?pr=124753 In How-To-Repeat, you said: "Then associate a recent Windows Mobile 6.1 device to the FreeBSD box running hostapd ..." In Description, you said: "The WM6.1 device recv ps-poll's for packets every 20 seconds ..." AFAIK, STA sends ps-poll to AP; AP does not send ps-poll to STA. Why did your windows STA receive ps-poll from freebsd AP? Did you capture it by using 802.11 tap? And which freebsd driver were you using? Your problem looks like: - Either freebsd AP did not properly configure TIM in beacons, which could be easily found out by using 802.11 tap. But I highly suspect if you were using ath(4), TIM would be misconfigured. - Or your windows STA didn't process TIM according to 802.11 standard. The PR states the listen interval sent by the station is 3 (beacons) and the beacon interval is 100TU. This means the AP is required to buffer unicast frames for only 300TU which is ~300 ms. But according to the report the Windows device is polling every 20 seconds so there's no guarantee any packets will be present (even with the net80211 code arbitrarily using 4x the list interval specified by the sta). I find it really hard to believe a device would poll every 20 secs so something seems wrong in what's reported/observed. Given that defeating the aging logic just pushed the problem elsewhere it sounds like there's something else wrong which (as you note) probably requires a packet capture to understand. I'm pretty sure TIM is handled correctly in RELENG_7 but a packet capture would help us verify that. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration [CFR/CFT]
Sam Leffler wrote: Larry Baird wrote: And how do I know that it works ? Well, when it doesn't work, I do know it, quite quickly most of the time ! I have to chime in here. I did most of the initial porting of the NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every line of code during this process. I found no security problems during the port. Like Yvan, my company uses the NAT-T patches commercially. Like he says, if it had problems, we would hear about it. If the patches don't get commited, I highly suspect Yvan or myself would try to keep the patches up todate. So far I have done FAST_IPSEC pacthes for FreeBSD 4,5,6. Yvan did 7 and 8 by himself. Keeping up gets to be a pain after a while. I do plan to look at the FreeBSD 7 patches soon, but it sure would be nice to see it commited. Please test/review the following patch against HEAD: http://people.freebsd.org/~sam/nat_t-20080616.patch This adds only the kernel portion of the NAT-T support; you must provide the user-level code from another place. The main difference from the patches floating around are in the ctloutput path (adding proper locking for HEAD) and decap of ESP-in-UDP frames. Assuming folks are ok w/ these changes I'll commit to HEAD. Once this stuff goes in we can look at getting the user-mode mods into the tree. Sam PS. Thanks especially to Matthew Grooms who tested an earlier version and fixed a bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration [CFR/CFT]
Bjoern A. Zeeb wrote: On Wed, 16 Jul 2008, Sam Leffler wrote: Hi, Please test/review the following patch against HEAD: http://people.freebsd.org/~sam/nat_t-20080616.patch This adds only the kernel portion of the NAT-T support; you must provide the user-level code from another place. The main difference from the patches floating around are in the ctloutput path (adding proper locking for HEAD) and decap of ESP-in-UDP frames. Assuming folks are ok w/ these changes I'll commit to HEAD. Once this stuff goes in we can look at getting the user-mode mods into the tree. I have skipped through the patch. My main concern at the moment is the API (pfkey stuff) to userland as Yvan had stated in <[EMAIL PROTECTED]>. I know that at the moment there seems to be one public (pseudo) reference implementation this all works together but there might be/are other people not using libipsec from ipsec-tools. The point is changing the API once this hits the tree will be hard to detect at a later point if at all (unless with a __FreeBSD_version or (another) library version bump/sym versioning). We are still missing other things I think not mentioned elswhere like partial checksum recalculation. Please send me your specific issues; I haven't seen any comments about "partial checksum recalculations". I still wonder if we'd have all the information (at the right place) in the kernel so we could easily add support for that at a later time w/o having to change APIs again. Considering that it seems noone using this patch in products has implemented this .. I dunno. It's something that is already mentioned in the introduction of RFC 3947 and in 3.1.2. of 3948 and thus should be very obvious to anyone ever seriously thought of finishing a proper more than "it works for me" version of the patch. I don't see any of the above blocking this work going in. Forcing people to maintain out-of-tree patches for years because of vague concerns is unproductive. This code is used by at least 2 vendors shipping products. Some minor things I had seen not reported so far: I have seen two printfs that should be changed to proper logging, ... /NAT-T OA present s,bave,have, in "...in the SPD: This means we bave a non-generated" but maybe change the entire comment. "non-generated SPD" is kind of wrong wording. I'd happily go through another patch once the missing/to be corrected things were addressed. Please apply your changes to the p4 branch or fix 'em when the code hits CVS. I've see no concrete rationale for holding this work out. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration [CFR/CFT]
VANHULLEBUS Yvan wrote: On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote: On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote: [...] Please test/review the following patch against HEAD: http://people.freebsd.org/~sam/nat_t-20080616.patch I have tested the RELENG7 version of the patch, and it works well. But I noticed a misplaced #endif at the beginning of udp_ctloutput(), which will generate problems if INET6 is not defined: [] After some more testing, I found another issue: in udp4_espdecap(), when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should not be discarded, but just returned for normal processing. Please edit the sam_nat_t branch in p4 or send a patch I can apply. And I also have doubts about a change in udp_ctloutput(), in the switch statement which process optval and searches for an UDP_ENCAP_ESPINUDP* flag. The way you changed it forces a flags cleanup anytime. I don't see why someone would set both UDP_ENCAP_ESPINUDP and UDP_ENCAP_ESPINUDP_NON_IKE, but as I was tracking down a problem, I changed it again to be processed "the old way" to ensure it was not the source of the issue. Sorry but I'm not clear on what you are saying. The code changed the behaviour of setting udp encapsulation so that only one of UDP_ENCAP_ESPINUDP and UDP_ENCAP_ESPINUDP_NON_IKE can be set a time. The original code from you permitted both flags to be set but the code that handled the encap/decap assumed only one was set. Sam, did you have a good reason to change that part of the code, or was it mostly to have a more compliant coding style ? See above. Updated patches are available for HEAD, RELENG7 and RELENG63 (yeah :-) here: http://people.freebsd.org/~vanhu/NAT-T/ Please all notice that there is still the word "test" in patches names. Sorry again I don't understand what you write. Sam Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration [CFR/CFT]
VANHULLEBUS Yvan wrote: [Larry, I kept you in an explicit CC, even if I guess you suscribed to the list] On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote: On Wed, 16 Jul 2008, Sam Leffler wrote: Hi, Hi. [...] My main concern at the moment is the API (pfkey stuff) to userland as Yvan had stated in <[EMAIL PROTECTED]>. It is also one of my main concerns actually. I know that at the moment there seems to be one public (pseudo) reference implementation this all works together but there might be/are other people not using libipsec from ipsec-tools. Well, people who use another libipsec are expected to "just" not see NAT-T extensions. The only "real issue" is that, actually, NAT-T ports are sent though sockaddr structs, when RFC 2367 says that zeroing ports MUST be done (section 2.3.3). There is already an open ticket on ipsec-tools side to cleanup that part of the code on userland's size of PFKey interface, and I hope it will be done for 0.8.0 release (sorry, no release date for now). As soon as I'll have a working patch on userland, I'll do the work on FreeBSD's kernel side. I hope everything will be done within a few weeks, but I already know that we'll have backward compatibility issues with various kernels (ipsec-tools runs at least on FreeBSD, NetBSD, Linux and MacOSX). With regard to changing the kernel API. First, this is HEAD and api's can change. I intentionally have said nothing about MFC and didn't touch user code. Getting the support into the kernel enables use and testing which was the point of getting the logjam broken so full NAT-T support can ship w/ 8.0. I committed to get everything necessary in the tree in time for 8.0 but now that you have direct access to freebsd's repo I think that's less important. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration [CFR/CFT]
Bjoern A. Zeeb wrote: On Mon, 21 Jul 2008, Sam Leffler wrote: Hi Sam, We are still missing other things I think not mentioned elswhere like partial checksum recalculation. Please send me your specific issues; I haven't seen any comments about "partial checksum recalculations". So what has kept you from reading the RFCs for the patch you were working on? "It works for me" does not mean "It's right and all done". Nothing; so far as I can see your comments are irrelevant and unless you're willing to spell out the specific concerns you have I'm not giving them much weight. As I said when I got involved in this discussion I've wanted NA-T support in FreeBSD for a long time. I've tried several ways to make this happen but now am actively putting my time into making it happen. If you don't want to participate that's fine. Otherwise please provide constructive help. Again, remember this work is going in HEAD and all the changes are conditionally compiled. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration [CFR/CFT]
VANHULLEBUS Yvan wrote:
On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote:
VANHULLEBUS Yvan wrote:
[]
After some more testing, I found another issue: in udp4_espdecap(),
when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just returned for normal processing.
Please edit the sam_nat_t branch in p4 or send a patch I can apply.
As Perforce is really really new for me, here is the patch:
--- sys/netinet/udp_usrreq.cTue Jul 22 11:04:30 2008
+++ sys/netinet/udp_usrreq.cMon Jul 21 21:30:52 2008
@@ -797,8 +797,8 @@ udp_ctloutput(struct socket *so, struct
if (INP_CHECK_SOCKAF(so, AF_INET6)) {
INP_WUNLOCK(inp);
error = ip6_ctloutput(so, sopt);
-#endif
} else {
+#endif
INP_WUNLOCK(inp);
error = ip_ctloutput(so, sopt);
#ifdef INET6
@@ -846,7 +846,9 @@ udp_ctloutput(struct socket *so, struct
case SOPT_GET:
switch (sopt->sopt_name) {
case UDP_ENCAP:
+#ifdef IPSEC_NAT_T
optval = inp->inp_flags & INP_ESPINUDP_ALL;
+#endif
INP_WUNLOCK(inp);
error = sooptcopyout(sopt, &optval, sizeof optval);
break;
@@ -1236,11 +1238,9 @@ udp4_espdecap(struct socket *so, struct
} else {
uint64_t marker;
- if (payload <= sizeof(uint64_t) + sizeof(struct esp)) {
- udpstat.udps_hdrops++; /* XXX? */
- m_freem(m);
- return NULL;/* discard */
- }
+ if (payload <= sizeof(uint64_t) + sizeof(struct esp))
+ return m; /* NB: no decap */
+
bcopy(data + off, &marker, sizeof(uint64_t));
if (marker != 0)
return m; /* NB: no decap */
<<< end of diff
There is an extra #ifdef, which I noticed yesterday when I tried to
compile using a wrong kernel conf file (without NAT_T support).
Please send patches as attachments so I can apply them directly. I have
hand-transcribed the above. Thank you.
Sam
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath using hostap sets MTU to 2290
John T. Yocum wrote: Hello, I have a system running pfSense, which is built on top of FreeBSD 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which when I enable hostap, changes it's MTU to 2290. If an explanation is listed on a man page, I apologize, I did try searching. Any ideas why this might happen? It doesn't appear to be a pfSense issue, as it appears their code actually tries to set the MTU to 1500. Only reason I ask here, is I noticed in my searching on Google, I noticed others that aren't running pfSense have their MTU set to 2290. MTU on an 802.11 network is 2290. If you don't want the default then change it. If you cannot then please provide the exact steps you take that do not work. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath using hostap sets MTU to 2290 / channel '0' no longer works
Chris Buechler wrote: Sam Leffler wrote: John T. Yocum wrote: Hello, I have a system running pfSense, which is built on top of FreeBSD 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which when I enable hostap, changes it's MTU to 2290. If an explanation is listed on a man page, I apologize, I did try searching. Any ideas why this might happen? It doesn't appear to be a pfSense issue, as it appears their code actually tries to set the MTU to 1500. Only reason I ask here, is I noticed in my searching on Google, I noticed others that aren't running pfSense have their MTU set to 2290. MTU on an 802.11 network is 2290. If you don't want the default then change it. If you cannot then please provide the exact steps you take that do not work. Thanks for the reply, Sam! I have an ath card I'm working with that sets its MTU to 1500 in hostap, so there seems to be inconsistent behavior here. This card, specifically: http://www.netgate.com/product_info.php?products_id=130 No ath card sets an mtu; this is done in s/w in the host. We added a forced MTU of 1500 to wireless cards in pfSense (as a stop gap testing measure since they're frequently bridged to Ethernet and the bridge won't work unless the wireless card is 1500), but it still appears to revert to 2290 for people. I cannot help w/ an issue unless I can reproduce it. The above does not help me. As I said previously when a card is attached to the system (e.g. on boot or card insert) the default mtu setup is 2290. If it changes at a later then some program is doing it. This is on RELENG_7 and later. I haven't had time to fully quantify this, and I can't replicate it with the hardware I have at hand as it uses 1500 without specifying any MTU. If I can come up with better info and steps to replicate, I'll post back. While I have your attention, we have found one change in behavior between 6.x and 7.0. I'm not sure if it's a regression or intentional, any insight would be appreciated. "ifconfig ath0 channel '0'" used to work in 6.x with hostap mode. Now users are finding their AP does not show up unless they manually specify a channel. Running that command shows: # ifconfig ath0 channel '0' ifconfig: unknown/undefined channel number 0 flags 0x0 At boot time when the above is set, I get (dmesg|grep ath0): Jul 27 18:24:44 pfSense kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Jul 27 18:24:44 pfSense kernel: ath0: mem 0x8801-0x8801 irq 10 at device 0.0 on cardbus1 Jul 27 18:24:44 pfSense kernel: ath0: [ITHREAD] Jul 27 18:24:44 pfSense kernel: ath0: using obsoleted if_watchdog interface Jul 27 18:24:44 pfSense kernel: ath0: Ethernet address: 00:0b:6b:20:3a:4d Jul 27 18:24:44 pfSense kernel: ath0: mac 5.9 phy 4.3 radio 3.6 Jul 27 18:24:47 pfSense kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150) Jul 27 18:24:47 pfSense kernel: ath0: unable to reset hardware; hal status 0 The above was also seen by a pfSense user with a different ath card, miniPCI I believe. Numerous people have reported that "auto" channel (what our GUI translates to channel 0 in ifconfig) no longer works with ath cards on 7.0-based versions when they were working fine previously on 6.2 and 6.3-based versions. Use ifconfig ath0 channel - (or any) to clear any locked channel. This is in fact a change; never noticed before. I can either change the man page or try to hack ifconfig but I'd prefer to just deprecate the use of "0". The ifconfig man page mentions using channel - or any should do the same as 0. Both of those do not produce any error messages (they return no output), but the AP still isn't visible. I haven't confirmed this part, but I believe running ifconfig ath0 down / ifconfig ath0 up after running either channel - or channel 'any' will make it work. Not sure on behavior at boot time. When you clear the locked down channel the device should scan. You can observe this by monitoring state w/ ifconfig or enable debug msgs with wlandebug scan+state. I tested an old wi(4) card with channel '0' and it still works the same as in 6.x. 6.x and 7.x are very different systems and wi is not a good indicator of changes in the system. I was waiting to post until I had time to gather more definitive information but since someone else brought it up, thought I'd add to it. If I can help gather any additional information please let me know. I'll fix the man page at least right now; thanks. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging wireless station
David Cornejo wrote: hi, i would like to bridge a wireless client to ethernet (in 8-CURRENT) - the last bug in the if_bridge man page says this is a no-no. the question is whether this could be worked around - don't need the highest performance, so maybe netgraph or even a userland daemon would work. i don't have any ability to do anything at the access point end so some of the tunneling protocols are out any thoughts are appreciated, The man page is out of date; HEAD has WDS support now so you can bridge traffic that's 4-address encapsulated. You might try to be more clear what you're trying to setup. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging wireless station
Andrew Thompson wrote: On Mon, Aug 04, 2008 at 12:13:09PM -1000, David Cornejo wrote: hi, i would like to bridge a wireless client to ethernet (in 8-CURRENT) - the last bug in the if_bridge man page says this is a no-no. The bridge man page needs to be updated as its possible to do this now. the question is whether this could be worked around - don't need the highest performance, so maybe netgraph or even a userland daemon would work. i don't have any ability to do anything at the access point end so some of the tunneling protocols are out The system supports wdslegacy and dwds modes. lecacy takes a static bssid address to forward the traffic to, this mode can only be encrypted with wep. dwds is a unique feature where the card connects as a standard station (with any crypto, such as wpa), and then is set into wds mode. This isnt hooked into the system scripts at all and needs to be finished off. Have a look at tools/tools/net80211/scripts/setup.wds* and try some scenarios out. A nit: dwds probably needs to be integrated with hostapd as there's some work involved that's best in a long-running application and I can't imagine anyone using it w/o some form of security. Having hostapd handle this would also simplify configuration. The integration work is straightforward and would be a good project for someone trying to learn about the wireless facilities. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging wireless station
Without WDS you'll need to bridge/tunnel at a different layer.
Sam
David Cornejo wrote:
I have an existing AP that I have no control over (assume it doesn't
support WDS) sitting on a clinic LAN. I have a second LAN that I need
to bridge to the clinic LAN through a client wireless device. I had
done this about a year ago using vtun (via an 'ethernet' tunnel), but
then I had some control over the AP.
thanks,
dave c
On Mon, Aug 4, 2008 at 12:48 PM, Sam Leffler <[EMAIL PROTECTED]> wrote:
David Cornejo wrote:
hi,
i would like to bridge a wireless client to ethernet (in 8-CURRENT) -
the last bug in the if_bridge man page says this is a no-no.
the question is whether this could be worked around - don't need the
highest performance, so maybe netgraph or even a userland daemon would
work. i don't have any ability to do anything at the access point end
so some of the tunneling protocols are out
any thoughts are appreciated,
The man page is out of date; HEAD has WDS support now so you can bridge
traffic that's 4-address encapsulated. You might try to be more clear what
you're trying to setup.
Sam
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
Luigi Rizzo wrote: On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: [EMAIL PROTECTED] wrote: The only thing i can think of is that it's the UDP checksum, residing beyond hlen, which is overwritten somewhere in the call to if_simloop -- in which case perhaps a better fix is to m_pullup() the udp header as well ? It is the checksum that gets trashed, yes. ... The m_*() routines actually have reasonable comments, it just seems the wrong one was used here. Actually, m_copy() has been legacy for some time now -- see comments. The API is undocumented, but in this specific function the reason for using one rather than the other is undocumented. Especially, if you use m_dup() then the call to m_pullup should be unnecessary. That's why I suggested to explain clearly what is wrong in the original code, so even if now we only apply a temporary bandaid (for lack of time, etc.) hopefully later this can be reverted to something more efficient such as pulling up the UDP header as well. I agree that doing the deep copy is just papering over a bigger problem. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
[EMAIL PROTECTED] wrote: At Tue, 26 Aug 2008 14:50:33 + (UTC), Bjoern A. Zeeb wrote: On Tue, 26 Aug 2008, George V. Neville-Neil wrote: Hi, At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: I have tried it and it does fix my problem. RIP2 over multicast works again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. So wait a second; what was the m_pullup vs. m_dup thing? Has anyone actually tried that? I mean using a sledgehammer if a mitten would be enough is kind of .. uhm. You get it. Perhaps I'm confused, I've been off dealing with other issues for a few days, but m_pullup doesn't make a copy of the packet or its fields, only makes sure that it's contiguous in memory. Am I wrong in that? Since the bug is that two pieces of code modify the same data, in ways that interfere, I'm not sure how we can avoid making a copy. It might be nice to limit the copy, but we'd still need two copies, one for the loopback device and one for the real device. pull the headers up. copy just the headers. no deep copy. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
Luigi Rizzo wrote: On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote: [EMAIL PROTECTED] wrote: At Tue, 26 Aug 2008 14:50:33 + (UTC), Bjoern A. Zeeb wrote: On Tue, 26 Aug 2008, George V. Neville-Neil wrote: Hi, At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: I have tried it and it does fix my problem. RIP2 over multicast works again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. So wait a second; what was the m_pullup vs. m_dup thing? Has anyone actually tried that? I mean using a sledgehammer if a mitten would be enough is kind of .. uhm. You get it. Perhaps I'm confused, I've been off dealing with other issues for a few days, but m_pullup doesn't make a copy of the packet or its fields, only makes sure that it's contiguous in memory. Am I wrong in that? Since the bug is that two pieces of code modify the same data, in ways that interfere, I'm not sure how we can avoid making a copy. It might be nice to limit the copy, but we'd still need two copies, one for the loopback device and one for the real device. pull the headers up. copy just the headers. no deep copy. and to be more explicit - the result of m_pullup is that the number of bytes specified as m_pullup argument are in a private piece of memory -- the 'data' region within the mbuf -- so you can freely play with them without trouble. That is why i suggested to just increase the argument to m_pullup by the size of the udp header so one can overwrite the checksum within the mbuf without touching the shared part in the cluster (if any). Hmm, never considered the m_pullup guaranteed a private copy (but I see it in the code). The original semantics were just that the data was contiguous. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
Andrew Thompson wrote: On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote: On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: Luigi Rizzo wrote: ... and to be more explicit - the result of m_pullup is that the number of bytes specified as m_pullup argument are in a private piece of memory -- the 'data' region within the mbuf -- so you can freely play with them without trouble. That is why i suggested to just increase the argument to m_pullup by the size of the udp header so one can overwrite the checksum within the mbuf without touching the shared part in the cluster (if any). Hmm, never considered the m_pullup guaranteed a private copy (but I see it in the code). The original semantics were just that the data was contiguous. funny, i thought the guarantee of a writable copy was also part of the original semantics :) The bridge code does a deep copy of the packet for each interface it broadcasts on due the firewall code modifying the headers. It sounds like this should just be a copy+pullup instead. I'd not do that. I think there are paths that assume the deep copy. Right now the network code is very poor honoring read-only-ness of mbuf chains. To get this right we need to do a good audit. I know I hit issues when doing some tricks w/ marking rx buffers read-only to avoid cache flushes. netbsd trys to be more pedantic but still has problems too. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MSI Wind Notebook's network interfaces
Milan Obuch wrote: > On Friday 05 September 2008 18:13:45 Kevin Downey wrote: >> On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch <[EMAIL PROTECTED]> wrote: >>> [ snip ] >>> Could anybody comment on wireless interface? >> I could not get the internal wifi to work with ndis wrapper. It >> appears that using the rtw driver netbsd, openbsd, and dragonflybsd >> all support this chipset. I found a (polish?) webpage with a very >> preliminary attempt at porting the rtw driver. The author of the port >> said it doesn't really work. >> >> I just gave up and bought a usb wifi stick. > > Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do not > show working wireless interface/no driver attached. How did you try it? Do > you have any reference, alternatively? > > Wireless interface is not top priority for me at a moment, but if it were not > too hard, I will try. > > My notebook is Wind U100 series... is yours similar or perhaps the same? rtw supports only an old 11b only part. If you've really got a RealTek wireless part in this laptop then it's not supported by any bsd driver I know of. There's a linux driver of unknown quality that someone can use to build a bsd driver but given how cheap wireless parts are your best bet is to just replace the card. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST
Frank Mayhar wrote: On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: On Mon, 15 Sep 2008, Henri-Pierre Charles said: I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. For the record, the same is true for my Acer Aspire One. After updating sys/contrib/dev/ath to HEAD I now have a working ath0. hooray! On the other hand, mine doesn't. I have a brand new Lifebook E8420 and I believe the Atheros wireless chipset is an a/g/n chipset. It lists as: [EMAIL PROTECTED]:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 I read somewhere that this chipset is supported by the new ath9k Linux driver but, of course, I run FreeBSD. That's a merlin part (aka 9280); I've got untested changes to support it. Unfortunately I don't have a card so it may take a while to get something out. Unfortunately it's not feasible for me to send out test code to try until I can actually work w/ a card. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Backporting iwn(4): WPA auth hangs... Help!
Paul B. Mahol wrote: On 9/21/08, Gavin Atkinson <[EMAIL PROTECTED]> wrote: Hi all, I'm attempting to backport the iwn(4) driver for the Intel 4965 driver from -HEAD to RELENG_7 and am getting stuck with it at one particular point: WPA authentication times out. I've so far tried to both take the -HEAD driver and de-vapify etc. it, and also to take a pre-vap version of the driver and bring in required changes. Both fail in exactly the same way, with authentication timing out. I have verified that the laptop can successfully connect to the same network with -HEAD and the same wpa_supplicant.conf file. I've attached the log file from wpa_supplicant. Code can be found at http://people.freebsd.org/~gavin/iwn/ - I'm currently working with the updated-from-pre-vap version so that's the one that generated the log file and is probably the best to look at. Sadly I don't have the infrastructure at the moment to test if the driver works with WEP. Any help or pointers would be greatfully received, Thanks! Gavin I can't understand why is IEEE80211_C_STA removed in both versions. ___ There is no explicit STA capability in RELENG_7; it only exists in HEAD. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hostapd network issue
didn't complete the group key handshake. I don't see a timeout msg so not sure exactly why. WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:1e:c2:bf:74:60 reason 2 bsd_sta_deauth: addr=00:1e:c2:bf:74:60 reason_code=2 hostapd dropped the station. WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECTED WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port Could not set station 00:1e:c2:bf:74:60 flags for kernel driver (errno=22). ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: deauthenticated due to local deauth request GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: Invalid argument ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: Invalid argument ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: Invalid argument hostapd was notified by net80211 the station went away so it tried to purge any keys but state was already gone. This is normal and the msgs can be ignored. Signal 2 received - terminating You hit ^C and stopped hostapd. Flushing old station entries bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 Deauthenticate all stations bsd_set_privacy: enabled=0 bsd_set_ieee8021x: enabled=0 bsd_set_iface_flags: dev_up=0 ___ There is nothing unusual in the log. Your problems are likely lower; e.g. loss of communication between the ap and sta. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC?
[EMAIL PROTECTED] wrote: Synopsis: [request] Isn't it time to enable IPsec in GENERIC? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) for consideration http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 Last I checked IPSEC added noticeable overhead. Before anyone does this you need to measure the cost of having it enabled but not used. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC?
Max Laier wrote: On Saturday 18 October 2008 19:05:26 Sam Leffler wrote: [EMAIL PROTECTED] wrote: Synopsis: [request] Isn't it time to enable IPsec in GENERIC? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) for consideration http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 Last I checked IPSEC added noticeable overhead. Before anyone does this you need to measure the cost of having it enabled but not used. It should be possible to turn IPSEC into a module - maybe only loadable on boot to avoid locking issues. This would reduce the overhead to a handful of function pointer checks that should not impact performance (thanks to modern branch prediction and cache sizes). This would have to be measured as well, of course. Maybe this should go to the project page? It's a good junior kernel hacker project, I believe. I believe the most important issue are the SADB checks in the tx path. It used to be possible to do them cheaply by checking a single ptr value but now it's much more expensive. My memory is hazy as it's been a while. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Gathering Hardware State During a Driver Initiated Kernel Panic
David Christensen wrote: Is there a method or callback in FreeBSD where a driver can be notified that it has caused a kernel panic in order to generate a dump of internal hardware state information? I've written a sysctl call for manual intervention and can handle some "expected" hardware events completely in the driver but I don't know of a way to get control again in cases where the driver wasn't expecting a failure. Not sure how one can deduce a driver is at fault but you might define a ddb command for the driver and invoke that on panic using the ddb script mechanisms (see ddb(4)). Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Determining counts or size of routing table? (netstat performance?)
Julian Elischer wrote: Mykel wrote: Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a handful of peers... I'd like to determine the size of the FIB/kernel routing table. OpenBGPd does not give me this data, and on my duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. I'm not looking for exact numbers, just something I can poll via NetSNMP and plot in cacti... I looked though netstat, route, sysctl, vmstat, even pored over an snmpwalk... can't find anything. Been asking around, and the only suggestion I've received was to write a daemon that dumps the table and then monitors the changes, but I'm not a programmer, nor could I find any tool in ports that might assist in this. I'd be happy with almost any metric that gives me some absolute reference as to how big my routing table is so I can get some nice pretty graphs done up. Not pounding the system every 60-300 seconds would be very nice. Any suggestions? Or does everyone just pipe netstat? Is there a MIB for sysctl or NetSNMP I'm missing? no. It's a hard thing to do so that is why it hasn't been done yet. Perhaps I misunderstand his question but trouble% vmstat -m |grep routetbl routetbl14 2K -33875 16,32,64,128,256 should show memory allocated to the routing table. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Determining counts or size of routing table? (netstat performance?)
Mykel wrote: Sam Leffler wrote: Julian Elischer wrote: Mykel wrote: Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a handful of peers... I'd like to determine the size of the FIB/kernel routing table. OpenBGPd does not give me this data, and on my duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. I'm not looking for exact numbers, just something I can poll via NetSNMP and plot in cacti... I looked though netstat, route, sysctl, vmstat, even pored over an snmpwalk... can't find anything. Been asking around, and the only suggestion I've received was to write a daemon that dumps the table and then monitors the changes, but I'm not a programmer, nor could I find any tool in ports that might assist in this. I'd be happy with almost any metric that gives me some absolute reference as to how big my routing table is so I can get some nice pretty graphs done up. Not pounding the system every 60-300 seconds would be very nice. Any suggestions? Or does everyone just pipe netstat? Is there a MIB for sysctl or NetSNMP I'm missing? no. It's a hard thing to do so that is why it hasn't been done yet. Perhaps I misunderstand his question but trouble% vmstat -m |grep routetbl routetbl14 2K -33875 16,32,64,128,256 should show memory allocated to the routing table. I was also shown (privately) this: # vmstat -z | grep "rtentry" rtentry: 120,0, 198, 474, 12190,0 Either works for me, so I'm now happy. Thanks! Yes, was looking for that but stopped when I found malloc's for the radix tree :-) Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath: is here full list of supported chipsets and chipsets comparsion?
Lev Serebryakov wrote: Hello, All. `man ath' on FreeBSD 7.1-PRE speaks only about WPA2 in AR5212 and not-supported AR5005VL. But in "current" cars here are many other chipsets -- 5213A, 5414, etc... And Atheros site is not very helpful now -- there are not 5212, 5213A, 5414 chipsets in both areas "WLAN for Home, Office and Metro Wi-Fi" and "WLAN for Mobile" (BTW, link to http://customerproducts.atheros.com/ doesn't work anymore). Is here full list of supported chipsets, and, maybe, some table with chipsets features (AES, WPA2, AP mode, etc)? HEAD supports most PCI/cardbus parts. The main exceptions are the 9280 and 9285. The ath9k driver for linux supports them and anyone can add support using that. 11n parts only support legacy operation though w/ ~10 line change to the driver you can get 11n RX + legacy TX. RELENG_7 has a much older hal and lacks support for many cards. I recommend using HEAD if wireless support is important to you. No ETA on an update by me--others are welcome to supply the changes. All ath cards support all features you listed (except for the 5210 which you're unlikely to care about). Sam ___ 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: ath: is here full list of supported chipsets and chipsets comparsion?
Wes Morgan wrote: On Mon, 15 Dec 2008, Sam Leffler wrote: Lev Serebryakov wrote: Hello, All. `man ath' on FreeBSD 7.1-PRE speaks only about WPA2 in AR5212 and not-supported AR5005VL. But in "current" cars here are many other chipsets -- 5213A, 5414, etc... And Atheros site is not very helpful now -- there are not 5212, 5213A, 5414 chipsets in both areas "WLAN for Home, Office and Metro Wi-Fi" and "WLAN for Mobile" (BTW, link to http://customerproducts.atheros.com/ doesn't work anymore). Is here full list of supported chipsets, and, maybe, some table with chipsets features (AES, WPA2, AP mode, etc)? HEAD supports most PCI/cardbus parts. The main exceptions are the 9280 and 9285. The ath9k driver for linux supports them and anyone can add support using that. 11n parts only support legacy operation though w/ ~10 line change to the driver you can get 11n RX + legacy TX. RELENG_7 has a much older hal and lacks support for many cards. I recommend using HEAD if wireless support is important to you. No ETA on an update by me--others are welcome to supply the changes. All ath cards support all features you listed (except for the 5210 which you're unlikely to care about). Sam, I just updated my system from -stable to -current this weekend, and I'm noticing a lot more issues with the ath driver losing its association much more frequently, sometimes failing to reassociate altogether. The strange part is that tcpdump shows packets being received from the network just fine, but nothing seems to be transmitted (although I have not stepped over to my file server to verify this). A manual unload / reload of the module "solves" the problem, but I get a warning about a memory leak. I see no relevant PR's. I cannot fix problems w/o information. Code-wise, the only difference since the "open sourcing" is simply that we now have the code, correct? Only difference between what? The code in the tree is my latest work. If there are problems I will do my best to fix them given sufficient information and/or the ability to reproduce the problem. Sam ___ 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: Getting WPA2-PSK
Brooks Davis wrote: On Fri, Dec 19, 2008 at 05:33:17PM -0500, Jordy Dickinson wrote: On Fri, Dec 19, 2008 at 11:46 AM, Brooks Davis wrote: On Fri, Dec 19, 2008 at 03:04:55PM +, Rui Paulo wrote: On 19 Dec 2008, at 14:19, Jordy Dickinson wrote: Hey, I've never used a mailing list before, so forgive me if I'm not doing this right. I'm trying to set up my network card, but I keep getting this error message. I type in this: ifconfig wi0 authmode wpa And I get this: ieee80211_load_module: load the wlan_xauth module by hand for now. ifconfig: SIOCS80211: Invalid argument Can anybody tell me what I'm doing wrong? You're probably running a custom kernel without the wlan_xauth module built in. Either load it as a module or compile it in your kernel. You may also want to use wpa_supplicant instead. More specifically, setting "authmode wpa" with ifconfig will always be wrong (unless perhaps someday someone adds a suplicant to the kernel). If you want WPA to work, you must run wpa_supplicant. -- Brooks So how do I use wpa_supplicant? I've installed it on my machine already, and the man pages are gibberish to me. You have to add appropriate entries to /etc/wpa_supplicant.conf for your network. See the examples in the default file and the wpa_supplicant.conf manpage for details. You would then add WPA to your ifconfig_wi0 line in /etc/rc.conf. However, even if you do this, you will not actually be able to use WPA because wi(4) devices only support WEP (I missed that you were running wi(4) before). If you have a WPA encrypted network you will need to get another card. Depends if he's running HEAD or something older. HEAD supports WPA w/ wi but only for Intersil cards w/ firmware rev >= 1.7. Also, is there a way to make the mailing list stop sending me emails that I'm not part of? You can not subscribe to the list. Since you have pretty basic questions you might consider asking the freebsd-questions list. There's also a section in the handbook that talks about setting up wireless network configs. Sam ___ 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: HEADSUP: arp-v2 has been committed
Hartmut Brandt wrote:
Kip Macy wrote:
The flag is not needed. It is only possible to retrieve arp entries by
way of sysctl. The converse of this is you no longer need to grab all
the entries in the routing table and look at each one to determine
which are cloned routes (dynamic host routes) which contain ARP
entries.
Does this mean that the snmp daemon cannot monitor the arp entries
through the routing socket anymore? This would be a performance issue,
since it would have to fetch the ARP table from the kernel each time
it is asked for. Now it refreshes the table only if it is older than
30 seconds and in the mean time monitors routing messages.
If this really becomes an issue you could add a generation # to the arp
table and watch for changes to trigger an update.
Alternatively it's possible to push the arp table bits through the
routing socket but that would likely require more work. We could also
define new arp-specific msgs; e.g. to track changes (or just reuse the
old msg format). Doing this however perpetuates the routing socket as a
kitchen-sink-kinda mechanism--at some point it's worth creating an
entirely new path for info like this with a proper TLV-style protocol
and support for features like filtering.
Sam
harti
-Kip
On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer
wrote:
The code in question on the Wine side is
#if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP)
int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far
as I can see.
If the arp-v2 update now made us incompatible both with earlier
versions
of FreeBSD and Linux, that sounds like something that should be fixed
(instead of hacking applications like Wine).
On the other hand, the commit message at
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h
explicitly says
The change in design obsoletes the semantics of RTF_CLONING,
RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications
such as "arp" and "ndp" have been modified to reflect those changes.
so I guess it's not so easy.
How many other ports are affected?
What shall we do on the Wine front? Simply #ifdef-ing out the code in
question may not be the best of ideas, either. :-(
Gerald
On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote:
On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote:
The arp-v2 changes have been committed into HEAD.
Please report problems to me and Kip Macy.
Wine is not build any more:
...
cc -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith
-I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o
ipstats.c
ipstats.c: In function 'getNumArpEntries':
ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this
function)
ipstats.c:1253: error: (Each undeclared identifier is reported only
once
ipstats.c:1253: error: for each function it appears in.)
ipstats.c: In function 'getArpTable':
ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this
function)
ipstats.c:1311: warning: initialization makes integer from pointer
without a cast
gmake[2]: *** [ipstats.o] ?? 1
gmake[2]: Leaving directory
`/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi'
gmake[1]: *** [iphlpapi] ?? 2
gmake[1]: Leaving directory
`/usr/ports/emulators/wine/work/wine-1.1.10/dlls'
gmake: *** [dlls] ?? 2
--
Gerald (Jerry) Pfeifer ger...@pfeifer.com
http://www.pfeifer.com/gerald/
___
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-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-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: HEADSUP: arp-v2 has been committed
Julian Elischer wrote: Qing Li wrote: I believe examining the impacts of RTF_LLINFO on the ports was a good exercise even if we have to rejuvenate it. I hope we could reach a consensus soon now that we have more input from the ports developers. Please provide your input ... reintroduce it with value 0 then teh optimiser should remove dead code... The worry is that this will cause subtle bugs when code assumes functionality is present. We tried yanking this entirely and it's obviously caused some issues. The question now is whether to follow through and accept an incompatibility or put back sufficient compatibility to enable legacy code to work unchanged. Sam ___ 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: VLAN interface management - unloading carrying driver hangs the machine
Yony Yossef wrote: Yony Yossef wrote: /sbin/ifconfig vlan3653 create Problem is when I assign an IP to the vlan interface. In that case, unloading the driver results in hanging the host. Does it sound familiar to anybody? Well, surely I'd expect problems by doing so. The correct way is to /sbin/ifconfig vlan3653 destroy before unloading the driver. Angelo. Thanks, I didn't know freebsd does not allow it. This seems wrong. Someone should disallow the driver detach/unload. Please file a PR about this so the issue is not lost. Sam ___ 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: VLAN interface management - unloading carrying driver hangs the machine
Jack Vogel wrote: On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler <mailto:s...@freebsd.org>> wrote: Yony Yossef wrote: Yony Yossef wrote: /sbin/ifconfig vlan3653 create Problem is when I assign an IP to the vlan interface. In that case, unloading the driver results in hanging the host. Does it sound familiar to anybody? Well, surely I'd expect problems by doing so. The correct way is to /sbin/ifconfig vlan3653 destroy before unloading the driver. Angelo. Thanks, I didn't know freebsd does not allow it. This seems wrong. Someone should disallow the driver detach/unload. Please file a PR about this so the issue is not lost. Sam In many drivers, ahem, like mine, there is a test at detach and it will not allow it if there is a non-NULL trunk. Sounds like a broken driver needs to be fixed is all... I don't agree; drivers should not be required to deal with this. If someone files a PR and assigns it to me I'll look at it. Sam ___ 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: iwi doesn't see a wireless network
Adam K Kirchhoff wrote:
I'm trying to get my laptop to connect to the wireless access point at
work. It has a Intel Pro Wireless 2200BG minipci card, and can
associate with my access point at home. In addition, I can get an
Ubuntu 8.10 liveCD to connect to the access point at work via
NetworkManager. So there is definitely no incompatibility between the
wireless card and access point.
Here's my wpa_supplicant.conf file:
network={
ssid="Mckella280Front"
key_mgmt=WPA-PSK
pairwise=TKIP
psk="#"
}
The preshared key is definitely correct, as it's the one that works
with the liveCD. For the sake of testing, I've removed the reference to
my wireless AP at home.
I'm attaching the output from wpa_supplicant run with -dd. Basically,
it keeps scanning but only ever sees the tmobile network. That's
actually coming from another person in the building using a tmobile
wireless broadband card. If she's not here, the scan never picks up
anything. Similarly, 'ifconfig iwi0 list scan' only picks up the
tmobile ssid.
Yet, if I reboot off the liveCD, it works. Here's the output of 'iwlist
eth1 scanning' under the liveCD:
eth1 Scan completed :
Cell 01 - Address: 00:22:6B:9A:CC:AF
ESSID:"Mckella280Front"
Protocol:IEEE 802.11bg
Mode:Master
Frequency:2.457 GHz (Channel 10)
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Quality=50/100 Signal level=-68 dBm
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Extra: Last beacon: 904ms ago
And, iwconfig while connected:
eth1 IEEE 802.11g ESSID:"Mckella280Front"
Mode:Managed Frequency:2.457 GHz Access Point: 00:22:6B:9A:CC:AF
Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=59/100 Signal level=-66 dBm Noise level=-87 dBm
Rx invalid nwid:0 Rx invalid crypt:6 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:3
The only thing I can think of is that the AP is using some feature that
the iwi driver, or wpa_supplicant, doesn't support.
Is there someway to get this working?
You don't indicate a freebsd version. Is your ap configured to hide the
ssid?
Sam
___
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: New Atheros card: channel reset error [sorry for posting of not ready message]
Lev Serebryakov wrote: Hello, Freebsd-net. I'm getting this error on every operation with new Atheros MiniPCI card: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 status 12 is: HAL_EINVAL = 12, /* Invalid parameter to function */ (from ah.h). The first flags translate to a 2GHz Dynamic Turbo channel (see _ieee80211.h). The hal flags translate to a 5GHz Dynamic Turbo channel (see ah.h). So the driver is mis-mapping the channel and causing the hal to reject the request. If I recall this causes scanning to stop on RELENG_7 so you'll want to force this channel to not be requested by disabling dynamic turbo mode. I can't recall how that's done on RELENG_7; consult ifconfig(8). What does it mean? Maybe, card is broken? # pciconf -lv a...@pci0:0:17:0: class=0x02 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet # grep ath /var/run/dmesg.boot ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xa006-0xa006 irq 15 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:2d:e8:1e ath0: mac 10.5 phy 6.1 radio 6.3 # sysctl dev.ath dev.ath.0.%desc: Atheros 5212 dev.ath.0.%driver: ath dev.ath.0.%location: slot=17 function=0 dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x185f subdevice=0x1600 class=0x02 dev.ath.0.%parent: pci0 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 0 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 2 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.fftxqmin: 2 dev.ath.0.fftxqmax: 50 dev.ath.0.rfsilent: 1 dev.ath.0.rfkill: 1 dev.ath.0.monpass: 24 # sysctl hw.ath hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 hw.ath.hal.version: 0.9.20.3 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 ___ 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: New Atheros card: channel reset error [sorry for posting of not ready message]
Your panic on card eject has been fixed in HEAD. That was one of the changes I hoped to backport to RELENG_7 after the hal is brought back. Sam Adam K Kirchhoff wrote: I get similar errors, but only when trying to connect to a particular wireless network (at work). I can connect to the one I have at home, and do not get any errors. I have opened up a pr about it: http://www.freebsd.org/cgi/query-pr.cgi?pr=131162 In my case, if I then remove the wireless card while the interface is trying to acquire an IP address, the kernel panics. Are you seeing something similar? Adam On Wed, 11 Feb 2009 19:33:47 +0300 Lev Serebryakov wrote: Hello, Freebsd-net. I'm getting this error on every operation with new Atheros MiniPCI card: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 What does it mean? Maybe, card is broken? # pciconf -lv a...@pci0:0:17:0: class=0x02 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet # grep ath /var/run/dmesg.boot ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xa006-0xa006 irq 15 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:2d:e8:1e ath0: mac 10.5 phy 6.1 radio 6.3 # sysctl dev.ath dev.ath.0.%desc: Atheros 5212 dev.ath.0.%driver: ath dev.ath.0.%location: slot=17 function=0 dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x185f subdevice=0x1600 class=0x02 dev.ath.0.%parent: pci0 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 0 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 2 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.fftxqmin: 2 dev.ath.0.fftxqmax: 50 dev.ath.0.rfsilent: 1 dev.ath.0.rfkill: 1 dev.ath.0.monpass: 24 # sysctl hw.ath hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 hw.ath.hal.version: 0.9.20.3 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 -- // Black Lion AKA Lev Serebryakov ___ 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: spliting kernel ipfw source ? (also involves sctp)
Luigi Rizzo wrote: Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files to make it more manageable, and while i do this I would also like to move the files related to ipfw2 (namely ip_fw*c) to a better place. Any objection to moving them to sys/netinet/ipfw2 ? Also, I can't help noticing that sys/netinet/ contains 36 files related to sctp -- wouldn't it be the case to move them (perhaps with the exception of the userland headers) to a separate subdirectory ? (I know the same reasoning would apply to tcp, which has 23 files, but the issue here is that there is 25 years of userland code expecting the tcp headers in netinet/ and moving them would be a nightmare for ports...) I think sctp belongs in it's own directory. I'd vote for just ipfw; the "2" was an artifact of previous code. Sam ___ 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: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
This patches avoids the crash. Not sure how ifma_protospec is supposed
to be handled so I'm not committing it.
Sam
Index: in.c
===
--- in.c(revision 189750)
+++ in.c(working copy)
@@ -1040,7 +1040,8 @@
*/
IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
- if (ifma->ifma_addr->sa_family != AF_INET)
+ if (ifma->ifma_addr->sa_family != AF_INET ||
+ ifma->ifma_protospec == NULL)
continue;
inm = (struct in_multi *)ifma->ifma_protospec;
LIST_INSERT_HEAD(&purgeinms, inm, inm_link);
Index: igmp.c
===
--- igmp.c (revision 189750)
+++ igmp.c (working copy)
@@ -623,7 +623,8 @@
if (igi->igi_version == IGMP_VERSION_3) {
IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
- if (ifma->ifma_addr->sa_family != AF_INET)
+ if (ifma->ifma_addr->sa_family != AF_INET ||
+ ifma->ifma_protospec == NULL)
continue;
inm = (struct in_multi *)ifma->ifma_protospec;
if (inm->inm_state == IGMP_LEAVING_MEMBER) {
___
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: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
It is the same issue but the root cause is unclear. There is much code
that does assumes ifma_protospec might be NULL and checks for it. In my
case (creating a wlan ifnet and then destroying it on eject) the patch
below is sufficient. I don't care to dig right now to understand how
this stuff is supposed to work; it should be clear from comments etc but
the code is lacking.
Sam
Coleman Kane wrote:
The crash that I am seeing (using if_ndis) occurs in igmp_fasttimo...
This patch doesn't fix that, I'll get more info as soon as I can.
On Sat, 2009-03-14 at 14:06 -0700, Sam Leffler wrote:
This patches avoids the crash. Not sure how ifma_protospec is supposed
to be handled so I'm not committing it.
Sam
plain text document attachment (mcast.patch)
Index: in.c
===
--- in.c(revision 189750)
+++ in.c(working copy)
@@ -1040,7 +1040,8 @@
*/
IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
- if (ifma->ifma_addr->sa_family != AF_INET)
+ if (ifma->ifma_addr->sa_family != AF_INET ||
+ ifma->ifma_protospec == NULL)
continue;
inm = (struct in_multi *)ifma->ifma_protospec;
LIST_INSERT_HEAD(&purgeinms, inm, inm_link);
Index: igmp.c
===
--- igmp.c (revision 189750)
+++ igmp.c (working copy)
@@ -623,7 +623,8 @@
if (igi->igi_version == IGMP_VERSION_3) {
IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
- if (ifma->ifma_addr->sa_family != AF_INET)
+ if (ifma->ifma_addr->sa_family != AF_INET ||
+ ifma->ifma_protospec == NULL)
continue;
inm = (struct in_multi *)ifma->ifma_protospec;
if (inm->inm_state == IGMP_LEAVING_MEMBER) {
___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Sean C. Farley wrote: On Tue, 17 Mar 2009, Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. Sam ___ 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: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
Bruce Simpson wrote: Coleman Kane wrote: If you are looking for a reliable test case, this might be it for you, but I think you need a wlan interface to test it with: * Install net/avahi from ports * Set avahi_daemon_enable="YES" in rc.conf * Configure VAP params for wlan0 card in rc.conf * Log in and run "dhclient wlan0" to trigger the panic Actually I was able to panic the kernel right away with the 802.11 code, just by joining a multicast group with mtest(8) on the wlan interface. i.e. # mtest j 224.0.0.2 192.168.x.x -> boom I believe I've found the symptom, but the root cause I don't fully understand. Sam indicated that the VAP code is using ifma's in some nested way between the ifnets which comprise the VAP's member interfaces. A workaround is pending net80211 uses the public api's to push mcast addresses from the vap's to the parent ifnet. It does not directly frob any internal data structures except to workaround the ioctl-based callback out of the mcast code when adding an address. Look at ieee80211_ioctl_updatemulti for details. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sam Leffler To: "Sean C. Farley" Cc: Matthias Apitz , Matthias Apitz , freebsd-net@freebsd.org, Bruce Simpson , bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:56:24 -0700 Sean C. Farley wrote: > On Tue, 17 Mar 2009, Matthias Apitz wrote: > >> El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson >> escribió: >> >>> Matthias Apitz wrote: >>>> as requested the output of dmesg(1) and the ath0 related part of >>>> 'pciconf -lv'; pls note also that the Wifi works fine in general, >>>> i.e. with the AP in my office (WPA) and in my home (WEP); >>>> >>> >>> Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. >> >> It is an Asus EeePC 900, not the 901. >> >>> I tested OK with the 701. Sam said that there may be models of >>> ath(4) requiring further changes to be back-ported from -CURRENT, >>> this could well be one of them. >> >> as I said the Wifi works in all places, but not with this special AP >> (while a Nokia cellphone can associate and DHCP without problems); >> >> let me know if you need more info; > > Is the AP made by Aruba Networks? > > On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of > wpa_supplicant for it to associate correctly. With v0.5.10, I could > see DHCP requests from my laptop but no responses. This is the patch > I am using currently: > http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch > > Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. Sam ___ 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: Dynamic loading of network kernel modules?
Oliver Fromme wrote: David Horn wrote: > Oliver Fromme wrote: > > > > network_interfaces="bge0 lo0" > > Ah. Ok, now I am understanding your scenario. > > I thought that using 'network_interfaces' with anything other than > "AUTO" was in the process of being depreciated ? Well, the manual page says so, but I think that is a mistake. There are cases where you have to specify the list of interfaces explicitly. The situation described in this thread is one such case. My opinion is that it is good to have the ability to let things be done automatically, but it is bad to remove the ability to do things manually. This is UNIX, after all. I personally hate the auto-magic-loading of modules that ifconfig does. Remember that we tried to yank it once before but had to bring it back for compatibility. If one argues that ifconfig should be consistent in it's treatment of module loading then the patch is fine and should go in. Otherwise... Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler escribió: His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. I will try to collect a better tcpdump of the dhclient packets on the weekend and as well figure out what kind of model the AP is; would it be helpful to connect with a Windows XP laptop (which seems to work) to gather some information of the Wifi and other network parameters? how this could be seen in Windows? maybe there is some special compression of the payload of the packages in place? Having a packet trace of a working connection to compare would be very helpful. I have seen such 'options' in another AP (a Netgear WGT624 v3), the option was called "[ ] Disable Advanced 108Mbps Features" and this must be checked (i.e. disabled) to make DHCP happy with the ath0 EeePC; That controls SuperG support in Atheros-based ap's and is unrelated. There is a known problem with SuperG support that has been fixed in HEAD but not yet backmerged. For reasons unknown your (apparently) simple setup is not working. I do not use RELENG_7 w/ the stock wireless and have no familiarity with it's status so it's more likely there's just some bug fix not back-merged. unfortunately I can't look into the AP about this problem is :-( thx matthias ___ 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: 802.1x broken after SVN rev 189592
Vany Serezhkin wrote: Hello. I do not really sure in this, but : after the current updated to 20090309 Merge IGMPv3 and Source-Specific Multicast (SSM) to the FreeBSD IPv4 stack. I can't use any wpa_supplicant related networks. It faulted in any WPA authentications , that i tried. Also it faulted when i try to login via 802.1x in my job network. All happens after i starts wpa_supplicant and looks like these: #11 0xc05cabec in panic (fmt=0xc08b16e9 "sbappendaddr_locked") at /opt/src/sys/kern/kern_shutdown.c:559 #12 0xc061fd40 in sbappendaddr_locked (sb=0xc66dd670, asa=0xc09021b4, m0=0xce435b00, control=0x0) at /opt/src/sys/kern/uipc_sockbuf.c:632 #13 0xc0620418 in sbappendaddr (sb=0xc66dd670, asa=0xc09021b4, m0=0xce435b00, control=0x0) at /opt/src/sys/kern/uipc_sockbuf.c:679 #14 0xc0671be4 in raw_input (m0=0xc64b0100, proto=0xe664ec60, src=0xc09021b4) at /opt/src/sys/net/raw_usrreq.c:96 #15 0xc06749e7 in rts_input (m=0xc64b0100) at /opt/src/sys/net/rtsock.c:151 #16 0xc066f752 in swi_net (dummy=0x0) at /opt/src/sys/net/netisr.c:145 #17 0xc05aa148 in intr_event_execute_handlers (p=0xc61617ec, ie=0xc61a2d00) at /opt/src/sys/kern/kern_intr.c:1134 #18 0xc05ab4d4 in ithread_loop (arg=0xc60ec660) at /opt/src/sys/kern/kern_intr.c:1147 #19 0xc05a7ac9 in fork_exit (callout=0xc05ab469 , arg=0xc60ec660, frame=0xe664ed38) at /opt/src/sys/kern/kern_fork.c:821 #20 0xc0833170 in fork_trampoline () at /opt/src/sys/i386/i386/exception.s:270 Are you certain it's that revision? Have you tried r189931 which worked around certain problems in the initial commit? Can you provide sufficient info to reproduce your problem? Filing a PR for reference is likely the best thing to do. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: El día Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribió: Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler escribió: His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. I've updated /usr/src/sys to HEAD, configured a kernel based on the new GENERIC (without any changes), compiled it and installed it; the kernel crashes on loading (note: on loading, not on booting): http://www.unixarea.de/trap.jpg i.e. without knowing any inconsistency of user land or file system; what I did wrong? This looks like a longstanding bug in handling modules loaded by loader that have undefined references (e.g. because your kernel is misconfigured). In general I don't think you're going to get very far booting a HEAD kernel against RELENG_7 world. This will certainly not work for wireless where you need all the changes to ifconfig. If you're trying to test HEAD you will want a separate partition with a fresh install/build of HEAD. Sam ___ 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: if_ath
dikshie wrote: > this is on RELENG_7 > > totoro# ident /usr/src/sys/dev/ath/if_ath.c > /usr/src/sys/dev/ath/if_ath.c: > $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.177.2.3 2009/03/12 > 03:09:11 bms Exp $ > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c > -I/usr/src/sys/dev/ath > /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': > /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct > ath_rx_status' has no member named 'rs_flags' > *** Error code 1 > > > > Read UPDATING; you need options AH_SUPPORT_AR5416 in your config file. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) below are some information concerning the AP, ifconfig ... the output of the tcpdump is on my server as http://www.unixarea.de/ath-current.txt let me know if you need more information; HIH matthias info about AP: Siemens Gigaset SE 505 dsl/cable S30853-S1006-R107-3 (handwritten label says: "this is no DSL router; IP 192.168.2.1") as DSL-modem some Fritz!Box is connected to this box http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:af:b2:ae:e6 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g status: associated ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL # tcpdump -n -i ath0 -y IEEE802_11_RADIO 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.750225 43659844us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] ... full log see: http://www.unixarea.de/ath-current.txt If you have the raw pcap capture please provide a url to it. From the log it appears you're sending+receiving wep-encrypted frames. They keyid is the same and since you're receiving frames I have to assume the key matter is correct as otherwise the h/w would drop the frame. You can verify this by feeding the key into wireshark to check if the frame contents make sense. I'm out of ideas. About the only thing I can suggest is you setup a different ap w/ the same wep key and see if things work. If so then you know it's something this ap is doing. I can't recall when I last tested wep on HEAD but I'm pretty sure it works. I will re-test that when I get a chance. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Bruce M Simpson wrote: Matthias Apitz wrote: I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. We have yet to produce a tcpdump to catch it 'in the act' and observe the DLT_IEEE80211 traffic when it actually happens, I have only seen the symptoms. The AP does not show the EeePC units as being associated any more at this point, but ath0 still shows 'status: associated'. The AP involved is a Netgear WG602 V2, and is running the vendor's firmware. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). There are many issues with the wireless code in RELENG_7. Now that the hal is merged we can try to address them. Unfortunately the 7.2 release has just begun so it's unclear what we can get in. I'm also limited in what I'm willing to commit given that I do not run RELENG_7. Sam ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sam Leffler To: Matthias Apitz Cc: bug-follo...@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 12:12:04 -0700 Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > > below are some information concerning the AP, ifconfig ... > the output of the tcpdump is on my server as > http://www.unixarea.de/ath-current.txt > let me know if you need more information; > > HIH > > matthias > > > info about AP: > Siemens Gigaset SE 505 dsl/cable > S30853-S1006-R107-3 > (handwritten label says: "this is no DSL router; IP 192.168.2.1") > as DSL-modem some Fritz!Box is connected to this box > > http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html > > > # uname -a > FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 > CET 2009 > r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC > i386 > > # ifconfig -a > ath0: flags=8843 metric 0 mtu 2290 > ether 00:15:af:b2:ae:e6 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:15:af:b2:ae:e6 > inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 > media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g > status: associated > ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 > regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 > wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS > wme burst roaming MANUAL > > > > # tcpdump -n -i ath0 -y IEEE802_11_RADIO > 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.750225 43659844us tsft 1.0 Mb/s -81dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise > antenna 1 [0x0012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 > 24.0 36.0 54.0 Mbit] ESS[|802.11] > ... > > full log see: http://www.unixarea.de/ath-current.txt > > > If you have the raw pcap capture please provide a url to it. From the log it appears you're sending+receiving wep-encrypted frames. They keyid is the same and since you're receiving frames I have to assume the key matter is correct as otherwise the h/w would drop the frame. You can verify this by feeding the key into wireshark to check if the frame contents make sense. I'm out of ideas. About the only thing I can suggest is you setup a different ap w/ the same wep key and see if things work. If so then you know it's something this ap is doing. I can't recall when I last tested wep on HEAD but I'm pretty sure it works. I will re-test that when I get a chance. Sam ___ 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: ath0 apparent silent disassociation
Bruce M Simpson wrote: Sam Leffler wrote: Bruce M Simpson wrote: ... This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). There are many issues with the wireless code in RELENG_7. Now that the hal is merged we can try to address them. Unfortunately the 7.2 release has just begun so it's unclear what we can get in. I'm also limited in what I'm willing to commit given that I do not run RELENG_7. OK. We've managed to reproduce this set of symptoms now in our work area. I've attached some script(1) output of netstat -in being run, and a pcap dump. Timebase: beginning of the pcap is in sync with a bringup from single-user mode; the tcpdump runs in the background from init whilst the system is brought up. OK, so I timed the apparent loss of connectivity as 6m 30s from that point I hit the stopwatch, to when I hit it again when the AP's Web GUI no longer shows the STA affected as being associated. Obviously such a timing is subject to human/visual jitter, and how often Netgear's firmware pulls the STA association list from the AP into the web GUI. What stands out in the pcap is that 302.291s in (almost 5m exactly), the STA (ath0) sends an IEEE 802.11 NULL frame to the AP with the PWR MGT bit set (I'm going to sleep!). This more or less coincides with a normal beacon from the Netgear AP. It does not advertise Auto Power Save Delivery (apsd), that bit is 0. This is puzzling as we don't enable power management by default. As I understand it, this may be an AP feature in some environments... I can try reproducing this with an explicit 'ifconfig ath0 -powersave' and see if it reoccurs. You'll see that after this NULL frame is sent, there is another Probe Request, and the Netgear AP does Probe Respond, but this makes no difference (I ended the capture around 150s after the NULL frame was sent). At this point we can't send traffic from the ath0, or rather, the AP is acting as though it never even heard the STA. The STA learns the AP's IP address/MAC mapping through passive ARP -- we still see broadcasts on the SSID -- but the AP has started to totally ignore the STA, and seemed to have ignored its ARP requests also. We are using MAC address ACL control with this AP, and the ath0 affected is definitely listed in its ACL table, configured up, rebooted etc. It is as though the STA is entering power saving mode when not explicitly told to, and the AP is not waking up the STA as it should. If any more information needed, or where to look, please let me know what's involved (I MFCed the change after all, so I'll help where I can until I'm on holiday this week...) My lab colleague is just working around this with 'ping ' for now, that keeps things up, as does OpenVPN... Your sta did a background scan. There are bugs in this area fixed in HEAD. One was that periodic calibration in the driver might kick in while off channel and setup state that was wrong for the channel where the ap was. As I said, now that the hal code is finally in RELENG_7 I'm willing to look at stuff. You or someone else can do likewise but given things have sat basically untouched since 7.0RC1 I suspect that's expecting too much. Of course if people don't test HEAD then once 8.0 goes out we'll likely have a similar situation on that branch. I do feel more confident about HEAD as that code has gone through multiple product cycles outside the tree. Sam ___ 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: ath0 apparent silent disassociation
Sam Leffler wrote: > You or someone else can do likewise but given things > have sat basically untouched since 7.0RC1 I suspect that's expecting too > much. Sorry, this wasn't directed at you; it was meant at the community as a whole. I don't run RELENG_7 and when I do I use a backport of the wireless code in HEAD. Folks running RELENG_7 need to pitch in and help maintain the wireless code. I'm always available to help/advise. Sam ___ 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: wds how-to?
David Cornejo wrote: Aloha, I'm trying to get WDS running - I am working my way through the stuff in /usr/src/tools/tools/net80211/scripts, but it really only gives examples and doesn't explain the why of it - is there a more verbose how to somewhere that would help me understand this? I've written nothing. You say the "why" is missing but you don't ask any questions. There are 2 flavors of wds, legacy and dynamic. The legacy stuff is trivial to setup; ifconfig wlan create wlandev ath0 wlanmode wds wlanbssid ... wdslegacy The bssid is the peer's mac address. This is just a fixed 4-address conduit for frames. There must be an ap vap already created. You want to plumb the vap into a bridge or assign it an ip address and route (not sure about routing; I always use it bridged). Dynamic wds setup depends on whether you're on the ap side or the sta side; the scripts are the best examples. The idea is you have a sta-ap association that carries 4-address traffic. Because there's a full-blown association you get discovery, roaming, and security for free. This is what you'll find in Apple's ap products though they've done a bunch of work to make it more production-quality. Note that wds is implemented above the drivers (modulo a bit of glue code). ath is just one driver that supports wds, ral is another. Sam ___ 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: Interrupts + Polling mode (similar to Linux's NAPI)
Andrew Brampton wrote: Hi, Linux has a feature called NAPI, which amongst other things has this Interrupt initiated polling mode. Whilst the network traffic is quiet the network interfaces use interrupts, however as soon as the load becomes higher polling kicks in and stays like that until the load drops again. I know that FreeBSD can do interrupts or polling, but not together. I think that that NAPI pretty neat as it provides the benefits of both interrupts and polling, namely low CPU load (when the network is not busy), and high performance. I was wondering if anyone has considered this approach in FreeBSD? If not why not? Is there some reason why the binary FreeBSD approach is better? Or is it just that no one has dedicated the time and effort to implement this feature? NAPI is essentially interrupt moderation in s/w. As Luigi noted elsewhere polling in freebsd is rather different with livelock avoidance being just one of the goals. I've had several projects where people coming from linux felt is was critical to implement NAPI or something similar on a bsd system. In the end they found it was not a significant win if the hardware is reasonably designed and the driver properly tuned. Some of this relates to how the network stacks differ in design. I think a NAPI-like facility would mostly be used for legacy devices which is not to say it's a bad idea or that you shouldn't work on it. Whether or not it's incorporated into the system would depend on how much of a win it turns out to be and how intrusive it is as you'd need to mod all the drivers. Sam ___ 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: wds how-to?
It must be the bssid of the peer; it is used to form the 4-address frames. Sam David Cornejo wrote: That brief description was a big help in itself, thank you. One question: should the BSSID in the legacy mode be the same as the MAC address of the main WDS node? Or can it be a random number? thanks, dave c On Wed, Mar 25, 2009 at 5:31 PM, Sam Leffler wrote: David Cornejo wrote: Aloha, I'm trying to get WDS running - I am working my way through the stuff in /usr/src/tools/tools/net80211/scripts, but it really only gives examples and doesn't explain the why of it - is there a more verbose how to somewhere that would help me understand this? I've written nothing. You say the "why" is missing but you don't ask any questions. There are 2 flavors of wds, legacy and dynamic. The legacy stuff is trivial to setup; ifconfig wlan create wlandev ath0 wlanmode wds wlanbssid ... wdslegacy The bssid is the peer's mac address. This is just a fixed 4-address conduit for frames. There must be an ap vap already created. You want to plumb the vap into a bridge or assign it an ip address and route (not sure about routing; I always use it bridged). Dynamic wds setup depends on whether you're on the ap side or the sta side; the scripts are the best examples. The idea is you have a sta-ap association that carries 4-address traffic. Because there's a full-blown association you get discovery, roaming, and security for free. This is what you'll find in Apple's ap products though they've done a bunch of work to make it more production-quality. Note that wds is implemented above the drivers (modulo a bit of glue code). ath is just one driver that supports wds, ral is another. Sam ___ 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: iwn(4): Porting Intel 5100/5300 support from OpenBSD?
Daniel Roethlisberger wrote: Is anyone already working on porting Damien Bergamini's updates to OpenBSD iwn(4) in order to support Intel 5100/5300 chipsets? Is there anything preventing this work (except ENOTIME)? I've been working with another person on this. It looks like the mods are straightforward but both of us have 4965 cards so can't test the new stuff. I suggest you not wait if you're motivated. Sam ___ 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: Multi-BSS problem with Atheros 5212
Boris Kochergin wrote: Ahoy. I'm having trouble with multiple hostap-mode wlan pseudo-devices. The machine is an 8-CURRENT from yesterday: # uname -a FreeBSD test 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Apr 7 16:54:56 UTC 2009 r...@test:/usr/obj/usr/src/sys/GENERIC i386 # dmesg | grep ath ath0: mem 0xf410-0xf410 irq 11 at device 13.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 # cat /etc/rc.conf wlans_ath0="wlan0 wlan1 wlan2" create_args_wlan0="wlanmode hostap bssid" create_args_wlan1="wlanmode hostap bssid" create_args_wlan2="wlanmode hostap bssid" ifconfig_wlan0="ssid wlan0 wepmode off up" ifconfig_wlan1="ssid wlan1 wepmode off up" ifconfig_wlan2="ssid wlan2 wepmode off up" # ifconfig ath0: flags=8843 metric 0 mtu 2290 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:90:27:72:c4:f3 inet 10.0.0.128 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan0 channel 11 (2462 Mhz 11g) bssid 00:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan1: flags=8843 metric 0 mtu 1500 ether 06:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan1 channel 11 (2462 Mhz 11g) bssid 06:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan2: flags=8843 metric 0 mtu 1500 ether 0a:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan2 channel 11 (2462 Mhz 11g) bssid 0a:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs The client is a 7.0 machine with another 5212 card: # uname -a FreeBSD peer 7.0-RELEASE-p10 FreeBSD 7.0-RELEASE-p10 #0: Mon Mar 23 09:26:18 EDT 2009 r...@peer:/usr/obj/usr/src/sys/PEER i386 # dmesg | grep ath ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: mem 0xa841-0xa841 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:d1:42:21:5a ath0: mac 7.9 phy 4.5 radio 5.6 The three SSIDs configured on the CURRENT machine show up in a scan: # ifconfig ath0 scan | grep wlan wlan0 00:18:e7:33:5e:24 11 54M -66:-93 100 ES WME wlan1 06:18:e7:33:5e:24 11 54M -65:-93 100 ES WME wlan2 0a:18:e7:33:5e:24 11 54M -65:-93 100 ES WME The client is only able to associate with wlan1, however. When scanning channels while attempting to associate with any of the other ones, it gets stuck on channel 11 for a while before moving on, which seems relevant. Also interesting is the fact that if i do "ifconfig ath0 down" on the CURRENT machine, followed by, for example, "ifconfig ath0 ssid wlan0" (which did not associate before) on the client, followed by "ifconfig ath0 up" on the CURRENT machine, the client will associate with wlan0, but will not be able to associate with wlan1 or wlan2. Any ideas? wlandebug scan+auth+assoc on the client machine will show you why you cannot associate. You can also enable the same info on the ap side to see what it thinks is happening. Sam ___ 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: Multi-BSS problem with Atheros 5212
Sam Leffler wrote: Boris Kochergin wrote: Ahoy. I'm having trouble with multiple hostap-mode wlan pseudo-devices. The machine is an 8-CURRENT from yesterday: # uname -a FreeBSD test 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Apr 7 16:54:56 UTC 2009 r...@test:/usr/obj/usr/src/sys/GENERIC i386 # dmesg | grep ath ath0: mem 0xf410-0xf410 irq 11 at device 13.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 # cat /etc/rc.conf wlans_ath0="wlan0 wlan1 wlan2" create_args_wlan0="wlanmode hostap bssid" create_args_wlan1="wlanmode hostap bssid" create_args_wlan2="wlanmode hostap bssid" ifconfig_wlan0="ssid wlan0 wepmode off up" ifconfig_wlan1="ssid wlan1 wepmode off up" ifconfig_wlan2="ssid wlan2 wepmode off up" # ifconfig ath0: flags=8843 metric 0 mtu 2290 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:90:27:72:c4:f3 inet 10.0.0.128 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan0 channel 11 (2462 Mhz 11g) bssid 00:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan1: flags=8843 metric 0 mtu 1500 ether 06:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan1 channel 11 (2462 Mhz 11g) bssid 06:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan2: flags=8843 metric 0 mtu 1500 ether 0a:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid wlan2 channel 11 (2462 Mhz 11g) bssid 0a:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs The client is a 7.0 machine with another 5212 card: # uname -a FreeBSD peer 7.0-RELEASE-p10 FreeBSD 7.0-RELEASE-p10 #0: Mon Mar 23 09:26:18 EDT 2009 r...@peer:/usr/obj/usr/src/sys/PEER i386 # dmesg | grep ath ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: mem 0xa841-0xa841 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:d1:42:21:5a ath0: mac 7.9 phy 4.5 radio 5.6 The three SSIDs configured on the CURRENT machine show up in a scan: # ifconfig ath0 scan | grep wlan wlan0 00:18:e7:33:5e:24 11 54M -66:-93 100 ES WME wlan1 06:18:e7:33:5e:24 11 54M -65:-93 100 ES WME wlan2 0a:18:e7:33:5e:24 11 54M -65:-93 100 ES WME The client is only able to associate with wlan1, however. When scanning channels while attempting to associate with any of the other ones, it gets stuck on channel 11 for a while before moving on, which seems relevant. Also interesting is the fact that if i do "ifconfig ath0 down" on the CURRENT machine, followed by, for example, "ifconfig ath0 ssid wlan0" (which did not associate before) on the client, followed by "ifconfig ath0 up" on the CURRENT machine, the client will associate with wlan0, but will not be able to associate with wlan1 or wlan2. Any ideas? wlandebug scan+auth+assoc on the client machine will show you why you cannot associate. You can also enable the same info on the ap side to see what it thinks is happening. FWIW I just setup 3 vap's as you did above and hooked them into a bridge. I verified I could associate and pass traffic using a MBPro. No problems. I also destroyed the bridge and re-tested w/o issues. Regardless the debug msgs should identify what your problem is. Sam ___ 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: m_tag, malloc vs uma
Karim Fodil-Lemelin wrote:
Robert Watson wrote:
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Thank you for the answer, clear and concise. I asked the question
because I had modified pf_get_mtag() to use uma directly in the hope
that it would be faster then calling malloc. But since pf_mtag is
20bytes, malloc will end up using a fixed 32bytes zone and I
shouldn't expect much speed gain from using something like (except
some savings from not having to select the 32bytes zone):
There is another small overhead, the critical section used to protect
the consistency of the per-CPU malloc type alloc and free counters,
but it's also very small.
I think it would be desirable to make a change to more flexible m_tag
types for 8.0, but I'm not sure I have time to implement/test it. Is
this something you might be interested in working on? I'm thinking
of basically replacing the m_tag_free pointer with a pointer to a
small vector of operations, possibly something along these lines:
struct m_tag_ops {
void(*m_tag_free)(struct m_tag *);
struct m_tag(*m_tag_copy)(struct m_tag *);
};
If the m_tag_ops pointer is NULL, we go with today's default
(requiring minimal change of existing consumers). I'm not sure if
there are any other function pointers we'd need at this point?
Is the m_tag_copy an 'overloaded' function for the current m_tag_copy
or something else? Now it could also be interesting to have another
function pointer to overload m_tag_alloc to give more control over
which zone the user wants its tags from (ex: pf_mtag ...). The
interest is there not sure if the schedule will allow it but that
depends if the new m_tag designs allows me to squeeze some
performances in.
Typically tags are allocated in a context where decisions like the above
can be made so I'm not sure where you think m_tag_alloc might be used.
At one point vlan-tagged packets were identified by an mbuf tag.
Initially they were allocated by malloc but I moved that to a dedicated
zone w/ a noticeable benefit. However the overhead was still too high
and so we now space was added to the mbuf pkt hdr explicitly to hold
vlan data.
It's unlikely any scheme where the tags are allocated independent of the
mbufs will scale well enough to handle existing high speed interfaces.
There's been discussion about supporting emedding of tags in the mbuf
itself; this might come along as part of the variable-size mbuf work
that Jeff Roberson was working on. However unless one pre-allocated
space and/or defined a general mechanism for managing such space you'd
still potentially need to allocate tags separately when they are
attached at a later time. For embedded/inline mbuf tag space management
I think m_tag_free and m_tag_copy would sufficient for current usage.
Sam
___
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"
