headers
Rui Paulo | 1 Mar 2010 01:03
Picon

Re: FreeBSD-8.0 802.11n support with ath/mwl

On 28 Feb 2010, at 17:38, Jim Pingle wrote:

> On 2/28/2010 7:54 AM, Rui Paulo wrote:
>> On 28 Feb 2010, at 03:22, Jim Pingle wrote:
>>> 
>>> Are you aware if similar work ongoing for the mwl(4) based 802.11n
>>> cards? I picked up a couple cheap this past week and have them working
>>> with hostapd but, as with the OP in the thread, only with G rates.
>>> 
>>> The ifconfig[1] output suggests that it is using 40MHz wide ht channels
>>> but devices only associate at 54Mbps[2].
>>> 
>>> Jim
>>> 
>>> [1] ifconfig mwl0_wlan1
>>> mwl0_wlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
>>> mtu 1500
>>> ether 00:01:36:17:96:0e
>>> inet6 fe80::201:36ff:fe17:960e%mwl0_wlan1 prefixlen 64 scopeid 0x9
>>> inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
>>> nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11na <hostap>
>>> status: running
>>> ssid WatchTower channel 100 (5500 MHz 11a ht/40+) bssid 00:01:36:17:96:0e
>>> regdomain DEBUG indoor authmode WPA2/802.11i privacy MIXED deftxkey 3
>>> AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 14 scanvalid 60
>>> ampdulimit 64k ampdudensity 4 shortgi smps burst dtimperiod 1
>>> 
>>> 
>>> [2] ifconfig mwl0_wlan1 list sta (w/addr removed)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Dan Langille | 1 Mar 2010 01:08
Favicon
Gravatar

FreeBSD 7.3-stable fails to boot under KVM

A bunch of use have colo'd a server at an ISP.  We each run our own KVM 
(I have no other details at present). I've been running FreeBSD 7.3 
inside my KVM (everyone else is running Linux.

I encountered a problem when I tried to upgrade the install from 
7.2-stable to 7.3-stable.

The boot process hangs.  The last thing shown is the memory in the 
system.  I'll copy/paste from /var/log/messages to demonstrate the point 
last thing I can see on the VNC screen.

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #0: Thu Dec  3 20:37:29 UTC 2009
dan <at> latens.example.org:/usr/obj/usr/src/sys/LATENS i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: QEMU Virtual CPU version 0.9.1 (3008.69-MHz 686-class CPU)
Origin = "AuthenticAMD"  Id = 0x623  Stepping = 3
Features=0x78bfbfd<FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
Features2=0x80000001<SSE3,<b31>>
AMD Features=0x20100800<SYSCALL,NX,LM>
real memory  = 268369920 (255 MB)
avail memory = 248524800 (237 MB)

^^^ last thing I see.

I can get to the boot loader screen (which is how I booted from kernel.old)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Pingle | 1 Mar 2010 03:18
Favicon

Re: FreeBSD-8.0 802.11n support with ath/mwl

On 2/28/2010 2:29 PM, Bernhard Schmidt wrote:
> On Sun, Feb 28, 2010 at 12:38:19PM -0500, Jim Pingle wrote:
[snip]
>> In this case, the mwl card is the AP. The client line is from an
>> associated Windows 7 laptop with an Intel 5100abgn card which does show
>> the AP as 802.11n in the AP list. I'm connected and sending this message
>> through it right now, actually.
>>
>> Are there some other bits that need set in order to have clients
>> associate with HT rates? Or some other prerequisite conditions such as
>> number of attached antennae? I do only have one antenna attached as I
>> didn't have a second pigtail for this test unit's case. The card
>> actually has three connectors.
>>
>> I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5),
>> or ifconfig(8) man pages about troubleshooting rates. I see plenty of
>> talk in ifconfig(8) about use and control of HT rates, but given what
>> I'm seeing in ifconfig, it should be set to use them. I've tried several
>> combinations of channels and standards (e.g. 11ng, 11na) but always end
>> up with a 54Mbps link.
>>
>> I'd appreciate any more pointers that you (or anyone else reading) may
>> have. I'd like to write up something on the topic once I get it fully
>> operational.
> 
> Did you measure the actual bandwidth you get? Changes are high that you
> are actually using HT rates, the rate information is just no accurate.

I did some tests and the throughput was quite slow. Enough to make me
wonder about the antenna situation again. I'll have to dig up more
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Pingle | 1 Mar 2010 03:26
Favicon

Re: FreeBSD-8.0 802.11n support with ath/mwl

