Using a USB wireless card with gl-inet firmware Part 1 - the honeymoon period

Technical Support for Routers
1

This post is a follow up from: Can anybody recommend a solution for increased 2.4ghz range on the GL-AR750S? - #19 by Thearties

I really hope that gl-inet decides to include the USB wifi option in other models because this was a real pain to work through. As there were lots of existing threads on the topic (and obviously much demand for this) I thought I’d share how I managed to make this all as painless as possible to save others the difficulties.

The external alfa card makes a big difference to signal - whilst it is not dual band and the antenna is wide enough to increase the noise significantly, there is a noticeable and tangible benefit in terms of connection speed and reliability. The improvement on signal level varied from 10-20dbm (not accounting for noise). With careful angle of the antenna you can help to reduce the noise quite significantly. This allowed me to connect to networks that the slate, my phone or laptop could not.

Firstly, to understand some idiosyncrasies:

  1. When you plug your usb wireless card in once, your configuration will be somewhat broken there on after (no scanning or joining wireless networks from the gl-inet firmware is possible - even after removing the external card and rebooting). To restore the original state you must remove all traces of the external card from /etc/config/wireless/wireless and restart the network with ‘wifi’ to implement the changes.

  2. When you plug in or unplug a USB wireless card afterwards, the whole configuration can become ‘messed up’ once again.

  3. When you reboot with or without the wireless card your whole configuration can be messed up and the order of devices (radio0 radio1 & radio2) can also be rearranged:

Sometimes, the device will recognise the external card as radio1, other times it will remain as radio2
Sometimes, the wlan-sta connection will decide it needs the external radio, sometimes it won’t

  1. The way in which things can get ‘messed up’ is not predictable even in the same conditions.

What did not help?

  1. Trying to execute commands over ssh to fix the configuration on a dynamic basis.
  2. Messing with adding different interfaces
  3. Trying to get everything to work simultaneously
  4. Trying to account for every possible configuration shift
  5. Trying to disable the internal card

What helped?

  1. Using radio0 (the 5ghz network on the slate) as a constant made this possible for me. I believe that if you do not have two radios like the Slate does, you might have some difficulties in having a stable solution - at least if you do not have ethernet port like me.

  2. Realising that you can ‘replace’ the internal 2.4ghz as radio1 by modifying the path to your radio2 and removing the radio2 entry from /etc/config/wireless entirely

So what was my solution?

When ever a configuration change occurs it is reflected in /etc/config/wireless.

After all the messing around, I realised that I could simply maintain two separate /etc/config/wireless configs - one for the internal card and one for the external. This means that it doesn’t matter what ever happens during a reboot, if I unplug something or whatever - as long as the 5ghz connection to radio0 is maintained I can just execute:

cp -f /etc/config/wireless/wireless.internal /etc/config/wireless && wifi

and to setup the device for the external card:

cp -f /etc/config/wireless/wireless.external /etc/config/wireless && wifi

This is a great solution that depends on the constant connection via 5ghz on radio0 to switch modes on the fly. It fixes all issues with buggy stuff happening to the wireless config in the meantime too. Also, with this method I can use glinet admin page to manage, scan and connect to networks whether I am using the external card or not.

I really wish gl-inet will make this a native option for all the people interested in using external wifi antenna on their routers (not just for brume) but until then, this will save you some time and effort.

Comments on the Alfa card:

I would maybe not get such a powerful card - the smaller model (NEH) would probably be sufficient. However, the plastic holder with clip and suction cup you get with the larger model was surprisingly useful. Overall I am impressed with the performance of the alfa card. Truly I do not believe that there is an urban location I will not be able to get wifi from now. I think that the directional alfa 7dbm panel would make the connection even better (while helping to reduce noise). It is important to understand the spread of each antenna to get the best out of the card so research is important too.

2 Likes
2

Using a USB wireless card with gl-inet firmware Part 2 - a bug with the gl-inet network repeater manager

After some experience with my usb alfa + slate setup I realised that there are some glaring issues because unluckily, the best network I had been piggy-backing on disappeared completely and I had to go back on the hunt for the next best alternative which was siginificantly worse in terms of signal and distance.

