Re: Beaglebone Black + FreeBSD + USB WiFi = WAP?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Beaglebone Black + FreeBSD + USB WiFi = WAP?

Russell Haley
This got sent only to Chris by accident so I am forwarding it to the
mailing list. Comment below...

Russ

---------- Forwarded message ----------
From: Russell Haley <[hidden email]>
Date: Mon, Sep 4, 2017 at 10:59 PM
Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP?
To: Chris Gordon <[hidden email]>


On Mon, Sep 4, 2017 at 10:50 PM, Russell Haley <[hidden email]> wrote:

> On Sat, Aug 26, 2017 at 11:48 PM, Russell Haley <[hidden email]> wrote:
>> On Sat, Aug 26, 2017 at 11:35 PM, Russell Haley <[hidden email]> wrote:
>>> On Thu, Aug 24, 2017 at 11:26 PM, Russell Haley <[hidden email]> wrote:
>>>> On Tue, Aug 22, 2017 at 5:51 PM, Chris Gordon <[hidden email]> wrote:
>>>>> Ilya,
>>>>>
>>>>> Thanks for the follow up.
>>>>>
>>>>>> On Aug 22, 2017, at 3:11 PM, Ilya Bakulin <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> have you found the issue already?
>>>>>
>>>>> I have not.  See below for some theories...
>>>>>
>>>>>> If not: what does `top -Sa` show when you're running your speed test?
>>>>>> Specifically what does "CPU:" line look like, and what are the top processes in the list?
>>>>>
>>>>> The system stays at >90% idle through the entire test (upload and download).  I see 2-4% WCPU for interrupts and 1-2% for USB.
>>>>>
>>>>>> I've had an issue with FreeBSD acting as WAP (although using Atheros-based NIC) some years ago,
>>>>>> the problem back then was that the machine CPU was just too slow to process the traffic.
>>>>>
>>>>> I had initially thought that maybe the little CPU in the BeagleBone wasn’t up to the WPA encryption or the interrupt rate + usb where just too much for it.  Sometimes changing channels helps for a little bit.  Since I’ve been tinkering with this little project, I’ve been paying a bit more attention to my overall WiFi performance and I’m beginning to think there are just too many WiFi signals nearby and congestion is just killing my overall WiFi performance.
>>>>>
>>>>> Any other ideas?
>>>>
>>>> Hi, I'm just trying to reproduce your setup with my BBB and an ASUS
>>>> wi-fi stick. The chipset is Ralink RT3052. I just got the dongle
>>>> working so I'll see if I can set it up as an access point this
>>>> weekend. I can't make any promises on play time though. :)
>>>
>>>
>>>
>>> Hi!
>>>
>>> So I'm only partially successful repeating your test so far, but I can
>>> cause a kernel panic! The following are my observations:
>>>
>>> Running BBB through ftdi cable.
>>> Asus WiFi Adapter, RT3071 chipset
>>> https://wikidevi.com/files/Ralink/RT307x%20product%20brief.pdf
>>>
>>> root@bbb:~ # uname -a
>>> FreeBSD bbb.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #7
>>> r321601M: Thu Aug 17 22:13:21 PDT 2017
>>> [hidden email]:/usr/home/russellh/FreeBSD/rh-armv6/obj/arm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/BEAGLEBONE-MMCCAM
>>>  arm
>>>
>>> root@bbb:~ # cat /boot/loader.conf
>>> if_run0_load="YES"
>>> wlan_mac_load="YES"
>>>
>>> root@bbb:~ # cat /etc/rc.conf
>>> hostname="bbb.highfell.local"
>>> ifconfig_cpsw0="inet 192.168.2.101 netmask 255.255.255.0"
>>> defaultrouter="192.168.2.1"
>>> hostapd_enable="YES"
>>> wlans_run0="wlan0"
>>> create_args_wlan0="wlanmode hostap"
>>> ifconfig_wlan0="up"
>>> #gateway_enable="YES"
>>> cloned_interfaces="bridge0"
>>> ifconfig_bridge0="addm cpsw0 addm wlan0 up"
>>>
>>> sshd_enable="YES"
>>> sendmail_enable="NONE"
>>> sendmail_submit_enable="NO"
>>> sendmail_outbound_enable="NO"
>>> sendmail_msp_queue_enable="NO"
>>> growfs_enable="YES"
>>>
>>>
>>>
>>> root@bbb:~ # cat /etc/hostapd.conf
>>> interface=wlan0
>>> debug=1
>>> ctrl_interface=/var/run/hostapd
>>> ctrl_interface_group=wheel
>>> ssid=freebsd
>>> wpa=2
>>> wpa_passphrase=testing
>>> wpa_key_mgmt=WPA-PSK
>>> wpa_pairwise=CCMP
>>>
>>> root@bbb:~ # cat /etc/resolv.conf
>>> # Generated by resolvconf
>>> nameserver 192.168.2.1
>>>
>>>
>>> 1) Before the kernel loads, loader give the following errors:
>>>
>>> can't find 'if_run'
>>> can't find 'wlan_mac'
>>>
>>> 2) It seems the run0 usb wi-fi interface only comes up after the
>>> bridge0 is already enabled. dmesg does NOT capture the output from the
>>> failed attempt to add the non-existent wlan0 interface. However, I
>>> grabbed it from the boot output in the serial console:
>>>
>>> #From dmesg:
>>>
>>> ugen1.2: <Ralink 802.11 n WLAN> at usbus1
>>> random: unblocking device.
>>> bridge0: Ethernet address: 02:94:dd:d7:a3:00
>>> cpsw0: link state changed to DOWN
>>> cpsw0: promiscuous mode enabled
>>> bridge0: link state changed to DOWN
>>> cpsw0: link state changed to UP
>>> bridge0: link state changed to UP
>>> run0 on uhub1
>>> run0: <1.0> on usbus1
>>> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address
>>> 60:a4:4c:ec:c9:a5
>>> ieee80211_load_module: load the wlan_amrr module by hand for now.
>>> wlan0: Ethernet address: 60:a4:4c:ec:c9:a5
>>> run0: firmware RT3071 ver. 0.33 loaded
>>>
>>> #From console grab:
>>>
>>> eeding entropy: .
>>> ifconfig: SIOCIFCREATE2: Invalid argument
>>> bridge0: Ethernet address: 02:94:dd:d7:a3:00
>>> Created clone interfaces: bridge0.
>>> cpsw0: link state changed to DOWN
>>> cpsw0: promiscuous mode enabled
>>> bridge0: link state changed to DOWN
>>> ifconfig: BRDGADD wlan0: No such file or directory
>>> cpsw0: link state changed to UP
>>> bridge0: link state changed to UP
>>> Starting Network: lo0 cpsw0 bridge0.
>>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>>         options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
>>>         inet6 ::1 prefixlen 128
>>>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>>>         inet 127.0.0.1 netmask 0xff000000
>>>         groups: lo
>>>         nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>>> cpsw0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>> metric 0 mtu 1500
>>>         options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
>>>         ether a0:f6:fd:8a:c5:be
>>>         hwaddr a0:f6:fd:8a:c5:be
>>>         inet 192.168.2.101 netmask 0xffffff00 broadcast 192.168.2.255
>>>         media: Ethernet autoselect (100baseTX <full-duplex>)
>>>         status: active
>>>         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>         ether 02:94:dd:d7:a3:00
>>>         id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>>         maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>>>         root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>>         member: cpsw0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>                 ifmaxaddr 0 port 1 priority 128 path cost 55
>>>         groups: bridge
>>>         nd6 options=9<PERFORMNUD,IFDISABLED>
>>> Starting devd.
>>> run0 on uhub1
>>> run0: <1.0> on usbus1
>>> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address
>>> 60:a4:4c:ec:c9:a5
>>> ieee80211_load_module: load the wlan_amrr module by hand for now.
>>> wlan0: Ethernet address: 60:a4:4c:ec:c9:a5
>>> Created wlan(4) interfaces: wlan0.
>>> run0: firmware RT3071 ver. 0.33 loaded
>>> Starting Network: wlan0.
>>> wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>         ether 60:a4:4c:ec:c9:a5
>>>         hwaddr 60:a4:4c:ec:c9:a5
>>>         groups: wlan
>>>         ssid "" channel 11 (2462 MHz 11g)
>>>         regdomain FCC country US authmode OPEN privacy OFF txpower 30
>>>         scanvalid 60 protmode CTS wme dtimperiod 1 -dfs bintval 0
>>>         media: IEEE 802.11 Wireless Ethernet autoselect <hostap>
>>> (autoselect <hostap>)
>>>         status: no carrier
>>>         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> add host 127.0.0.1: gateway lo0 fib 0: route already in table
>>> add net default: gateway 192.168.2.1
>>> add host ::1: gateway lo0 fib 0: route already in table
>>>
>>>
>>> *Something else to note about this setup output is that wlan0 did NOT
>>> get the ssid or the security setup from /etc/hostapd.conf
>>>
>>> After boot I manually add the wlan0 to the bridge and then set the ssid
>>>
>>> root@bbb:~ # ifconfig bridge0 addm wlan0
>>> root@bbb:~ # ifconfig wlan0 ssid freebsd
>>>
>>> I brought the interface down and back up again which made the AP is
>>> available to the clients. I open the ipod and get the system to
>>> associate with the ap and enter the following information
>>>
>>> static IP
>>>
>>> address: 192.168.2.102
>>> subnet: 255.255.255.0
>>> router: 192.168.2.1
>>> dns : 192.168.1
>>>
>>> After numerous wrong attempts at configuring the client, I managed to
>>> get exactly ONE request through. The freebsd.org page came up. I then
>>> tried to search for the ookla page and my bbb kernel paniced! (yay!)
>>> https://pastebin.com/zB9AnWTv
>>>
>>> The next time I booted the entire board hung right after the usb wifi
>>> adapter loaded (chop of hung board output, full output here
>>> https://pastebin.com/M09C5NEP):
>>>
>>> cpsw0: link state changed to UP
>>> bridge0: link state changed to UP
>>> Starting Network: lo0 cpsw0 bridge0.
>>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>>         options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
>>>         inet6 ::1 prefixlen 128
>>>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>>>         inet 127.0.0.1 netmask 0xff000000
>>>         groups: lo
>>>         nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>>> cpsw0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>> metric 0 mtu 1500
>>>         options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
>>>         ether a0:f6:fd:8a:c5:be
>>>         hwaddr a0:f6:fd:8a:c5:be
>>>         inet 192.168.2.101 netmask 0xffffff00 broadcast 192.168.2.255
>>>         media: Ethernet autoselect (100baseTX <full-duplex>)
>>>         status: active
>>>         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>         ether 02:94:dd:d7:a3:00
>>>         id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>>         maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>>>         root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>>         member: cpsw0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>                 ifmaxaddr 0 port 1 priority 128 path cost 55
>>>         groups: bridge
>>>         nd6 options=9<PERFORMNUD,IFDISABLED>
>>> Starting devd.
>>> run0 on uhub1
>>> run0: <1.0> on usbus1
>>>
>>> U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)
>>> bad magic
>>>
>>> Sometimes it boots, sometimes it hangs (I'd say 3 to 1). The lights on
>>> the cpsw0 interface still blink but the serial console is dead. I'm
>>> trying to *avoid* triggering that so I don't know the sequence that's
>>> causing it. However, I can cause the kernel to panic on the BBB
>>> relatively quickly from a handful of page requests on the ipod. No
>>> more than three full page requests so far.  It seems there is a bad
>>> memory copy happening in bridge_broadcast() at bridge_broadcast+0x1c4?
>>>
>>> https://www.freebsd.org/cgi/man.cgi?apropos=0&sektion=9&query=m_dup
>>>
>>> Anyway, that's all the time I have for this weekend. I'm going to take
>>> the chance that someone wants to see this and put it in bugzilla.
>>>
>>> Cheers,
>>>
>>> Russ
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221845
>>
>> Cheers,
>> Russ
>
> Hi,
>
> I've been digging into the code for if_bridge.c, which is found under
> sys/net. bridge_broadcast only has one call to m_dup on line 2553.

Hi,

I've been digging into the code for if_bridge.c, which is found under
sys/net. bridge_broadcast only has one call to m_dup on line 2553.

            mc = m_dup(m, M_NOWAIT);
            if (mc == NULL) {
                if_inc_counter(sc->sc_ifp, IFCOUNTER_OERRORS, 1);
                continue;
            }

This is just a guess: I'm wondering if the M_NOWAIT is causing the
panic because... er... "someone has a sleep lock they shouldn't"?  I
don't really know what I'm talking about though (a little bit of
knowledge...)

I guess I'd have to try and correlate to some sort of lock begin held
in the adapter specific code?

Cheers,

Russ
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"