On 2/28/2010 7:03 PM, Rui Paulo wrote:
> On 28 Feb 2010, at 17:38, Jim Pingle wrote:
>> Are there some other bits that need set in order to have clients
>> associate with HT rates? Or some other prerequisite conditions such as
>> number of attached antennae? I do only have one antenna attached as I
>> didn't have a second pigtail for this test unit's case. The card
>> actually has three connectors.
> 
> Having only 1 antenna connected will likely impact your connection.

I'll hook up two more and try again when I get a chance, I just need to
pull them from a working unit that isn't using its wifi currently.

>> I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5),
>> or ifconfig(8) man pages about troubleshooting rates. I see plenty of
>> talk in ifconfig(8) about use and control of HT rates, but given what
>> I'm seeing in ifconfig, it should be set to use them. I've tried several
>> combinations of channels and standards (e.g. 11ng, 11na) but always end
>> up with a 54Mbps link.
>>
>> I'd appreciate any more pointers that you (or anyone else reading) may
>> have. I'd like to write up something on the topic once I get it fully
>> operational.
> 
> I don't know what's happening, but I guess your Windows 7 laptop isn't sending the necessary HT rates in the
association. Try using wlandebug to see what's happening.

Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate
on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug
and that doesn't show up on my system. Another system with a ral(4) card
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rui Paulo | 1 Mar 2010 03:41
Picon

Re: FreeBSD-8.0 802.11n support with ath/mwl


On 1 Mar 2010, at 02:26, Jim Pingle wrote:

> On 2/28/2010 7:03 PM, Rui Paulo wrote:
>> On 28 Feb 2010, at 17:38, Jim Pingle wrote:
>>> Are there some other bits that need set in order to have clients
>>> associate with HT rates? Or some other prerequisite conditions such as
>>> number of attached antennae? I do only have one antenna attached as I
>>> didn't have a second pigtail for this test unit's case. The card
>>> actually has three connectors.
>> 
>> Having only 1 antenna connected will likely impact your connection.
> 
> I'll hook up two more and try again when I get a chance, I just need to
> pull them from a working unit that isn't using its wifi currently.
> 
>>> I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5),
>>> or ifconfig(8) man pages about troubleshooting rates. I see plenty of
>>> talk in ifconfig(8) about use and control of HT rates, but given what
>>> I'm seeing in ifconfig, it should be set to use them. I've tried several
>>> combinations of channels and standards (e.g. 11ng, 11na) but always end
>>> up with a 54Mbps link.
>>> 
>>> I'd appreciate any more pointers that you (or anyone else reading) may
>>> have. I'd like to write up something on the topic once I get it fully
>>> operational.
>> 
>> I don't know what's happening, but I guess your Windows 7 laptop isn't sending the necessary HT rates in
the association. Try using wlandebug to see what's happening.
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jim Pingle | 1 Mar 2010 04:05
Favicon

Re: FreeBSD-8.0 802.11n support with ath/mwl

On 2/28/2010 9:41 PM, Rui Paulo wrote:
> On 1 Mar 2010, at 02:26, Jim Pingle wrote:
>> Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate
>> on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug
>> and that doesn't show up on my system. Another system with a ral(4) card
>> does have that sysctl. Judging by the information in the wlandebug(8)
>> man page it appears as though this may be a side effect of mwl doing
>> much of the work in firmware.
> 
> wlandebug takes an -i argument. I seem to recall you created your wlan interface named "mwl_wlan0", so you
need to type wlandebug -i mwl_wlan0.

I saw that, but that is hardcoded to expect wlan<x> (wlan0, wlan1, etc)
for an interface name. Having seen that, I recompiled wlandebug without
the hardcoded interface name check and it didn't work either, but it did
toss an error for the sysctl it was trying to tweak.

