WLAN associated, but DHCP not working (iwm) (iwlwifi)

R

raph

Hi all,

I have Dell Latitude E7390. I bought it especially for FreeBSD, I checked the compatibility on https://wiki.freebsd.org/Laptops, so I didn't expected any issues with hardware.
However the WiFI does not work, i.e. The connection is associated, but the dhclient cannot obtain a configuration.
Code: 
$ ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 5c:87:9c:xx:xx:xx
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
    groups: wlan
    ssid xxx-bgn channel 11 (2462 MHz 11g) bssid 30:23:03:xx:xx:xx
    regdomain ETSI country PL authmode WPA2/802.11i privacy ON
    deftxkey UNDEF AES-CCM 3:128-bit txpower 30 bmiss 7 scanvalid 60
    protmode CTS wme roaming MANUAL
    parent interface: iwlwifi0
    media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g
    status: associated
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Code: 
# dhclient wlan0
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

The device is Intel Dual Band Wireless AC 8265:
Code: 
$ pciconf -l | grep wifi
iwlwifi0@pci0:2:0:0:    class=0x028000 rev=0x78 hdr=0x00 vendor=0x8086 device=0x24fd subvendor=0x8086 subdevice=0x0050

My current system is FreeBSD 13.2-RC1, but I had the same on 13.1.
I tested both iwm and iwlwifi drivers, there's no difference in behaviour - I can scan available wifi networks and connect to the one of them, but dhclient does not work.
I'm able to use tcpdump, it shows dhcp requests and broadcast packets from other devices, but no dhcp offers.
I checked also router (openwrt) using tcpdump. On the router's side tcpdump does not show dhcp requests.

I checked the hardware using Ubuntu Live CD, it seems that wifi works perfectly fine.
I have no idea what else can be wrong, after three days I'm here for some help.
 
