Actually i was thinking about this some more and i believe that an ssh
tunnel would be a very good option. I would go about the configuration
differently though.
I would add a debug setting that the customer can enable and disable if
they choose to do so.
For instance if they enable it and then connect network cable then the
device creates the tunnel and allows connection.
If they disable it the device terminates the connection and closes the
tunnel. This way if they decide they want their device to run wired then
there is no concern about an open port on the network.
Also a thought would be to have the system monitor the connection and if
after say 1 minute there isn't a response it would automatically disable
debugging or if there is a connection then set a timer for say 5 minutes
this way it gives you time to look at the logs without having to worry
about losing the connection.
And possibly create a custom reboot script "reboot debug" which reboots the
device in debug mode so that if you have to reboot the device remotely you
don't have to ask the customer to turn debug mode on again.
A plus about this is that you shouldn't have to worry about trying to
figure out if it is connected to the network wired or wireless. You should
be able to ssh in either way.
-WIL
On Wed, Oct 2, 2013 at 4:27 PM, monzie <[email protected]> wrote:
> Thanks for the links, very helpful.
>
> I take your point about privacy. The use case I am thinking of is this:
> 1. The product is designed to work wirelessly. However I expect some
> customers to have issues connecting to their wireless network because they
> don't know their essid, or type in the wrong passphrase, or their router is
> not configured correctly, etc...
> 2. When the customer exhausts all troubleshooting and still can't
> connect, he can plug in an ethernet cable into the bbk. A valid ethernet
> connection will signal to the bbk to start the ssh connection.
> 3. The software is going to be open source, so technical people like
> yourself can configure it as they wish, for instance disabling the ssh
> debugging option.
>
> Any thoughts on the programming environment for the server? I am leaning
> towards Python.
>
>
>
> On Wednesday, October 2, 2013 2:40:39 PM UTC-4, Wilfredo Nieves wrote:
>
>> You may find these bit of reading interesting. http://**
>> chamibuddhika.wordpress.com/**2012/03/21/ssh-tunnelling-**explained/<http://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/>
>>
>> On Wednesday, October 2, 2013 12:30:33 PM UTC-6, Wilfredo Nieves wrote:
>>
>>> Just my 2 cents. Your idea is absolutely feasible. If you take a look at
>>> minipwner, it creates an ssh tunnel, which I believe is what you want to
>>> accomplish. The only and most unpredictable problem is going to be the end
>>> user. If they are like me nothing goes on my network unless I am absolutely
>>> sure what it is doing and that I am the one in control of it. So the auto
>>> update idea may be your best option. As for the debugging you may also set
>>> it up so that it records the logs and sends them out at set intervals. That
>>> way the customers are sure that there isn't anyone inside their network
>>> when they shouldn't be.
>>> On Oct 2, 2013 6:05 AM, "monzie" <[email protected]> wrote:
>>>
>>>> Problem:
>>>> 1. You release a wildly successful Beagleboneblack (BBK) product. The
>>>> product is one where the customer connects the BBK to the Internet thru the
>>>> router on their home LAN (ie. the BBK is behind a router and does NOT have
>>>> a public ip address)
>>>> 2. After product release you find a major bug in your software, and
>>>> the customer support calls start piling up because of this bug.
>>>> 3. You find a fix but because most of your customers are not
>>>> technical, it is difficult for them to update the software. Your customers
>>>> start ranting about how terrible your brainchild is, you start losing hair,
>>>> gaining weight, and wish you had gone into accounting instead of
>>>> engineering.
>>>> 4. SSH'ing into each BBK would be great because then the fix could be
>>>> easily applied.
>>>>
>>>> I'm thinking of writing a software package that provides a solution to
>>>> this. In a nutshell:
>>>>
>>>> 1. A web server (SERVER1) is built and connected to the internet.
>>>> BBK Side:
>>>>
>>>> 2. Each product is given a unique ID (UNIQUE_ID) before being shipped.
>>>> 3. A daemon process installed on the BBK sends an HTTP request for a
>>>> file named UNIQUE_ID on SERVER1. The request is repeated periodically (say
>>>> once every few seconds).
>>>> 4. If the request is successful then the BBK sets up an SSH connection
>>>> to SERVER1.
>>>>
>>>> Tech Support Side:
>>>> 5. Tech support has a list of the customers and their unique IDs.
>>>> 6. When a customer calls in , Tech support creates and SSH connection
>>>> to SERVER1. THen creates the file UNIQUE_ID on the server.
>>>> 7. Tech support can now SSH into the customer's BBK.
>>>>
>>>> I am a little unclear still on SSH port forwarding but I am pretty sure
>>>> the SSH connections thru SERVER1 should be relatively easy to set up.
>>>>
>>>> Thoughts, comments, opinions?
>>>> Is there something out there already that is simple to use?
>>>>
>>>> Anybody want to work with me on this?
>>>>
>>>> Monzie
>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to beagleboard...@**googlegroups.com.
>>>>
>>>> For more options, visit
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
