Support new networking setup by rgw3d · Pull Request #14 · SchmidtScoreboard/rust-scoreboard

rgw3d · 2021-01-23T03:42:44Z

No description provided.

rgw3d · 2021-01-23T03:43:49Z

Need to fix comments/ further test things. This still shuts off interfaces which is probably bad.

rgw3d · 2021-01-23T03:45:11Z

src/main.rs

    if matches.is_present("wait") {
-        info!("Waiting 90 seconds");
-        sleep(Duration::from_secs(90));
+        info!("Waiting 5 seconds");


I figure a short delay might be useful? I tried this to see if the is_connected() function would work again. No change, is_connected() is still broke.

rgw3d · 2021-01-23T03:45:38Z

src/shell_executor.rs


-        self.execute("sudo", &["ifup", "wlan0"])?;
+        info!("Sleeping for a little bit to allow wpa to catch up after being restarted.");
+        sleep(Duration::from_secs(15));


Necessary to sleep because the hostname -I call to show the sync code will fail if run too soon.

schmidtwmark · 2021-01-23T13:43:26Z

src/common.rs

-    let response = ureq::get("http://clients3.google.com/generate_204").call();
-    info!("Checking connection, status is {:?}", response.status());
-    response.status() == 204
+    true


Stonks. It’s able to connect to AWS to get scores, I assume?

Yup, works fine

Can you try running this just before or after getting scores?

Wack, still returning 400s on startup. Maybe the scoreboard service is running too early, before other networking things are fully up.

I get 204s if I start the scoreboard app manually, so I don't think its the endpoint.

schmidtwmark · 2021-01-23T13:46:30Z

src/shell_executor.rs

-                "set",
-                interface,
-                if enable { "up" } else { "down" },
+                "echo"


The only reason I’m disabling interfaces is because I don’t want the scoreboard to constantly be broadcasting a WiFi connection. Does this still do that?

It doesn't. I'm working on a better way to disable the WIFIs

schmidtwmark · 2021-01-23T14:08:24Z

Are you thinking you want to merge this now? I think I’d be okay to merge it iff there’s a feature flag for it. I’ve been thinking about how I want to do this, it would look something like:

there’s a new file in /var/lib/scoreboard called features
if it does not exist, it gets created and defaulted to good defaults

For example, right now it would just be JSON looking like: { “networking_version”: 1 }. You would set this to networking_version 2, and that would also be set on any new scoreboards made from your Raspbian fork. Then, we could do things like have networking_version checks before the startup wait, and create a second run method for shellExecutor that will handle actions the way you’ve changed here.

I’d rather do that as a bridge while I figure out how I’m going to get everyone else upgraded, and so I can support feature development for you on your new networking code and for everyone else.

rgw3d · 2021-01-23T14:39:19Z

@schmidtwmark This should not be merged now. Feature gating is a good idea, that's what I was going recommend!

rgw3d · 2021-01-24T18:17:03Z

@schmidtwmark Instead of using ip link set I shutdown/ restart the services (wpa_supplicant & hostapd). This seems to be the better approach.

schmidtwmark · 2021-01-25T13:35:06Z

README.md

+  - Substitute your own IP addresses for the Access point
+  - Use wlan1 as access point
+  - Use wlan0 as internet connection
+- Modify the wpa systemctl service such that wpa_supplicant will actually get wlan0 to connect to the internet.


Do you not have to install drivers for the dongle?

Nope! Works without installing anything.

schmidtwmark · 2021-01-25T23:00:22Z

On January 25, 2021, "dependabot[bot]" ***@***.***> wrote: @rgw3d commented on this pull request. In src/common.rs <https://github.com/SchmidtScoreboard/rust- scoreboard/pull/14#discussion_r564097766>: @@ -100,16 +100,18 @@ pub fn color_from_string(s: &str) ->

Result<rpi_led_matrix::LedColor, Box<dyn Er } pub fn is_connected() -> bool { - let response = ureq::get("http://clients3.google.com/generate_204").call(); - info!("Checking connection, status is {:?}", response.status()); - response.status() == 204 + true

Wack, still returning 400s on startup. Maybe the scoreboard service is running too early, before other networking things are fully up. lmao thus the 90 second wait. Maybe give it 90 seconds during startup in a loop to check if it is connected iff the scoreboard setup state is ready?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/SchmidtScoreboard/rust- scoreboard/pull/14#discussion_r564097766>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/ADLB5EN7LBDODFZDW27H6J3S3XZBZANCNFSM4WPLCFSQ>.

Support new networking setup

f3b3ecd

rgw3d requested a review from schmidtwmark January 23, 2021 03:42

rgw3d linked an issue Jan 23, 2021 that may be closed by this pull request

Wait for interface rather than just waiting 90 seconds #10

Open

rgw3d commented Jan 23, 2021

View reviewed changes

schmidtwmark reviewed Jan 23, 2021

View reviewed changes

rgw3d added 2 commits January 23, 2021 16:23

Add Readme

1258b1a

Kill the carrier, not the interface

b30aea6

schmidtwmark reviewed Jan 25, 2021

View reviewed changes

Base automatically changed from master to main February 23, 2021 01:38

Conversation

rgw3d commented Jan 23, 2021

Uh oh!

rgw3d commented Jan 23, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

schmidtwmark commented Jan 23, 2021

Uh oh!

rgw3d commented Jan 23, 2021

Uh oh!

rgw3d commented Jan 24, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

schmidtwmark commented Jan 25, 2021 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants