According to example 12 here I should be able to use
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/4 org.freedesktop.NetworkManager.Device.Wireless.GetAllAccessPoints
to discover all available wireless access points, because /org/freedesktop/NetworkManager/Devices/4 is my wireless adaptor. However, it seems to return results different from the command-line equivalent
nmcli device wifi list
which returns many more SSIDs. Whilst experimenting with the above at work, I could only get one SSID via dbus-send. At home, the first time I ran the dbus-send command it returned an array of four access points, which is the same number as returned by nmcli. I ran the same dbus-send command again and this time it produced a list of only one access point, just as at work.
The next day at home I tried the dbus-send command several times and it listed just one access point. I then ran the nmcli command again and it listed five access points. After that, the dbus-send command also listed five access points. It seems that the nmcli command somehow goes further than the dbus-send command to discover access points, but once it has done so, the dbus-send command is also able to find the access points. That is not the case at work, however: the nmcli command always discovers 12 or more APs but the dbus-send command only ever discovers one.
I definitely only have one wireless adaptor: ifconfig -a lists: enp0s25, lo, sit0 and wlp3s0.
What does the nmcli command that the dbus-send command does not?
The answer is that you have to run a rescan (method RequestScan) just before getting the list of SSIDs.
Related
Suppose I am working on LocalA (username userA). I use ssh to tunnel to RemoteB (username userB), then to RemoteC (username userC), then finally to RemoteDestinationD (username userD).
It would look something like the following:
userA#LocalA$ ssh userB#RemoteB
userB#RemoteB$ ssh userC#RemoteC
userC#RemoteC$ ssh userD#RemoteDestinationD
userD#RemoteDestinationD$
Suppose I forget which series of connections I used to connect from LocalA to RemoteDestinationD. It could have been one jump (e.g. userA#LocalA$ ssh userD#RemoteDestinationD) or three jumps (as in my example above). How could I programmatically determine what my series of jumps was? ("Scroll through your history, dummy!" doesn't count....)
I'd like a BASH script that would output something like the following:
userA#LocalA$ --> userB#RemoteB
userB#RemoteB$ --> userC#RemoteC
userC#RemoteC$ --> userD#RemoteDestinationD
Any ideas?
Thanks in advance!
There is no good way to do this, I suspect. There are a bunch of true hacks you could do if you were willing, such as turning on X11 port forwarding and using different ports for counting.
Or, more obnoxiously:
sshcount=0
ssh userA#RemoteA "echo sshcount=$(($sshcount+1)) > .bashrc; bash"
And from there do something similar to get to B, so sshcount keeps incrementing.
Clearly this should be done via overwriting a .sshcountrc file or something, and source that from the .bashrc. And then, you might need to make the file name dependent on some munging of $SSH_TTY if you want to support doing parallel versions of this.
And the whole thing is really a hack so maybe you shouldn't anyway and you should solve the problem another way. Or remove the need for counting in the first place.
I know there are several posts asking similar things, but none address the problem I'm having.
I'm working on a script that handles connections to different Bluetooth low energy devices, reads from some of their handles using gatttool and dynamically creates a .json file with those values.
The problem I'm having is that gatttool commands take a while to execute (and are not always successful in connecting to the devices due to device is busy or similar messages). These "errors" translate not only in wrong data to fill the .json file but they also allow lines of the script to continue writing to the file (e.g. adding extra } or similar). An example of the commands I'm using would be the following:
sudo gatttool -l high -b <MAC_ADDRESS> --char-read -a <#handle>
How can I approach this in a way that I can wait for a certain output? In this case, the ideal output when you --char-read using gatttool would be:
Characteristic value/description: some_hexadecimal_data`
This way I can make sure I am following the script line by line instead of having these "jumps".
grep allows you to filter the output of gatttool for the data you are looking for.
If you are actually looking for a way to wait until a specific output is encountered before continuing, expect might be what you are looking for.
From the manpage:
expect [[-opts] pat1 body1] ... [-opts] patn [bodyn]
waits until one of the patterns matches the output of a spawned
process, a specified time period has passed, or an end-of-file is
seen. If the final body is empty, it may be omitted.
I have a serial usb device that is connected to a linux box and it works fine with serial communication programs, such as minicom.
For instance, within that program, I send the string "V" and I get back an answer: "UBW FW D Version 1.4.3".
Now, I'd like to do a shell script that could do the same, in order to test variables. I investigated the possibility to use minicom without being "interactive" but it seems is not possible. I also tried the obvious "echo V > /dev/ttyACM0" but had no luck as well.
Any idea of how can I send and receive strings to/from a serial device in such way I can use the received data in a shell script?
Thanks
In the olden days of modems, we would use the program 'expect' to send and receive data from the serial line. This doesn't exactly solve your problem, but might get you some of the way there.
Have a look at Use expect in bash script to provide password to SSH command
The atinout program does exactly what you are asking for. Example:
$ echo AT | atinout - /dev/ttyACM0 -
AT
OK
$
Now, from you example command and response, I see that your "modem" seems to able to configure or modify to not return the OK Final Result Code, and atinout absolutely needs that for its operation, so make sure the UBW behaves properly.
i'm working on a script that will monitor traffic on specific hosts from nagios. I have studied some scripts already made and have gathered almost all the info i need to do it but i have encountered a problem in identifying the OID's necessary for the traffic. I wanted to use IF-MIB::ifOutOctets.1 and IF-MIB::ifInOctets.1 to get the incoming and outgoing traffic but when i tested with the following line:
snmpwalk -v 1 -c public myComputer OID
i got the same result for both the OID's and that doesn't seem right. I'm wandering if there are other variables i could try instead of those i'm using now.
It would be useful even if you can point me to where i could find some info on the IF-MIB, because i can get all the values with snmpwalk but i don't know how to interpret them
Ok, i found the answer, after some searching. The values are equal because i was not asking the right interface(i was asking the loopback). There is this command snmpwalk -v 1 -c public hostname 1.3.6.1.2.1.31.1.1.1 that lists a lot of OID's and from there you can see 'IF-MIB::ifName' which stand for the interfaces. And if you execute IF-MIB::ifInOctets.x where x corresponds to the interface you are interested in you can find a number in bytes. I am not sure what it means, or how it's generated but i tested executing twice the command:
date ; snmpwalk -v 1 -c public myComputer ifOutOctets.x
at an interval of aprox 1 min, and then i subtracted the two values and devided them by the number of seconds that passed between the executions. I compared the value with the one obtained from iptraf and they kinda match, so i think you can used this way to find the traffic a station with snmp.
I know there is a command to list all the clients that are connected to the same network I'm connected to and get basic information (IP, MAC...)
I thought of writing it down the last time I used it but probably figured I'd remember it. Yeah, right.
Are you looking for rwho?