Forums

远程调试

开始于 未知 2019年2月26日
gnuarm.deletethisbit@gmail.com writes:
> Essentially I want the serial port on the rPi to become a virtual > serial port on a PC located anywhere else on the planet. :)
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: //serverfault.com/a/227268 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. 4. You probably want to assign a domain or subdomain name to the VPS. So you'll run something like ssh yourproxy@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).
On 28/02/2019 02:49, gnuarm.deletethisbit@gmail.com wrote:
> On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote: >> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote: >>> On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote: >>>> I am working on a test fixture that uses an RS-232 port for control. I travel 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 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 from the test fixture to provide a reset. >>>> >>>> What I didn't try before was using this rig over the Internet. I'm not 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 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. >>>> >>>> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet. :) >>>> >>>> Rick C. >>> >>> 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. >>> >> >> This clears up a few points. But there are some questions that could >> make this easier. >> >> 1. Is the PC running Windows or Linux? >> >> 2. Are you reasonably confident about Linux, ssh, etc.? >> >> 3. Does the control program have to run on the PC, or can it run on the Pi? >> >> 4. Do you have source for the control program, and can you modify it to >> use a TCP/IP port instead of a serial port? > > > 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.
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.
> > 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'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 longer I can put off working on the actual test code. The only difference is involving the Internet vs. the local network. >
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.)
> 3) The control program can possibly run on the rPi, but it would require 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 copying them into the Windows paste buffer for the user to copy into a spread sheet. 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 do further development in a flexible work environment. >
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.
> 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. >
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.
On 28.2.19 04:08, gnuarm.deletethisbit@gmail.com wrote:
> On Wednesday, February 27, 2019 at 8:00:25 PM UTC-6, edward....@gmail.com wrote: >> >> 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. > > 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. >
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
On Thursday, February 28, 2019 at 2:09:25 AM UTC-6, David Brown wrote:
> On 28/02/2019 02:49, gnuarm.deletethisbit@gmail.com wrote: > > On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote: > >> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote: > >>> On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote: > >>>> I am working on a test fixture that uses an RS-232 port for control. I travel 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 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 from the test fixture to provide a reset. > >>>> > >>>> What I didn't try before was using this rig over the Internet. I'm not 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 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. > >>>> > >>>> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet. :) > >>>> > >>>> Rick C. > >>> > >>> 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. > >>> > >> > >> This clears up a few points. But there are some questions that could > >> make this easier. > >> > >> 1. Is the PC running Windows or Linux? > >> > >> 2. Are you reasonably confident about Linux, ssh, etc.? > >> > >> 3. Does the control program have to run on the PC, or can it run on the Pi? > >> > >> 4. Do you have source for the control program, and can you modify it to > >> use a TCP/IP port instead of a serial port? > > > > > > 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. > > 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. > > > > > 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'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 longer I can put off working on the actual test code. The only difference is involving the Internet vs. the local network. > > > > 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.) > > > 3) The control program can possibly run on the rPi, but it would require 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 copying them into the Windows paste buffer for the user to copy into a spread sheet. 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 do further development in a flexible work environment. > > > > 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. > > > 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. > > > > 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.
I'm not sure you read everything I write or maybe you forgot what I wrote earlier. I know I have that trouble in some threads. Or maybe I'm not following what you are saying. It sounds like you think the rPi will be used by users. When the test fixture is used, a serial port directly connects the test fixture to the PC running the test program. This is needed because the user has to plug and unplug UUTs to/from the text fixture. There is no rPi and there 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 significant 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 the rPi to provide remote access to the serial port from a Windows PC via Putty over my local network only. The differences between these two systems are that I need to account for getting through the router/modem and instead of using Putty which knows about IP addresses and SSH, my control program only knows about serial ports. So 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 able to work on this a bit later this week. Thanks, Rick C.
On 01/03/2019 00:27, gnuarm.deletethisbit@gmail.com wrote:
> On Thursday, February 28, 2019 at 2:09:25 AM UTC-6, David Brown > wrote: >> On 28/02/2019 02:49, gnuarm.deletethisbit@gmail.com wrote: >>> On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown >>> wrote: >>>> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote: >>>>> On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, >>>>> gnuarm.del...@gmail.com wrote: >>>>>> I am working on a test fixture that uses an RS-232 port for >>>>>> control. I travel 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 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 from the test fixture to provide a reset. >>>>>> >>>>>> What I didn't try before was using this rig over the >>>>>> Internet. I'm not 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 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. >>>>>> >>>>>> Essentially I want the serial port on the rPi to become a >>>>>> virtual serial port on a PC located anywhere else on the >>>>>> planet. :) >>>>>> >>>>>> Rick C. >>>>> >>>>> 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. >>>>> >>>> >>>> This clears up a few points. But there are some questions that >>>> could make this easier. >>>> >>>> 1. Is the PC running Windows or Linux? >>>> >>>> 2. Are you reasonably confident about Linux, ssh, etc.? >>>> >>>> 3. Does the control program have to run on the PC, or can it >>>> run on the Pi? >>>> >>>> 4. Do you have source for the control program, and can you >>>> modify it to use a TCP/IP port instead of a serial port? >>> >>> >>> 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. >>> >> >> 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. >> >>> >>> 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'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 longer I can put >>> off working on the actual test code. The only difference is >>> involving the Internet vs. the local network. >>> >> >> 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.) >> >>> 3) The control program can possibly run on the rPi, but it would >>> require 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 copying them into the Windows paste >>> buffer for the user to copy into a spread sheet. 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 do further development in a flexible work environment. >>> >> >> 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. >> >>> 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. >>> >> >> 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. > > I'm not sure you read everything I write or maybe you forgot what I > wrote earlier. I know I have that trouble in some threads. Or maybe > I'm not following what you are saying. It sounds like you think the > rPi will be used by users.
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.
> > When the test fixture is used, a serial port directly connects the > test fixture to the PC running the test program. This is needed > because the user has to plug and unplug UUTs to/from the text > fixture. There is no rPi and there 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 significant 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.
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.
> > I had a different target controlled via serial port set up so I could > use the rPi to provide remote access to the serial port from a > Windows PC via Putty over my local network only. > > The differences between these two systems are that I need to account > for getting through the router/modem and instead of using Putty which > knows about IP addresses and SSH, my control program only knows about > serial ports. So 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 able to work on this a bit later this week. >
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 <Pi's IP><port 22> you connect to <Modem's IP><port 54321>, and set up port forwarding on the modem from external port 54321 to the Pi's IP and port 22.