Remote Debugging

I am working on a test fixture that uses an RS-232 port for control. I tra vel a lot and don't want to have to drag the test fixture around with me.

Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from anot her room. That worked pretty well. I didn't have a means of rebooting the target however. This time I will add a capability of removing power from the test fixture to provide a reset.

What I didn't try before was using this rig over the Internet. I'm not eve n sure where to being digging into how to do that. I expect it is not comp licated to make the serial port accessible through the router and modem, bu t 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 source s I've found address the issue of getting through the router, etc.

Essentially I want the serial port on the rPi to become a virtual serial po rt on a PC located anywhere else on the planet. :)

Rick C.

Reply to
gnuarm.deletethisbit
Loading thread data ...

  1. Enable SSH on the Pi
  2. Disable password authentication and copy an SSH key from whatever machine you want to connect from
  3. Set up your router to port-forward port 22 to the Pi port 22
3a. (Optional) Set up dynamic DNS using someprovider, if your ISP doesn't offer a static IP
  1. SSH from your laptop on the internet (or whatever) to your router
  2. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a terminal
  3. Configure the Pi for automatic software updates, so it's kept up to date with security patches

Theo

Reply to
Theo

travel a lot and don't want to have to drag the test fixture around with m e.

an rPi (Raspberry Pi) to put the serial port on the network and work from another room. That worked pretty well. I didn't have a means of rebooting the target however. This time I will add a capability of removing power f rom the test fixture to provide a reset.

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

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

ine

te

Thanks. From what you've written here the modem is agnostic to this proces s? It's only the router I need to worry about?

Rick C.

Reply to
gnuarm.deletethisbit

Yes - it doesn't matter whether you're on DSL, cable, whatever. Just that your ISP gives you a public IP address (ie not behind some kind of firewall that blocks inbound connections).

By forwarding a port, you're exposing an internal device. You need to secure it, otherwise you'll expose the rest of your internal network to someone who manages to compromise your Pi (hence using automatic updates and SSH keys rather than passwords is good practice).

Theo

Reply to
Theo

not a good idea to open port 22 to the outside world. It's better to use another port (at least for the WAN). And maybe install fail2ban.

Bye Jack

Reply to
Jack

