Closed snowzach closed 2 months ago
snowzach
commented
2 months ago Ugh... have you ever bricked your modem? I made some change to /etc/passwd and /etc/shadow and rebooted... and now it seems dead.. There's no USB at all or ethernet.. It might be coincidence and it just died... but I dunno... I read somewhere you can recover with fastboot but I'd rather not take the cover off if it's likely just dead and maybe I can return it.
iamromulan
commented
2 months ago Ugh... have you ever bricked your modem? I made some change to /etc/passwd and /etc/shadow and rebooted... and now it seems dead.. There's no USB at all or ethernet.. It might be coincidence and it just died... but I dunno... I read somewhere you can recover with fastboot but I'd rather not take the cover off if it's likely just dead and maybe I can return it.
Yes! You can absolutely recover it! I intend to post that info in the guide eventually but I wrote it up here https://whrl.pl/RgHC1H
I try not to modify too much in the rootfs Here's how it works. The default login binary at /bin/login is a actually a sym link to /bin/login.shadow (a binary that's compiled to include the Shadow file as part of it by Quectel. It has its own custom login process where it displays a code you are supposed to provide to Quectel to get the root password) We bypass this by installing shadow-login and shadow-passwd from entware (to /opt/bin/login and /opt/bin/passwd) Those binaries use the passwd and shadow files in /opt/etc So we copy the existing ones in /etc there and we have a separate login system for us while preserving the original login.shadow binary.
/opt is actually mounted from /usrdata/opt
Keep an eye on the order at which partitions are mounted. If /usrdata isn't mounted yet and there's a redirected dependency that exists there then the boot process will probably stall.
iamromulan
commented
2 months ago Ugh... have you ever bricked your modem? I made some change to /etc/passwd and /etc/shadow and rebooted... and now it seems dead.. There's no USB at all or ethernet.. It might be coincidence and it just died... but I dunno... I read somewhere you can recover with fastboot but I'd rather not take the cover off if it's likely just dead and maybe I can return it.
Also, did you see my comment about the multi-SAN cert? If we can regenerate the certs at boot/when a the potential systemd processes for this is triggered: define 5 different possible hosts from info gathered from various places it would maximize accessibility. Since we can change the gateway address and domain name and on top of that Tailscale's own IP +2 different domains that can potentially access it I was hoping we could have a cert that covers everything the toolkit supports. I can look into this further when I have a moment as well. 😁
snowzach
commented
2 months ago Ahh perfect.. I was wondering if one of those pins would reset it...
Yeah, I saw your comment about it.. I can look at doing that tonight.. Here's the thing though, it's a self-signed cert.. It doesn't really matter what you put into it as it's never going to be valid. It's always going to give you that warning in the browser but will still be reachable from anywhere. (Unless tailscale somehow treats it differently but I kinda doubt it)
iamromulan
commented
2 months ago Ahh perfect.. I was wondering if one of those pins would reset it...
Yeah, I saw your comment about it.. I can look at doing that tonight.. Here's the thing though, it's a self-signed cert.. It doesn't really matter what you put into it as it's never going to be valid. It's always going to give you that warning in the browser but will still be reachable from anywhere. (Unless tailscale somehow treats it differently but I kinda doubt it)
Ah gotcha. I haven't messed with SSL much at all so I wasn't too sure. I was hoping to avoid the full screen warning but still take advantage of the encryption features for data transmission. I was thinking that I may confuse some users. I know certain routers (Asus, Gl.inet, Netgear, etc.) don't have that full screen warning so I thought maybe it would be possible.
iamromulan
commented
2 months ago @snowzach @dr-dolomite These changes seem ready to test. 💯 Please take a look at the additional modifications I have made. Let me know or PR if i missed something or you think something can be improved. -Enware checks are stricter, to account for the different revisions potently already installed -ttyd is now installed with simpleadmin -ttyd update process now occurs as a systemd process in case it is ran from ttyd -Added Console to the navbar, directs to /console which lighttpd should be proxying -Cleaned up a few things in the toolkit to account for all installation/upgrade scenarios. @snowzach Thank you for your work on this!!!
iamromulan
commented
2 months ago Well, after testing it seems I can't access the interface from http://192.168.225.1 https://192.168.225.1 However I can get to it from tailscale The /console yeilds a Tailscale web interface is unavailable message Edit: tailscale web interface listens on 8088 if enabled. Edit: ttyd.service is masked? TTL will not set from simpleadmin
That's about it for me tonight though. Sync with dev and PR if you see where the problem is 😁 Compare with main for a point of reference. @snowzach @dr-dolomite
snowzach
commented
2 months ago I don't remember if it does but I manually configure a 192.168.225.2/30 IP address on my router. In passthrough mode you only may get a 192.0.0.2 address via DHCP. Try accessing 192.0.0.1 instead and see if that works. I can move the ttyd port.
Have you ever run into a problem with band 71 on T-Mobile. It was working great with 71+41+41 and now all of the sudden I can only get 41+41 and 71 never shows up.
iamromulan
commented
2 months ago I got it working :) Other bugs though: https://github.com/iamromulan/quectel-rgmii-toolkit/discussions/30
Replaces httpd with lighttpd
/ttyd