Update:
Debugging iwlwifi, dmesg:
Code: 
iwlwifi0: <iwlwifi> mem 0xef000000-0xef001fff irq 18 at device 0.0 on pci2
iwlwifi0: successfully loaded firmware image 'iwlwifi-8265-36.ucode'
iwlwifi0: loaded firmware version 36.ca7b901d.0 8265-36.ucode op_mode iwlmvm
iwlwifi0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230
iwlwifi0: base HW address: 5c:87:9c:xx:xx:xx, OTP minor version: 0x4
wlan0: Ethernet address: 5c:87:9c:xx:xx:xx
lo0: link state changed to UP
wlan0: start running, 0 vaps running
wlan0: ieee80211_start_locked: up parent iwlwifi0
wlan0: start running, 1 vaps running
wlan0: ieee80211_new_state_locked: INIT -> SCAN (arg 0) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: INIT -> SCAN arg 0
wlan0: sta_newstate: INIT -> SCAN (0)
wlan0: ieee80211_alloc_node 0xfffffe011342e000<30:23:03:xx:xx:xx> in station table
wlan0: node_reclaim: remove 0xfffffe01121a6000<5c:87:9c:xx:xx:xx> from station table, refcnt 1
wlan0: ieee80211_sta_join1 0xfffffe011342e000<30:23:03:xx:xx:xx> SCAN -> AUTH, FC0_SUBTYPE_DEAUTH
wlan0: ieee80211_new_state_locked: SCAN -> AUTH (arg 192) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: SCAN -> AUTH arg 192
wlan0: [30:23:03:xx:xx:xx] station assoc via MLME
wlan0: ieee80211_alloc_node 0xfffffe01115bf000<30:23:03:xx:xx:xx> in station table
wlan0: node_reclaim: remove 0xfffffe011342e000<30:23:03:xx:xx:xx> from station table, refcnt 2
wlan0: ieee80211_sta_join1 0xfffffe01115bf000<30:23:03:xx:xx:xx> SCAN -> AUTH, FC0_SUBTYPE_DEAUTH
wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost
wlan0: ieee80211_new_state_locked: SCAN -> AUTH (arg 192) (nrunning 0 nscanning 0)
wlan0: sta_newstate: SCAN -> AUTH (192)
wlan0: ieee80211_ref_node (ieee80211_send_mgmt:2708) 0xfffffe01115bf000<30:23:03:xx:xx:xx> refcnt 4
wlan0: ieee80211_newstate_cb: AUTH -> AUTH arg 192
Invalid TXQ id
wlan0: ni 0xfffffe01115bf000 vap 0xfffffe01121a4010 mode STA state AUTH m 0xfffff8000951da00 status 4543576
wlan0: ni 0xfffffe01115bf000 mode STA state AUTH arg 0x2 status 4543576
wlan0: vap 0xfffffe01121a4010 mode STA state AUTH flags 0x2000 & 0x80
wlan0: ieee80211_new_state_locked: AUTH -> SCAN (arg 1) (nrunning 0 nscanning 0)
wlan0: sta_newstate: AUTH -> AUTH (192)
wlan0: ieee80211_ref_node (ieee80211_send_mgmt:2708) 0xfffffe01115bf000<30:23:03:xx:xx:xx> refcnt 4
wlan0: ieee80211_newstate_cb: AUTH -> SCAN arg 1
wlan0: ni 0xfffffe01115bf000 vap 0xfffffe01121a4010 mode STA state AUTH m 0xfffff80012352a00 status 1
wlan0: ni 0xfffffe01115bf000 mode STA state AUTH arg 0x2 status 1
iwlwifi0: lkpi_iv_newstate: error -5 during state transition 2 (AUTH) -> 1 (SCAN)
wlan0: sta_newstate: AUTH -> SCAN (1)
wlan0: vap 0xfffffe01121a4010 mode STA state AUTH flags 0x2000 & 0x80
wlan0: ieee80211_new_state_locked: SCAN -> SCAN (arg 1) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: SCAN -> SCAN arg 1
wlan0: sta_newstate: SCAN -> SCAN (1)
wlan0: [30:23:03:xx:xx:xx] station deauth via MLME (reason: 3 (sending STA is leaving/has left IBSS or ESS))
wlan0: ieee80211_new_state_locked: SCAN -> INIT (arg 3) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: SCAN -> INIT arg 3
wlan0: sta_newstate: SCAN -> INIT (3)
wlan0: node_reclaim: remove 0xfffffe01115bf000<30:23:03:xx:xx:xx> from station table, refcnt 2
wlan0: ieee80211_alloc_node 0xfffffe011343b000<5c:87:9c:xx:xx:xx> in station table
wlan0: ieee80211_new_state_locked: INIT -> SCAN (arg 0) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: INIT -> SCAN arg 0
wlan0: sta_newstate: INIT -> SCAN (0)
wlan0: [30:23:03:xx:xx:xx] station assoc via MLME
wlan0: ieee80211_alloc_node 0xfffffe0113080000<30:23:03:xx:xx:xx> in station table
wlan0: node_reclaim: remove 0xfffffe011343b000<5c:87:9c:xx:xx:xx> from station table, refcnt 1
wlan0: ieee80211_sta_join1 0xfffffe0113080000<30:23:03:xx:xx:xx> SCAN -> AUTH, FC0_SUBTYPE_DEAUTH
wlan0: ieee80211_new_state_locked: SCAN -> AUTH (arg 192) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: SCAN -> AUTH arg 192
WARNING mvmvif->ap_sta_id != 0xFF failed at /usr/src/sys/contrib/dev/iwlwifi/mvm/sta.c:1761
wlan0: sta_newstate: SCAN -> AUTH (192)
wlan0: ieee80211_ref_node (ieee80211_send_mgmt:2708) 0xfffffe0113080000<30:23:03:xx:xx:xx> refcnt 4
wlan0: ni 0xfffffe0113080000 vap 0xfffffe01121a4010 mode STA state AUTH m 0xfffff800048a3700 status 0
wlan0: ni 0xfffffe0113080000 mode STA state AUTH arg 0x2 status 0
wlan0: [30:23:03:xx:xx:xx] recv auth frame with algorithm 0 seq 2
wlan0: ieee80211_new_state_locked: AUTH -> ASSOC (arg 0) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: AUTH -> ASSOC arg 0
wlan0: sta_newstate: AUTH -> ASSOC (0)
wlan0: ieee80211_ref_node (ieee80211_send_mgmt:2708) 0xfffffe0113080000<30:23:03:xx:xx:xx> refcnt 4
wlan0: ni 0xfffffe0113080000 vap 0xfffffe01121a4010 mode STA state ASSOC m 0xfffff80012f8b400 status 0
wlan0: ni 0xfffffe0113080000 mode STA state ASSOC arg 0x3 status 0
wlan0: [30:23:03:xx:xx:xx] assoc success at aid 1: short preamble, short slot time, QoS
wlan0: ieee80211_new_state_locked: ASSOC -> RUN (arg 16) (nrunning 0 nscanning 0)
wlan0: ieee80211_newstate_cb: ASSOC -> RUN arg 16
wlan0: sta_newstate: ASSOC -> RUN (16)
wlan0: [30:23:03:xx:xx:xx] bss node join
wlan0: link state changed to UP

