What's new

ChannelHog - Monitor And Force Maximum 5GHz Bandwidth

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

From post 1 of this thread.

ChannelHog will monitor your current 5GHz channel bandwidth on a daily basis and if it detects anything lower then 160MHz it will restart the 5Ghz radio. This script also includes optional Discord notification support.

Note: Your clients will temporarily be disconnected from the 5GHz band in the event of a restart, this usally takes 1-2 minutes and occurs at 4.45am.
 
Looks a stripped-down channelhog on a faster cronjob?
No, it's just a script I wrote for myself over a year ago. I created it independently without reference to ChannelHog.

I think a pull request could have been the more collaborative approach if you found any bugs.
I've never used ChannelHog as it doesn't (AFAIK) address the problem I was trying to solve.
 
I've pushed v1.1.2 which should solve the issue for the XT8. For any other affected models please post the output of;

[ -z "$(nvram get odmpid)" ] && model="$(nvram get productid)" || model="$(nvram get odmpid)"; echo $model
 
Why, is it the complexity introduced by Asus, or Broadcom?
Might be a hardware design issue that was worked around through software (PCI express devices not connected to the expected lanes or enumerating in the wrong order), I don't know.
 
Quick question: Does ChannelHog survive a router reboot, or do I need to add a cron job (as in "sh /jffs/addons/channelhog/channelhog.sh start") to run shortly after boot?
 
Might be a hardware design issue that was worked around through software (PCI express devices not connected to the expected lanes or enumerating in the wrong order), I don't know.
Your guess is sound, they probably wouldn't be worth re-changing the hardware for such a small mistake, which reminds me of the RT-N66U and the little-known MicroSD slot inside.
 
Curious if there is something I'm missing. I have an AX88, with two hardwired AX86 Aimesh nodes - poking around nvram I find the AX88 is set to 160Mhz (Thanks Channelhog for keeping it there) and 36/100. But looking at the hardwired AX86 Aimesh nodes, they are set to 80Mhz and no specific channel, running Channelhog on those confirms 80Mhz.

Is there a way to all three working at 160Mhz and 36/100 (or similar) to get 160Mhz support through the house?
 
Last edited:
Quick question: Does ChannelHog survive a router reboot, or do I need to add a cron job (as in "sh /jffs/addons/channelhog/channelhog.sh start") to run shortly after boot?
it adds its own crontab entry during install
 
Hi @Adamm I am a big fan of Channelhog and have a query regarding AiMesh nodes. Once Channelhog runs it seems to be potluck as to whether my node (AX58) notices this and follows channels. Is there a way to adapt the script - or add a separate cron job - so that 11 minutes after Channelhog runs (to allow for DFS checks) a reboot instruction is sent to any wireless nodes and if so what is the command to reboot a node (from the router)? Thanks, Archiel.
 
Hi @Adamm I am a big fan of Channelhog and have a query regarding AiMesh nodes. Once Channelhog runs it seems to be potluck as to whether my node (AX58) notices this and follows channels. Is there a way to adapt the script - or add a separate cron job - so that 11 minutes after Channelhog runs (to allow for DFS checks) a reboot instruction is sent to any wireless nodes and if so what is the command to reboot a node (from the router)? Thanks, Archiel.
My AX88 (Merlin 386.8) runs at at 160Mhz and looking at NVRAM I see where its set to use 160Mhz bandwidth using 36/100, but on my AX86's mesh nodes (Merlin 386.7), they stay at 80Mhz. Was thinking I would have to abandon AIMesh and turn them into AP's to get the control to have them run at 160Mhz. But if you get 160Mhz on your AX58 maybe I need to consider running stock firmware on those instead and see if that works to get 160Mhz on them... ¯\_( ͡° ͜ʖ ͡°)_/¯
 
a reboot instruction is sent to any wireless nodes and if so what is the command to reboot a node (from the router)?

That’s a good question… if you figure it out I’ll automate it.
 
That’s a good question… if you figure it out I’ll automate it.
It would be great if you could give me some guidance -

After ChannelHog runs all may be well or the Node (an RT-AX58U) will either show as not connected or weak, where weak=2.4GHz link only

if it is not connected then running service restart_wifi on the Router will change the status to weak. After rebooting the node, AiMesh then shows Great (=5 GHz link)

From the GUI if I go to AiMesh, select the Node and select Management, I can then select Reboot Node. This produces a pop-up asking if I want to proceed or cancel.
1662036931053.png

What I do not understand is how to find the command issued by OK.
 
I've pushed v1.1.2 which should solve the issue for the XT8. For any other affected models please post the output of;

Thanks for the update.

