Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28559 > unrolled thread

Remote Debugging

Back to article view | Back to comp.arch.embedded

Contents

  Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-26 13:42 -0800
    Re: Remote Debugging Theo <theom+news@chiark.greenend.org.uk> - 2019-02-26 22:37 +0000
      Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-26 15:39 -0800
        Re: Remote Debugging Theo <theom+news@chiark.greenend.org.uk> - 2019-02-27 01:32 +0000
      Re: Remote Debugging Jack <jack4747@gmail.com> - 2019-02-26 22:49 -0800
      Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 09:08 +0100
        Re: Remote Debugging Grant Edwards <invalid@invalid.invalid> - 2019-02-27 14:49 +0000
        Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 18:45 +0100
          Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 21:25 +0100
            Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 22:12 +0100
              Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 23:00 +0100
                Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 23:28 +0100
                  Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 23:50 +0100
    Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 15:41 -0800
      Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-28 01:23 +0100
        Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 17:41 -0800
        Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 17:49 -0800
          Re: Remote Debugging edward.ming.lee@gmail.com - 2019-02-27 18:00 -0800
            Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 18:08 -0800
              Re: Remote Debugging Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-02-28 11:21 +0200
          Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-28 09:09 +0100
            Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-28 15:27 -0800
              Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-03-01 10:11 +0100
    Re: Remote Debugging Les Cargill <lcargill99@comcast.com> - 2019-02-27 22:07 -0600
    Re: Remote Debugging Paul Rubin <no.email@nospam.invalid> - 2019-02-27 21:35 -0800

Page 1 of 2  [1] 2  Next page →

#28559 — Remote Debugging

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.

[toc] | [next] | [standalone]

#28560

gnuarm.deletethisbit@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.  :) 

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
4. SSH from your laptop on the internet (or whatever) to your router
5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
terminal
6. Configure the Pi for automatic software updates, so it's kept up to date
with security patches

Theo

[toc] | [prev] | [next] | [standalone]

#28561

On Tuesday, February 26, 2019 at 4:37:44 PM UTC-6, Theo wrote:
> gnuarm.deletethisbit@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.  :) 
> 
> 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
> 4. SSH from your laptop on the internet (or whatever) to your router
> 5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
> terminal
> 6. Configure the Pi for automatic software updates, so it's kept up to date
> with security patches
> 
> Theo

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

Rick C.

[toc] | [prev] | [next] | [standalone]

#28562

gnuarm.deletethisbit@gmail.com wrote:
> Thanks.  From what you've written here the modem is agnostic to this process?  It's only the router I need to worry about?  

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

[toc] | [prev] | [next] | [standalone]

#28563

On Tuesday, 26 February 2019 23:37:44 UTC+1, Theo  wrote:

> 3. Set up your router to port-forward port 22 to the Pi port 22

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

[toc] | [prev] | [next] | [standalone]

#28564

On 26/02/2019 23:37, Theo wrote:
> gnuarm.deletethisbit@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.  :) 
> 
> 1. Enable SSH on the Pi

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.

> 2. Disable password authentication and copy an SSH key from whatever machine
> you want to connect from

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.

> 3. Set up your router to port-forward port 22 to the Pi port 22

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.

> 3a. (Optional) Set up dynamic DNS using someprovider, if your ISP
> doesn't offer a static IP

Yes.

> 4. SSH from your laptop on the internet (or whatever) to your router

Yes.

> 5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
> terminal

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.

> 6. Configure the Pi for automatic software updates, so it's kept up to date
> with security patches
> 

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.

[toc] | [prev] | [next] | [standalone]

#28567

On 2019-02-27, David Brown <david.brown@hesbynett.no> wrote:

>> 3. Set up your router to port-forward port 22 to the Pi port 22
>
> 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.

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!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#28568

Den 2019-02-27 kl. 09:08, skrev David Brown:
> On 26/02/2019 23:37, Theo wrote:
>> gnuarm.deletethisbit@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.  :)
>>
>> 1. Enable SSH on the Pi
> 
> 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.
> 
>> 2. Disable password authentication and copy an SSH key from whatever machine
>> you want to connect from
> 
> 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.
> 
>> 3. Set up your router to port-forward port 22 to the Pi port 22
> 
> 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.
> 
>> 3a. (Optional) Set up dynamic DNS using someprovider, if your ISP
>> doesn't offer a static IP
> 
> Yes.
> 
>> 4. SSH from your laptop on the internet (or whatever) to your router
> 
> Yes.
> 
>> 5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
>> terminal
> 
> 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.
> 
>> 6. Configure the Pi for automatic software updates, so it's kept up to date
>> with security patches
>>
> 
> 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.
> 

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

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

[toc] | [prev] | [next] | [standalone]

#28569

On 27/02/2019 18:45, A.P.Richelieu wrote:

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

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.


 > The Pi should only have read access to the repo.
 >

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.

[toc] | [prev] | [next] | [standalone]

#28571

Den 2019-02-27 kl. 21:25, skrev David Brown:
> On 27/02/2019 18:45, A.P.Richelieu wrote:
> 
>> 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.
> 
> 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.
> 
> 
>  > The Pi should only have read access to the repo.
>  >
> 
> 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.

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

[toc] | [prev] | [next] | [standalone]

#28572