I quickly saw that the external alfa card (that was masquerading to the gl-inet firmware as the internal 2.4ghz card) was having real difficulty in staying connected to the distant open networks I needed to access. These networks are very common - they are all open networks, with 3 local ISPs and all of the networks have the same name. I have logins for all these networks and I experienced the same issue on all of the networks.

I was a bit annoyed at the lack of performance of the alfa to say the least and in a futile bid to see what’s up, I plugged it into my chromebook (which is not supposed to support external wifi adapters).

To my surprise, the alfa device instantly boosted the signal of available networks on my chromebook and I was able to use the adapater in chrome os without issue. Going on the hunt for those networks again, I quickly realised that the chromebook was having no problem staying connected to the same wireless networks that would kick me off with the slate - despite using the same radio, antenna and location.

I found one particularly decent signal and tried both the chromebook and the slate to compare - everytime the slate would kick me off the network very quickly while the chromebook could maintain a stable network downloading away for hours.

I thought that this was strange - I believe that both devices should be using wpa_supplicant without too many crazy differences… I then remembered all the posts about people being regularly disconnected from repeater with the slate on this forum.

I retried with the slate in the same location but instead of using my trick to use the gl-inet firmware to connect to the network, I tried the original method of configuring everything to work simultaneously.

The details are in the next post, but the point is worthy of it’s own mention:

The gl-inet repeater mode will consistently fail to remain connected to distant open networks - open networks with other AP’s likely in range also.

When connecting to a new network via LuCi, using a different interface and network name (no ‘wlan-sta’ and no ‘wwan’) then the same connection is completely stable. I tested the same with internal wifi and noticed the exact same behaviour!

Also, I noticed that often, gl-inet network manager will not always scan and connect to the network with the best signal - I sometimes had to forget the network on the gl-inet side and manually edit the mac address I wanted to get the right AP over ssh or LuCi.

The takeaway however is that the gl-inet network repeater manager consistently causes unecessary disconnections - Connecting to different open APs with the same name, or just in an environment with variable signal levels and noise can be really problematic.

2 Likes
3

Using a USB wireless card with gl-inet firmware Part 3 - Configuring external card with LuCi

Going back to the drawing board to avoid using the buggy gl-inet network manager I quickly realised that the internal 2.4ghz just will not work properly in conjunction with the external card:

what ever I have tried so far does very little to change that - When the alfa is plugged in, the slate appears to be able to remain connected as a client to my phone’s hotspot with the internal 2.4ghz wireless, but there is no AP mode working for the 2.4ghz radio1 (even after disabling client mode in LuCi - there is just no AP from the internal card possible). If the client mode is set to autoconnect then I believe it may reconnect automatically if the network’s mac address doesn’t change, but there is no scanning or joining new networks possible from the gl-inet firmare nor from LuCi - the scan does nothing. Really don’t know why or how to debug this but as it is not most important it will have to wait for another day…

Incidentaly, when client mode of internal 2.4ghz wifi is disabled I notice this entry in the logs repeating over and over again when client on internal radio is set to disabled:

[ 6480.361637] IPv6: ADDRCONF(NETDEV_UP): tmp.radio1: link is not ready

The Solution:

This time I gave the alfa card it’s own interface ‘alfa’ and labeled the network as ‘alfa’ instead of ‘wlan*’ or ‘wwan’. I scanned for networks from LuCi and selected the network that I wanted to stay connected to.

This result in no disconnections at all!

Comments:

Fingers crossed! …this setup is now allowing me to maintain a stable network connection to an AP located god know’s where and god know’s how far with a signal no better than -65dbm. The quality of the connection goes up and down, but I have clocked 10mbps which is probably the highest allowed for that free AP.

I’m a bit bummed at how the gl-inet network repeater manager is struggling - really the appeal of these devices for me was exactly for the handling of these kind of situations. That’s why I made the effort to make the external card work with the gl-inet firmware but when you are on the road it is just the worst time to be debugging things and fighting with software configs.

I hope that gl-inet takes the lead and finds a fix for their network manager… Oh and if you could throw in USB support whilst you’re there :stuck_out_tongue_winking_eye:

1 Like
4

