Am I way off?

[tpprynn]

Have been discussing this on and off with the author of a linux driver my laptop uses. I'm trying to write a script to patch one function but it's a first attempt and I can't know if it's insanely naive. Aiming to turn wireless led of/on depending on if online wirelessly. echo 1 > wlan is found to turn the led on.



#!/bin/sh

if [ "$IFACE" = "wlan1" ] && [ "$STATUS" = UP ]; then
for direc in /sys/devices/platform/asus_laptop
do
echo 1 > wlan

done

fi


I'm hoping the led will stay on, constantly, when online wirelessly and off when not online.
I'll carry on reading other people's scripts online for a couple of days in case I've just not got my head round the form, because ideally I'd come to understand this myself though I'm no programmer (though I did write two games in BASIC in 1985!) and it is all new to me.

Does the file name (I've called it toshled) need to have .sh after it? Network Manager will read it and constantly if it is saved in /etc/NetworkManager/Dispatcher.d?
sudo su and then cd /etc/NetworkManager/Dispatcher.d and then chmod +x toshled will make the file executable? I should or shouldn't first put a tick in the box in toshled > properties > permissions > Allow executing file as program?

Pardon my naivety. Clues/pointers welcome but I'd like to solve this myself unless I'm still at it in a few days as I'm sure it should be simple.

Thanks.

[tpprynn]

Apparently this is correct, but as yet it is having no effect. Any ideas as to what I've forgotten/ not understood?




WLAN_LED=/sys/devices/platform/asus_laptop/wlan

if ["$IF" = "wlan1"] && ["$STATUS" = "up"]; then
echo 1 > $WLAN_LED
fi

if ["$IF" = "wlan1"] && ["$STATUS" = "down"]; then
echo 0 > $WLAN_LED
fi

[dagon]

What is the permissions of the file?

Code: Select all

ls -l <filename>

If you want it to work continuously you need to put your statements in a loop. Otherwise you will just test the conditions once.

[tpprynn]

That command gives:

-rwxr-xr-x 1 root root 209 and the date and time. Is that correct? (Is there any difference between using chmod as opposed to logging into Nautilus as root and putting a tick in the box to execute the file in its properties?)

Is it a standard command used to make a script continuous? I've seen suffixes after the #!bin/bash line like -f. Is this anything to do with it?

At the moment I really need a bit of bed and paracetomol and would rather be just told what is missing. Ha.

Thanks!

Edit:

Any better?

#!/bin/sh

WLAN_LED=/sys/devices/platform/asus_laptop/wlan

while ["$IF" = "wlan1"] && ["$STATUS" = "down"]; then
do
echo 0 > $WLAN_LED
done

fi

while ["$IF" = "wlan1"] && ["$STATUS" = "up"]; then
do
echo 1 > $WLAN_LED
done
fi

[dagon]

1 - Always post the whole lot of what you did.
Example: Comman + ouput

oskar@oskar-Aspire-5741G ~ $ ls -l /sys/devices/system/
total 0
drwxr-xr-x 3 root root 0 2011-11-08 02:08 clocksource
drwxr-xr-x 9 root root 0 2011-11-07 13:01 cpu
etc...

2 - Please enclose your codeexamples as code. Press the Code button above and paste the shell script in between the marks.

--------------------------------------------------------------------------

-rwxr-xr-x 1 root root 209 and the date and time.

The file belongs to root, is executable and is 209 bytes long.

Do you try and execute the statements one at a time?

Code: Select all

echo 1 > $WLAN_LED

or

Code: Select all

echo $STATUS

[tpprynn]

I've tried a few combinations, almost blindly:

Code: Select all

root@xxxxx-laptop:/sys/devices/platform/asus_laptop# echo 1 > $WLAN_LED
bash: $WLAN_LED: ambiguous redirect
root@xxxxx-laptop:/sys/devices/platform/asus_laptop# cd /etc/NetworkManager/dispatcher.d
root@xxxxx-laptop:/etc/NetworkManager/dispatcher.d# echo 1 > $WLAN_LED
bash: $WLAN_LED: ambiguous redirect
root@xxxxx-laptop:/etc/NetworkManager/dispatcher.d#

Code: Select all

xxxxx@xxxxx-laptop:~$ sudo su
[sudo] password for xxxxx:
root@xxxxx-laptop:/home/xxxxx# cd /sys/devices/platform/asus_laptop
root@xxxxx-laptop:/sys/devices/platform/asus_laptop# echo 1 > wlan
root@xxxxx-laptop:/sys/devices/platform/asus_laptop# echo 0 > wlan


When using the phrase echo 1 [or 0] > wlan the LED changes state as hoped. But when the string $WLAN_LED is used as defined in the toshleds.sh script as advised by a programmer this ambiguous redirect message comes up and the LED state does not change. I don't have the knowledge to know if the routine should still work in the context of the script regardless of whether the lines work in isolation. I've not done any scripting before - I did a bit of BASIC programming in the mid-1980s and I've done a bit of gtk theming in the last two years. I don't want to master it but I would like to achieve this goal and I have one idea for something else later. It is fascinating to me but I have other creative outlets and can't really spare the time to learn in great depth.

I imagine I'm still without the line(s) that make the script look for change continually?

Code: Select all

#!/bin/sh

WLAN_LED=/sys/devices/platform/asus_laptop/wlan

while ["$IF" = "wlan1"] && ["$STATUS" = "down"]; then
  echo 0 > $WLAN_LED

fi

while ["$IF" = "wlan1"] && ["$STATUS" = "up"]; then
  echo 1 > $WLAN_LED

fi

Is chmod +x [filename] enough? It shouldn't be chmod u+x as I've seen elsewhere?

Could this script only work in NetworkManager/dispatcher.d?

Thanks.

[Anakinholland]

I've tried a few combinations, almost blindly:

Code: Select all

root@xxxxx-laptop:/sys/devices/platform/asus_laptop# echo 1 > $WLAN_LED
bash: $WLAN_LED: ambiguous redirect
root@xxxxx-laptop:/sys/devices/platform/asus_laptop# cd /etc/NetworkManager/dispatcher.d
root@xxxxx-laptop:/etc/NetworkManager/dispatcher.d# echo 1 > $WLAN_LED
bash: $WLAN_LED: ambiguous redirect
root@xxxxx-laptop:/etc/NetworkManager/dispatcher.d#

Code: Select all

xxxxx@xxxxx-laptop:~$ sudo su
[sudo] password for xxxxx:
root@xxxxx-laptop:/home/xxxxx# cd /sys/devices/platform/asus_laptop
root@xxxxx-laptop:/sys/devices/platform/asus_laptop# echo 1 > wlan
root@xxxxx-laptop:/sys/devices/platform/asus_laptop# echo 0 > wlan


When using the phrase echo 1 [or 0] > wlan the LED changes state as hoped. But when the string $WLAN_LED is used as defined in the toshleds.sh script as advised by a programmer this ambiguous redirect message comes up and the LED state does not change. I don't have the knowledge to know if the routine should still work in the context of the script regardless of whether the lines work in isolation. I've not done any scripting before - I did a bit of BASIC programming in the mid-1980s and I've done a bit of gtk theming in the last two years. I don't want to master it but I would like to achieve this goal and I have one idea for something else later. It is fascinating to me but I have other creative outlets and can't really spare the time to learn in great depth.

I imagine I'm still without the line(s) that make the script look for change continually?

Code: Select all

#!/bin/sh

WLAN_LED=/sys/devices/platform/asus_laptop/wlan

while ["$IF" = "wlan1"] && ["$STATUS" = "down"]; then
  echo 0 > $WLAN_LED

fi

while ["$IF" = "wlan1"] && ["$STATUS" = "up"]; then
  echo 1 > $WLAN_LED

fi

Is chmod +x [filename] enough? It shouldn't be chmod u+x as I've seen elsewhere?

Could this script only work in NetworkManager/dispatcher.d?

Thanks.

Hya tpprynn, couldn't let this topic go

There's a lot of questions in here, may not cover them all, but I'll try at the hand of an example. Mind you, there's more than 1 way to do this, but I'll stick to this one

I am gonna use the bash-shell myself, as overhere /bin/sh is redirected to dash, of which I didn't even know it excisted or how it will react to my script.

for the echo's I've put the target between quotes, and variables between { and } as that has solved quite some issues for me over the past years.

I'll put my script first, and discuss it after.

Code: Select all

#!/bin/bash

## File I will use.
WLAN_LED=/sys/devices/platform/asus_laptop/wlan

## Now, we need to create a loop that will continuously check the status of the interface, and to minimiza I/O,
## load, modifications, only alter the file if the state changes.

while true
do
   case ${IF} in
      wlan1)      if [ "${STATUS}" = "down"]
               then
                  if [ `cat ${WLAN_LED}` = "1" ]
                  then
                     echo 0 > "${WLAN_LED}"
                  fi
               elif [ `cat ${WLAN_LED}` = "0" ]
               then
                  echo 1 > "${WLAN_LED}"
               fi
               ;;
      *)         echo "Caught wrong interface. Exiting."
               exit 2
               ;;
   esac
done

Breaking it down step by step:

line 1: Choose bash-shell
line 4: declare variable (file that needs to be edited)
line 9: continuous loop starts
line 11: compare content of variable IF to a list consisting of text "wlan1" and "everything else".
line 12: IF matched to "wlan1", compare the variable STATUS to the word "down". if it matches, go to line 14, else go to line 18.
line 14: We're here, so status of wifi is "down" and LED needs to be turned of. Compare content of file to text "1". If it's a match, go to line 16. If it's not a match, it means it's already turned off so we're done: pass fi twice, "exit" the entered match using ";;", pass esac, and go to line 27.
line 16: Put a 0 in the file to turn off the LED, pass fi twice, "exit" the entered match using ";;", pass esac, and go to line 27.
line 18: We're here, so we know status of wifi is "up" and LED needs to be turned on. Compare content of file to text "0". If it's a match, go to line 20. If it's not, it means it's already turned on so we're done: pass fi, "exit" the entered match using ";;", pass esac, and go to line 27.
line 20: Put a 1 in the file to turn on the LED, pass fi, "exit" the entered match using ";;", pass esac, and go to line 27.
line 22: ";;" means last line of this match.
line 23: IF did not match to "wlan1", so we tell the user that we were not succesfull.
line 24: exit the script with status 2.
line 25: ";;" means last line of this match.
line 26: "esac" means last line of this case.
line 27: we're done for now. Test the while-statement again. If it's true, go to line 9. If it's not true, break and go to next line.