Search for Invalid TXQ id leads to https://wiki.freebsd.org/WiFi/Iwlwifi -> it seems that the issue was fixed, but somehow it does not work. BTW I have 13.2-RC2
Invalid TXQ id observed a few times.. some extra debug printf for this case currently assumed fix
Click to expand...
 
Update:
I tried to debug iwm driver. As far as I cannot see something incorrect, but it seems that my card is able to receive packets but it has some troubles with sending.
Some update from tcpdump: freebsd:
Code: 
22:21:20.621802 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 5c:87:9c:xx:xx:xx, length 300
And router, this is interesting!

Code: 
22:21:24.715638 5c:87:9c:xx:xx:xx Null > ff:ff:ff:ff:ff:ff 802.1B I Information, send seq 0, rcv seq 16, Flags [Command], length 352
                                 ip start?
    0x0000:  0200 0020 0000 0000 aaaa 0300 0000 0800  ................
                                 ttl,protocolUDP
                                      crc  src ip
    0x0010:  4510 0148 0000 0000 8011 3996 0000 0000  E..H......9.....

             dst ip    68   67   len  crc
    0x0020:  ffff ffff 0044 0043 0134 5658 0101 0600  .....D.C.4VX....
    0x0030:  f24d 1598 0007 0000 0000 0000 0000 0000  .M..............
                                 mac address (in the middle of DHCP)
    0x0040:  0000 0000 0000 0000 5c87 9cxx xxxx 0000  ........\.......
    0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0060:  0000 0000 0000 0000 0000 0000 0000 0000  ................
...

I'm not able to read this packet, but it seems to contain valid DHCP request wrapped around valid UDP protocol packet. I'm not 100 sure with IP packet.

I will continue with my investigation.
 
I also have a similar problem with 13.1 and iwlwifi with some hotspots.

I have never debugged the problem, just wanted to add a datapoint that iwlwifi (at least in 13.1) indeed seems to have some glitches still.
 
I have contacted with the developer. I have sent an example packet transmited by freebsd and received by router - there's obviously a difference but I'm not able to say more at this moment.
Still, it is wired that I have an issue with rather mature driver (iwm).
 
iwlwifi was in no useable condition in 13.1. It appears to work fine now in 13.2 in my Fujitsu.
I'm not using DHCP.
 
I wouldn't be that harsh, PMc. I use iwlwifi daily on my Dell XPS13 and most APs or also iPhone hotspots work fine for me.

That is not to say that there is not indeed room for improvement regarding WIFI or FreeBSD on notebooks in general.
 
I'm just saying, don't bother to get iwlwifi somehow working in a 13.1, go straight for 13.2 (as of now), and things will look a lot better.
I tried to run it in 13.1, and it crashed. And the developer stated that it cannot do ifconfig down/ifconfig up, it crashes. So I had to do kldunload/kldload instead - which also crashed until I patched the kernel to ignore the already free objects entering lkpi to be freed.
And no, that's not a useable condition.