That made me look deeper at the code and see it was really just setting
the debug sysctl based on flags that wlandebug was aware of. Handy, but
the same thing could be done by hand with sysctl and some bitwise math
in a pinch, assuming the interface has the right oids. (Which mine
doesn't, for some reason...)

Jim
_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rui Paulo | 1 Mar 2010 04:16
Picon

Re: FreeBSD-8.0 802.11n support with ath/mwl

On 1 Mar 2010, at 03:05, Jim Pingle wrote:

> On 2/28/2010 9:41 PM, Rui Paulo wrote:
>> On 1 Mar 2010, at 02:26, Jim Pingle wrote:
>>> Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate
>>> on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug
>>> and that doesn't show up on my system. Another system with a ral(4) card
>>> does have that sysctl. Judging by the information in the wlandebug(8)
>>> man page it appears as though this may be a side effect of mwl doing
>>> much of the work in firmware.
>> 
>> wlandebug takes an -i argument. I seem to recall you created your wlan interface named "mwl_wlan0", so
you need to type wlandebug -i mwl_wlan0.
> 
> I saw that, but that is hardcoded to expect wlan<x> (wlan0, wlan1, etc)
> for an interface name. Having seen that, I recompiled wlandebug without
> the hardcoded interface name check and it didn't work either, but it did
> toss an error for the sysctl it was trying to tweak.

The whole system was designed for the interfaces to start with "wlan" and be named "wlan<something>".

> That made me look deeper at the code and see it was really just setting
> the debug sysctl based on flags that wlandebug was aware of. Handy, but
> the same thing could be done by hand with sysctl and some bitwise math
> in a pinch, assuming the interface has the right oids. (Which mine
> doesn't, for some reason...)

The purpose of wlandebug is to not do any math by hand.

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jim Pingle | 1 Mar 2010 05:56
Favicon

Re: FreeBSD-8.0 802.11n support with ath/mwl

On 2/28/2010 10:16 PM, Rui Paulo wrote:
> On 1 Mar 2010, at 03:05, Jim Pingle wrote:
> 
>> On 2/28/2010 9:41 PM, Rui Paulo wrote:
>>> On 1 Mar 2010, at 02:26, Jim Pingle wrote:
>>>> Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate
>>>> on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug
>>>> and that doesn't show up on my system. Another system with a ral(4) card
>>>> does have that sysctl. Judging by the information in the wlandebug(8)
>>>> man page it appears as though this may be a side effect of mwl doing
>>>> much of the work in firmware.
>>>
>>> wlandebug takes an -i argument. I seem to recall you created your wlan interface named "mwl_wlan0", so
you need to type wlandebug -i mwl_wlan0.
>>
>> I saw that, but that is hardcoded to expect wlan<x> (wlan0, wlan1, etc)
>> for an interface name. Having seen that, I recompiled wlandebug without
>> the hardcoded interface name check and it didn't work either, but it did
>> toss an error for the sysctl it was trying to tweak.
> 
> The whole system was designed for the interfaces to start with "wlan" and be named "wlan<something>".

It does certainly seem to lean that way. Personally I prefer to keep the
hardware name in there, but I wasn't aware that would cause other
issues. Especially when VAPs come into play, I'd rather have, for
example, mwl0_wlan1, mwl0_wlan2, ath0_wlan0, etc, so I can better tie
what goes where. But that's more of a bikeshed of personal preference. :-)

> 
>> That made me look deeper at the code and see it was really just setting
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Rikhlivsky | 1 Mar 2010 08:29
Picon

Neighbors inactivity

I have a few NASes based on FreeBSD 7.2 and quagga 0.99.14, they all have same
configuration with little changes.

When I add to network a test server based on FreeBSD 8.0-STABLE
with quagga 0.99.15, other servers doesn't receive HELLO packets from him.

nas9# tcpdump -i vr0 proto ospf
13:24:04.591907 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:09.594136 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:14.596375 IP 193.62.62.14a>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:19.598678 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:24.600867 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:29.603050 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:34.605322 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:39.607564 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44
13:24:44.609799 IP 193.62.62.14>  OSPF-ALL.MCAST.NET: OSPFv2,
Hello, length 44

Counter of multicast packets on switch port constantly increasing.
What the reason of inaccessibility other servers over multicast?

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Mamalakis | 1 Mar 2010 11:35
Picon
Favicon

mount_newnfs & mount_nullfs problem.

Dear all,

In short:
If I export the filesystem /export/homes, and mount it through nfsv4 on 
a fbsd8-stable box in the folder /mnt, and then use mount_nullfs /mnt/ 
/path1/path2/path3, then I have the following-wrong behaviour. If I use 
vi /path1/path2/path3/mamalos/newfile to write a file, the file is saved 
in /path1/path2, instead (!!?!). Which is on my local filesystem tree. 
If I echo "mytestfile" > /path1/path2/path3/mamalos/one, then the file 
is correctly written in /path1/path2/path3/mamalos/one.

In my jail environment, I use a similar approach to that of 
freebsd-handbook for application jails (paragraph 15.6).

So in my setup, mount command shows:

solaris:/export/homes on /mnt (newnfs)
/jails/j/mroot on /jails/j/postfix (nullfs, local, read-only)
/jails/s/postfix on /jails/j/postfix/s (nullfs, local, read-only)
/jails/t/postfix on /jails/j/postfix/t (nullfs, local)
/mnt on /jails/j/postfix/t/home (nullfs)

where we see my imported filesystem, the path where my postfix jail 
starts (/jails/j/postfix) along with two other filesystems mounted on it 
(/jails/j/postfix/s and /jails/j/postfix/t). On top of the latter's 
folder "home" I mount /mnt.

If I jexec to that jail, and try to create a file using vi, then vi 
/home/mamalos/myfile is written in /jails/t/postfix (which is the same 
as /jails/j/postfix/t)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane