Re: atheros broadcast/multicast corruption with multiple hostap's
(I'm removing Sam from the CC: ; it seems he's not interested in this stuff any longer.) On 8 December 2010 09:54, Russell Yount russell.yo...@gmail.com wrote: Adrian, Yes, I can help track down this. I have only 11agb radios though: NL-5354MP + Aries2 5004 MP Atheros 4G / CM9 Which chipsets are they? The changes I made definiately work for these chips, I have 4 APs operating with 4 SSID each all configured with WPA2 using x509 certs. Currently, the kernel I am using is 8.1. Are they using different keys? Did you try WPA + AES/CCMP in STA mode with these? If not, would you please do that? I seem to recall that the hardware abstration layer for different chipsets treated handling of multicast reception differently. Could you send me pointers to what problems are described? Sorry, I took so long to reply, been rather busy, I do not check this email account as often as my others. What would be a better account to email? What I'd really like to do is write up a set of testing procedures for doing things to the ath driver - in station, hostap and adhoc modes - so I can test my local 11n+refactored HAL against it. If you've got a working setup then I'd like to try and get that documented and reproducable, complete with a set of tests for each to try and ensure that as much stuff works as possible. I'd also like to make sure that the AR5416 HAL as shipped in FreeBSD behaves the same way as the AR5210,AR5211,AR5212 HALs as well. I only have an AR5213 card here; the rest of mine are 11n (AR5416, AR9160, AR9280.) I don't know if I'm going to be able to get all of this into 9.0-RELEASE but I'd like to try. The atheros 11n chipsets are everywhere now; I'd like to both support the legacy stuff and the new stuff with all the features fully working. :-) Right now I haven't any idea about what works and what doesn't. Thanks, Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: aesni(?) corrupts data on 8.2-BETA1
On 12/12/2010 15:26, Mike Tancsa wrote: On 12/12/2010 3:43 AM, Kostik Belousov wrote: Please try this patch on the latest HEAD or RELENG_8. I tried both on i386 and amd64 and all looks good! I did 1000 iterations of cryptotest -c -z -t 10 without issue! Thanks for the quick fix! I redid my testing on a (read-only attached) geli provider (now with XTS instead of CBC) taking checksums of all files: 8.2-BETA1 without patch without aesni loaded: all checksums ok. 8.2-BETA1 with patch without aesni loaded: all checksums ok. 8.2-BETA1 without patch with aesni loaded: 124 of 18209 failures. 8.2-BETA1 with patch with aesni loaded: all checksums ok. The patch seems to fix my geli problem on 8.2-BETA1 amd64, too. Thanks! Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: atheros broadcast/multicast corruption with multiple hostap's
Hi Adrian, I've found the chipsets you were asking - those cards are pretty popular as far as I can see on many wireless forums. I have only 11agb radios though: Which chipsets are they? NL-5354MP + Aries2 It looks that it's miniPCI Atheros 5213, Senao NL-5354MP Plus Aries2 [1] 5004 MP Atheros 4G / CM9 Atheros AR5004 4th generation chipset. AR5213 (MAC+BB) + AR5112 (2.4/5GHz radio) more info [2] What I'd really like to do is write up a set of testing procedures for doing things to the ath driver - in station, hostap and adhoc modes - so I can test my local 11n+refactored HAL against it. If you've got a working setup then I'd like to try and get that documented and reproducable, complete with a set of tests for each to try and ensure that as much stuff works as possible. That would be very nice to have it in one place to follow in case of any suspected problems. I'd also like to make sure that the AR5416 HAL as shipped in FreeBSD behaves the same way as the AR5210,AR5211,AR5212 HALs as well. I only have an AR5213 card here; the rest of mine are 11n (AR5416, AR9160, AR9280.) I don't know if I'm going to be able to get all of this into 9.0-RELEASE but I'd like to try. The atheros 11n chipsets are everywhere now; I'd like to both support the legacy stuff and the new stuff with all the features fully working. :-) Right now I haven't any idea about what works and what doesn't. Thanks, Adrian [1] http://www.seattlewireless.net/ClientAdapters/802.11g [2] http://store.netgate.com/5004-MP-ATHEROS-4G-CM9-80211abg-miniPCI-Card- P125.aspx Greetings, Maciej ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /libexec/ld-elf.so.1: Cannot execute objects on /
On Saturday, December 11, 2010 11:51:41 am Miroslav Lachman wrote: Miroslav Lachman wrote: Garrett Cooper wrote: 2010/4/20 Miroslav Lachman000.f...@quip.cz: I have large storage partition (/vol0) mounted as noexec and nosuid. Then one directory from this partition is mounted by nullfs as exec and suid so anything on it can be executed. The directory contains full installation of jail. Jail is running fine, but some ports (PHP for example) cannot be compiled inside the jail with message: /libexec/ld-elf.so.1: Cannot execute objects on / The same apply to executing of apxs r...@rainnew ~/# /usr/local/sbin/apxs -q MPM_NAME /libexec/ld-elf.so.1: Cannot execute objects on / apxs:Error: Sorry, no shared object support for Apache. apxs:Error: available under your platform. Make sure. apxs:Error: the Apache module mod_so is compiled into. apxs:Error: your server binary '/usr/local/sbin/httpd'.. (it should return prefork) So I think there is some bug in checking the mountpoint options, where the check is made on parent of the nullfs instead of the nullfs target mountpoint. It is on 6.4-RELEASE i386 GENERIC. I did not test it on another release. This is list of related mount points: /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) /usr/ports on /vol0/jail/rain_new/usr/ports (nullfs, local) devfs on /vol0/jail/rain_new/dev (devfs, local) If I changed /vol0 options to (ufs, local, soft-updates) the above error is gone and apxs / compilation works fine. Can somebody look at this problem? Can you please provide output from ktrace / truss for the issue? I did # ktrace /usr/local/sbin/apxs -q MPM_NAME The output is here http://freebsd.quip.cz/ld-elf/ktrace.out Let me know if you need something else. Thank you for your interest! The problem is still there in FreeBSD 8.1-RELEASE amd64 GENERIC (and in 7.x). Can somebody say if this is a bug or an expected feature? I think this is the expected behavior as nullfs is simply re-exposing /vol0 and it shouldn't be able to create a more privileged mount than the underlying mount I think (e.g. a read/write nullfs mount of a read-only filesystem would not make the underlying files read/write). It can be used to provide less privilege (e.g. a readonly nullfs mount of a read/write filesystem does not allow writes via the nullfs layer). That said, I'm not sure exactly where the permission check is failing. execve() only checks MNT_NOEXEC on the upper vnode's mountpoint (i.e. the nullfs mountpoint) and the VOP_ACCESS(.., V_EXEC) check does not look at MNT_NOEXEC either. I do think there might be bugs in that a nullfs mount that specifies noexec or nosuid might not enforce the noexec or nosuid bits if the underlying mount point does not have them set (from what I can see). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
cryptodev cipher registration (aesni and padlock)
While doing some testing with the aesni driver, it seems some ciphers are registered with openssl and some are not. e.g. if I start an ssh session using aes128, I see the following [pyroxene]% ssh -c aes128-cbc smarthost1 cryptostats | grep sym 654198 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes128-cbc smarthost1 cryptostats | grep sym 654225 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ie it shows the hardware transformation count increasing. But if I do aes 192 or 256, it does not [pyroxene]% ssh -c aes256-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes192-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes192-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes192-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% Yet the are supposed to be supported, no ? Where in openssl is this configured ? The padlock driver does the same thing % ssh -c aes256-cbc smarthost1 cryptotest -z 0.000 sec, 2aes crypts, 16 bytes, 400 byte/sec,30.5 Mb/sec 0.000 sec, 2aes crypts, 32 bytes, 1600 byte/sec, 122.1 Mb/sec 0.000 sec, 2aes crypts, 64 bytes, 3200 byte/sec, 244.1 Mb/sec 0.000 sec, 2aes crypts, 128 bytes, 6400 byte/sec, 488.3 Mb/sec 0.000 sec, 2aes crypts, 256 bytes, 12800 byte/sec, 976.6 Mb/sec 0.000 sec, 2aes crypts, 512 bytes, 17067 byte/sec, 1302.1 Mb/sec 0.000 sec, 2aes crypts,1024 bytes, 292571429 byte/sec, 2232.1 Mb/sec 0.000 sec, 2aes crypts,2048 bytes, 45511 byte/sec, 3472.2 Mb/sec 0.000 sec, 2aes crypts,4096 bytes, 51200 byte/sec, 3906.2 Mb/sec 0.000 sec, 2aes crypts,8192 bytes, 420102564 byte/sec, 3205.1 Mb/sec 0.000 sec, 2 aes192 crypts, 16 bytes, 800 byte/sec,61.0 Mb/sec 0.000 sec, 2 aes192 crypts, 32 bytes, 1600 byte/sec, 122.1 Mb/sec 0.000 sec, 2 aes192 crypts, 64 bytes, 3200 byte/sec, 244.1 Mb/sec 0.000 sec, 2 aes192 crypts, 128 bytes, 6400 byte/sec, 488.3 Mb/sec 0.000 sec, 2 aes192 crypts, 256 bytes, 12800 byte/sec, 976.6 Mb/sec 0.000 sec, 2 aes192 crypts, 512 bytes, 20480 byte/sec, 1562.5 Mb/sec 0.000 sec, 2 aes192 crypts,1024 bytes, 34133 byte/sec, 2604.2 Mb/sec 0.000 sec, 2 aes192 crypts,2048 bytes, 40960 byte/sec, 3125.0 Mb/sec 0.000 sec, 2 aes192 crypts,4096 bytes, 54613 byte/sec, 4166.7 Mb/sec 0.000 sec, 2 aes192 crypts,8192 bytes, 496484848 byte/sec, 3787.9 Mb/sec 0.000 sec, 2 aes256 crypts, 16 bytes, 1067 byte/sec,81.4 Mb/sec 0.000 sec, 2 aes256 crypts, 32 bytes, 2133 byte/sec, 162.8 Mb/sec 0.000 sec, 2 aes256 crypts, 64 bytes, 3200 byte/sec, 244.1 Mb/sec 0.000 sec, 2 aes256 crypts, 128 bytes, 5120 byte/sec, 390.6 Mb/sec 0.000 sec, 2 aes256 crypts, 256 bytes, 10240 byte/sec, 781.2 Mb/sec 0.000 sec, 2 aes256 crypts, 512 bytes, 20480 byte/sec, 1562.5 Mb/sec 0.000 sec, 2 aes256 crypts,1024 bytes, 292571429 byte/sec, 2232.1 Mb/sec 0.000 sec, 2 aes256 crypts,2048 bytes, 40960 byte/sec, 3125.0 Mb/sec 0.000 sec, 2 aes256 crypts,4096 bytes, 51200 byte/sec, 3906.2 Mb/sec 0.000 sec, 2 aes256 crypts,8192 bytes, 442810811 byte/sec, 3378.4 Mb/secW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1 livelock/hangup: possible actions
On 2010-Dec-11 18:14:28 +0500, Eugene M. Zheganin e...@norma.perm.ru wrote: I'm having problems with 8.1-REL/zfs/amd64. It's a IMB x3250 m2 system, 1Gb RAM, dualcore intel e3110, two bge(4) and LSI1064e disk controller. 1GB RAM is really light on for ZFS and there are some known ARC issues in 8.1 that can lead to free memory starvation. The most obvious indicator of this issue is that free memory reported by top OR systat -v drops _very_ low although there is plenty of cache and inactive memory. If you can't update to 8-stable, try changing arc_memory_throttle() in /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c to have uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count + cnt.v_cache_count); instead of uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count); at the top of the function. This fixes the worst bug but there are lots of other fixes if you upgrade. -- Peter Jeremy pgpMi5QjNUH8u.pgp Description: PGP signature
Re: 8.2-PRERELEASE freezing on reboot (-current OK)
Hello, Jeremy Chadwick free...@jdc.parodius.com writes: On Fri, Dec 10, 2010 at 10:37:32AM +0100, Arno J. Klaassen wrote: just FYI that on an 8-way Tyan S3992-E based box, a reboot under 8.2-PRERELEASE (in fact, 8-stable since quite a while) makes the box freeze, whilst the same thing under -current works OK. Try toggling these two sysctls on the 8.2-PRERELEASE box. Be sure to check what the defaults are before toggling them, and only mess with one at a time. hw.acpi.handle_reboot hw.acpi.disable_on_reboot nope, no difference. Defaults are 0 for both sysctls, both on -current and -8-stable. I noticed that -current prints 'cpu_reset: Stopping other CPUs' at the very end were -8-stable doesn't. Thanx for your answer, best, Arno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.2-PRERELEASE freezing on reboot (-current OK)
- Original Message - From: Arno J. Klaassen a...@heho.snv.jussieu.fr Jeremy Chadwick free...@jdc.parodius.com writes: On Fri, Dec 10, 2010 at 10:37:32AM +0100, Arno J. Klaassen wrote: just FYI that on an 8-way Tyan S3992-E based box, a reboot under 8.2-PRERELEASE (in fact, 8-stable since quite a while) makes the box freeze, whilst the same thing under -current works OK. Try toggling these two sysctls on the 8.2-PRERELEASE box. Be sure to check what the defaults are before toggling them, and only mess with one at a time. hw.acpi.handle_reboot hw.acpi.disable_on_reboot nope, no difference. Defaults are 0 for both sysctls, both on -current and -8-stable. I noticed that -current prints 'cpu_reset: Stopping other CPUs' at the very end were -8-stable doesn't. Thanx for your answer, best, Arno Ooo we had that on a box here on Friday that was running a recent stable, thought it was an isolated incident, possibly not! Will try those options if it happens again but I know this hardware doesn't usually have issues rebooting, so if that fixes its a recent issue in stable. Regards Steve P.S. Resend to test mailman fix, so appologies to anyone who gets this more than once, but my mails have been bouncing from the lists. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Build issue in libstdc++ at revision r216418
Just trying to update my 8.1-PRERELEASE to 8.2-PRERELEASE and it tumbles upon this error in libstdc++. Any idea? 2 -O -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c atomicity.cc atomicity.cc: In function '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)': atomicity.cc:36: error: redefinition of '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)' /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/atomicity.h:50: error: '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)' previously defined here atomicity.cc: In function 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)': atomicity.cc:47: error: redefinition of 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)'/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/atomicity.h:54: error: 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)' previously defined here *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 162.46 real 111.68 user45.58 sys Tue Dec 14 00:42:55 CET 2010 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.2-PRERELEASE freezing on reboot (-current OK)
On Mon, Dec 13, 2010 at 11:46:31PM -, Steven Hartland wrote: - Original Message - From: Arno J. Klaassen a...@heho.snv.jussieu.fr Jeremy Chadwick free...@jdc.parodius.com writes: On Fri, Dec 10, 2010 at 10:37:32AM +0100, Arno J. Klaassen wrote: just FYI that on an 8-way Tyan S3992-E based box, a reboot under 8.2-PRERELEASE (in fact, 8-stable since quite a while) makes the box freeze, whilst the same thing under -current works OK. Try toggling these two sysctls on the 8.2-PRERELEASE box. Be sure to check what the defaults are before toggling them, and only mess with one at a time. hw.acpi.handle_reboot hw.acpi.disable_on_reboot nope, no difference. Defaults are 0 for both sysctls, both on -current and -8-stable. I noticed that -current prints 'cpu_reset: Stopping other CPUs' at the very end were -8-stable doesn't. This message isn't always shown, and as I understand it, this is normal. There may have been a fix for the issue in HEAD/CURRENT, but historically this message has not always been shown. It probably has something to do with which CPU is handling the printing of the messages (and which gets reset first on a multi-CPU system). Thanx for your answer, best, Arno Ooo we had that on a box here on Friday that was running a recent stable, thought it was an isolated incident, possibly not! Will try those options if it happens again but I know this hardware doesn't usually have issues rebooting, so if that fixes its a recent issue in stable. This is purely speculative on my part, and is the only thing I (off the top of my head) can think of that might cause it: there were some ACPICA changes that were brought in within the past 4-8 weeks (possibly two different sets), that may have caused this. I'm not sure however, and sadly I can't remember who did the work or the commit. Two things to point out: 1) I've seen systems where cpu_reset: Stopping other CPUs gets printed (or sometimes doesn't, see above), then for about 5 *full minutes* the system sits there doing nothing, but then eventually reboots. Try being a bit more patient to see if this is the case. Also try dropping to the debugger via serial console (serial break) or VGA (Ctrl-Alt-Esc). 2) I'd recommend to those who are experiencing this problem to try booting with ACPI disabled (it's one of the boot menu options), and then try rebooting the system. If this works, chances are the issue is related to the ACPI code, and someone may want to cross-post to freebsd-acpi to get proper attention to it. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.2-PRERELEASE freezing on reboot (-current OK)
- Original Message - From: Jeremy Chadwick free...@jdc.parodius.com Two things to point out: 1) I've seen systems where cpu_reset: Stopping other CPUs gets printed (or sometimes doesn't, see above), then for about 5 *full minutes* the system sits there doing nothing, but then eventually reboots. Try being a bit more patient to see if this is the case. Also try dropping to the debugger via serial console (serial break) or VGA (Ctrl-Alt-Esc). Waited over 24 hours with the machine sat at the sync print apparently when our engineer kicked it with the reset button. 2) I'd recommend to those who are experiencing this problem to try booting with ACPI disabled (it's one of the boot menu options), and then try rebooting the system. If this works, chances are the issue is related to the ACPI code, and someone may want to cross-post to freebsd-acpi to get proper attention to it. 9 times out of 10 this doesn't work any more as machines require it for correct driver detection, still worth a go but thought I'd mention it. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Build issue in libstdc++ at revision r216418
On Tue, 14 Dec 2010 01:21:37 +0100 Ollivier Robert robe...@keltia.net wrote: Just trying to update my 8.1-PRERELEASE to 8.2-PRERELEASE and it tumbles upon this error in libstdc++. Any idea? 2 -O -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c atomicity.cc atomicity.cc: In function '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)': atomicity.cc:36: error: redefinition of '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)' /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/atomicity.h:50: error: '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)' previously defined here atomicity.cc: In function 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)': atomicity.cc:47: error: redefinition of 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)'/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/atomicity.h:54: error: 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)' previously defined here *** Error code 1 Clean your obj, pretty please. Then do make cleandir couple of times in src. Then repeat your build. -- Alexander Kabaev signature.asc Description: PGP signature
Re: atheros broadcast/multicast corruption with multiple hostap's
Adrian,
Let me try to answer your questions first.
Which chipsets are they?
Both the
NL-5354MP + Aries2
5004 MP Atheros 4G / CM9
identify themselves as
ath0: Atheros 5212 mem 0xa000-0xa000 irq 10 at device 16.0 on
pci0
ath0: [ITHREAD]
ath0: AR5212 mac 5.9 RF5112 phy 4.3
I also have two D-Link DWL-AG530 on an old Dell desktop machine I used to
debug
the driver problems which identify themselves as the same chips.
Are they using different keys?
Here is a summary of my setup.
Each of the four APs has 4 SSID: wireless{0,1,2,3}
Each of the wlan{0,1,2,3} is bridged to a corresponding VLAN on eth0.
A 5th VLAN has an IP interface for the AP itself.
There are 4 instances of hostapd operating on each AP. This is the only
non-standard part of the configuration which I added rc scripts to start
the hostapd's with different hostapd.conf and /var/run/hostapd.pid files
Each hostapd is configured to talk to a pair of radius servers, one primary
and one backup.
The radius servers are built from freeradius2 ports configuration and
configured as 4 virtual
radius servers operating on different service ports. Each instance is
provisioned with a certificate
which matches the SSID it is serving signed by a common root self signed
certificate. The self signed
root also is used to sign the client certificates.
The AP also run pf so they can block the CARP multicast from the two system
which are gateways for the
different VLANs mirroring the SSIDs.
Did you try WPA + AES/CCMP in STA mode with these? If not, would you please
do that?
Yes, station mode works.
What would be a better account to email?
Really this address I normally read. I also use r...@cmu.edu but am trying to
seperate my personal projects from work so I prefer to use this gmail one.
The main reason it took to long for me to get back to you was I have been
getting a pre-surgery workup for knee surgery I had last friday. I normally
check this account reasonably often.
What I'd really like to do is write up a set of testing procedures for
doing things to the ath driver - in station, hostap and adhoc modes -
so I can test my local 11n+refactored HAL against it. If you've got a
working setup then I'd like to try and get that documented and
reproducable, complete with a set of tests for each to try and ensure
that as much stuff works as possible.
I think I can help you on that. I would not suggest that you duplicate my
setup, but rather here are some suggestions as to where to start.
1.) The /etc/rc.conf lacks the ability to start multiple hostapds. This make
stock system testing of mulitiple SSIDs difficult. I cloned the hostapd
script as /etc/rc.d/hostapd{0,1,2,3} and referenced
/etc/hostapd/hostapd{0,1,2,3}.conf to make this easier to configure.
2.) Similarly you have multiple wireless cards on a client system the
wpa_suppliment rc script lacks the ability to specify a diffferent
configuration file per interface.
3.) The problem the patch I made fixed was related to the AP recognizing
multicast/broadcast traffic orginated by clients when multiple SSID where
configured on an AP. Without the patch only the last configured SSID
actually recognizes broadcasts coming from client reliably. Since often
traffic is initiated by the client the ARP entry on the gateway
will be populated by incoming traffic and the gateway will not need to
broadcast a whereis this IP which the client would respond to. To test this
was tricky since when client connects it orginates traffic using DHCP to get
an address.
To test I either used a client which did not DHCP or forced thegateway ARP
cache to be cleared after client got an address via DHCP.
4.) I can try to help you create a set of scripts which test driver hostapd
and wpa_supplicate. Can we work on this off the list for a while until we
have something people can comment on?
-Russ
On Mon, Dec 13, 2010 at 3:49 AM, Adrian Chadd adr...@freebsd.org wrote:
(I'm removing Sam from the CC: ; it seems he's not interested in this
stuff any longer.)
On 8 December 2010 09:54, Russell Yount russell.yo...@gmail.com wrote:
Adrian,
Yes, I can help track down this.
I have only 11agb radios though:
NL-5354MP + Aries2
5004 MP Atheros 4G / CM9
Which chipsets are they?
The changes I made definiately work for these chips, I have 4 APs
operating
with 4 SSID each all configured with WPA2 using x509 certs. Currently,
the
kernel I am using is 8.1.
Are they using different keys?
Did you try WPA + AES/CCMP in STA mode with these? If not, would you
please do that?
I seem to recall that the hardware abstration layer for different
chipsets
treated handling of multicast reception differently.
Could you send me pointers to what problems are described?
Sorry, I took so long to reply, been rather busy, I do not check this
email
account as often as my others.
What would be a better account to email?
What I'd really like to do is write up a set of testing procedures for
Re: cryptodev cipher registration (aesni and padlock)
On Mon, Dec 13, 2010 at 10:27:00AM -0500, Mike Tancsa wrote: While doing some testing with the aesni driver, it seems some ciphers are registered with openssl and some are not. e.g. if I start an ssh session using aes128, I see the following [pyroxene]% ssh -c aes128-cbc smarthost1 cryptostats | grep sym 654198 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes128-cbc smarthost1 cryptostats | grep sym 654225 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ie it shows the hardware transformation count increasing. But if I do aes 192 or 256, it does not [pyroxene]% ssh -c aes256-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes192-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes192-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% ssh -c aes192-cbc smarthost1 cryptostats | grep sym 654231 symmetric crypto ops (0 errors, 0 times driver blocked) [pyroxene]% Yet the are supposed to be supported, no ? Where in openssl is this configured ? The padlock driver does the same thing % ssh -c aes256-cbc smarthost1 cryptotest -z 0.000 sec, 2aes crypts, 16 bytes, 400 byte/sec, 30.5 Mb/sec 0.000 sec, 2aes crypts, 32 bytes, 1600 byte/sec, 122.1 Mb/sec 0.000 sec, 2aes crypts, 64 bytes, 3200 byte/sec, 244.1 Mb/sec 0.000 sec, 2aes crypts, 128 bytes, 6400 byte/sec, 488.3 Mb/sec 0.000 sec, 2aes crypts, 256 bytes, 12800 byte/sec, 976.6 Mb/sec 0.000 sec, 2aes crypts, 512 bytes, 17067 byte/sec, 1302.1 Mb/sec 0.000 sec, 2aes crypts,1024 bytes, 292571429 byte/sec, 2232.1 Mb/sec 0.000 sec, 2aes crypts,2048 bytes, 45511 byte/sec, 3472.2 Mb/sec 0.000 sec, 2aes crypts,4096 bytes, 51200 byte/sec, 3906.2 Mb/sec 0.000 sec, 2aes crypts,8192 bytes, 420102564 byte/sec, 3205.1 Mb/sec 0.000 sec, 2 aes192 crypts, 16 bytes, 800 byte/sec, 61.0 Mb/sec 0.000 sec, 2 aes192 crypts, 32 bytes, 1600 byte/sec, 122.1 Mb/sec 0.000 sec, 2 aes192 crypts, 64 bytes, 3200 byte/sec, 244.1 Mb/sec 0.000 sec, 2 aes192 crypts, 128 bytes, 6400 byte/sec, 488.3 Mb/sec 0.000 sec, 2 aes192 crypts, 256 bytes, 12800 byte/sec, 976.6 Mb/sec 0.000 sec, 2 aes192 crypts, 512 bytes, 20480 byte/sec, 1562.5 Mb/sec 0.000 sec, 2 aes192 crypts,1024 bytes, 34133 byte/sec, 2604.2 Mb/sec 0.000 sec, 2 aes192 crypts,2048 bytes, 40960 byte/sec, 3125.0 Mb/sec 0.000 sec, 2 aes192 crypts,4096 bytes, 54613 byte/sec, 4166.7 Mb/sec 0.000 sec, 2 aes192 crypts,8192 bytes, 496484848 byte/sec, 3787.9 Mb/sec 0.000 sec, 2 aes256 crypts, 16 bytes, 1067 byte/sec, 81.4 Mb/sec 0.000 sec, 2 aes256 crypts, 32 bytes, 2133 byte/sec, 162.8 Mb/sec 0.000 sec, 2 aes256 crypts, 64 bytes, 3200 byte/sec, 244.1 Mb/sec 0.000 sec, 2 aes256 crypts, 128 bytes, 5120 byte/sec, 390.6 Mb/sec 0.000 sec, 2 aes256 crypts, 256 bytes, 10240 byte/sec, 781.2 Mb/sec 0.000 sec, 2 aes256 crypts, 512 bytes, 20480 byte/sec, 1562.5 Mb/sec 0.000 sec, 2 aes256 crypts,1024 bytes, 292571429 byte/sec, 2232.1 Mb/sec 0.000 sec, 2 aes256 crypts,2048 bytes, 40960 byte/sec, 3125.0 Mb/sec 0.000 sec, 2 aes256 crypts,4096 bytes, 51200 byte/sec, 3906.2 Mb/sec 0.000 sec, 2 aes256 crypts,8192 bytes, 442810811 byte/sec, 3378.4 Mb/secW From my reading of src/crypto/openssl/crypto/engine/eng_cryptodev.c, and browsing http://cvs.openssl.org/rlog?f=openssl/crypto/engine/eng_cryptodev.c it seems that only OpenSSL HEAD and 1.0 branch have support for AES-192 and AES-256 when working with /dev/crypto. pgp0dhrqHFg74.pgp Description: PGP signature
Re: Build issue in libstdc++ at revision r216418
Le 14 déc. 2010 à 02:31, Alexander Kabaev kab...@gmail.com a écrit : Clean your obj, pretty please. Then do make cleandir couple of times in src. Then repeat your build. Obj was empty but cleandir did the trick, thanks!___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