Now in 13.2 it looks like it has been fixed, and also Colin did something about the lkpi issue. Anyway, my piece does now nicely suspend/resume, and so I switched back from STABLE to releng, and think the matter is solved now.
 
raph said:
Hi all,

I have Dell Latitude E7390. I bought it especially for FreeBSD, I checked the compatibility on https://wiki.freebsd.org/Laptops, so I didn't expected any issues with hardware.
However the WiFI does not work, i.e. The connection is associated, but the dhclient cannot obtain a configuration.
Code: 
$ ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 5c:87:9c:xx:xx:xx
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
    groups: wlan
    ssid xxx-bgn channel 11 (2462 MHz 11g) bssid 30:23:03:xx:xx:xx
    regdomain ETSI country PL authmode WPA2/802.11i privacy ON
    deftxkey UNDEF AES-CCM 3:128-bit txpower 30 bmiss 7 scanvalid 60
    protmode CTS wme roaming MANUAL
    parent interface: iwlwifi0
    media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g
    status: associated
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Code: 
# dhclient wlan0
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

The device is Intel Dual Band Wireless AC 8265:
Code: 
$ pciconf -l | grep wifi
iwlwifi0@pci0:2:0:0:    class=0x028000 rev=0x78 hdr=0x00 vendor=0x8086 device=0x24fd subvendor=0x8086 subdevice=0x0050

My current system is FreeBSD 13.2-RC1, but I had the same on 13.1.
I tested both iwm and iwlwifi drivers, there's no difference in behaviour - I can scan available wifi networks and connect to the one of them, but dhclient does not work.
I'm able to use tcpdump, it shows dhcp requests and broadcast packets from other devices, but no dhcp offers.
I checked also router (openwrt) using tcpdump. On the router's side tcpdump does not show dhcp requests.

I checked the hardware using Ubuntu Live CD, it seems that wifi works perfectly fine.
I have no idea what else can be wrong, after three days I'm here for some help.
Click to expand...
Are you sure your configuration is correct? My wireless device is working correctly on my Dell Latitude 7390 laptop. You have not forgotten to provide your wifi network credentials via /etc/wpa_supplicant.conf?
network={
ssid="MY NETWORK SSID"
psk="MY NETWORK PASSWORD"
}

File /etc/rc.conf something like this using "link aggregation" networking

wlans_iwm0="wlan0"
ifconfig_wlan0="WPA"
ifconfig_em0="ether wi:vi:ma:ca:dd:rress"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"
create_args_wlan0="country ES regdomain ETSI"
wpa_supplicant_program="/usr/sbin/wpa_supplicant"
defaultroute_delay="0"
background_dhclient="YES"

I hope its helps you
 
raph, thanks for this note. Yesterday, when I tried to power on my laptop after six days, and after it had an orderly shutdown while still being connected to mains (i.e. battery should be fully charged), I found the battery entirely sucked dry and at 0%.
I still have to investigate if this was an operational mistake, a hardware problem or whatever, but the notion that these things may not correctly turn off everyting is interesting (I was already thinking along that line).
 
So, I have tested 14-CURRENT 13.1-RELEASE 13.2-RC1 13.2-RC2 13.2-RC3 and 12.4-RELEASE
Intel wifi is not working on iwm, on 13.1 the iwlwifi reports errors with microcode.
I have installed windows to disable fast boot and properly shutdown my computer.
I have restored BIOS defaults many times, I have tested many BIOS configurations.

The issue is always the same, the card is able to connect to access point but no communication is possible.
I have tried to debug this issue using tcpdump and airomon - the conclusion is that the frames sent by wifi card are invalid.
I have no idea how I can proceed.
I'm professional programmer, so my assumption is that the maybe communication between kernel and driver does not work properly.
The same iwlwifi driver works without any issues under linux kernel (ubuntu live cd) so why there's a problem on FreeBSD?