It seems that the addon can detect my XT8 channels correctly but it still restarts my 5GHz-1 radio. Checking channel bandwidth after I made sure the 5Ghz-2 was already on 160MHz channel:-

Code:
ChannelHog: [*] 80MHz 160MHz Channel Width Detected - Restarting 5GHz-1  Radio
 
2 questions:
1) do you think this will work on the rt-ax3000
and
2) if so whats the easiest way to ensure it starts automatically on power cycle? im not that familiar with linux in general, let alone embedded linux.
 
2 questions:
1) do you think this will work on the rt-ax3000
and
2) if so whats the easiest way to ensure it starts automatically on power cycle? im not that familiar with linux in general, let alone embedded linux.
I can at least answer question 2. Once installed and started it will start automatically each boot. You just set it and forget it.
 
I combined @Adamm and @ColinTaylor code so that after WIFI is brought down/up it will compare the current channel to the targeted channel and reboot WIFI (should then force targeted channel) if needed. I parse the log file and compare when last 'Radar detected' event occurred so that no unnecessary reboot of WIFI occurs if < 30 minutes.

Bash:
if [ "$restart5ghz1" = "true" ]; then
    wl -i "$port5ghz1" down
    wl -i "$port5ghz1" up
fi
if [ "$restart5ghz2" = "true" ]; then
    wl -i "$port5ghz2" down
    wl -i "$port5ghz2" up
fi

#After down/up event
#Get targeted and current WIFI channel
#Currently only checks $port5ghz1.

targetChanSpec="$(nvram get wl1_chanspec)"
targetChan=${targetChanSpec%/*}
currentChanSpec="$(wl -i $port5ghz1 chanspec | awk '{print $1}')"
currentChan=${currentChanSpec%/*}

#Compare if current channel differs from target channel
if [ "$targetChan" != "0" ] && [ "$currentChan" != "$targetChan" ]; then
    
    #Check log for 'Radar detected'
    lastRadarFoundLine="$(grep "Radar detected" /tmp/syslog.log | tail -1)"
    
    if [ ! -z "$lastRadarFoundLine" ]; then
        #Parse date from last radar detected log line
        lastRadarFoundY="$(date +"%Y")"
        lastRadarFoundPY=$((lastRadarFoundY-1))
        lastRadarFoundM="$(echo $lastRadarFoundLine | awk '{print $1}')"               
        case $lastRadarFoundM in
            Jan) MON="01" ;;
            Feb) MON="02" ;;
            Mar) MON="03" ;;
            Apr) MON="04" ;;
            May) MON="05" ;;
            Jun) MON="06" ;;
            Jul) MON="07" ;;
            Aug) MON="08" ;;
            Sep) MON="09" ;;
            Oct) MON="10" ;;
            Nov) MON="11" ;;
            Dec) MON="12" ;;
        esac   
        lastRadarFoundM=$MON
        lastRadarFoundD="$(echo $lastRadarFoundLine | awk '{print $2}')"
        lastRadarFoundT="$(echo $lastRadarFoundLine | awk '{print $3}')"
        
        #No year is listed in log so apply current year as a work-around. If combined radar found date is greater than current date then change year to previous year.
        lastRadarFoundCombined="$(date +%s -d "$(echo $lastRadarFoundY"."$lastRadarFoundM"."$lastRadarFoundD"-"$lastRadarFoundT)")"
        lastRadarFoundCombinedPY="$(date +%s -d "$(echo $lastRadarFoundPY"."$lastRadarFoundM"."$lastRadarFoundD"-"$lastRadarFoundT)")"
        currentTime=$(date +%s)           
        if [ "$lastRadarFoundCombined" -gt "$currentTime" ]; then
            lastRadarFoundCombined=$lastRadarFoundCombinedPY
        fi
        
        #Restart wireless if greater than 30 minutes from last radar detection
        currentTime30M=$(date +%s -d@"$(( `date +%s`-30*60))")
        if [ "$lastRadarFoundCombined" -ge "$currentTime30M" ]; then
            logger -st ChannelHog "[*] Channel (${currentChan}) can't switch back yet as still in Non-Occupancy Period."
        else
            logger -st ChannelHog "[*] Channel has changed from ${targetChan} to ${currentChan}. Restarting WiFi."
            service restart_wireless
        fi
    fi                   
fi
 
Welcome to the forums @jb1187.

Thanks for sharing your merged scripts with us.
 
Keep in mind that the log may not always show "Radar detected". Nine out of 10 times I see wl_chanspec_changed_action as the only entry prior to a channel change.

So users that use the script above may want to consider that grep term.

Before coming across @ColinTaylor 's script, I was testing out an email notification of channel change using several hacks including pruning the log after grepping the chanspec entry. But his is so much more elegant.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top