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.

Not sure it answers your query, but task-console-productivity pulls in tasksel as dependency, and the following as "recommends":

abook, alsa-utils, apcalc, aspell, aspell-en, bastet, beep, bind9-host, bittornado,
bombardier, brltty, bsdgames, caca-utils, calcurse, cavezofphear, clex, cmatrix,
cowsay, crawl, curl, curseofwar, dialog, dnsutils, dvtm, ed, edbrowse, eject, empire,
entr, espeak, espeak-ng-espeak, espeakup, fbi, fbterm, fetchmail, figlet, fortune-mod,
fortunes-min, freesweep, ftp, gddrescue, gdisk, geoip-bin, ghostscript, gnuchess,
gnupg, gnupg-agent, gnupg2, gpm, greed, hasciicam, htop, iftop, imagemagick, iotop,
irssi, iw, jhead, lftp, links2, lrzsz, man-db, manpages, manpages-dev, matanza, mc,
mcabber, minicom, mlocate, moc, moria, mosh, msmtp, mtr-tiny, multitail, mutt, ncdu,
net-tools, netcat, nethack-console, nfacct, ninvaders, nrss, omega-rpg,
openssh-client, openssh-server, pacman4console, parallel, parted, pciutils, pente,
poppler-utils, procmail, psmisc, radio, rename, rpl, rsync, sc, screen, sox, sudo,
sudoku, taskwarrior, telnet, termsaver, time, tin, tmux, toilet, toilet-fonts,
traceroute, ttyrec, unzip, w3m, wavemon, wget, whois, wireless-tools,
wpasupplicant, yasr, zile, zsh

If /dev/mmcblk0 was the full disk, you can't mount the image file directly. One solution to that would be to use nbd (network block device) where you set up the nbd server to use the image file, and then "install it" to the system with an nbd client, which would create a series of /dev/nbd0p1, /dev/nbd0p2, ... points for the partitions and subsequent file system mounting.

However, I don't think file recognizes the image correctly, but rather that the image is a raw NAND image, which needs to be pulled as such. It's a fair while since I was blistering my eyebrows on that problem, and apart from me having forgotten most of it, the details of the story are probably quite different nowadays anyhow. I can only suggest that you follow up on reading/writing NAND images.

Devuan jessie has 5.6.36+dfsg-0+deb8u1, in jessie-security, so you might be able to install from there.

As far as I can tell, the first rule pair is the right one. However,  it's not possible to rename an interface to an already taken name, and the problem is that the udev rules apply well after both interfaces have gained their kernel names. I.e., both names eth0 and eth1 are in use when the rules apply.

Thus, when udev wants to rename eth0 to eth1, it fails because eth1 is already taken. Then the renaming of eth1 to be eth0 also fails for the same reason.

You may however probably rely on that the interface originally named eth0 by the kernel will be processed first. You could therefore set up the rules to name the secondary interface eth2 rather than eth1. Doing so makes eth0 free for any subsequent renaming of the other interface. In that case you will have the interfaces named as eth0 and eth2 via their mac addresses.

If you insist on having eth0 and eth1 you will need a subsequent renaming to happen. That is not easily done through udev, but I think  the ifrename package would be able to deal with this.

That sounds good. I'll prepare the "translation pack" and email this to your registration email. It involves some 1500 phrases and 17 email templates. Though half or so are for the admin pages, which don't necessarily need translations.

Great work. I've lodged a bug on your behalf. https://bugs.devuan.org//cgi/bugreport.cgi?bug=222

Det låter jättebra. Tack. Låt mig samla ihop underlaget, så skickar jag det till din regestreringsadress (om en dag eller två).