I haven't got any response from developer.

The same was reported here https://forums.freebsd.org/threads/wifi-stopped-working-13-1.85429/
 
susicarlos4
Thanks for this. I think that my configuration is fine. However if you have no issues we can use this info to limit impacted devices. Could you show the output of pciconf -l | grep iwm?
 
Ok, I have a workaround, the static configuration (without DHCP) seems to work on iwm driver.
So, maybe the issue is about multicast, I don't know.
 
What does file /etc/rc.conf contain for the line ifconfig_wlan0="WPA DHCP" Are you connecting to an encrypted WPA-PSK Wifi Access Point? or to an non-encrypted OPEN network WiFi Access Point? Use ifconfig_wlan="DHCP" or "SYNCDHCP" for an open network.
Explanation for issuing manual commands to connect to a WiFI Access Point network:
https://forums.ghostbsd.org/viewtopic.php?f=64&t=526 RTWN Edimax EW-7811un version1RTL8192cu, maybe version 2 is now supported
https://forums.ghostbsd.org/viewtopic.php?f=64&t=570 PCI RTL8188ce version of PCI Half Height card

Use these commands to follow your own method and debug your setup. I use NetworkMgr to make the Wifi Network connection for me.
pkg install networkmgr

susicarlos4 said:
File /etc/rc.conf something like this using "link aggregation" networking

wlans_iwm0="wlan0"
ifconfig_wlan0="WPA"
Click to expand...
ifconfig_wlan0="WPA DHCP" for a encrypted WPA-PSK network
ifconfig_wlan0="DHCP" for a non-encrypted OPEN network

pciconf -lv
usbconfig list
usbconfig -d ugenX.Y dump_device_desc #Where X and Y are numbers that refer to your usb wireless dongle


To list what Vendor and Product IC codes you have for your wlan wifi devices.
https://srobb.net/fbsdquickwireless.html SRobb freebsd quick wireless setup

For Open non-encrypted network minimal entry
Code: 
network={
   ssid="innflux"
   key_mgmt=NONE
}
For a WPA-PSK encrypted network, bare minimum setup of 3 lines and 1 comment
Code: 
network={
    #: my NetGear box
    ssid="NETGEAR59"
    psk="my_passkey_892"
    key_mgmt=WPA-PSK
}
a more complete network configuration with many items setup.
Code: 
network={
    #: my NetGear box
    ssid="NETGEAR59"
    priority=3
    bssid=c4:04:15:7d:53:80
    key_mgmt=WPA-PSK
    proto=RSN
    psk="my_passkey_892"
}

WPA-passphrase to add a network entry to the end of the /etc/wpa_supplicant.conf file use the command below.
https://www.unix.com/man-page/freebsd/8/wpa_passphrase wpa-passphrase mywpassid my_psk_password >> /etc/wpa_supplicant.conf
https://forums.freebsd.org/threads/wpa_supplicant.39527/#:~:text=Code: psk: WPA preshared key; 256-bit pre-shared key,be between # 8 and 63 characters (inclusive).

https://github.com/ghostbsd/networkmgr/issues/85 I added your connection issue to the GhostBSD NetworkMgr Github issues, as an explanation of how much lost time happens from leaving the "WPA" in that one line in the /etc/rc.conf file.
 
I have a regression on FreeBSD 13.2-RELEASE, my iwlwifi device (Ice Lake, see below) no longer connects to an AP while it (with most APs) did so on 13.1

ppt0@pci0:0:20:3: class=0x028000 rev=0x30 hdr=0x00 vendor=0x8086 device=0x34f0 subvendor=0x1a56 subdevice=0x1651
vendor = 'Intel Corporation'
device = 'Ice Lake-LP PCH CNVi WiFi'
class = network
Click to expand...

This is not nice, but I am writing this mainly to remind people coming across a similar problem of net/wifibox: It took me about 20-30min to get my WIFI up and running with it.
 
You must log in or register to reply here.
Back
Top