Hi.
You wrote:
" When connecting to a new network via LuCi, using a different interface and network name (no ‘wlan-sta’ and no ‘wwan’) then the same connection is completely stable. I tested the same with internal wifi and noticed the exact same behaviour!"
I’am connected to a public wifi antenna 50m away from me, good signal -58dBm now and never disconnects but if I use GL UI problems comes, may be these problems are caused because there are 4 same SSID different channels, 2 Ghz and 5 Ghz (only one internet company in my country) and GL-UI makes confusion to which SSID connects, no MAC defined there. In Luci you can asign MAC to connect to.
Also I’m interested in increase wifi range, in my case I have a usb dongle RTL8814AU but I did’nt try it because I worry about usb power failures or Router power failures after using that.

2 Likes
5

I think power issues will not be of any concern because the alfa adapter I have is pushing 1000mw (apparently capable of 2000mw). As long as your power supply is good it should be ok for most adapters.

However, I’m not sure there will be much improvement to the built-in wifi unless it has a big antenna, more power, or at least if you leave the dongle outside or somewhere closer to the source than the slate can go.

But yes I think there is a huge problem with the gl-inet network manager in these conditions. I’ve read half a dozen topics and only read one post that suggested to use openwrt classic or at least configure the connection via LuCi.

I tested with the same radio and antenna, as well as internal radio and the results were very clear and 100% reproducible. I noticed the issue with the mac address too when I was confused that a network wasn’t working as expected.

Even when the gl-inet firmware connects to the right AP… it doesn’t want to stay connected.

Thanks for reading all the way… wasn’t sure if any one would bother :smiley:

6

thank you for your feedback. I can confirm everything you are saying. And to add to the above comment it’s worse than you think. using many other usb adapters I have encountered this problem. it is not just symptomatic of gl-inet but also ocurrs with clean openwrt 18.06 and 19.07.x and furthermore when I thought I had found one that would work and would always set the usb adapter to radio2 on a soft reboot. I was smiling and overjoyed only to discover a power cylcle throws it elsewhere into the line up at radio0 or radio1.

but, alas I found the tp-link wn722N version1 always stayed at radio2 because of the other atheros drivers being similar but not exact. :slight_smile: It also supports 802.11w

another solution you could use is luci-app-travelmate. this may interfere with other gl functionality but no more than how your using it. like your alfa interface that you created, it creates a trm_wwan interface where all wisp radio connections exit too. this has some very useful feature sets. (advanced or daring users only)
when using it you do have to disable gl_health and not have any access points on the adapter you use for wisp
directions here.AR750s Keeps disconnecting - #32 by wellnw
Myself I only use travelmate with clean openwrt

this adapter works great in many wifi routers from gl… except 300nv2. nothing works with that to to the proprietary drivers used.

before complaining that this is a 15 year old adapter and is hard to find. you may find one on ebay.
and thank you for your contribution. I myself could not eloquently describe or went as deep as you did.

1 Like
7

Hey @rp201rp thanks for your most interesting reply!

I had seen that long post before but thank you for bringing it to my attention. I will know where to look if my config starts getting tedious,

For now I have found a great balance… the radio order is actually no longer changing between reboots and the external public network re-connects like clock work. ALL I have to deal with is stopping the VPN to login to captive portal (the VPN policy seems not to work while VPN is in connecting phase… or at all).

The secret to avoiding the reordering I believe lies in leaving the your ‘wwan/wlan-sta’ connection on the internal 2.4ghz radio enabled. For me, this is my phone’s hotspot. I deleted the connections from the gl-inet firmware and disabled automatic re-connection there too… The last network is still saved in LuCi even when you delete everything from gl-inet firmware. Interestingly, with this wlan-sta left as enabled, when I switch on my phone hotspot now the slate will still automatically connect - even when it changes mac address! This is really useful behaviour for me so I’m really pleased about that.

here is my current /etc/config/wireless that works with internal 5ghz AP, internal 2.4ghz automatic wlan-sta and external Alfa wireless client mode simultaneously (…ish only one internet source works at a time). Gl-inet firmware scanning and connecting does not work for either internal radios. Neither does 2.4ghz AP on internal radio:

config wifi-device ‘radio0’
option type ‘mac80211’
option hwmode ‘11a’
option path ‘pci0000:00/0000:00:00.0’
option htmode ‘VHT80’
option doth ‘0’
option txpower_max ‘20’
option band ‘5G’
option disabled ‘0’
option noscan ‘0’
option txpower ‘10’
option channel ‘36’