ssh is certainly a solid way to handle this - as long as the user has a ssh client on their machine, and is comfortable with it (I have no idea of Rick's experiences here). For Windows, msys2 command-line ssh is my choice, but putty is good for those that prefer a gui.

ssh keys make things faster and easier - but not more secure, if there is a risk of theft of the client laptop. (Again, I don't know the OP's security needs.)

Password authentication is fine if the passwords are good, though usually you don't want to allow direct root login via ssh with a password. Password login is an excellent back-stop for when you are in the middle of nowhere and your laptop dies - it will let you get things working on a new laptop without having to go back to the office first.

No. Set it up from a wildly different port. An open port 22 is an invite to drive-by script kiddies, and you will get regular probes. They won't break in (since they don't have your keys and can't guess your passwords), but they are a nuisance and a waste of bandwidth, and /if/ there are bugs in sshd or the kernel, this hugely increases the risk. Use a high, unrelated port number on the outside connection - forward port 54321 to port 22 on the Pi. Then the will be no script attacks.

Yes.

Yes.

Or "screen /dev/ttyUSB0 115200", which would be my choice here. Or run any other serial port program locally on the Pi.

An alternative would be to use a serial port to network proxy (like socat, which I have not tried myself), and access it over the ssh link. That would require doing a port forward over the ssh tunnel, but that is quite easy. The best choice depends on the OP's needs.

Madness.

Automatic software updates are for ignorant Windows admins who want to be able to say "it's not /my/ fault there was a problem". The risk of security problems that would be a problem for such a system (especially on a non-standard port) is absolutely tiny. The risk of the OP being specifically targeted is tiny (it's for debugging a card, not for running a bank). The benefits of getting an update fast, rather than when it is convenient, are tiny. These all multiply to utterly negligible. On the other hand, the risk of complications, breakage, or simply interrupt what you are doing by the automatic updates is very real.

Another possibility to consider as a way of accessing your office devices while you are away, is a VPN. This is particularly useful if you need to access multiple systems and not just the one board. I strongly recommend OpenVPN here, and I recommend running it over TCP/IP rather than the standard UDP. It is not the most efficient VPN (especially with TCP/IP), but the client can easily traverse almost any firewall, NAT router, etc., unlike lower-level VPN's.

Reply to
David Brown

Maybe not none, but there will be far fewer attacks. My ssh servers running on non-standard ports still see SSH login attempts from attackers.

--
Grant Edwards               grant.b.edwards        Yow! FUN is never having to 
                                  at               say you're SUSHI!! 
 Click to see the full signature
Reply to
Grant Edwards

If you have a set of stuff on the Pi, dedicated for the test, that should be refreshed, then just create a git repo somewhere with the test code, and let the Pi do a "git pull --rebase" periodically. The Pi should only have read access to the repo.

AP

Reply to
A.P.Richelieu

If the test program(s) are running on the Pi, then you need some way to get them onto the Pi and to keep them updated with any changes. git is one way to share a set of source files. But there is nothing special about it - the OP should use whatever makes sense to him and whatever suits his current practices.

One thing for sure is that automatic rebases are probably a very bad idea - just like any other automatic updates. Connect to the Pi with ssh, and do an update when you are ready to test the new software - not before.

One thing I didn't mention earlier - when running programs via ssh on a setup like this, run them within "screen" (or "tmux") on the Pi. Then the terminals and programs stay alive even if you disconnect the ssh and connect again later.

That is an arbitrary restriction which may not be appropriate. (It doesn't even make much sense - /users/ have access to a repo, not /computers/.) If the OP is happy fiddling with the software using nano over ssh, then he should be able to check in changes - there is no reason to force a specific direction to the development process.

Reply to
David Brown

Not really, if you give write access, it will be possible for anyone that can break into the Pi to get write access to your repo. Breaking in, consists of removing the SD-Card and mounting it in your laptop, after which you can copy the ssh private key. Not a good idea.

The important part of git is that this is something that the Pi starts, not something that is pushed into the Pi.

It is certainly a good idea to update the Pi automatically with the latest test suite. If you find you have a problem, you can easily revert to an older commit. Obviously you should be able to disable the automatic update, if for some reason you do not like to use the latest version.

AP

Reply to
A.P.Richelieu

First, you don't have to store ssh keys to make git work. You can put in the password manually, without storing it.

Secondly, you can have more than one account - storing a user on the Pi with ssh keys that has write access to relevant repository, does not mean using the users main ssh keys. They can be used solely for this purpose.

Third, the aim is to keep the Pi secure despite being accessible from the net. No security is ever perfect, but people hacking in over the net should be a very low risk problem.

Fourth, if someone is physically breaking into the guy's office, then it is extremely unlikely that they will be interested in stealing the SD-Card from the Pi in order to copy the ssh keys. And this is unlikely to reach high on the OP's list of concerns if he has had a physical break-in.

Fifthly, if the git master is set up correctly and you are using appropriate keys, then all the ssh key thief can do is commit to that one repository of test code. That is not going to be a big issue - and all changes are tracked, logged, and reversible.

Sixth, if you think it is not possible to set up git to give safe and reliable write access like this, then you should not be recommending git for the job.

No. The Pi does not start anything.

The user, logged into the Pi by ssh, starts the update or pull. And that same user can edit files directly on the Pi, and should be able to commit and push the changes.

Nonsense. It is a good idea to know exactly what you are running on the test system, and update it when it is time to update it, not based on some periodic pulls.

Yes, that's easy - if you are in control of your updates and haven't set an automatic job for it.

You have it ass-backwards.

Reply to
David Brown

Which is totally unneccessary, if you only give read access.

Not really.

That is unneccessary trouble.

I am recommending read only git, and you say that git is useless, if you do not have write access from all over the world. I beg to disagree.

The proper procedure is to have a test setup in your office where the Pi has write access. In this setup, you test and verify that it works. Only after testing there, is the test system released.

Pi's at remote locations should not have write access. All experiments should be done on the local system. If need to, a remote system could be made to use a dedicated branch.

The update is started by running code on the Pi.

The used should commit and push the stuff in a controlled environment, not in a customer system.

Automatic, does not neccessarily mean that there is a periodic pull. It might do the pull every time you reset the target.

You are in control of the main repo. Noone will pull in something, which is not part of that repo.

No I don't.

AP

Reply to
A.P.Richelieu

Yes - assuming that you don't mind hackers getting read access to your files (if you are realistically worried about hackers), and you don't mind the limitations of being read-only.

Personally, I would find read-only access too limiting.

If is a realistic issue, then the OP should drop the whole idea.

If you don't let in the hackers in the first place, there is no problem

- and this gives you a plan B if you need it.

That is not what I said. I said that if git won't do an appropriate job here, which I expect will include write access in a secure manner, then it is not the right tool for this job. That does not make git useless - it would make it a poor choice here. (git /can/ give you write access in a secure way here, so it could be a good choice.)

Of course, the question of git or alternative ways to share files is totally irrelevant to what the OP has been asking about.

I believe I may have found the source of your confusion. The Pi is staying put - it is the developer who is moving around.

That code is run by the user, when /they/ decide to run it.

You are misunderstanding the setup.

Also, customer systems may be a controlled environment - at least, controlled enough for that purpose.

True. But my answer is unchanged.

Well, we must leave it to the OP to decide what he wants to do.

I am sure that if we were in the same room, discussing plans for a real setup, we'd be much closer to agreement - I think we are making different kinds of assumptions about the OP's situation here.

Reply to
David Brown

ravel a lot and don't want to have to drag the test fixture around with me.

n rPi (Raspberry Pi) to put the serial port on the network and work from an other room. That worked pretty well. I didn't have a means of rebooting t he target however. This time I will add a capability of removing power fro m the test fixture to provide a reset.

ven sure where to being digging into how to do that. I expect it is not co mplicated to make the serial port accessible through the router and modem, 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 sour ces I've found address the issue of getting through the router, etc.

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

Just to make things more clear...

Conventional Use of Test Fixture

+---------+ +--------+ | +-----+ | | | | | UUT | | | PC | | +-----+ | RS-232 | | | Test || Cntl | | Fixture | | Prog | +---------+ +--------+

Desired use of Test Fixture

+---------+ +--------+ | +-----+ | | | /-----\ | | UUT | | | rPi | ( ) | +-----+ | RS-232 | | ( Inter ) | Test || |( net ) | Fixture | | | ( ) +---------+ +--------+ \-----/ +--------+ | | /-----\ | PC | ( ) | | ( Inter ) | Cntl |( net ) | Prog | ( ) +--------+ \-----/

I hope this clears up any confusion.

Rick C.

Reply to
gnuarm.deletethisbit

This clears up a few points. But there are some questions that could make this easier.

  1. Is the PC running Windows or Linux?

  1. Are you reasonably confident about Linux, ssh, etc.?

  2. Does the control program have to run on the PC, or can it run on the Pi?

  1. Do you have source for the control program, and can you modify it to use a TCP/IP port instead of a serial port?

Reply to
David Brown

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

d an rPi (Raspberry Pi) to put the serial port on the network and work from another room. That worked pretty well. I didn't have a means of rebootin g the target however. This time I will add a capability of removing power from the test fixture to provide a reset.

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

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

i?

I have done this before from my Windows PC through my home network, the rPi to the target board. I don't think I mentioned I used SSH if I remember c orrectly. I most likely used Putty or a derivative on the PC. I had a bun ch of trouble finding something on the rPi that would work correctly. Some of the issues were the differences in line endings I think, but there was something else that I don't recall. So I'll likely have to research that p ath again.

I was running Forth on the target. This time the target is a command line reader in the FPGA with a syntax that is analogous to the hardware interfac e to the UUT, data, address, one letter command all separated by spaces ala Forth. When the target sees the command letter it replies with the data, address, command and a numeric response. If the command is a write or read it is the data of interest. If the command is a "select" command (chooses the test fixture or one of two UUTs as the point of communications) the re sponse is the unit selected. Every command other than the select command i s reading or writing a register in the selected target. I guess that's mor e info than you need, but there it is.

The connection over the lan was made by getting the router to assign fixed IP addresses to the devices. That actually never worked well. I could tel l the router to use "these" assignments and tried to set that up in multipl e locations where I used this, but sometimes it would do that, other times it would assign other addresses.

Rick C.

Reply to
gnuarm.deletethisbit

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

d an rPi (Raspberry Pi) to put the serial port on the network and work from another room. That worked pretty well. I didn't have a means of rebootin g the target however. This time I will add a capability of removing power from the test fixture to provide a reset.

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

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

i?

Sorry, my other post didn't address all of your questions.

1) Windows 10 now. Most likely it was Win Vista or Win 8 before. 2) If you mean using Linux, I'm not afraid to learn. But Linux is not easy to learn because there are so many assumptions of existing knowledge. I'v e 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 longer I can put off working on the actual test code. The only difference is invol ving the Internet vs. the local network. 3) The control program can possibly run on the rPi, but it would require so me 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 copyi ng them into the Windows paste buffer for the user to copy into a spread sh eet. Everyone using this program is very happy with it, so little interest in changing our methods. Remember, what I am doing now is just so I can d o further development in a flexible work environment. 4) Yes, I wrote the control program, but I have no interest in modifying it for this purpose. I shouldn't need to I am pretty sure.
Reply to
gnuarm.deletethisbit

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. :)

