Sure. Poweroff does what halt does but it also turns the unit completely off and cuts the power. Except the OEM did not design a way to turn it off. The system sees power and boots again.
1 Like
has a anyone got theirs vertical?
mounting holes on the back for a wall mount but don't want to drill, maybe a book or tablet stand will do.
anyone found something else?
I got mine vertical but without a mount, i just used screws in the wooden cabinet.
i dont know if something like nano double tape can hold it?
you can also look into some type of industerial din rail mount construction but you need to check what type mounts work the best, i did this with my Mochabin and that worked very flawless 
1 Like
Thanks for the reply @xize. had a good look around and found an old dlink router stand, covers up the status LED but at least its raised so the airvents aren't hampered.
base could do with being a bit bigger for stability but it will do.
wonder if anyone has tested horizontal vs vertical device temperatures.
2 Likes
Are you still having this wifi crash issue? If so, any chance you're configured to use channel 36?
2 posts were split to a new topic: Can't find bridger package in menuconfig
Hello,
Somebody tested of It Is Faster packet steering or offloading on a 2,5gbit pppoe fiber?
I'm pretty sure that offloading is going to be the faster but offloading will break SQM for example. It's not that u will be able to shape 2.5G speeds (@ pppoe) anyway with that CPU without (hardware) offloading but SQM is essential for many people using OpenWrt.
Hardware Offloading in OEM builds will also mess up SQM/QoS and other features (e.g. Parental Control), so packet steering might be a valid option for users with high internet speeds and SQM setups.
What do you think about the logs below on the wifi side, are they normal?
Hostname OpenWrt
Model GL.iNet GL-MT6000
Architecture ARMv8 Processor rev 4
Target Platform mediatek/filogic
Firmware Version OpenWrt SNAPSHOT r25829-e6f7e9dca9 / LuCI Master git-24.089.54606~0ecb5ed
Kernel Version 6.1.82
Sat Apr 6 20:48:37 2024 user.notice firewall: Reloading firewall due to ifup of wan_6 (pppoe-wan)
Sat Apr 6 20:48:37 2024 user.notice nlbwmon: Reloading nlbwmon due to ifup of wan_6 (pppoe-wan)
Sat Apr 6 20:48:56 2024 daemon.err collectd[3508]: Sleeping only 2s because the next interval is 1.965 seconds in the past!
Sat Apr 6 20:49:02 2024 daemon.err uhttpd[3149]: [info] luci: accepted login on / for root from 192.168.8.153
Sat Apr 6 20:49:06 2024 cron.err crond[6401]: crond (busybox 1.36.1) started, log level 5
Sat Apr 6 20:49:06 2024 daemon.notice netifd: radio1 (6454): WARNING: Variable 'data' does not exist or is not an array/object
Sat Apr 6 20:49:06 2024 daemon.notice netifd: radio0 (6453): WARNING: Variable 'data' does not exist or is not an array/object
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Set new config for phy phy1:
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Set new config for phy phy0:
Sat Apr 6 20:49:07 2024 daemon.notice wpa_supplicant[2163]: Set new config for phy phy1
Sat Apr 6 20:49:07 2024 daemon.notice wpa_supplicant[2163]: Set new config for phy phy0
Sat Apr 6 20:49:07 2024 daemon.notice wpa_supplicant[2163]: Set new config for phy phy0
Sat Apr 6 20:49:07 2024 daemon.notice wpa_supplicant[2163]: Set new config for phy phy1
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Set new config for phy phy0: /var/run/hostapd-phy0.conf
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Restart interface for phy phy0
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Set new config for phy phy1: /var/run/hostapd-phy1.conf
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Restart interface for phy phy1
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: Configuration file: data: driver=nl80211 logger_syslog=127 logger_syslog_level=2 logger_stdout=127 logger_stdout_level=2 country_code=RO ieee80211d=1 hw_mode=g supported_rates=60 90 120 180 240 360 480 540 basic_rates=60 120 240 beacon_int=100 chanlist=9 noscan=1 #num_global_macaddr=1 ieee80211n=1 ht_coex=0 ht_capab=[HT40-][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935] ieee80211ax=1 he_su_beamformer=1 he_su_beamformee=1 he_mu_beamformer=1 he_bss_color=128 he_spr_sr_control=3 he_default_pe_duration=4 he_rts_threshold=1023 he_mu_edca_qos_info_param_count=0 he_mu_edca_qos_info_q_ack=0 he_mu_edca_qos_info_queue_request=0 he_mu_edca_qos_info_txop_request=0 he_mu_edca_ac_be_aifsn=8 he_mu_edca_ac_be_aci=0 he_mu_edca_ac_be_ecwmin=9 he_mu_edca_ac_be_ecwmax=10 he_mu_edca_ac_be_timer=255 he_mu_edca_ac_bk_aifsn=15 he_mu_edca_ac_bk_aci=1 he_mu_edca_ac_bk_ecwmin=9 he_mu_edca_ac_bk_ecwmax=10 he_mu_edca_ac_bk_timer=255 he_mu_edca_ac_vi_ecwmin=5 he_mu_edca_ac_vi_ecwmax=7 he_m
Sat Apr 6 20:49:07 2024 daemon.notice netifd: Wireless device 'radio0' is now up
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 63.787396] br-lan: port 6(phy0-ap0) entered blocking state
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 63.792969] br-lan: port 6(phy0-ap0) entered disabled state
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 63.798746] device phy0-ap0 entered promiscuous mode
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 63.803783] br-lan: port 6(phy0-ap0) entered blocking state
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 63.809350] br-lan: port 6(phy0-ap0) entered forwarding state
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 63.815344] br-lan: port 6(phy0-ap0) entered disabled state
Sat Apr 6 20:49:07 2024 daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 64.053994] IPv6: ADDRCONF(NETDEV_CHANGE): phy0-ap0: link becomes ready
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 64.060777] br-lan: port 6(phy0-ap0) entered blocking state
Sat Apr 6 20:49:07 2024 kern.info kernel: [ 64.066346] br-lan: port 6(phy0-ap0) entered forwarding state
Sat Apr 6 20:49:07 2024 daemon.notice netifd: Network device 'phy0-ap0' link is up
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: phy0-ap0: interface state COUNTRY_UPDATE->ENABLED
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: phy0-ap0: AP-ENABLED
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: Configuration file: data: driver=nl80211 logger_syslog=127 logger_syslog_level=2 logger_stdout=127 logger_stdout_level=2 country_code=RO ieee80211d=1 ieee80211h=1 hw_mode=a beacon_int=100 chanlist=36 tx_queue_data2_burst=2.0 #num_global_macaddr=1 ieee80211n=1 ht_coex=0 ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935] ieee80211ac=1 vht_oper_chwidth=2 vht_oper_centr_freq_seg0_idx=50 vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][SOUNDING-DIMENSION-4][BF-ANTENNA-4][VHT160][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7] ieee80211ax=1 he_oper_chwidth=2 he_oper_centr_freq_seg0_idx=50 he_su_beamformer=1 he_su_beamformee=1 he_mu_beamformer=1 he_bss_color=128 he_spr_sr_control=3 he_default_pe_duration=4 he_rts_threshold=1023 he_mu_edca_qos_info_param_count=0 he_mu_edca_qos_info_q_ack=0 he_mu_edca_qos_info_queue_request=0 he_mu_edca_qos_info_t
Sat Apr 6 20:49:08 2024 kern.info kernel: [ 64.269262] br-lan: port 7(phy1-ap0) entered blocking state
Sat Apr 6 20:49:08 2024 kern.info kernel: [ 64.274832] br-lan: port 7(phy1-ap0) entered disabled state
Sat Apr 6 20:49:08 2024 kern.info kernel: [ 64.280595] device phy1-ap0 entered promiscuous mode
Sat Apr 6 20:49:08 2024 kern.info kernel: [ 64.285654] br-lan: port 7(phy1-ap0) entered blocking state
Sat Apr 6 20:49:08 2024 kern.info kernel: [ 64.291249] br-lan: port 7(phy1-ap0) entered forwarding state
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: phy1-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->HT_SCAN
Sat Apr 6 20:49:08 2024 daemon.notice netifd: Wireless device 'radio1' is now up
Sat Apr 6 20:49:08 2024 kern.info kernel: [ 64.816921] br-lan: port 7(phy1-ap0) entered disabled state
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: phy1-ap0: interface state HT_SCAN->DFS
Sat Apr 6 20:49:08 2024 daemon.notice hostapd: phy1-ap0: DFS-CAC-START freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Apr 6 20:50:10 2024 daemon.notice hostapd: phy1-ap0: DFS-CAC-COMPLETED success=1 freq=5180 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5250 cf2=0
Sat Apr 6 20:50:10 2024 daemon.warn hostapd: Can't set DFS state for freq 5180 MHz
Sat Apr 6 20:50:10 2024 daemon.warn hostapd: Can't set DFS state for freq 5200 MHz
Sat Apr 6 20:50:10 2024 daemon.warn hostapd: Can't set DFS state for freq 5220 MHz
Sat Apr 6 20:50:10 2024 daemon.warn hostapd: Can't set DFS state for freq 5240 MHz
Sat Apr 6 20:50:10 2024 kern.info kernel: [ 126.346996] IPv6: ADDRCONF(NETDEV_CHANGE): phy1-ap0: link becomes ready
Sat Apr 6 20:50:10 2024 kern.info kernel: [ 126.353727] br-lan: port 7(phy1-ap0) entered blocking state
Sat Apr 6 20:50:10 2024 kern.info kernel: [ 126.359286] br-lan: port 7(phy1-ap0) entered forwarding state
Sat Apr 6 20:50:10 2024 daemon.notice netifd: Network device 'phy1-ap0' link is up
Sat Apr 6 20:50:10 2024 daemon.notice hostapd: phy1-ap0: interface state DFS->ENABLED
Sat Apr 6 20:50:10 2024 daemon.notice hostapd: phy1-ap0: AP-ENABLED
Looks like you try 160 MHz channel with half non-DFS and DFS channels and get a (likely harmless) warning about trying set DFS state to a non-DFS channels 36, 40, 44, 48.
I would just stick to 80 MHz width.
4 Likes
If you need to use a 160 MHz width, manually set the channel number to 36, as this width implies that the client covers the whole 36-64 channel block.
But I had channel 36 set with 160Mhz, should I still receive the above logs, and what do I do if I have a device that is compatible with 160Mhz?
Is there any good reason why I should put the 2.4GHz AP on N mode or is AX the right pick for the GL-MT6000? I'm currently using Mode: AX, Channel: auto, Width: 20MHz but tbh the 2.4GHz Wifi with the GL-MT6000 isn't the greatest range and throughput wise, I was hoping for better 2.4GHz Wifi. Anyway the 5GHz Wifi is great and way better than the 5GHz Wifi with my old WRT3200ACM.
160 Mhz on WiFi 5Ghz not working.
You should select AX because most devices that support 802.11ax will be able to achieve over 150 Mbps.
If you select N mode then you'll struggle to get more than 110 Mbps when using 2.4 GHz.
If you want to use 160 MHz then you should select a DFS channel (100-144). And should it still fail to work then it's probably because you've got a weather radar in your area or you didn't set your radios country codes.
2 Likes
I kept mine vertical for a couple of weeks. I noticed that it had much worse wifi coverage than MT3000 in this setup (antennas pointing down). I had all ethernet ports connected, so my hypothesis is that all these ethernet cables might have interfered with wifi antennas. Cables were pretty much going down parallel to antennas. In the "classic" setup, ethernet cables are far from antennas. YMMV
I set the channel to automatic, is that why it doesn't work? because with the original GL.inet firmware setting it to automatic it works, it always uses the DFS channels but at least it chooses them on its own.
But was that with firmware 4.5.8? Since that firmware uses the proprietary MTK driver and it will behave differently.
If the issue isn't caused by the firmware version then I'd assume you didn't set the same country codes on both firmwares.
Yes, still putting up with the issue. WiFi goes dark on 5GHz every now and then.
It was originally using Ch. 52. I thought DFS might be the issue so now it is in 36. I know OpenWrt limits the power on that channel which is not a bad thing given the AP is unstable.
I've been fine tuning the script to restart the radio if no stations are responding so the issues are logged and maybe some pattern can be identified from it. I have too many false positives as of now because iPhones are tricky... they stop responding to pings if they lock up (which makes absolute sense but doesn't help my case).
I've seen better behaviour by running the AP in 11ac mode (htmode 'VHT80'). Thought of giving that a try as all the other APs are 11ac devices.
Running snapshot didn't help... running stable didn't either... running without dawn made no difference... There is something fundamentally messed up with the driver of this thing. Some kind of memory leak or something.
Are you having similar issues? Misery loves company.
Oddly enough, if I set one of my MT6000s to Ch 36, it will not survive overnight without hanging. If I set it to some other channel, be it 40 or 44, for example, no daily wifi hang. It's the strangest thing. I figured it was just me, so I never really brought it up or reported an issue.
Are you running 80MHz channels?
I can certainly try 40, 44, or 48 and hope it comes up. As long as it uses UNII-1 I don't really care which of the four is the control channel (if such is the right term).
Can you look at Channel Analysis in Luci? Is it crowded on 36 where you are? Crowding is not an issue for me.
Thanks for the tip. Let's see what happens.