I suppose, if you choose to stay with the names eth0 and eth2 (i.e. not eth1) it might also work as udev rules.

Almost exactly right, I'd say. Time has blessed us with three different ways of ending a line, all relating back to the use of these characters for printer control, and basically a matter of how it is represented on file. So, nowadays we have:

• the Microsoft line ending idea of using both CR (carriage return) and LF (line feed),

• the Apple idea of ending lines with only CR, and

• the Unix (and Linux) idea of ending lines with LF.

That line ending are characters within the files, to make up the traditional "text file" representation. Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

Regarding that "X days has passed ...", it sounds like the fsck output, telling you that the file system hasn't been checked in X days, and that a check is forced. Nowadays there is a tendency of not showing the startup messages, but rather just showing an image or a black screen until the desktop environment kicks in. This is something you can configure by changing the boot command line.

Regarding your sudo configuration, I suspect the issue is rather the absence or presence of a newline at the end of the line.

is an unusual first line for a script. Or was it a mistake when copying to here? Otherwise you should remove the first 6 characters, so that the very first character is the "#" character. Or equally, make it so to say:

#!/sbin/openrc-run

Looking at my own system (ascii), the story is something like the following.

The process is named udevd.

It's first started by its pre-pivot init-top/udev script, in initramfs. That process is then killed at the end of the pre-pivot init sequence, by its  init-bottom/udev script, still in initramfs.

Next it has its init link /etc/rcS.d/S0?eudev (or possibly /etc/rcS.d/S0?udev) for starting udevd in the post-pivot init sequence.

The pre-pivot start up includes a forced traversal of the /sys tree through a udevadm trigger --action=add command, and then that init-top/udev script also waits for udevadm settle to return, before it "pokes" extra on scsi devices, if any, followed by an optional additional timeout in some circumstances. Further, the init-bottom/udev script at the end of pre-pivot init merely kills the pre-pivot udevd process, and then moves the pre-pivot /dev to be available as post-pivot /dev.

Note that pre-pivot init is a script, usually a copy of /usr/share/initramfs-tools/init, and it ends with an exec run-init ..., which becomes the post-pivot init process (or a panic, if exec fails).

The generation need not be a mystery. It's indeed that "rules" file 75-persistent-net-generator.rules that comes into play whenever some hotplug event occurs, plus the once off initial scanning of /sys. I suppose you need to learn a bit udev-ish to work it out in detail, but essentially:

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules. It's all at a deplorable level and style of programming, but I'm sure someone is proud of it.

One thing is that the  logic ignores other possibilities of setting NAME before 75-persistent-net-generator.rules. I have a vague memory of various random "solutions" to adapter naming that end up setting NAME early, and thus also disarm the generation of 70-persistent-net.rules, but without them being grounded in their logic. The result is more untouchable udev rules mess, which is good for nothing but clocking consulting time.

I suppose it's also possible to make it a single source line, i.e., replace the one you had (that matches the beginning of the one I suggested) with the one I suggested. That should have the same effect but without the warnings.

The "confirm" popup is in the RouterStatus.htm script to come up before the reboot request gets issued; so it's before that wget request gets issued.

When checking the file again with more care, I realized that there is the hidden input field named buttonSelect. Thus that should be the name used in the post data. I.e., try using buttonSelect=2 instead of button=2.

Since both 1.htm and 2.htm are the same progress bar response, it suggests that the id number is not very important. Thus option 1 may well work with buttonSelect=2.

The complex, third, variant doesn't work at all as is, which is my fault. It should have -O- instead of -v; you will want the download of the inner wget to go to standard output, and piped to sed, which extracts the form action (with path and id) to be used by the outer wget.

Though the complex variant is only needed if the id number is important. If there also is a connection to the session cookie, the command might need to be made even more complex, so as to making the inner wget save the cookie, and the outer load it.

My read buffer for python is rather limited I'm afraid, but I noticed you're using form[1] and that the javascript in post #10 submits a form[0]. I know javascript starts indexing from 0, and if python does the same, it might mean that the submitted form is actually a hidden element prior to the visible form. Perhaps there is a "tag name" selector in selenium offering the array of forms, to let you mimic the index==3 action.

Other than that, I think I'm out of ideas (well, suggesting an excursion with wget, perhaps, which also is cookie capable).

Most likely the router uses "basic authentication", which means that the username and password is passed on as an HTTP header with every request, and if so, you'll be able to pass it to curl (or wget) as part of its arguments. You'd use the inspect tool of the browser (hoping it has that) to find out the triggering url for the reboot button, and it'll work nicely with a single curl (or wget) command. The reboot url would be either a simple "get request", or possibly a "post request" action of a "form" in the page.

If your browser doesn't have an inspect tool, you should be able to save the page and view it in a plain text editor instead (looking for the "reboot" text).

If the authentication is something else, you might need the more complicated solution of running a "web monkey" (e.g. casperjs, or take your pick) to mimic the human gestures across the interface, relative to the browser document representations. It would however be a bit surprising to me if it offered that kind of complexity.

Did you forget to ask your favourite search engine

Mine came up with https://community.netgear.com/t5/Wired- … d-p/495136 which suggests a simple curl command... though I can't test and confirm.

ok; as a slight side track on the thread: your IP ended up as "dubious", because at about half past four today (UTC), you let your computer make a "head" request to "//dev1galaxy.org/req_message". There might be an ordinary explanation for this happening, but we haven't yet got any from anyone who has done this, so it remains classified as "dubious activity". In the olden days, afaict that kind of request did something against phpbb forums, so it remains noted as a security concern although it technically is useless against this forum.