Wifi connection setup in Ohio

[lionfish0]

Besides mounting and power....

• Connecting to the wi-fi: How should the Ohio team get the unit on to their network?
• Also: we need to suddenly care about security a bit - if it's being given a public IP address!

[lionfish0]

From Scott:

OSU has a wifi network called “Registered4OSU” which is specifically for connecting equipment to the wifi without special authentication (like Duo). To add a device, we just need the MAC address and then to register it with OCIO.

[lionfish0]

To Do:

• send over MAC addresses of bee boxes (will need Frances to turn on the boxes & connect so we can find out).
• send some text about data collected; where it's going; how it will be controlled remotely [send to whole team]
• chat with IT person [week of 8th]

[lionfish0]

Network and Data Notes

Background:

8-10 bumblebee tracking systems will be placed in the CEA. Each has onboard two cameras (greyscale & colour), camera flashes, and a raspberry pi for control, storage and local processing.

Data Collected:

The systems store locally files containing a python pickle object that has:

• the raw image from the camera
• metadata (which flashes fired, the time, length-of-exposure, camera id) and if local tracking is enabled the location of the bee(s) in the photo.

Getting the data:

These files need transferring. Options are:

• copying by removing the sd card (this is awkward as the tracking systems are mounted out of reach).
• transferring via wifi to a local computer (this is awkward as it will mean introducing a computer into the CEA).
• transferring via wifi to a remote server.

This last option is preferred.

We anticipate this is done via the local raspberry pi pushing the image-data-files when they are collected/generated, to a remote server (likely either an s3 bucket on AWS; cloud storage on GCP, given Sheffield already has a paid account; etc).

Quantity:

The images are raw, but we typically compress (using non-image lossless compression: zipping). To estimate data transfer: each compressed image is ~0.5Mb; with two cameras on each tracking system; 8 tracking systems; 1frame/second; 12 hours/day = 170Gb/day. If this is too much we could add code onboard the pi to store this far more efficiently (e.g. we probably don't need to store the whole image!!!). I'm currently just wanting to store everything rather than regret it later!

Access/Network:

The pi computers will connect/transfer data using HTTPS to S3 (port 443). Configuration support: To configure the camera systems (e.g. adjust framerate; select times of day the camera systems operate; etc) we will need to access them.

Currently we access via a local wifi network and use SSH and/or a webinterface (that uses a FLASK API running on port 5000). This isn't practical for this project as we are usually remote from the site: Instead we propose that the raspberry pi computers maintain SSH connections to a remote server (e.g. my one at michaeltsmith.org.uk) and use remote port forwarding so that myself (and the Research Software Engineers) can access the camera systems for maintenance and configuration.

Summary: Outbound connections:

• HTTPS (port 443)
• SSH (port 22) Inbound connections:
• None.

These two ports are almost certainly available already to users of the wifi.

Connecting to the WIFI:

Will connect to "Registered4OSU" - which is specifically for connecting equipment to the wifi without special authentication (like Duo). To add a device, we just need the MAC address and then to register it with OCIO.

Frances: When you have the tracking boxes, charged batteries and power cable -- we can have a call to:

• (a) get the boxes connected temporarily to the internet (e.g. via your phone wifi hotspot) so that we can,
• (b) configure them to SSH to set up a remote port forwarding system
• (c) then access them remotely to get the MAC address
• (d) communicate with Scott et al. to get them set up on Registered4OSU.

Notes

• They register a MAC address -> generate a password that needs to be set on box (system is called "Clearpass")
• vendor network option? can assign IP addresses [still sectioned off from internal network, but allows us to have a public IP with a port]
• experiment - to check reverse SSH works?
• could also give Sponsored Guest account - ssh option (gucamole).
• isilon storage internal?
• not s4 "HIPA" data - this is personal identifiable [use US AWS instance]
• check pi can write to SMB share.
• get MAC!

[lionfish0]

• Setting up Redhat server in OSU (for doing analysis).

[Joe-Heffer-Shef]

re: Getting the data

Getting the research data from the Pi SSD storage over Wi-Fi by syncing to AWS S3 seems like a suitable solution.

Another good option is to SSH onto a virtual machine and transfer the data using rsync or SFTP to store in on research storage X:

However, we don't yet offer a cloud object storage service for researchers. As a university, we're going with AWS and eventually S3 may be available, although it's not clear to me if and when exactly. (There's no plan to adopt Google Cloud Platform here.)

As a temporary stand-in, we could set up a virtual machine running an S3 server using MinIO or a similar tool. This could write to research storage X: to keep the data safe and accessible.