I am not sure how you determined the TYCON TPDIN had ip address 92.168.0.243.
A quick google search for add secondary ip address linux on interface with dhcp client found this serverfault post Set up two IPs (one using DHCP and other static) over the same Interface On the other hand, it the Raspberry Pi is getting its ip address via dhcp, then it will be more invoved. If the Raspberry Pi has a static ip address, adding a secondary address should be straight forward.
#Gftp time out download#
Is this the device you are talking about? Edit: The first time I tried to download the userguide I got a dns failure, but after I downloaded the spec sheet, and after I posted this the first time, I was able to download the user guide and it does claim to support telnet. The spec sheets for the TYCON TPDIN only talk about Web and SNMP, no ssh or even telnet, adding a secondary address to the RB960PGS is going to be of limited value. If you are worried about breaking stuff on the RB960PGS and you have a Raspberry Pi in the LAN with the TYCON TPDIN, I would focus on the Raspberry Pi. Have any of you heard of any exploits going on for that subset of hardware?Įdit: After posting this, I saw that problem was solved in the mean time. One thing in common between the two devices - they are all running very basic Web servers to display settings and use SoC devices like the Microchip PIC18F97J60: Why change the Gateway and DNS address as well? Just changing the IP would have been enough. The changes that were made are so consistent they almost seem automated.if someone found their way in to those devices and wanted to mess with me, I would have thought they would do something more drastic.
#Gftp time out password#
I will readily admit I didn't have password protection on the TPDIN and didn't disallow network setting changes on the charge controller.
Having this happen multiple times is weird. I fixed that by connecting to the CC locally with a USB to RS-232 cable which does not care about IP's. The very same thing occurred in August to a solar charge controller - the 192.168.0.x entries for IP, Gateway, and DNS 1 and 2 were all truncated to 92.168.0.x. Now, I need to figure out what happened as this is not the first time. Was then able to reconfigure the remote TPDIN. And was successfully able to access the TPDIN.Īfter proving that it didn't take out anything (especially WAN access to the router), I plugged that rule into the remote 960.
#Gftp time out upgrade#
I have a spare TPDIN I had brought back from the remote site to upgrade firmware here with me, so to try things locally, I set it to 92.168.0.243, then added the above to the mAP I am using here. Thanks for any help you might offer.Īll I needed to do was add this entry to IP>Addresses:ģ address=92.168.0.254/24 network=92.168.0.0 interface=bridge1
I have a Raspberry Pi inside the network with VNC access for working on this. The network is 400 miles away and whatever I try must NOT break things with the 960. If I reboot the router and then check the log, I can see the router find the incorrect address during the reboot. My question is: is there any way to access this "new" address remotely since it falls outside of the 192.168.0.x range I am using? It doesn't ping. Using the various tools in the 960, I found that the static IP for the TPDIN has lost the first digit of the first octet of it's IP address. Recently, one of the TYCON TPDIN remote voltmeters (original version) I use to monitor legacy solar systems that don't have their own remote monitoring became inaccessible. There are several wireless clients and a bunch of IP cameras and remote solar system monitors on its LAN side. I have a small remote network using a RB960PGS as core router.
0 kommentar(er)
