From charlesreid1

No edit summary
No edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Current status: FIXING STUNNEL CONTAINER.
Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).
* Each time I try and replicate this pipeline, a different piece goes wrong.
* This time, it's been the rsync stunnel container's secure communications port, 273, not opening up between host/container.
* This is why we need Docker - *so* much bullshit involved in configuring Linux networking services. I'm not calling technical complexity bullshit, I'm calling hypernuanced, undocumented, impossible-to-debug network configuration and hardware issues bullshit.
 
Okay, here is the status of getting ssh and rsync up and working over rsync.


ssh over stunnel: works ok.
ssh over stunnel: works ok.
Line 29: Line 24:
* Ensure external port 273 is open with <code>nmap localhost</code>
* Ensure external port 273 is open with <code>nmap localhost</code>


Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service.
Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service, by using two instances of stunnel using two external ports. I'm using one instance of stunnel to forward local port 2222 to external port 443, and a second instance of stunnel to forward local port 873 to external port 273.
 
Success!
 
Used the following approach:
* Reorganized all of the files in the repository so that each service had its own configuration and build sequence
* Makefile was entry point: make rsync or make ssh
* The Makefile would set the port, and feed that as an argument to each script.
* Build script, run script, open firewall script
* This enabled flexibility in port number, and enabled switching from 273 to 443 more easily
* Better organization of stunnel - since each service requires different configurations and ports should be easy to switch in and out.
 
Successful experiment and experimental data acquisition:
* Ran aircrack collection script on both pis
* Ran rsync stunnel forever loop in another tab
* Collected 30 minutes of data
* Verified data was transferred to server successfully
 
What comes next?
* Data aggregation and database population script
* MongoDB population/extraction scripts
* Jupyter notebooks for data analysis




Line 39: Line 55:
[[Category:Networking]]
[[Category:Networking]]
[[Category:Linux]]
[[Category:Linux]]
[[Category:Wireless]]
[[Category:Docker]]

Latest revision as of 21:43, 16 April 2017

Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).

ssh over stunnel: works ok.

  • Client is pi on dropbear, connected directly to router which is connected to internet
  • Client can run stunnel, local port 2222 open
  • Server can run stunnel, port 443 open
  • Able to connect the stunnel client and server just fine

rsync over stunnel:

  • Client is pi on dropbear, connected directly to router which is connected to internet
  • Client can run 2nd instance of stunnel, local port 873 open

(Previously, we were not seeing the stunnel port opening. Turned out this was because there was no local rsync server listening on port 873, so stunnel had no service to connect to.)

rsync on the server:

  • rsync is running on the host machine, not in a docker. (Next steps.)
  • To start rsync service, use sudo service rsync start
  • Note that rsync will NOT print out error messages, it will fail silently. Check its status to ensure it is running via systemctl status rsync.service
  • Once it is running, your rysnc server instance should be ready and waiting for input

stunnel on the server:

  • stunnel is running via docker
  • The rsync service must be ready on port 873 when docker stunnel starts, or the connection will not be made
  • Ensure external port 273 is open with nmap localhost

Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service, by using two instances of stunnel using two external ports. I'm using one instance of stunnel to forward local port 2222 to external port 443, and a second instance of stunnel to forward local port 873 to external port 273.

Success!

Used the following approach:

  • Reorganized all of the files in the repository so that each service had its own configuration and build sequence
  • Makefile was entry point: make rsync or make ssh
  • The Makefile would set the port, and feed that as an argument to each script.
  • Build script, run script, open firewall script
  • This enabled flexibility in port number, and enabled switching from 273 to 443 more easily
  • Better organization of stunnel - since each service requires different configurations and ports should be easy to switch in and out.

Successful experiment and experimental data acquisition:

  • Ran aircrack collection script on both pis
  • Ran rsync stunnel forever loop in another tab
  • Collected 30 minutes of data
  • Verified data was transferred to server successfully

What comes next?

  • Data aggregation and database population script
  • MongoDB population/extraction scripts
  • Jupyter notebooks for data analysis