Now, for some of the questions you asked:

Putting the redirect-target between quotes should give you a better error, if you get one at all.
chmod +x works, albeit overkill as it grants everyone on the system executing-rights. chmod u+x limits this to the owner of the file.
The script should be able to work from any location, as long as you have access to the script and the file you want to alter.

I hope I've been of help and at least helped out with understanding shell-scripting. It's so much fun!

Cheers,

Anakin

P.S. I saw the forum-software plays a bit with the indenting, I've put the script in as an attachment as well.

[tpprynn]

Thanks for that. I was very hopeful there for a moment, and I enjoyed your 'crash course' documentation, that's going to be printed out on the wall by my pillow next to the Nox gtk theme file's very ample and almost arousing built-in documentation. How pin-ups have changed...

Unfortunately, for whatever reason, it hasn't worked. And it should have, I'm sure. Quite a shame, it's such a relatively trivial fault, the non-working light - I wonder how many people have ignored it with their own laptops - as my video chip and wireless have almost always been fine. Today someone has just given me some unexpected money and though the LED issue would not at all be the reason I'm tempted to sidestep solving this matter with a new, faster purchase. (Most new laptops look disgusting though to me, they may work great but it's not inspiring spending money on garish plastic...)

But I'd be very pleased if there was anything more to try or say that became a solution. Such a script would only work if placed in /etc/NetworkManager/disatcher.d I'm guessing? Not in /usr/bin or /etc/network or /home, whether or not it's linked in the Startup Applications list? I am yet to trace which log file might show some activity and a clue but that's only just occurred to me to try.

Printing your notes out right now...

Thanks.

[Anakinholland]

if you think that was sexy (pin-up), maybe someone can write you something in perl, hehehe

Anyway, the script should run at any location, since I didn't incorporate relative paths. It's a shame to see that this didn't work. Couple of things I want to verify:

- Did you run the script while being user root, or with sudo?
- I made a script with variables IF and STATUS, but never "declared" them, so where do they come from and how are they filled?
- can you please run the script in verbose/debugging mode and post the result here (use [ code] [ /code] without spaces, so the text will become scrollable and not take the entire page ) or over at pastebin?

Run the script like this:

Code: Select all

sudo bash -x /location/of/your/script.sh

Cheers,

Anakin

[tpprynn]

I may have been naive about how the script is used. I put it in /etc/NetworkManager/Dispatcher.d and then rebooted and tried out the front physical switch on this laptop and the Fn & F8 key combination.

I'm going to try to do this debug mode thing in a minute but I suspect tonight is doomed as I am fading out here after three weeks of kernel/LED/gtk theme experiments till it was almost light again outside.

Thanks. If you're around maybe have a look in here tomorrow.

[dagon]

- I made a script with variables IF and STATUS, but never "declared" them, so where do they come from and how are they filled?

As Anakinholland points out... you are namedropping variables but we mortals haven't got a clue about them as you don't specify them... It just may be that your computer don't have a clue about them either...

[tpprynn]

I see what you mean - Mr Vader was leaving some space for my own brain's input? I had assumed they were regular Linux terminology rather than variables. Well it's an adventure, this, isn't it... I'm one of those people who has run things blind. I'll look over this properly tomorrow when I'm lucid.

[Anakinholland]

I assumed that you already had something going to retrieve the state of the wifi-connection, and therefore never asked. And we all know: assumption is the mother of all screw-ups...

Anyway, now I also get why you kept referring to that one directory. You want the service NetworkManager to interact with it! And I just made a script that could be run by anyone and anything other than a service

If I have time today I'll have a look at it, else Saturday at the earliest. Of course anyone else who can solve this: go for it!

Anakin

[Pilosopong Tasyo]

Howdy.

The way I see it, the algorithm for this problem should be straightforward:

(1) Check the operational state of the wireless device if it's UP or DOWN.
(2) If device is up, turn on the LED. Otherwise, turn off the LED.
(3) Go back to step (1) and repeat.

Step (2) has already been determined, since it simply involves:

Code: Select all

echo "1" > /sys/devices/platform/asus_laptop/wlan # turn on the LED
echo "0" > /sys/devices/platform/asus_laptop/wlan # turn off the LED


That leaves step (1). I did some googling a while ago and I chanced upon this site. One of the answers suggested:

Check /sys/class/net/eth0/operstate and other files in this directory.

Applying this suggestion to the OP's case, we can determine the operational state of wlan1 by:

Code: Select all

cat /sys/class/net/wlan1/operstate

which returns either "up" or "down." Step (1) is now determined and we can complete the script.

With due respect to those who helped the OP earlier, the following script is how I would tackle the problem.

asus-led.sh

Code: Select all

#!/bin/sh

# Changes the on/off state of the wireless LED depending
# on the operational status of the wireless device.

INTERFACE="wlan1"    # Change this where applicable
STATE_FILE="/sys/class/net/$INTERFACE/operstate"
LED_FILE="/sys/devices/platform/asus_laptop/wlan"
LED_STATUS=`cat $LED_FILE`    # Check the current state of the LED

# Loop forever
while [ true ]
do
  INTERFACE_STATUS=`cat $STATE_FILE`    # Is wireless up or down?

  if [ "$INTERFACE_STATUS" = "up" ]
  then
    if [ "$LED_STATUS" -eq "0" ]    # Is it necessary to turn on the LED?
    then
      echo "1" > $LED_FILE    # turn on the LED
      LED_STATUS="1"
    fi
  else
    if [ "$LED_STATUS" -eq "1" ]    # Is it necessary to turn off the LED?
    then
      echo "0" > $LED_FILE    # turn off the LED
      LED_STATUS="0"
    fi
  fi

  sleep 2    # Thou shalt not hog thy CPU's cycles!
done

# EOF

The above script should be self-explanatory, I hope! (When in doubt, feel free to ask for clarification.) I used variables to keep things flexible and readable. The $LED_FILE is also updated only if it's necessary. Save the script to your home directory. To test it:

Code: Select all

chmod +x ./asus-led.sh
sudo ./asus-led.sh

See if it does what you expected it to do. If you're satisfied, move the script to the /root directory and change ownership:

Code: Select all

sudo mv ./asus-led.sh /root
sudo chown root:root /root/asus-led.sh

Edit root's cron table:

Code: Select all

sudo crontab -u root -e

Code: Select all

# m h  dom mon dow   command
@reboot /root/asus-led.sh

Save the changes and reboot your laptop. The wireless LED should now function.

HTH.

[Pilosopong Tasyo]

Update: I noticed another reply from the website I posted earlier:

/sys/class/net/eth0/carrier was the perfect answer to this question for me.

Again, applying that to the OP's:

Code: Select all

cat /sys/class/net/wlan1/carrier

will return 1 if wlan1 is UP and 0 otherwise. This optimizes the script since the value returned coincides with the state of the LED (1 = UP = ON, 0 = DOWN = OFF). The script can be re-written as follows:

asus-led-optimized.sh

Code: Select all

#!/bin/sh

# Changes the on/off state of the wireless LED depending
# on the operational status of the wireless device.

INTERFACE="wlan1"  # Change this where applicable
CARRIER_FILE="/sys/class/net/$INTERFACE/carrier"
LED_FILE="/sys/devices/platform/asus_laptop/wlan"
LED_STATUS=`cat $LED_FILE`    # Check the current state of the LED

while [ true ]    # Loop forever
do
  # Check current wireless state
  CARRIER_STATUS=`cat $CARRIER_FILE`
  if [ -z $CARRIER_STATUS ]   # Variable might be empty; catch this possibility!
  then
    CARRIER_STATUS=0
  fi

  # Is it necessary to update the LED?
  if [ $CARRIER_STATUS -ne $LED_STATUS ]
  then
    echo $CARRIER_STATUS > $LED_FILE
    LED_STATUS=$CARRIER_STATUS
  fi

  sleep 2    # Thou shalt not hog thy CPU's cycles!
done

# EOF

HTH.

[Anakinholland]

Looking good!

We would've gotten there eventually, but this is a nice solution

[dagon]

This script has officially been pimped!

[tpprynn]

I'm still dwelling on this though I had to take a couple of days off as it was driving me mad. I'm going out now with my spear to hunt for food - in a supermarket, and I rarely have to use the spear - but when I get back the rest of today is dedicated to trying this stuff out.

Two things I noticed before I ran out of steam the other day though: firstly, for no reason that I understand my wireless went from being wlan1 to wlan0, without me noticing initially, which I suppose will have thrown some of my tests off. I'm fairly sure the relevant folders have been labelled wlan0 throughout.

I can't still at present tell a variable from a typical bash command/term but maybe I will suss that out when I'm fully concentrated. I can see how if I mistake a variable for a command and don't alter it to my particulars it won't work, but it's not so obvious. But if I give up and offer to give up to three English pounds to the charity of your choice and give you all the specifics (although I think I have) maybe you could give me the exact script I need? Unless it turns out that you have and the wlan-/wlan1 mix-up was the problem...

Thanks.

Edit: I had a quick go before going out and it turns the light on but then the light does not respond to the wireless being turned off - the light stays on. This may turn out to be my fault, I'll see later. I ran the 'pimped' script exactly as it is bar the change ot wlan0.

[Pilosopong Tasyo]

I can't still at present tell a variable from a typical bash command/term...

It has been a common practice among programmers to use/adhere/follow certain guidelines when naming variables. If you haven't noticed it already, I always use UPPERCASE when it comes to variables (at least as far as shell scripting is concerned). It's not a rule per se, but a standard practice that I follow whenever I write scripts.

But if I give up and offer to give up to three English pounds to the charity of your choice and give you all the specifics (although I think I have) maybe you could give me the exact script I need? Unless it turns out that you have and the wlan-/wlan1 mix-up was the problem...

Donate those 3 quid to Linux Mint!

Yes, the asus-led.sh (or its variant, asus-led-optimized.sh) should solve the issue. No need to poke around with system files (/etc/NetworkManager/dispatcher.d/*).

Edit: I had a quick go before going out and it turns the light on but then the light does not respond to the wireless being turned off - the light stays on. This may turn out to be my fault, I'll see later. I ran the 'pimped' script exactly as it is bar the change ot wlan0.

I own an Asus laptop too (model A8JN) so I had the chance to actually try the scripts on my laptop before posting it here. Incidentally, my laptop exhibited the opposite behavior: the wireless LED stays ON even when I press the WiFi button to turn it off. Running asus-led.sh solved the problem nicely for me. The asus-led-optimized.sh script was spewing different error messages (about the carrier file) in terminal when WiFi is being disabled, but it also did the job, regardless. You could try using asus-led.sh instead of asus-led-optimized.sh if you haven't done it yet. asus-led.sh appears to be more stable.

[tpprynn]

Wow, really. So it's worked for you. (Does that mean you weren't bothered until working out this script?) I'm now very keen to sit down and do this as soon as this plate of mammoth is off the table.

Yes, to be clear, my laptop's light before I started looking into this properly would not turn off. This is a Toshiba laptop that uses the asus_laptop module. Hopefully it will transpire that that factor doesn't matter. Then the author, or an author, of asus_laptop helped me a bit and gave me a kernel parameter that defaulted to no light on, though it remains to be seen if I'll have to get rid of that. Anyway, It's nearly five now and I'm happy ot spend till midnight hammering this thread into my bash-resistant brain... just in time in all likelihood for the day next week that I buy a new laptop anyway. D'oh! It's like going out with a string of neurotic women and leaving them, bored, once their minds settle isn't it.

Anyway, I'll wrap this thread up with a [ Solved ] later hopefully, and will also go round the other forums I asked about this, to be useful to someone. I was intending to give my first and very fair and overdue donation to Mint next year early on so I will add a few quid for your work.