Never seen such error. Please provide the output of
/etc/init.d/travelmate status
and your travelmate config. Thanks!
Reported problems seems to be unrelated to travelmate. Why do you use this unknown fork? The GL-AR750S is officially supported by OpenWrt (NOR-flash).
I got it to work eventually, all is well again!
I'm using their fork because (apparently...) I'm supposed to then be able to create Nand firmware, which as I understand it is better because then I'm also updating kernel drivers. Still learning... Little info on this device.
Dear all, I am using travelmate (newest version) on an GL-MT300A. I would like to change my Mac-address. When travelmate is not running I can do so using macchanger but as soon as I turn travelmate back on the Mac-address changes back to its original state.
Can you give me a clue how to proceed? (Actually what I want to achieve is to use a random Mac-address everytime the device starts - that is the ultimate goal.
Thanks
I installed travelmate (both 1.2.2 and 1.3.1) on a GL-AR750 on 18.06.1, and it refused to connect to any of the wireless networks I specified. After debugging the code, I found that the wifi-iface section names (in /etc/config/wireless) cannot contain underscores (_).
I had added wifi-iface sections manually, and copying the existing config, I had specified section names like:
config wifi-iface 'trm_wwan_home'
...
config wifi-iface 'trm_wwan_work'
...
Looking at /usr/bin/travelmate.sh, in f_main(), section names and radios are retrieved from the keys of trm_stalist:
config="${sta%%_*}"
sta_radio="${sta##*_}"
If the section name contains underscores, then config would hold only the first part of the section name (before the first underscore).
I believe changing the config line to
config="${sta%_*}"
(removing the shortest matching pattern instead of the longest) should work, but I haven't tested it.
(I believe radio device names can also contain underscores, but I haven't tested this either.)
It would be great if the code can be modified to accommodate underscores in section names. At the very least, it would help if this limitation was documented in the readme.
Thanks!
Nice finding! 
I'll change that with the next update.
@jefferyto I've pushed a PR regarding named 'wifi-iface' sections (see https://github.com/openwrt/packages/pull/7882). Would be nice, if you could test that ... thanks!
I did a quick test and it seems to be working - thanks!
Also, it would be nice to have a way to disable an interface so that travelmate doesn’t try to connect to it at all (e.g. after the time limit of a preferred wifi network is over, can disable it and fallback to a less preferred network).
Normally I would manually comment out the config entry, but travelmate (through uci) has a habit of removing all comments when saving.
Just prioritize the configured stations as you like via "UP"/"DOWN" in Wireless Stations tab, e.g.
In this example travelmate will switch to my mobile AP (meinIO) as soon as I enable this functionality on my mobile ... and fall back to lower prioritized whenever I disable this AP.
Oops, somehow I thought travelmate decides which network to connect to based on signal strength. (Even on this LuCI screen, it's not clear to me that travelmate will try to connect in top-to-bottom order. I thought the ordering was only for my visual preference.)
I still think a clear "disabled" setting would be useful though. In my case, the signal for the less-preferred network is weak. No matter how many disconnections I experience, I still wouldn't want travelmate to give up and try the other (time-limited, now expired) network.
And now that I know travelmate tries networks in order, I would also suggest adding a "priority" option instead of relying on config section order. I guess because I prefer manually editing config files, I want to order/group my sections in a way that makes sense to me. (And because the order of connection is an actual setting, having it set explicitly as an option makes me feel better 
)
(A thought I had after posting:) If you keep a list of opt-in wifi interfaces (a bit like mwan3 policies):
config travelmate 'global'
...
list trm_interfaces 'networkA'
list trm_interfaces 'networkB'
then it can support disabled networks (by not including in the list) and connection ordering (using list order).
These are not deal-breakers though - thanks again for this package!
Just a small "heads up" for users which are currently running travelmate 1.3.x. Please update to latest 1.3.3 (backend changes only, LuCI is untouched), which fixes the "ProActive" mode (enabled by default) ... most important is the removal of needless ubus network reload calls, which could lead to intermittent uplink dis-connections.
Hi
I'm a new openenwrt and travelmate user. Firstly it's fantastic! works really well and such a big improvement on anything else I used for this purpose.
I'm having problems connecting to eduroam wifi network. When I try to connect I get asked for identity, password and 'path to CA-certificate'. I've attached a screenshot.
The identity and password are the same whenever I connect from any device (universityusername@domain.tld), but I'm stuck at the certificate part.
Any help would be gratefully appreciated.
The CA-Certificate is optional. If eduroam works without certificate it's fine. Please make sure that you have installed one of the full wpad-versions. Check with ...
opkg list-installed | grep wpad
... by default OpenWrt only installs a PSK-only wpad version (to save space).
Hi, I'm currently trying to run this on a HooToo Tripmate Titan running OpenWrt Chaos Calmer 15.05 r47065. I manually installed version 1.4.0 with the luci companion app. I know that Chaos Calmer is moldy and not officially supported, but I was hoping you might be able to help me.
When accessing the wizard/interface in luci, everything appears to work correctly except for the wireless stations tab. When I try to access it, I get the following:
Any idea on how (or even if) I can fix this? The rest of it appears to be working, I just can't access the station list (which is almost the most important part qq)
Getting the device to broadcast its AP even when it fails to connect in client mode (like if I'm not near the access point it was previously connected to) is the last step in getting this to work as a proper travel router/extender/repeater which I heard this can solve (?)
Sorry, CC is too old and is not supported (to be honest I have no time & no test device for that). Just curious, why did you still use CC on the HT-TM05!? I'm using such device with latest OpenWrt snapshot flawlessly ... 
Truth be told, I just found an image for it online/on the openwrt site (using a premade image, there was a wip forum somewhere around here for it).
Just curious, what do I have to do to get the latest and greatest openwrt running on it? Ideally I'd love to run something less ancient, assuming there's enough space on the device for that...
(Specifically, I was just following the instructions on it's device page: https://openwrt.org/toh/hootoo/hootoo_ht-tm05)
Setup your own buildroot environment based on the target profile for GL-MT300N. Or send me a short email to my maintainers address and I'll send you my working image in return.
Is there another forum for travelmate discussions/support? Having a single thread makes finding relevant information nearly impossible.
The reason I am looking for this is I have an issue that I could use some input on that will likely take some creative scripting as it involves flaky connections and the need to reset the wireless AP and restart both travelmate and openvpn in a smooth manner.
TIA
If you don't find a solution in the forum, just open a new topic or describe your issue within this thread.