Thanks for the tip, but you should fix your incorrect documentation.
Why don't you just fix your broken script and stop breaking LED triggers?
Also fix your attitude. When someone comes to you with a bug report, giving them the "You're holding it wrong" treatment just makes you look like a jerk.
It's not my fault your script breaks LED triggers. That's your fault, and your responsibility to fix if you care. The way you reacted to me bringing this to your attention is also your responsibility.
I hope you can be more respectful to others in the future when they bring you a bug report. Don't tell people it's their fault when your software breaks stuff.
Huh? Bug? Fix your attitude? I don't know what you're talking about - you've simply selected a wrong led trigger ... there's nothing to fix in travelmate.
Thanks for your prompt reply!!
I agree with you that hotspot quota control can be complicated.
On the other hand I hope you will consider Leds and date prioritation in a future release, as they should be much easier enhancements.
When do you plan to release TM 2.0?
Thanks
Davide
@pdneri, search the forum or github for some scripts called "iptmon" ... depending on your skill level, you could have them dump per-uplink (with some modification) total-used... into separate folders. but things get tricky with multiple profiles and reset dates etc...
fair bit of work... but something that may suit your requirement. or at least give you a starting point on how to achieve your goal.
uh thanks @anon50098793 !!
My skills are really basic but I will give it a try.
To be honest I would be happy enough to manage at least leds and date priorities... do you have any suggestions for them too?
start a new thread called "wwan quotas" or similar
Really?
I would like leds and date priorities to work within TravelMate ... and I would abandon priorities based on quota limits for the moment
Hi dibdot,
thanks a lot for the useful travelmate package!
I'm using 19.07.3 and have installed the latest versions of travelmate and qrencode. What I observe is, that AP-passwords containing any of the characters ()& do not result in an QR-code when pressing the button.
Any help (except changing the password)?
Thanks in advance
Jochen
Clearly a bug/limitation. Fixed with this commit https://github.com/openwrt/luci/commit/06ce62b65d05806d39099b46102579eeff66aad2 (backported to 19.07 as well). Just update your luci-travelmate package in a couple of hours/days.
Thanks!
Confirmed - works now!
Thanks for the ultrafast fix
1 Like
Hi @dibdot - I'm having a small issue with Travelmate, and it's quite confusing... See, it is very random how and when it happens.
I've got right now two RAVPower RP-WD009 devices, which just gained support (as such, I'm using a snapshot build). Travelmate is practically designed for travel routers, so I installed it, set it up, and... Nothing. The logs show that scans do happen for the host APs, but apparently it can't find the AP:
Mon Jul 6 16:31:56 2020 user.debug travelmate-1.5.4[1222]: f_jsnup ::: uci_section: -, status: running / not connected, sta_iface: -, sta_radio: -, sta_essid: -, sta_bssid: -, faulty_list: -, list_expiry: 0
Mon Jul 6 16:31:56 2020 user.debug travelmate-1.5.4[1222]: f_check ::: mode: initial, name: -, status: false, connection: -, wait: 1, max_wait: 30, min_quality: 20, captive: 1, netcheck: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_prepdev ::: config: radio0, disabled: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_prepdev ::: config: radio1, disabled: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_env ::: trm_eapcheck: 1, trm_saecheck: 1, trm_owecheck: 1, trm_wificmd: reconf
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_jsnup ::: uci_section: -, status: running / not connected, sta_iface: -, sta_radio: -, sta_essid: -, sta_bssid: -, faulty_list: -, list_expiry: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_check ::: mode: initial, name: -, status: false, connection: -, wait: 1, max_wait: 30, min_quality: 20, captive: 1, netcheck: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_main ::: status: false, proactive: 1
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_prepif ::: config: default_radio0, mode: ap, network: lan, radio: radio0, trm_radio: radio0, trm_active_sta: -, proactive: 1, disabled:
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_prepif ::: config: default_radio1, mode: ap, network: lan, radio: radio1, trm_radio: radio0, trm_active_sta: -, proactive: 1, disabled:
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_prepif ::: config: radio0_Lyvster_79_, mode: sta, network: trm_wwan, radio: radio0, trm_radio: radio0, trm_active_sta: -, proactive: 1, disabled: 1
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_check ::: mode: dev, name: radio0, status: false, connection: -, wait: 1, max_wait: 30, min_quality: 20, captive: 1, netcheck: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_main ::: iwinfo: /usr/bin/iwinfo, dev_list: radio0, sta_list: , faulty_list: -
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_main ::: no station on 'radio0' - continue
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_jsnup ::: uci_section: -, status: running / not connected, sta_iface: -, sta_radio: -, sta_essid: -, sta_bssid: -, faulty_list: -, list_expiry: 0
Mon Jul 6 16:32:57 2020 user.debug travelmate-1.5.4[1222]: f_check ::: mode: initial, name: -, status: false, connection: -, wait: 1, max_wait: 30, min_quality: 20, captive: 1, netcheck: 0
Except, if I run iwinfo wlan0 scan, it works - and in a mere second, spits out a nice big list of APs, including mine.
What can be the problem here? Multiple installs/reinstalls, rebooting the device, and sometimes even letting it sit and wait are tactics I've achieved some marginal success, but it's annoying to not know the cause of this issue.
EDIT:
Moved the main router AP I was trying to connect to from WPA2/WPA3 Personal to WPA2 only, and now it works much more reliably. Still some disconnects from time to time, though.
Please PM me the output of iwinfo wlan0 scan in a text file, also your travelmate and wireless config (redact passwords please). Thanks!
I am using travelmate on a Ubiquiti Nanostation M5.
I tried travelmate because I had problems to use STA + AP simultaneously with 1 radio.
But I had the same problems with travelmate, it did not work.
Until I found on the forum the answer from user mk24 that STA + AP is not supported for DFS channels in my case.
When I changed the channel of the existing AP from 100 to 36 it works like a charm.
This will limit the use of Travelmate I think, quest networks cannot use a DFS channel.
@dibdot is this correct?
Hi,
i am trying to setup Travelmate with OpenVPN. The goal is to have a travelrouter that can connect via LTE oder via Wifi to a unencrypted network and always has a secured connection via OpenVPN (and no connection if OpenVPN is down). That works so far.
However, if a wifi has a captive portal, it will not be redirected to the clients.
My Zoneconfig looks like this:
If I disable OpenVPN and put WAN into the possible destionation Zone of LAN (instead of VPNZONE), then the captive portal is redirected to the clients.
Is it somehow possible to also achieve this while being connected to the VPN?
Atm I do the following:
Disable OpenVPN, put WAN into the possible destionation Zone of LAN (instead of VPNZONE), connect with a client, handle the captive page, and then reset the zones (as shown above) and enable OpenVPN.
I also tried to disable rebind protection, but that did not work.
I don't know a way that's gonna work... you need to take down the VPN first.
I've never seen a public Uplink/AP in the wild which is sending only on 5G and configured on a DFS channel. Furthermore I'm not sure if this DFS limitation is valid for all supported chipsets ... sorry can't help here.
I am using an Engenius ENS202EXT with OpenWRT firmware on it, together with Travelmate. This was installed last year, running OpenWRT 18.06.4 and compatible Travelmate package, which was working fine until last week. The hotspot is loosing its connection now and then, so I decided to upgrade to the latest versions:
OpenWRT 19.07.3 and Travelmate 1.5.4-3 (with Luci addon).
Unfortunately, since the upgrade, I cannot get Travelmate to scan for new WiFi hotspots and getting the same error over and over:
/usr/lib/lua/luci/template.lua:97: Failed to execute template 'travelmate/wifi_scan'.
A runtime error occurred: [string "/usr/lib/lua/luci/view/travelmate/wifi_scan..."]:4: module 'luci.xml' not found:
no field package.preload['luci.xml']
no file './luci/xml.lua'
no file '/usr/share/lua/luci/xml.lua'
no file '/usr/share/lua/luci/xml/init.lua'
no file '/usr/lib/lua/luci/xml.lua'
no file '/usr/lib/lua/luci/xml/init.lua'
no file './luci/xml.so'
no file '/usr/lib/lua/luci/xml.so'
no file '/usr/lib/lua/loadall.so'
no file './luci.so'
no file '/usr/lib/lua/luci.so'
no file '/usr/lib/lua/loadall.so'
stack traceback:
[C]: in function 'require'
[string "/usr/lib/lua/luci/view/travelmate/wifi_scan..."]:4: in main chunk
stack traceback:
[C]: in function 'error'
/usr/lib/lua/luci/template.lua:97: in function </usr/lib/lua/luci/template.lua:85>
(tail call): ?
/usr/lib/lua/luci/dispatcher.lua:1015: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>
I am missing some files, but I cannot find out how to add them, since I do not know which package is needed for it.
The difference between the 18.06.4 and the 19.07.3 installation is that the old installation was a "generic" version of OpenWRT, and the new one is a "tiny" version of OpenWRT (since there is no generic for the ENS202EXT).
Anyone who can point me to the right direction?
Never seen this before, looks like a luci base class is missing ... please provide the output of opkg list-installed | grep "^luci". Maybe @jow had a better idea ...
Edit: @DaLassOnline Did you install travelmate from master or from 19.07 package feed? Please use the latter one.
I think you need to upgrade luci-base and luci-libs-base