Pi?

sy 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 no t interested in becoming a guru. I did the remote thing before and I am su re I can do it again. Besides, the more I putz with this issue, the longer I can put off working on the actual test code. The only difference is inv olving the Internet vs. the local network.

RPi runs a version of Linux. So, you don't have a choose. You are working with Linux anyway. Basically, you ssh into the rPi and minicom/screen/etc to your test fixture.

Reply to
edward.ming.lee

Of course I have a choice. The rPi is there to connect the target serial port to the network. There is nothing that says I have to use an rPi. Or even if I use an rPi there is nothing that says I have to run Linux.

Given the tremendous knowledge pool with Linux on the rPi, I expect Linux will be the path of least resistance.

Rick C.

Reply to
gnuarm.deletethisbit

There exist USB controlled power strips. The ones I used had a crude C api. The goal there was to automate finding a bootup bug.

Every time I have done this, I write a custom TCP server in Tcl and use that to drive the serial port. I've had entire simulations of some fairly complex plant done in this way. A RasPi can have a great many peripherals. I used a Komodo CAN tester-device with an API to build an engine/transmission simulator more than once. The API is fairly awful but it worked out.

The Brent Welch book has a good deal of detail on how to do this. ISBN-13: 978-0130385604

How you get a route to the device is a seperate problem - you'll have to negotiate with your service provider.

--
Les Cargill
Reply to
Les Cargill

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.