Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 20 Jan 2021 04:41:49 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 252844] wpa_supplicant(8): CPU is high and can't associate with wireless network
Message-ID:  <bug-252844-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252844

            Bug ID: 252844
           Summary: wpa_supplicant(8): CPU is high and can't associate
                    with wireless network
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: ankohuu@outlook.com

My laptop has one wireless NIC and I use wpa_supplicant to connect wireless.
After git commit 81728a538d24f483d0986850fa3f51d5d84d8f26, the wireless net=
work
cannot be associated.

lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
        ether 9c:da:3e:a1:8a:fb
        groups: wlan
        ssid "" channel 1 (2412 MHz 11g)
        regdomain FCC country US authmode WPA1+WPA2/802.11i privacy MIXED
        deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
        roaming MANUAL bintval 0
        parent interface: iwm0
        media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
        status: no carrier
        nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

The wpa_supplicant's CPU is high.
root  901 100.0  0.1 18584  7916  -  Rs   11:35    38:47.24
/usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant.conf -D bsd =
-P
/var/run/wpa_supplicant/wlan0.pid

I trace wpa_supplicant, kdump tell me it loop works on
   901 100532 wpa_supplicant 0.108685 CALL=20
select(0x6,0x800e3d100,0x800e3d180,0x800e3d200,0x7fffffffe9e0)
   901 100532 wpa_supplicant 0.108689 RET   select 1
   901 100532 wpa_supplicant 0.108693 CALL  read(0x4,0x800e08010,0)
   901 100532 wpa_supplicant 0.108696 RET   read 0
0x4 is PF_ROUTE socket, and read(2)'len is 0, very weird.

I check wpa_supplicant's code, and find read length is got by sysctl
static size_t=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
rtbuf_len(void)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
{=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20
    size_t len;=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

    int mib[6] =3D {CTL_NET, AF_ROUTE, 0, AF_INET, NET_RT_DUMP, 0};=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20

    if (sysctl(mib, 6, NULL, &len, NULL, 0) < 0) {=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
        wpa_printf(MSG_WARNING, "%s failed: %s", __func__,=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
               strerror(errno));=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20
        len =3D 2048;=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
    }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20

    return len;=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
}
What is returned is the total length of current AF_INET route items.

When system is started, rc.d/netif starts network interfaces in "ifconfig -=
l"
order,
very lucky, lo0 is before wlan0, and ipv4_up lo0 adds 127.0.0.1 to lo0,
subsequently wlan0's up call wpa_supplicant and use sysctl to get rtbuf_len=
.=20

respond to lo0 ipv4_up operation,=20
before the git commit, network calls in_control->in_addprefix->rtinit, and =
then
AF_INET family has route items, and sysctl return non zero.
after the git commit, in_addprefix calls in_handle_ifaddr_route, but
in_handle_ifaddr_route don't add loopback routes, so sysctl returns zero ca=
use
the problem, maybe util rc.d/routing's start, loopback routes can be added.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252844-227>