No problem, in the meantime I'm trying to figure out a way to recognize that, it might help in the future to others with the same issue.
Thanks for your support
I've added partial support for this kind of captive portal in the next release of travelmate. We can't extract the cp domain for automatic dhcp rebind whitelisting, but the rest (execution of a login script) should work from now on. Stay tuned - will take some time until next release, cause I rework the whole frontend.
I think I did something too since yesterday and mine has been working since then. Not pretty but it seems to get the job done.
Thanks for your help
How do I keep an uplink from becoming disabled? I want to setup openwrt in my mini van and have it connect to my phone when I am there, but it keeps becoming disabled due to repeated failed connection attempts.
Is it "normal" when installing luci-app-travelmate via LuCI I get a truckload of "check_data_file_clashes" errors and the installation fails?
Problem with WIFI AP switching off automatically
I have a WE826-T2 router running OpenWrt 19.07.2 r10947-65030d81f3
I'm using it as a mobile hotspot with Travelmate.
My problem is that the router automatically disables the wireless AP whenever theres no client connected.
I thought Travelmate was supposed to fix this problem out of the box or is there another step?
How can I force the router to keep the wireless AP always enabled?
No, it's not normal. Please provide the error message and the OpenWrt & Travelmate version you try use. Thanks!
Full debug logs of a travelmate run please - thanks!
It just started working. I think it may have been a power supply problem.
Hi Dirk,
OpenWrt 19.07.02 on R36A
Install Travelmate seems to go fine
Install luci-app-travelmate gives "check-data-file-clash" errors (about 20 or so)
I don't have the router here and cannot check the version, but I picked the latest available.
But to be honest I have given up on OpenWrt for now. After spending way over a week trying to install and get it to work, the external USB-WiFi does nog get recognized either. I probably shall enter that configuration manually in a configuration file somewhere, somehow. I don't have the time now to plough throug all documentary pages in order to find out which apply and end up finding out it does not work for this specific hardware.
I went back to the latest stock-firmware and it works out of the box. Not brilliant, but it works. Just acceptable for now.
OpenWrt is probably very nice if networking and Linux are your profession or serious hobby. At the moment, not for me.
Thank you for the work and support.
Best regards,
Leon
random suggestion... take from it what you will...
might have been requested / covered already... but had a boot delay ( well delay pre rc.local to be exact ) on my system for ages and showed itself recently;
ubus -t 30 wait_for network.wireless network.interface.trm_wwan
i wonder if there is scope of maybe something like;
option bootwait '1'
or similar... maybe it can alternatively/additionally bypassed by the init.d script if /proc/net/.. or similar interface check does not exist etc.... I think in my case wireless wasn't even enabled... so check that too first?
I think it's no problem to make that timeout configurable ... just curious you've installed travelmate on a device without wifi?
1 Like
sweet... mostly, i roll it into all devices that might take on a wan role. it's there in the event my ISP/HFC has any outages and I need to tether out my smartphone 3/4G ( so dormant )...
fwiw... perma-merging into luci / base... would be great for this and vpn-pbr... but yeah... small devices and all of that... gotta draw the line somewhere...
i have firstboot scripts that disable alot of stuff I roll-in... and don't really use immediately / all the time.
( edit: these scripts also now disable wpad / wireless also... as I noticed background hostapd etc. even with disabled on both radios... )
I didn't have travelmate on the list... suppose I just assumed with "option trm_enabled '0'" being the default... it would not do much... but I could never nail down... why there was a 30sec-1min delay before rc.local ran.
another example similar ... but it's only logbloat... just notices today vpn-policy-routing > 'option enabled '0'' ... yet every time hotplug fires it logs i.e.;
log-bloat
Wed Jun 17 19:47:00 2020 user.notice vpn-policy-routing [10979]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 20:03:40 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 20:03:40 2020 user.notice vpn-policy-routing [11250]: vpn-policy-routing is currently disabled.
Wed Jun 17 20:03:40 2020 user.notice vpn-policy-routing [11250]: Run the following commands before starting service again:
Wed Jun 17 20:03:40 2020 user.notice vpn-policy-routing [11250]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 20:20:20 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 20:20:20 2020 user.notice vpn-policy-routing [11519]: vpn-policy-routing is currently disabled.
Wed Jun 17 20:20:20 2020 user.notice vpn-policy-routing [11519]: Run the following commands before starting service again:
Wed Jun 17 20:20:20 2020 user.notice vpn-policy-routing [11519]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 20:37:02 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 20:37:02 2020 user.notice vpn-policy-routing [11796]: vpn-policy-routing is currently disabled.
Wed Jun 17 20:37:02 2020 user.notice vpn-policy-routing [11796]: Run the following commands before starting service again:
Wed Jun 17 20:37:02 2020 user.notice vpn-policy-routing [11796]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 20:48:41 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 20:48:41 2020 user.notice vpn-policy-routing [12018]: vpn-policy-routing is currently disabled.
Wed Jun 17 20:48:41 2020 user.notice vpn-policy-routing [12018]: Run the following commands before starting service again:
Wed Jun 17 20:48:41 2020 user.notice vpn-policy-routing [12018]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 20:51:43 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 20:51:43 2020 user.notice vpn-policy-routing [12159]: vpn-policy-routing is currently disabled.
Wed Jun 17 20:51:43 2020 user.notice vpn-policy-routing [12159]: Run the following commands before starting service again:
Wed Jun 17 20:51:43 2020 user.notice vpn-policy-routing [12159]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 20:53:42 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 20:53:42 2020 user.notice vpn-policy-routing [12477]: vpn-policy-routing is currently disabled.
Wed Jun 17 20:53:42 2020 user.notice vpn-policy-routing [12477]: Run the following commands before starting service again:
Wed Jun 17 20:53:42 2020 user.notice vpn-policy-routing [12477]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 21:10:22 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 21:10:22 2020 user.notice vpn-policy-routing [13092]: vpn-policy-routing is currently disabled.
Wed Jun 17 21:10:22 2020 user.notice vpn-policy-routing [13092]: Run the following commands before starting service again:
Wed Jun 17 21:10:22 2020 user.notice vpn-policy-routing [13092]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 21:27:02 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 21:27:02 2020 user.notice vpn-policy-routing [13421]: vpn-policy-routing is currently disabled.
Wed Jun 17 21:27:02 2020 user.notice vpn-policy-routing [13421]: Run the following commands before starting service again:
Wed Jun 17 21:27:02 2020 user.notice vpn-policy-routing [13421]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 21:43:44 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 21:43:44 2020 user.notice vpn-policy-routing [13861]: vpn-policy-routing is currently disabled.
Wed Jun 17 21:43:44 2020 user.notice vpn-policy-routing [13861]: Run the following commands before starting service again:
Wed Jun 17 21:43:44 2020 user.notice vpn-policy-routing [13861]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 21:43:48 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 21:43:48 2020 user.notice vpn-policy-routing [13976]: vpn-policy-routing is currently disabled.
Wed Jun 17 21:43:48 2020 user.notice vpn-policy-routing [13976]: Run the following commands before starting service again:
Wed Jun 17 21:43:48 2020 user.notice vpn-policy-routing [13976]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 22:00:24 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 22:00:24 2020 user.notice vpn-policy-routing [15803]: vpn-policy-routing is currently disabled.
Wed Jun 17 22:00:24 2020 user.notice vpn-policy-routing [15803]: Run the following commands before starting service again:
Wed Jun 17 22:00:24 2020 user.notice vpn-policy-routing [15803]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
Wed Jun 17 22:17:04 2020 user.notice vpn-policy-routing: Reloading vpn-policy-routing due to ifupdate of wan6 (eth1)
Wed Jun 17 22:17:05 2020 user.notice vpn-policy-routing [16159]: vpn-policy-routing is currently disabled.
Wed Jun 17 22:17:05 2020 user.notice vpn-policy-routing [16159]: Run the following commands before starting service again:
Wed Jun 17 22:17:05 2020 user.notice vpn-policy-routing [16159]: uci set vpn-policy-routing.config.enabled='1'; uci commit;
will add these to my "default-off" firstboot... ( as I should have )... just when you extrapolate out the number of users with these packages... small things like this maybe add up, especially with a few of them onboard.
I also found same result in latest version of travelmate. AP is not accessible anymore when the sta-ap router is off 
Hi @dibdot, really great job .. Travelmate is so useful ....thanks a lot!!
I just installed it yesterday for the first time on a WR1043ND 19.07. I do confirm it finishes with an error and the Services menu is not visible until reboot. But everything seems to work fine, a part that the AP is going down when loosing/changing the STA.
I have basic knowledge of linux, networking and openwrt.
I was wondering if there is a way to use switch LEDs to show which STA is currently connected.
e.g. LAN1 to LAN4 leds switched on for STA1 to STA4 or blinking for STA5 to 8
I use Travelmate to switch among smartphone hotspots depending on contractual remaining data usage. It would be safer to have visual confirmation to avoid bad data usage when forgotting the wrong hotspot activated.
I know I can partially control this prioritising STA in the hotspot list.
It could also be very useful if prioritation could be parametrized.
I have 4 smarthphone with 4 different data plans.
I'd like to change priorities based on the monthly reset date.
Higher priority if reset date is coming closer, to use residual data amount.
It would also be useful if a data limit could be set for each hotspot within the month period.
Example:
hotspot #1 with 30Gb data and reset date 25th
hotspot #2 with 50Gb data and reset date 3th
If only one STA available, connect to it but only if monthly data limit has not being reached.
If both STAs available, connect to one with the closest deadline (e.g. if it is June 15th, connect to hotspot #1) and switch to the other when monthly data limit is reached.
I know that the monthly data limit calculated by the router is different to the real one, but I could set a lower amount (25Gb instead of 30Gb) to be conservative.
Hope it is clear enough.
Thanks again for your great job!!
David
I've been experimenting with travelmate today. I noticed that it broke my WLAN LED trigger based on phy0assoc. This happened on two different device types. Is this a known issue? I don't see a bug for it.
UPDATE: The LED gets triggered later after boot, if there new wifi events. It seems like it's just getting broken at boot.
/etc/init.d/travelmate status does nothing, contrary to documentation.
root@openwrt:/etc/config# /etc/init.d/travelmate status
Syntax: /etc/init.d/travelmate [command]
Available commands:
start Start the service
stop Stop the service
restart Restart the service
reload Reload configuration files (or restart if service does not implement reload)
enable Enable service autostart
disable Disable service autostart
That's a known bug/limitation in 19.07.x ... use 'status_service' instead.
Just use another trigger, e.g. the logical wwan interface, by default 'trm_wwan'
Hi, thanks for your feedback. I'm afraid your wishes are going far beyond what I'm able to build into Travelmate ... currently I'm working on forthcoming Travelmate 2.0 which includes better/easier uplink organization, e.g.
you can enable/disable uplinks explicitly and you can prioritze the uplinks by drag and drop ... but no accounting or something like that.