Travelmate support thread

And what will happen if source wifi is not available? What is name of AP in this case?
AP should be accessable even if there is no source network.

Has there been any luck/progress in building a cache of captive-portal auto-login scripts?


The typical Travelmate setup is known as a routed client, see here

There is no such version, use 18.06 or later ...

Unfortunately I didn't receive more scripts up to now ...

Looks like latest Snapshot 1.5.3 still having Luci Frontend Issues.

Version Info
openwrt-18.06 branch (git-19.170.32094-4d6d8bc) / OpenWrt 18.06.4 r7808-ef686b7292

luci-app-travelmate git-20.009.37523-c8909a6-1
travelmate 1.5.3-1

Here's a cron job super simple script I've hacked together to login public wifi every hour as it requires. Essentially I visit that URL and it logs me in. It started off as a bookmark on Chromium before I adapted as cron job.

#Login on WiFi every hour
*/59 * * * * sleep 57 && wget -O - ''>/dev/null 2>&1

It works decently, but I've been trying to adapt it to a proper bash CURL script referencing/forking
but I don't know how to A) break down the login process and B) Write bash scripts in general.

I'd prefer the script only ran when I was using the AP instead of all the time.

Any advice would be hugely appreciated!

I've never tested latest Travelmate with 18.06.x, use stable 19.07 or master snapshots instead.

Pity. I wonder if there is some way for travelmate to "watch" the user log in to the captive portal and capture the sequence and turn that into a script that can be submitted.

Travelmate would have to know when the user is logging into the captive portal. It could guess that by testing if the internet is available and if not, watching the traffic through the router until the internet is available.

I have set Travelmate-Box up to a separate SSID/Subnet as my Modem/Switch (a Fritzbox). Not sure this is right, but that is how examples work.
My phone app (fritzphone) can be connected to the Fritzbox throughout the Travelmate repeater (although I am than in a different net) - but I can't hear any sound while calling ... Anything I missed ? Please try to explain in simple words. Thank you for any help!

Thinking about this a bit more, what if travelmate tests for the presence of a captive portal and if it finds one, sets up it's own captive portal which is just a web page telling the user that the hotspot he is using uses a captive portal and would he like to automate using that hotspot's captive portal with options:

  • yes
  • no
  • never show me this again for this hotspot

If he chooses yes, then travelmate watches what he does with the hotspot captive portal page and creates a login script for it once he has submitted the hotspot's captive portal page.

The Luci page for travelmate could then have a submit login script feature for the user to share the login script with the community. Or the travelmate captive portal page could even have a checkbox to submit it or not.

I think automating in this sort of way is the only way that users are going to enjoy automation and grow the library of login scripts.

Even I, as a software/network/devops engineer, am not clear about how I, (say) using my Android phone, would figure out what the login script magic is for a given hotspot that I connect to through travelmate. A Linux laptop as a client, perhaps, but I'm rarely going to be carrying my Linux laptop around to hotspots with my travel router.

1 Like

On a pristine 19.07.0 install GL.iNet GL-AR750 (ar71xx)
travelmate 1.5.3-1
luci-app-travelmate git-20.016.32041-5baeb64-1

Edit: Also see this on snapshot build (ath79)

Failed to execute cbi dispatcher target for entry '/admin/services/travelmate/wifiadd'.
The called action terminated with an exception:
/usr/lib/lua/luci/model/cbi/travelmate/wifi_add.lua:203: attempt to concatenate a nil value
stack traceback:
	/usr/lib/lua/luci/model/cbi/travelmate/wifi_add.lua:203: in function 'write'
	/usr/lib/lua/luci/cbi.lua:1440: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:1562: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:248: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:248: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:713: in function 'parse'
	/usr/lib/lua/luci/dispatcher.lua:1079: in function </usr/lib/lua/luci/dispatcher.lua:1069>

Is there an Internet up event that can be hooked into? I.e. things to do once the captive portal has been satisfied and the router actually has Internet access.

This would be an ideal place to hook a VPN up action. I.e. /etc/init.d/openvpn start <profile>, because you don't really want a VPN to come up before that and start plumbing routes that are not accessible yet.

When does this happen? Did you try to add a WPA3-Uplink?

Edit: Will be fixed with this PR:

1 Like

Best place is the autologin script, cause it will be fired up as long as we're sitting behind a captive portal. Of course this needs more logic within this script (e.g. check the return code of an autologin attempt).

On the other hand there are the usual hotplug handlers in OpenWrt, e.g. interface handler (not "internet up"!) - see for details.

Isn't that used to automatically log in to captive portals? If so, I'm not sure how I see how that can be applied run being run after the captive portal has been opened by logging into it.

What hotplug event is fired when the captive portal has been logged into and the Internet is available?

I don't think logging into the portal causes an interface hotplug event. Logging into the portal doesn't change any interface states. They are already up by the time the captive portal page is accessible.

Pseudo-code of your autologin script:

# Do CP portal stuff with curl ...
# If the last curl step ends with return code "0" you're in, your internet connection is up & running
if [ $? -eq 0]
  # Wait 5 seconds to settle down or test internet availability again
  # start your vpn
  # go back to travelmate with exit 0

This assumes I have an auto-login script for every captive portal I use. That is not really practical.

Something much more generic and non-auto-login-script based is needed.

Feel free to come up with a better approach - this is an open source project.

It would be nice to be able to sort and filter the scan results. I would suggest a default sort more like that of mobile phones, or Windows/Linux where the non-encrypted APs are listed first, sorted by signal strength followed by encrypted APs, sorted by signal strength.

But being able to filter on encrypted and non-encrypted would be additionally useful.

Also, I wonder why there is a separate scan per radio. Why not, again, more like Android/Linux/Windows/etc. scan on all radios and present a unified list. Perhaps flag whether the uplink is on 2.4GHz or 5GHz for the user to choose which frequency they want to use. And a filter for frequency.