Modify

Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#10350 closed defect (fixed)

5GHZ Radio - WNDR3700 (v1) not coming up Trunk r28753

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

Updated to trunk r28753 and now the 5GHZ radio won't come online. It is configured to enabled but simply won't start.

Using the same settings in menuconfig that I've used for a year and used sysupgrade while keeping existing configuration files.

I was working fine with Trunk 28715 so it seems to be something that was changed after that.

Attachments (0)

Change History (9)

comment:1 Changed 6 years ago by hnyman <hannu.nyman@…>

Now that you mentioned it, I noticed the same with my 3700v2. 5GHz radio is off. By coincidence, also my last build was 28715, and there it worked.

The regression might be related to r28746 (updating hostapd to a new version) or to r28733 (change of timing of "wifi detect").

comment:2 Changed 6 years ago by hnyman

Manually running '/sbin/wifi up' reveals more:

root@OpenWrt:~# /sbin/wifi up
wlan1: IEEE 802.11 Configured channel (36) not found from the channel list of current mode (2) IEEE 802.11a
wlan1: IEEE 802.11 Hardware does not support configured channel
rmdir[ctrl_interface]: No such file or directory
Failed to start hostapd for phy1
root@OpenWrt:~#

Probably the error is related to that hostapd change.

I tried to change channel, but not help. Clearing wifi config and running 'wifi detect' gives pretty much the correct output, so no fault there.

comment:3 follow-up: Changed 6 years ago by anonymous

I use dir825, same thing with r28746. Doing iw list, shows all 5GHz channels as "(disabled)", whereas before the hostapd change, only the DFS channels were disabled.

comment:4 in reply to: ↑ 3 Changed 6 years ago by anonymous

Replying to anonymous:

I use dir825, same thing with r28746. Doing iw list, shows all 5GHz channels as "(disabled)", whereas before the hostapd change, only the DFS channels were disabled.

Reverted back to r28732 and my 5GHZ is up and running again.

comment:5 follow-up: Changed 6 years ago by Mark Mentovai <mark@…>

I explained this on #openwrt. The bug was caused by nbd’s r28733.

r28733 caused kernel modules to be loaded before hotplug2 is started. This means that the wireless module will load and likely issue a CRDA request for regulatory information via a uevent. Because hotplug2 is not running, the uevent is never dispatched to crda. hotplug2 is started afterwards, but by that time, the uevent is “lost.” Subsequent regulatory requests from within the kernel don’t work because the in-kernel regulatory code only issues one outstanding CRDA request at a time, in an effort to avoid races. The driver waits for a response that will never arrive, and all subsequent regulatory requests queue up in the kernel.

With the current regulatory architecture, hotplug2 needs to be running before any wireless modules load.

A simple back-out of r28733 is sufficient as a workaround to get things back on their feet. Moving hotplug2’s startup to occur before load_modules in /etc/init.d/boot may also do the trick.

comment:6 Changed 6 years ago by Mark Mentovai <mark@…>

I guess running

COUNTRY=00 /sbin/crda

might “unstick” things too, although that’s pretty hokey.

The “country” that the wireless driver is waiting to hear back from CRDA about, if any, will be in /sys/devices/platform/regulatory.0/uevent as a COUNTRY= line. In this case, I expect 00 because with this bug, cfg80211 is likely to be waiting for the response to “cfg80211: Calling CRDA to update world regulatory domain”.

comment:7 in reply to: ↑ 5 Changed 6 years ago by anonymous

Replying to Mark Mentovai <mark@…>:

A simple back-out of r28733 is sufficient as a workaround to get things back on their feet. Moving hotplug2’s startup to occur before load_modules in /etc/init.d/boot may also do the trick.

I test both approaches.

Reverting r28733 totally worked, naturally.

But so did also your other suggestion of moving hotplug startup ahead, before the modules.d and wireless. I have not tested it for any side effects, but the approach seemed to work and both radios came up just fine.

root@OpenWrt:~# diff /rom/etc/init.d/boot /etc/init.d/boot
--- /rom/etc/init.d/boot
+++ /etc/init.d/boot
@@ -65,6 +65,12 @@
        grep -q debugfs /proc/filesystems && mount -t debugfs debugfs /sys/kernel/debug
        [ "$FAILSAFE" = "true" ] && touch /tmp/.failsafe

+       killall -q hotplug2
+       [ -x /sbin/hotplug2 ] && /sbin/hotplug2 --override --persistent \
+                       --set-worker /lib/hotplug2/worker_fork.so \
+                       --set-rules-file /etc/hotplug2.rules \
+                       --max-children 1 >/dev/null 2>&1 &
+
        load_modules /etc/modules.d/*

        /sbin/wifi detect > /tmp/wireless.tmp
@@ -76,12 +82,6 @@
        apply_uci_config
        config_load system
        config_foreach system_config system
-
-       killall -q hotplug2
-       [ -x /sbin/hotplug2 ] && /sbin/hotplug2 --override --persistent \
-                       --set-worker /lib/hotplug2/worker_fork.so \
-                       --set-rules-file /etc/hotplug2.rules \
-                       --max-children 1 >/dev/null 2>&1 &

        # the coldplugging of network interfaces needs to happen later, so we do it manually here
        for iface in $(awk -F: '/:/ {print $1}' /proc/net/dev); do

comment:8 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r28768

comment:9 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.