I found this method of reconnecting the WIFI dongle from this post. But, I want to be clear on how it works, before I try and implement it.

  1. Go to /etc/ifplugd/action.d/ and rename the ifupdown file to ifupdown.original.
  2. Then do: cp /etc/wpa_supplicant/ifupdown.sh ./ifupdown.
  3. Finally: sudo reboot
  1. When is /etc/ifplugd/action.d/ifupdown called ?
  2. What does the script /etc/wpa_supplicant/ifupdown.sh essentially do in laymens terms, it looks pretty complex to me; and when is it called too.
  3. Could doing steps 1 to 3 cause any other unforeseen problems that would prevent my WIFI from working? I'm trying to implement this on a Raspberry PI, via SSH, without a keyboard and monitor in a hard to reach location.

I tried to Google various bits, but got a bit lost!

2 Answers 2


ifplugd is meant to detect remove or reconnection of an ethernet connector. The associated directory /etc/ifplugd/action.d/ hosts scripts that get called when, for example, the connector is plugged in (or removed).

Step 2 in your process would cause the wpa connection to be (re)negotiateed when the connector is inserted (or removed), and it assumes the connection is WPA. The rename/copy process you describe would disable any pre-existing processing done in the pre-existing ifupdown script, which might be negligible or not. You might consider simply calling the /etc/wpa_supplicant/ifupdown.sh by adding that to the existing ifupdown script (at the end, for example), but it depends on understand what is already in the existing script (which is often simple).

If you merely want to renegotiate the wifi connection if or when it drops, instead of handling physical disconnection of the connector, you might consider using this:


That script is robust, mostly harmless, and should do the trick robustly.


Short version

  1. Answered by dudek already; that directory is used for scripts that tell your system how to handle things getting pluged in to it or un-pluged from it.

  2. See "Long version" for attempts at explaining how I've come to understand the script in question. Basicly after running some checks and loading some externall functions it checks if it should run either the start sequence of commands, or stop, or error out and exit.

  3. Oh yeah, it very well could lock you out of remote access if ya touch the networking configs in a way that the RPi doesn't much like. I've touched my networking configs so roughly in the past on my RPi that it's been simpler to start from a fresh install. Be cairful and consider moving the RPi temperaroly to a location that is easire to login to localy.

Long version

Looking through this file on my RPi it seems well commented and it doesn't use to many external function calls. But you've asked for laymens terms so I'll do my best to explain how I go about coming to understand these kinds of scripts, though, as it looks like you're a RPi user like me (headless remote server setup) ya might wana check what I've alread writen over on the RPi StackExchange for auto-reconection to hidden WiFi networks as it may have other tricks useful to your server requirements.

To help aid in answering your questions here's a bit of shell scripting syntax expaination;

In shell ~.sh scripts it is common to find functions defined like so;

function_name () {
    echo "doing stuff for function_name"

and then called via function_name latter on in the script, sometimes within other functions. Functions, script files and if statments are just lists of commands to run. In the case of functions the stuff between { and } are run and in the case of if statments the stuff between then and fi are run and in instences where else or elif are used within if statments conditionally.

For the file we're disecting there are functions named do_start, do_stop and some functions defined in other files... "What files are these other functions definded?" or "How do I find if script a loads functions from file b?" are two questions we'll have to answer first.

Around line 48 in /etc/wpa_supplicant/ifdown.sh there's a commented line (ie line beguining with # simble; these are ignored by script intrupriter... mostly) with source functions coventently labbling the next few lines' intended perpos~

# source functions
if [ -f /etc/wpa_supplicant/functions.sh ]; then
    . /etc/wpa_supplicant/functions.sh

Note this is a good example of scripting behaviour; checking if a file is there before assuming that it is.

The first bit if [ -f is checking for a file under the defined file path. And if present then load contents of file via source (short-hand of source command is . but I avoid using it in my scripts because it can be missintuprated by cp and other commands but digress I have) the file defined by the path. Next is an else check that if that file was not found exit 0 exit with status 0 the script. Then the if stetment ends with fi to close actions to take if the first statment didn't pass. Or in other words if /etc/wpa_supplicant/functions.sh does not exsist then exit, otherwise load those functions and continue processing. This kind of duble-checking if a value or file is present is something you'll see repeated throughout the script in question as well as other scripts, the -f checks for files, -n checks string length, -x checks not only if a file is there but also if user running the script has executable permissions for the file defined, -s checks if a file is empty, -n checks if string is not empty or null value, and = compares strings (or values) in if statments. Something else you'll see in shell and bash scripts on Linux with if statments elif but that's for another day. Within this script are other tricks used in addition to if statments such as || "or", && "and", and ! "not" operators, such as on line 55~

# quit if executables are not installed
if [ ! -x "$WPA_SUP_BIN" ] || [ ! -x "$WPA_CLI_BIN" ]; then
    exit 0

~ which simply put states, if file defined by $WPA_SUP_BIN is not executable or the file defined by $WPA_CLI_BIN is not executable then exit with status 0 without processing further. These can look complex at first but reading them out loud in a more human syntax can help when first learning, for the simple ones, and adding comments with # for complex ones is really helpful when learning or coming back to the subject latter.

The file that is sourced internally should also be inspected if unsure as to what something called within the ifupdown.sh file. I'd suggest nano /etc/wpa_supplicant/functions.sh and then using ^w or Ctrl+w to search around for the function's name that you wish to know more about. Because between what ever task calls this script and the contence of functions.sh most of the puzzel peces will be found.

Now things get to looing a bit differant 'round line 135 where a case statment is started, these kinds of statments have a sertain structure we can use to help decode opearations.

case $some_variable in
         echo "The word [start] was detected in \$some_variable"
         echo "The word [stop] was detected in \$some_variable"
         echo "The word [$some_variable] was detected in \$some_variable but not understood"

In the above example as with other case statments we're essentially searching the contents of $some_variable for the key words defiened, ie start or stop and if the key word is found then issue commands found between trailling ) and preseading ;; that acts to sepperate differant actions to take for various key words found. Note in some scripts you may find these case statments within for loops but that too is for another day.

In the case of the case statements within ifupdown.sh script we're first matching the start or stop status within $MODE variable and using $PHASE value to match if pre-up or post-up sequence of command should be called or if the pre-down or post-down sequence of commands should be called instead. If niether start nor stop where detected then an error is logged, printed and script is exited with status 1 an error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .