Do you have a feature that you’d like to see added to the InvisaGig software in a future update?
…or maybe you have a physical hardware version feature request you’d like to see incorporated in the InvisaGig product?
Post your requests and ideas here, for all to converse and talk about.
You never know, you might get your idea put into the next update or version!
This maybe too much to ask due to firmware limitations. Have a setting that would check the bandwidth speeds of available channels locally of both lte and 5g then choose options based on that. Like maximize upload(streaming/ servers attached to invisagig), Max Download, Balanced, Most reliable (based on signal strength) etc…
This is actually on the roadmap internally. It’s definitely something we are looking into.
When done manually it takes multiple steps and potentially 20-30 minutes of running tests.
Turning this into a ‘quick’ automated process is going to take some trickery and likely will still be a long process.
I think this is the reason even the billion dollar companies don’t have this feature done in any meaningful way.
If there can be a log files feature for the modem, would really be helpful for troubleshooting in times something does not working as expected.
The typical logged values given, like on router systems, is actually logged by the router/host and uses the USB driver interfaces (MBIM/QMI and URCs) between the router and the modem. Since we aren’t interfacing in this way, we don’t have the same level of logging available. The core Qualcomm interfaces also do not provide a human readable debug or logging output that would be useful for connectivity troubleshooting…
BUT we are working on making it much easier to troubleshoot uptime/downtime/connectivity.
That make senses. Thanks for the info and looking forward for the next release.
It would be nice to have SSH access to the device.
I am currently running it in the following Lab setup 
IG + Cablemodem DUAL WAN > Proxmox hosted OPNSENSE > PALO > Unifi UDM SE > workstations.
Yrying to get various rules / routing right to connect to the IG mgmt is a headache . 5g Connectivity works great though.
It would be nice if I could just text mode SSH from the OPNSENSE shell side to the management interface on the IG.
The new release, 1.0.12, is soon to hit beta testing.
It includes Tailscale support, which should fill the remote access void a bit.
Not looking for remote access , but internal LAN text access not WAN. instead of via HTTPs However that tailscale will be cool too.
@richard @ryan perhaps a “dark mode”, but for being able to turn off the LED’s on the unit? I’m going to be using mine as a backup modem in my house and I get the best signal in my living room on the entertainment center. Perhaps there is some gpio pin black magic that could disable the status LEDs, making for a more stealth install? Or perhaps in a future revision add a physical toggle switch that just kills power for the LED’s.
(Sorry if this was asked before, haven’t combed the entire forum yet)
Hans
Thank you! Certainly a great suggestion that we will keep in mind as future IG hardware revisions take shape
@cybrnook @jgyoblonski
If you set your defined IG WAN Gateway’s ‘Monitor IP’ to the web UI address (‘192.168.225.1’ by default) then OPNSense/pfSense will kill two birds with one stone:
Interface changes on the IG side due to carrier reconnection are less disruptive in the default IP Passthrough (Bridge) mode since you provide the static, NAT IP of the device (as opposed to the passed through IP which can disappear or change during reconnection).
A static route is set for the web UI address automatically so there should be no other configuration necessary to reach it from LAN clients.
That makes sense, I guess I was speaking more to the LAN access vs. Tailscale. Apologies for the confusion on my part.
Sigh… and now re-reading over @jgyoblonski original post, I now realize I am the only person talking about “over tailscale”, ROFL. So, with that being said, forget everything I mentioned after my suggestion of LED control.
I guess I was still amped up from getting tailscale setup minutes before that post that I still had everything tailscale on the brain (it’s a mess up there).
P.S. Feel free to clean up the thread if needed. (I went ahead and deleted the posts as to not spam this feature req thread)
No worries!
Start a new thread of you like.
I’ve got a couple of thoughts / feature requests ( or things for someone to tell me that it’s already there - that I just don’t know where to look as a newb to InvisaGig!):
First, I’ll give a +1 to these to previous suggestions:
@hhzhao2016 's suggestion for a log file. My InvisaGig just restarted. I don’t know why.
@jgyoblonski 's suggestion to allow ssh (not Tailscale, but actually sshing in instead of using the web interface)
@cybrnook 's suggestion to allow the status LEDs to be disabled
My thoughts:
Howdy and thank you for the feedback!
Regarding reboot log file, unless there is some mains power removal, the device will not reboot itself unless WatchDog is enabled. In the event of WatchDog restart the restart intervention with timestamps are fully visible in the Action Log (Main Menu > WatchDog & Scheduled Reboot > Connection WatchDog > Action Log):
SSH access will not be possible at this time but we will take it under advisement for consideration in the future
LED disablement is definitely on our list for future hardware iterations.
Uptime is already available on the Modem Info page:
All current settings are shown under Modem Info. Please let us know if there is a setting you are looking for that isn’t already shown here:
As you’ve noted, when WatchDog is not enabled it will not show an enabled interval at the Connection WatchDog menu. It will also not be present on the Modem Info screen. Thank you for the suggestion of an explicit disablement message; we will consider this
WatchDog is enabled in only two cases, if a user enables it explicitly themselves or if Tower Locking is active. If a user loads a User Profile that included a Tower Lock or explicit enablement of WatchDog this would re-enable it as well. Carrier Profile selection does not enable or disable WatchDog.
InvisaGig ‘profile’ concept is based on User Profiles (vs. SIM ICCID) which includes the complete collection of user settings currently active. While an ‘automatic’ IMEI repair would not be possible without running afoul of the cellular carriers, a user can insert a SIM, complete any settings customizations, then save everything to a new named User Profile. This can be done for each desired carrier SIM ad infinitum and the user can then easily swap SIMs loading any one of their saved User Profiles as needed. In future dual SIM hardware releases, the User Profiles functionality will be further leveraged per SIM slot for Automatic Failover between SIMs as well if the user wishes to enable this
Can you share some reasoning behind the suggestion of not sharing any information in the user interface prior to logging in? Is there some additional information you would wish to see protected? From a support and user convenience perspective we have received a great deal of user feedback that reflects a need for basic information that is not uniquely identifiable to be available prior to login (ex. a device is unplugged frequently during remote installation placement and users value the Live Signal outputs without the delay of entering a credential). If there is some reasoning here for restricting all info behind a login, we would like to understand this before considering making such a change here
First, I’m absolutely delighted not just by the speed of your reply, but that you addressed each of my points with such depth. Show me a single other provider in the cellular space that does this!
As for my reasoning for locking down the UI further, that’s simple: if this is used in a business environment, we may not want users to see anything, specially where there are building who may use the cellular network or when the main line is down at HQ. None of their business what the signal strength is, what carrier is being used, the last bits of IMEI/number/SIM ID etc.
An alternative would be us restricting access altogether to the console using the firewall that sits behind it. But what about those organizations using InvisaGig who don’t have the technical expertise to do that? Those are exactly the type that could fall for what I’ll describe below:
“Who cares” you might ask, “if someone sees the limited information that’s displayed without logging in?” Well, I’m of the opinion that the less information we give out, the lower the risk of successful social engineering…
Picture this - “TMobile calls in to HQ. This is Tim from TMobile. I know you use us for backup internet. We’re getting very strange traffic from your modem.” The receptionist transfers to IT. TMobile continues “I see an IMEI ending in 1234 and a SIM ID ending in 7890.”
Rat, that’s us thinks the low level IT person. The Tmobile guy continues, “Before we continue, I need to do account verification. Please provide your account number and PIN.”
The IT guy should be suspicious, but the TMobile rep knows the IMEI and sim ID.
It wouldn’t be terribly hard for someone to call into TMobile with the right information and have the line suspended. If I were doing a red team operation, first I’d work to see what kind of connectivity there is. It’s often not that hard to get into a building’s closet where cable or fiber comes in. We plant something to disable that on a timer. But there’s cellular backup, which we know about because we tested when on their guest network.
And once you’re in an account at a cellular provider, it’s not that hard to order phones and services, (a bit harder) to do sim swaps, or be otherwise malicious.
Thank you very much for the kind words and detailed explanation. We will take this under advisement for consideration in future releases