On 27/02/2019 22:12, A.P.Richelieu wrote:
> Den 2019-02-27 kl. 21:25, skrev David Brown:
>> On 27/02/2019 18:45, A.P.Richelieu wrote:
>>
>>> 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.
>>
>> 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.
>>
>>
>>  > The Pi should only have read access to the repo.
>>  >
>>
>> 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.
> 
> 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.

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.

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

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.

> It is certainly a good idea to update the Pi automatically
> with the latest test suite.

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.

> If you find you have a problem, you can easily revert to an older commit.

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

> Obviously you should be able to disable the automatic update,
> if for some reason you do not like to use the latest version.
> 

You have it ass-backwards.

[toc] | [prev] | [next] | [standalone]

#28573

Den 2019-02-27 kl. 23:00, skrev David Brown:
> On 27/02/2019 22:12, A.P.Richelieu wrote:
>> Den 2019-02-27 kl. 21:25, skrev David Brown:
>>> On 27/02/2019 18:45, A.P.Richelieu wrote:
>>>
>>>> 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.
>>>
>>> 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.
>>>
>>>
>>>  > The Pi should only have read access to the repo.
>>>  >
>>>
>>> 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.
>>
>> 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.
> 
> First, you don't have to store ssh keys to make git work.  You can put 
> in the password manually, without storing it.

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

> 
> 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.
>
Not really.

> 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.
> 
That is unneccessary trouble.

> 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.
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 important part of git is that this is something that the Pi
>> starts, not something that is pushed into the Pi.
>>
> 
> No.  The Pi does not start anything.

The update is started by running code on the Pi.


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

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

> 
>> It is certainly a good idea to update the Pi automatically
>> with the latest test suite.
> 
> 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.

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



>> If you find you have a problem, you can easily revert to an older commit.
> 
> Yes, that's easy - if you are in control of your updates and haven't set 
> an automatic job for it.
> 
You are in control of the main repo.
Noone will pull in something, which is not part of that repo.

>> Obviously you should be able to disable the automatic update,
>> if for some reason you do not like to use the latest version.
>>
> 
> You have it ass-backwards.
> 
No I don't.

AP

[toc] | [prev] | [next] | [standalone]

#28574

On 27/02/2019 23:28, A.P.Richelieu wrote:
> Den 2019-02-27 kl. 23:00, skrev David Brown:
>> On 27/02/2019 22:12, A.P.Richelieu wrote:
>>> Den 2019-02-27 kl. 21:25, skrev David Brown:
>>>> On 27/02/2019 18:45, A.P.Richelieu wrote:
>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>  > The Pi should only have read access to the repo.
>>>>  >
>>>>
>>>> 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.
>>>
>>> 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.
>>
>> First, you don't have to store ssh keys to make git work.  You can put 
>> in the password manually, without storing it.
> 
> Which is totally unneccessary, if you only give read access.

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.

> 
>>
>> 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.
>>
> Not really.

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

> 
>> 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.
>>
> That is unneccessary trouble.

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.

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

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.

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

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

> All experiments should be done on the local system.
> If need to, a remote system could be made to use a dedicated branch.
> 
> 
>>
>>>
>>> The important part of git is that this is something that the Pi
>>> starts, not something that is pushed into the Pi.
>>>
>>
>> No.  The Pi does not start anything.
> 
> The update is started by running code on the Pi.
> 

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

> 
>>
>> 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.
> 
> The used should commit and push the stuff in a controlled environment,
> not in a customer system.
> 

You are misunderstanding the setup.

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

>>
>>> It is certainly a good idea to update the Pi automatically
>>> with the latest test suite.
>>
>> 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.
> 
> Automatic, does not neccessarily mean that there is a periodic pull.
> It might do the pull every time you reset the target.
> 

True.  But my answer is unchanged.

> 
> 
>>> If you find you have a problem, you can easily revert to an older 
>>> commit.
>>
>> Yes, that's easy - if you are in control of your updates and haven't 
>> set an automatic job for it.
>>
> You are in control of the main repo.
> Noone will pull in something, which is not part of that repo.
> 
>>> Obviously you should be able to disable the automatic update,
>>> if for some reason you do not like to use the latest version.
>>>
>>
>> You have it ass-backwards.
>>
> No I don't.
> 

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.

[toc] | [prev] | [next] | [standalone]

#28575

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.

[toc] | [prev] | [next] | [standalone]

#28576

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?

[toc] | [prev] | [next] | [standalone]

#28577

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?

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 correctly.  I most likely used Putty or a derivative on the PC.  I had a bunch 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 path 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 interface 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 response is the unit selected.  Every command other than the select command is reading or writing a register in the selected target.  I guess that's more 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 tell the router to use "these" assignments and tried to set that up in multiple locations where I used this, but sometimes it would do that, other times it would assign other addresses. 

Rick C.

[toc] | [prev] | [next] | [standalone]

#28578

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. 

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. 

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. 

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.

[toc] | [prev] | [next] | [standalone]

#28579

On Wednesday, February 27, 2019 at 5:49:43 PM UTC-8, gnuarm.del...@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. 
> 
> 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. 

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.

[toc] | [prev] | [next] | [standalone]

#28580

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. 

[toc] | [prev] | [next] | [standalone]

#28587

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web