@dlang

It's not LuCI fault. It's the way LEDE implemented the checks on the firmware.

nitroshift

Yes, i wonder too, maybe it would be good to share that knowledge, or better teach as fishing, write some steps for building that knowledge:-)

dlang,

Luci calls the sysupgrade binary, but without -f. The "bug" is in the sysupgrade code, though could be addressed in Luci asking like OEM firmware if you still want to force an update and then adding -f to the command line. Bugs like this happen but if reported it should be a high priority item. Being able to flash back to OEM is probably the most important feature of third party firmwares. It was reported 5-6 months ago. What is holding up progress?

tapper

There is this sysupgrade bug which mishandles *factory.img. Should have sent you the *sysupgrade.tar, though that one can't be flashed from OEM. Besides CC obviously LEDE wasn't fixed either. It's a pure coincidence that it's working in CC / LEDE. One of the more ugly kernel hacks (which I obviously dropped) allows to recover from a broken upgrade and so this got hidden away. LEDE was told off on this EOF marker hack by upstream, along the lines of "If you change the on-disk format keep all bugs for yourself, we won't care".

To sum up, *factory.img can be flashed from swrt,  OEM or via tftp / usb, otherwise use the *sysupgrade.tar. Glad you could install Villeneuves builds, they probably also come with all common packages already installed.

Sorry

root@openwrt:~# cat /var/run/hostapd-phy0.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=DE
ieee80211d=1
ieee80211h=1
hw_mode=a
channel=36

ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][SU-BEAMFORMER][SU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC1][MAX-A-MPDU-LEN-EXP7]

interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
ap_max_inactivity=60
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
auth_algs=1
wpa=0
ssid=openwrt
bridge=br-lan
bssid=*:*:*:*:*

I have the feeling that it doesn't disconnect at all if stations just drop out (i saw Idle times of 20+ hours...)

lifehacksback, gsustek

The secret might just be time, if you do something for two decades as a hobby you are prone to get better at it. As for OpenWrt specifically, the buildroot was neglected quite a bit. Besides pointless stuff / ugly hacks there is a huge lack of documentation making for a high entry barrier. As I already was familiar with far more elaborate package management setups and related topics it certainly was a lot easier to figure what the single bits are supposed to do or what to look out for when needing a specific feature.

Another aspect is being familiar with unix tools, being able to read Makefiles like prose. Knowing plenty of programming languages, having read millions of lines of code by others and other things along this line probably play their role as well.

The above holds true for everyone. More personal, having the world view of a physicist and a better than average memory paired with an unwillingness to throw in the towel fast are aspects that I would list as helping get started as well.

For learning to code, write an app with 100'000+ lines of code, only then architecturing starts to play an important role, working out those issues will be an invaluable foundation for any such activity. Also don't stick to OpenWrt solely, there are plenty other distributions / OSes worth looking into as well, most _documented_ well. Get familiar with one of those first, it might be a lot easier.

hnk

so "option max_inactivity '90'" got properly translated to ap_max_inactivity=60 assuming you actually changed the configuration in-between from 90 to 60. skip_inactivity_poll is missing all together. So what you see is expected based on the hostapd.conf. Will look into the code later today to see where this option gets dropped.

@sera I don't get this! "Guess for you it's working DSA support"  @Chadster is it true for you?

@sera Does swrt support swconfig? i can't find time to overhaul my config from WRT1900acs and replace swconfig with DSA(which i will for sure), i want to apply exactly the same config on boot routers.

Yes, for me DSA support is important.

Interesting it sounded like @Sera was saying that DSA support isn't functional in 4.11 yet.

You are right- i changed the value inbetween...

Great! Thank you for your quick support!

Hi don't worry about it, thanks for the help. I flashed back to a k4.9 build anyway as Villeneuves build had a few problems, like some settings would not stick and addblock would not download  any of the block lists. I will wate for the next build and giv that a try.

hnk,

the option skip_inactivity_poll was never supported to begin with. Patch [1] adds support. You can do the same modification on a live system by editing /lib/netifd/hostapd.sh.

[1] https://gist.github.com/anonymous/b93dc … 5b4772ec7c

gsustek,

swrt support swconfig for all devices. As it's not the default you will have to select it under image options in menuconfig respectively run "echo CONFIG_MVEBU_SWITCH_DRIVER_SWCONFIG=y >> .config "

McDebian is using DSA since long, so before 4.9 performance was not great and abysmal on Mamba. 4.9 wasn't fine but got since fixed in stable releases.

As I obviously was unclear. DSA performs great with kernel 4.10+ and later 4.9 kernels. 4.11 seems to put on the finishing touch on DSA support.