config wifi-iface ‘default_radio0’
option device ‘radio0’
option network ‘lan’
option mode ‘ap’
option encryption ‘psk2’
option disassoc_low_ack ‘0’
option ifname ‘wlan0’
option wds ‘1’
option ssid ‘XXXXXXXX’
option key ‘XXXXXXXX’
option dtim_period ‘3’

config wifi-device ‘radio1’
option type ‘mac80211’
option hwmode ‘11g’
option path ‘platform/qca956x_wmac’
option txpower_max ‘20’
option noscan ‘0’
option htmode ‘HT40’
option band ‘2G’
option txpower ‘10’
option channel ‘11’

config wifi-iface ‘default_radio1’
option device ‘radio1’
option network ‘lan’
option mode ‘ap’
option encryption ‘psk2’
option wds ‘1’
option disassoc_low_ack ‘0’
option ifname ‘wlan1’
option ssid ‘XXXXXXXX’
option key ‘XXXXXXXX’
option dtim_period ‘3’
option disabled ‘1’

config wifi-iface ‘guest5g’
option device ‘radio0’
option network ‘guest’
option mode ‘ap’
option wds ‘1’
option ssid ‘XXXXXXXX’
option encryption ‘none’
option ifname ‘wlan2’
option disabled ‘1’
option guest ‘1’
option disassoc_low_ack ‘0’

config wifi-iface ‘guest2g’
option device ‘radio1’
option network ‘guest’
option mode ‘ap’
option wds ‘1’
option ssid ‘XXXXXXXX’
option encryption ‘none’
option ifname ‘wlan3’
option disabled ‘1’
option guest ‘1’
option disassoc_low_ack ‘0’

config wifi-iface ‘sta’
option network ‘wwan’
option mode ‘sta’
option ifname ‘wlan-sta’
option ssid ‘XXXXXXXX’
option channel ‘1’
option device ‘radio1’
option encryption ‘psk2’
option key ‘XXXXXXXX’

config wifi-device ‘radio2’
option type ‘mac80211’
option hwmode ‘11g’
option path ‘platform/ehci-platform.0/usb1/1-1/1-1:1.0’
option htmode ‘HT20’
option country ‘US’
option legacy_rates ‘1’
option channel ‘1’

config wifi-iface
option ssid ‘XXXXXXXX’
option encryption ‘none’
option device ‘radio2’
option mode ‘sta’
option network ‘alfa’
option bssid ‘XXXXXXXX’
option ifname ‘alfa’

As the connection is stable I’m leaving everything as is and rebooting without issues so I don’t need to restore /etc/config/wireless configs on the fly. I still have my original configuration stored to switch back if I need to get back to better functionality with the gl-inet firmware.

Thanks for your praise… I actually took notes while I was working over this and figured that it would be better to post after having had the experience rather than while it was happening.

EDIT: actually I think I was wrong about the cause for out of order devices… I believe that removing the unnecessary radios from /etc/config/wireless is the cause for this behavior in my case. If each radio has a defined role in /etc/config/wireless then it seems that the order of radio0, radio1 and radio2 is maintained on reboot for me… Time will tell.

8

I’m running a setup like yours on a default OpenWRT image, instead of GL-inet’s firmware version. When you go in to advanced settings, the default scripts will no longer be able to make sense of the router’s config and mess up.

You could use something like the package Travelmate as connection manager in a default openwrt firmware. In my experience the most stable is really just building your /etc/config/wireless yourself and not actually using an script to update that.

9

You could use something like the package Travelmate as connection manager in a default openwrt firmware. In my experience the most stable is really just building your /etc/config/wireless yourself and not actually using an script to update that.

I think you’re right.

It’s funny I was originally keen on the glinet firmware for avoiding openwrt but having access still to advanced features (as well as no need for ethernet to configure and simple restoring)… But it looks like I am learning more stuff about openwrt than ever. Soon enough I will be using only LuCi and keeping the glinet firmware just for OTA software updates!

At this rate I just need travelmate, mwan3, wireguard and openvpn. Still some way to go, but at this rate it certainly looks like that’s where I’m heading.

10

Or… you can just do everything from command line, just copy pasting scripts you make like i do :stuck_out_tongue:

I think that is where you are heading :smiley:

1 Like
11

Great post.

If you use Brume, when you plugin a support wifi dongle, the UI will recognize it and you can use set up as repeater or AP.