Remote Debugging

The main issues here are bypassing your home firewall and the possible lack of a static IP address on your home internet.

The approach I would suggest is

1) rent a virtual private server (VPS) with a static IP address: this starts around $15 a year for a dedicated address and I can email you some recommendations if you want. 2) set up a reverse ssh proxy on your raspberry pi, to connect an inbound port on the VPS to the login port on the raspberry pi. See here for how to do this:
formatting link
But you want to forward to port 22 instead of 3) You will need to set up systemd or some other supervision system on the rpi to restart the proxy in case of a reboot (power interruption at home while you are travelling etc.) What OS distro are you running on the Pi (Raspian?) I don't know the exact command for this offhand but someone else here might, or I can research it a little.
  1. You probably want to assign a domain or subdomain name to the VPS. So you'll run something like

ssh snipped-for-privacy@yourdomain.com:1234

if the proxy port is 1234. That will then forward to port 22 on your pi, and you can login to the pi normally and run something like minicom or whatever other serial comm program you like.

Set your home firewall to block incoming connections (your tunnel works over an outbound one from the pi) and use public key authentication (if you can) or strong passwords (if you have to) on both of the ssh ports. You WILL get bad guys trying to connect to the ports and brute force the password. Using the nonstandard port (1234 or whatever; "standard"=22) will help with this but be careful anyway.

The other approach of simply opening the pi's port 22 to incoming connections works in principle, but you need a static address, and it's generally safer to firewall off incoming connections completely rather than open a way for someone to take over your internal home network (especially scary if you have windows machines etc. on it).

Reply to
Paul Rubin
Loading thread data ...

OK, so it is putty or msys2 ssh for the ssh client (depending on your preferences). If you want to go for the OpenVPN route, that will work too.

Once you have the port forward in place, there should be little difference between local net and internet. If you are using a TCP/IP port between the client and the Pi, you can use ssh port forwarding to pass that over the ssh link securely.

Learning Linux does not have assumptions of existing knowledge, and it is not particularly hard to learn. The people who have most difficulty with it are usually Windows gurus - many of their assumptions, and much of their expertise, becomes wrong in the Linux world. For people just using programs on Linux, it is easy - my 75 year old mother in law uses it, and my kids have used it since they were old enough for TuxPaint. Some things are easier in the Windows world, and some things are easier in the Linux world - I need both for my work. But when I have the choice, it's Linux all the way - it is just so much more efficient and flexible for most of what I do. (I am not saying you need to "learn Linux" or switch to Linux - merely that you should not be afraid of it. And listen to this random guy off the internet, not the people who told you to avoid it.)

OK. There is probably a dozen ways to make a system that works as well or better for users, without requiring anything in particular on the client machine (i.e., any authorised user can do it from their own system). But all of them require work, and changing the software setup significantly. When you want to make "version 2" of the system, post again for more advice.

If you had it all working locally on the net before, you should not need to change things to get it working over the internet. The only visible difference would be in the timings - you get longer latencies over the internet.

Reply to
David Brown

I'm a late comer to this discussion ...

I'm running a Rpi with one RS-232 USB dongle and one OpenOCD JTAG dongle connected. I connect to the Rpi with SSH and use the RS-232 and JTAG connections like I were directly on the Rpi.

It seems that you're having a problem to access the Rpi via the Net. There are at least two ways to do it:

- have the Pi in a local network which is accessible via VPN,

- have a publicly visible IP address on the Pi and access it directly.

Anyway, you do need an IP address publicly visible to your PC. My solution to this is DynDNS, as most of the DHCP client networks are still accessible from the outside, if the IP address is known, although the address is not fixed.

Both access solutions have security implications, as the badly behaving members of the Net will attack it within half an hour after connecting. The VPN solution is better walled off from the wild part of the Net.

--

-TV
Reply to
Tauno Voipio

I travel a lot and don't want to have to drag the test fixture around wit h me.

sed an rPi (Raspberry Pi) to put the serial port on the network and work fr om another room. That worked pretty well. I didn't have a means of reboot ing the target however. This time I will add a capability of removing powe r from the test fixture to provide a reset.

not even sure where to being digging into how to do that. I expect it is n ot complicated to make the serial port accessible through the router and mo dem, but I'm not sure where to begin. Or does the router even get involved and is just transparent and I only need the local IP address? None of the sources I've found address the issue of getting through the router, etc.

rial port on a PC located anywhere else on the planet. :)

e Pi?

o

o.

easy to learn because there are so many assumptions of existing knowledge. I've actually had people tell me I shouldn't be working with Linux if I'm not interested in becoming a guru. I did the remote thing before and I am sure I can do it again. Besides, the more I putz with this issue, the long er I can put off working on the actual test code. The only difference is i nvolving the Internet vs. the local network.

e some Windows specific code to be modified and this version would only be for my development. This is a test fixture that provides test results by c opying them into the Windows paste buffer for the user to copy into a sprea d sheet. Everyone using this program is very happy with it, so little inte rest in changing our methods. Remember, what I am doing now is just so I c an do further development in a flexible work environment.

g it for this purpose. I shouldn't need to I am pretty sure.

I'm not sure you read everything I write or maybe you forgot what I wrote e arlier. I know I have that trouble in some threads. Or maybe I'm not foll owing what you are saying. It sounds like you think the rPi will be used b y users.

When the test fixture is used, a serial port directly connects the test fix ture to the PC running the test program. This is needed because the user h as to plug and unplug UUTs to/from the text fixture. There is no rPi and t here is no need for access via the Internet or even a local network.

The need for Internet access via an rPi is purely because I want to do sign ificant development work on the test fixture control program but don't want to lug a test fixture around with me while I travel, which is pretty much all the time these days.

I had a different target controlled via serial port set up so I could use t he rPi to provide remote access to the serial port from a Windows PC via Pu tty over my local network only.

The differences between these two systems are that I need to account for ge tting through the router/modem and instead of using Putty which knows about IP addresses and SSH, my control program only knows about serial ports. S o this system needs to emulate a serial port on the Windows PC.

There may be enough info in this thread to make this work, but I'm not sure since I do have the test fixture with me, but not the rPi. I should be ab le to work on this a bit later this week.

Thanks,

Rick C.

Reply to
gnuarm.deletethisbit

I was extrapolating from your description of using the test program (running on Windows, but getting data from the test system via the Pi) and the user copying the data into a spreadsheet. You haven't said anything about who the "user" might be here, so maybe I have made unwarranted assumptions.

Ah, so this is just for you to be able to do development work on the test fixture even when you are not at the office? I think I am getting a clearer picture now.

If you have a port forward from your internet connection to the Pi, and the internet connection has a fixed global IP address, then the setup should work the same as now. Instead of connecting to , and set up port forwarding on the modem from external port 54321 to the Pi's IP and port 22.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.