PS: just sent the pwm-fan driver after some more modifications for upstream review.

@sera thanks for clarifying that.

(Last edited by Chadster766 on 24 Mar 2017, 16:21)

Is that a bug or some purpose to that "feature" ?

The idea was that it would prevent you from flashing something that wasn't a firmware image (say your finger slipped as you were selecting the file and tried to flash with a photo file instead, or gave it an invalid url and ended up flashing a 404 error page instead)

good intentions, but they only tested it with LEDE/OpenWRT image files and the vendor files don't match what they check (they never tested reverting to factory firmware, call it a blind spot in their thinking :-)

I understand how it got in, I just wish they would revert it. Unfortunately they did not do so before the 17.01 release

@JW0914
Here is [/etc/config/wireless]

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
    option htmode 'HT40'
    option txpower '20'
    option country 'JP'
    option channel '11'

config wifi-iface
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid '****'
    option encryption 'psk-mixed'
    option key '******'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid '*****'
    option network 'guest'
    option encryption 'psk-mixed'
    option key '******'

Any idea?
Thanks!!

dolemhao,

you haven't configured the 5GHz band at all.

mv /etc/config/wireless /etc/config/wireless.old
wifi detect > /etc/config/wireless

Then take it from there?

Sera, wow thank you for your quick fix!

Unfortunately my /lib/netifd/hostapd.sh looks different than your's:

inside the same function:

        set_default disassoc_low_ack 1                                                                                 
        set_default hidden 0                                                                                           
        set_default wmm 1                                                                                                
        set_default uapsd 1                                                                                              
                                                                                                                             
        append bss_conf "ctrl_interface=/var/run/hostapd"                                                                    
        if [ "$isolate" -gt 0 ]; then                                                                                        
                append bss_conf "ap_isolate=$isolate" "$N"                                                                   
        fi   

my try to "convert" it, didnt yield the desired hostapd conf

hnk,

some processing happens till it ends up in /lib/netifd/hostapd.sh. So the first line of the patch needs adding to json_get_vars and  a call to  set_default for the variable skip_inactivity_poll. The rest remains the same (just replace variable $var with it's value "bss_conf").

I patched it, had to change the default value, but never the less: it works now (adds it to the hostapd.conf) and seems  to disconnect idle clients now.

Sera, thank you so much for your quick and knowledgeable help!

hnk,

thanks for reporting back.

Upstream (hostapd) default is 0, so you should have to override it with "option skip_inactivity_poll 1" in your /etc/config/wireless for it to make it into hostapd.conf. If disabled the option won't be printed to hostapd.conf at all. Changing the default would break this "promise". Maybe I just misunderstood you.

@sera

Running swrt on Rango with luci + htop + iperf + iperf3

Linksys WRT3200ACM
Firmware Version
OpenWrt Designated Driver 50104+swrt-2017-03-22 / LuCI Master (git-17.080.69173-773734e)
Kernel Version
4.11.0-rc3-next-20170322

While radio1 is fine...  No matter what I try, radio0 will not come up.  All I see is the now familiar to all:

Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): command failed: Not supported (-95)
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): Configuration file: /var/run/hostapd-phy0.conf
Sun Mar 26 16:53:30 2017 kern.debug kernel: [47125.262258] ieee80211 phy0: change: 0xffffffff
Sun Mar 26 16:53:30 2017 kern.info kernel: [47125.397296] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): nl80211: Could not configure driver mode
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): nl80211 driver initialization failed.
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): wlan0: interface state UNINITIALIZED->DISABLED
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): wlan0: AP-DISABLED 
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): hostapd_free_hapd_data: Interface wlan0 wasn't started
Sun Mar 26 16:53:30 2017 daemon.notice netifd: radio0 (18639): Device setup failed: HOSTAPD_START_FAILED

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
        option channel '36'
        option htmode 'VHT20'
        option txpower '20'
        option country 'CA'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'WRT3200ACM5GHz'
        option encryption 'none'

Thoughts?  Would like to get past this and move on to running this on the Mamba

Cheers

EDIT:

It seems that I have bigger problems.  Stuck with a read only file system after flashing from stock to next, making some config changes, and rebooting.  Something is wrong with /overlay...  not mounting or corruption....

(Last edited by doITright on 27 Mar 2017, 00:48)

+1 no settings would save for me.

doITright, tapper

looks like a new regression with ubifs in linux-next. Only the squashfs with overlay based images are affected. Will look into it, till then you can use the non squashfs based images or an older kernel.

Thanks for the report.