Create Task
Maniphest T833

Networking Helper
Open, WishlistPublic
Actions

Description

Networking with the Beta is currently not very easy. Here are some Ideas to improve this situation

  • I think it would be helpful, if the Beta would detect interfaces, that don't have a DHCP Server and open one on its own. This would simplify direct connections to the Beta. Moreover, we could spawn a DNS server, that can only resolve my.apertus.org to the cameras IP address.
  • Detect, when a Wifi dongle is inserted and open a Wifi-Hotspot automatically
  • Run a mDNS Service to enable simple auto discovery. Hostname could be my.apertus.org, too
  • Have a simple error page with possible networking solutions set up at my.apertus.org
anuejn created this task.Nov 18 2017, 10:18 PM
anuejn updated the task description. (Show Details)
anuejn raised the priority of this task from to Wishlist.
anuejn added projects: AXIOM Beta Software, Brainstorming.
anuejn moved this task to Usability Improvements on the AXIOM Beta Software board.
anuejn added a subscriber: anuejn.
nothingismagick added a subscriber: nothingismagick.Feb 19 2018, 4:22 PM

In my opinion, until the networking stack and sudoers permissions are hardened in the Beta Software package, any exposure to the lighttpd service is really dangerous...

In general, these are great ideas! But in practice you will run into problems, such as when there are several betas / gammas on the same network. For a simple LAN - not a problem, but if for example you are connected to a regional network like Freifunk in Hamburg, mDNS will lead to collisions. (I've seen this with some NAS servers. They use some drastic PIN-type workarounds, also not good for decentralization...)

Automatic setup of a wifi is not trivial, especially on Arch where I have seen problems with USB detection and pretty much always needed to use the CLI to setup wifi. Other than supporting a small subset of dongles (that would need to be tested and have their UDEV rules integrated) I am not sure exactly how plausible this is. It is probably better to use the onboard wifi module. At least that way you know what you're getting into...

As far as the my.apertus.org idea is concerned, it might be worth looking into a scheme that serves unique / registered apertus hostnames on a subdomain with the cert being held on the device. There was a German company named protonet that followed this type of approach - except they held the certs on their company servers... Not good if the parent company faces problems - or your internet uplink fails. Good thing they recovered and moved to the US. :)

Your last point, however, is quite brilliant. I think it will really enhance user experience.

anuejn updated the task description. (Show Details)Feb 19 2018, 10:31 PM
anuejn added a comment.Feb 19 2018, 10:49 PM

As far as the my.apertus.org idea is concerned, it might be worth looking into a scheme that serves unique / registered apertus hostnames on a subdomain with the cert being held on the device.

Sounds like a pretty cool idea :). According to the XIlinx docs, we can get a (almost) unique uuid of the zynq. With this we could generate an (almost) unique hostname consisting of words for each camera (something like docker is doing for container names)

nothingismagick added a comment.Feb 19 2018, 10:53 PM

Exactly. Going further, you could also allow users to opt-in their hardware into something like a "fleet health check" which would be a pathway to send errors / regressions / heat statistics whatever back to HQ for QA...

RexOr added a subscriber: RexOr.Feb 20 2018, 5:48 PM