I am developing a handheld device based on IMX233 running embedded linux and is using Unifi CSR6026 for connecting to the WiFi networks. I have got the basic WiFi connectivity running using the wpa_supplicant and wpa_cli utilities. But i'm not able to detect when the user has entered a wrong key for the access point. The 'wpa_cli status' shows 'wpa_state=COMPLETED' and the iwconfig also returns the correct ESSID and MAC address of the access point as currently connected. Is there any other way to find out whether the user has entered a wrong key or not ??
root#freescale ~$ wpa_cli status
Selected interface 'eth0'
bssid=00:24:01:6a:3f:26
ssid=FirstFloorBGN
id=1
pairwise_cipher=WEP-40
group_cipher=WEP-40
key_mgmt=NONE
wpa_state=COMPLETED
root#freescale ~$ iwconfig
lo no wireless extensionsunifi1: unifi_giwencode: Surprise, do not have a
valid key index (0)
.
eth0 IEEE 802.11-b/g ESSID:"FirstFloorBGN"
Mode:Managed Frequency:2.422 GHz Access Point: 00:24:01:6A:3F:26
Bit Rate=24 Mb/s
RTS thr=0 B Fragment thr:off
Encryption key:off
Power Management period:500ms mode:All packets received
Link Quality=25/40 Signal level=-47 dBm Noise level=-72 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
With WEP, there is no explicit key exchange, so there is no place in which a decryption error could be noticed. Your options are
switch to WPA
monitor the wireless statistics for decryption errors.
Note that the latter need not be an indication that the access point is using a different key.
Related
I have a very basic setup to understand 802.11: Netgear router/AP (no "backside" connection to internet), Ubuntu laptop "client" and a KaliLinux box "sniffer" running wireshark in monitor mode. I start a ping from client to the AP, and it replies fine, sending/receiving 1/second. However, the sniffer doesn't detect anything different from no pinging. I ran the setup for 30 minutes with the client idle (no pinging) and see lots of QoS Data and Null packets (272 data / 158 null from client to AP; 13 data / 0 Null from AP to client). Then I did the same while the client was pinging the AP (72 data / 39 null from client to AP; 56 data / 0 null from AP to client).... less packets when pinging. ... I am using a capture filter to show only client i/o : ether host mac_of_client
Any thoughts on what I'm doing wrong? I'd expect an 802.11 "radio" to pick up anything in the air, and with a capture filter specific to the client, to see ANYTHING going/coming from the client.... but I only see these occasional QoS and Null packets, which must be background maintenance packets (not needed as much while pinging is going on). Thanks!
I want to be able to detect when a peripheral sensor is NOT connected to my Raspberry Pi 3.
For example, if I have a GPIO passive infrared sensor.
I can get all the GPIO ports like this:
PeripheralManagerService manager = new PeripheralManagerService();
List<String> portList = manager.getGpioList();
if (portList.isEmpty()) {
Log.i(TAG, "No GPIO port available on this device.");
} else {
Log.i(TAG, "List of available ports: " + portList);
}
Then I can connect to a port like this:
try {
Gpio pir = new PeripheralManagerService().openGpio("BCM4")
} catch (IOException e) {
// not thrown in the case of an empty pin
}
However even if the pin is empty I can still connect to it (which technically makes sense, as gpio is just binary on or off). There doesn't seem to be any api, and I can't legitimately think of logically how you can differentiate between a pin that has a peripheral sensor connected and one that is "empty".
Therefore at the moment, there is no way for me to assert programmatically that my sensors and circuit is setup correctly.
Any one have any ideas? Is it even possible from a electronics point of view?
Reference docs:
https://developer.android.com/things/sdk/pio/gpio.html
There are lots of ways to do "presence detection" electrically, but nothing that you will find intrinsically in the SoC. You wouldn’t normally ask a GPIO pin if something is attached—it would have no way to tell you that.
Extra GPIO pins are often used to detect if a peripheral is attached to a connector. The plug for some sensor could include a “detect” line that is shorted to ground and pulls the GPIO low when the sensor is attached, for example. USB and SDIO do something similar with some dedicated circuitry in the interface.
You could also build more elaborate detection circuits using things like current sensing, but they would inevitably have to put out a binary signal that you capture through a dedicated GPIO.
This is easier to achieve for serial peripherals, since you can usually send a basic command and verify that you get a response.
Detection using solely the input line can be tough. First, you'd want to narrow the scope of the problem. Treat as not-present the condition of a sensor not being connected, the sensor being connected but not responding, or the sensor responding in an uncharacteristic manner.
So, if it is a digital sensor, then communicating with the sensor may be enough to tell if it is present or not (especially if checksums or parity bits are involved).
Some analog sensors also have specific specs on how it behaves when triggered. You can utilize deviation from those specs to determine if the sensor is not present.
If you have a digital sensor w/o any error checking on it's output, where you clock out data (so all 0s or all 1s is valid) or it's just a binary 1 or 0 for output, then you'd need external help. Same for most analog sensors.
This external help would be something where you put the system in a known controlled state, press a button, and it then checks the sensors for output within a specific range. To be absolutely sure, you'd want at least two different states, to ensure your digital or analog inputs didn't happen to be stuck at the correct state for your test.
Just about any other method would be external to the system. Using additional IO to "detect" a sensor could help increase confidence the sensor is there, but you could get false positives where all you've learned is that "something" is there - not necessarily the sensor you expect.
how to use AT+CWLAP in esp8266 to get wifi signal strength? I want to get the signal strength which is displayed on the serial monitor and use it in my code in arduino IDE!
After sending the AT+CWLAP command, ESP8266 will answer with a list of all available AP's detected.
The format of the response will be like:
+CWLAP:<ecn>,<ssid>,<rssi>,<mac>,<freq offset,<freq calibration>
where:
<ecn>: indicates the security level, from 0 (OPEN) to 4 (Maximum security level)
<ssid>: it's the ssid of the AP
<rssi>: it's the signal strength, which is indicated in decibel format (e.g. -70)
<mac>: it's the MAC address
<ch>: channel
<freq offset>: ut's the frequency offset of AP，unit：KHz.
<freq calibration>: it's the calibration for frequency offset
So, the <rssi> parameter is what you are interested in.
Maybe, depending on the firmware version of your ESP8266, it's possible that AT+CWLAP command returns a different number of parameters, omitting, for example, the last four.
I am trying to lower the transmitted Wifi power on a router running OpenWRT.
I've tried using the iw command to set the txpower to a very low 100 (1dBm)...
root#GL-iNet:~# iw dev wlan0 set txpower fixed 100
...and `iwinfo seems to report that the command was executed correctly...
root#GL-iNet:~# iwinfo
wlan0 ESSID: "Moonphase WAP"
Access Point: E4:95:6E:40:39:8C
Mode: Master Channel: 1 (2.412 GHz)
Tx-Power: 1 dBm Link Quality: unknown/70
Signal: unknown Noise: -92 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0
...but the actual emitted power does not seem to change no matter what I set the txpower to.
I've also tried...
using iw on the phy rather than the dev
setting the txpower in the /etc/config/wireless and rebooting
downing/upping the interfaces
...and none seem to have any effect on actual output power.
How can I pro grammatically lower the output power?
Notes:
I am aware of all the driver limitations in regulatory.bin, but I do not think these should matter here since I am trying to set a txpower that is lower than the county specific limits.
This router is a a clone of a TP-LINK TL-703N.
The router is running OpenWRT...
root#GL-iNet:~# cat /proc/version
Linux version 3.10.49 (alzhao#alzhao-ubuntu) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r42801) ) #6 Thu Oct 9 18:20:47 HKT 2014
The Wifi is handed by an AR9331 chip.
It turns out that the command...
iw wlan0 set txpower fixed 1
...does seem to set the radio to 1dBm, it is just even at this low level every client I have still shows 5 bars when in the same room. I had to take the receivers 30 feet away and on the other side of a wall for the lower signal strength to be visible.
Debugging this problem was compounded by the fact that the syntax for setting the power level inside /etc/config/wireless is different from the imperative form, so this is the format for setting it to 1dBm in the wifi-defvice section of the config file...
config wifi-device 'radio0'
option txpower '1'
I want to have a list of source IP addresses of an interface outbound traffic. How could I find the direction of a packet whether it's inbound or outbound reading traffic using libpcap? I don't know the subnet information of either side. And there are clients/servers on both sides, so I can't rely on port number ranges to filter traffic.
Why there is no information in libpcap packet header about direction, or filter option like inbound in pcap-filter?
Netsniff-NG, while not relying on libpcap, supports Linux kernel packet type extensions.
They're documented
here
One of the packet types is outgoing and commented as "outgoing of any type".
The following example will capture all packets leaving your interface.
$ netsniff-ng --in eth0 --out outgoing.pcap --type outgoing
Using this you can utilize other command-line tools to read the PCAP file and pull out all the source
addresses. Maybe something *nix-ey like this:
$ tcpdump -nnr outgoing.pcap | cut -d " " -f3 | cut -d . -f1-4
Note: I haven't tried this on a router.
you could use "ether src" or "ether dst" to filter packet direction. This require you to know the mac address of the interface.
You can select a direction that packets will be capture calling pcap_setdirection() before pcap_loop().
For example, to capture incoming packets only you need to write:
handle = pcap_open_live("eth0", 65535, 1, 0, errbuf);
pcap_setdirection(handle, PCAP_D_IN);
pcap_loop(handle, -1, process_packet, NULL);
Possible directions are: PCAP_D_IN, PCAP_D_OUT, PCAP_D_INOUT.
See tcpdump.org/manpages/pcap_setdirection.3pcap.txt
The PCAP file format does not contain a field that holds the interface used during the capture. With that said, the newer PCAP-NG file format, currently used by Wireshark & Tshark, supports it along with packet direction.
Existing pcap-ng features:
packet dropped count
annotations (comments)
local IP address
interface & direction
hostname <-> IP address database
PcapNg
It sounds like you're capturing from a router or firewall so something like the following
would not work.
ip src 192.168.1.1
Capturing the traffic into flows may be an option but it still will not provide you with direction information. Though, you will be able to determine the source and destinations address easily. If you have an existing pcap you can convert it to the ARGUS format:
argus -r capture.pcap -w capture.argus
ra -nnr capture.argus
Other tools, some w/ examples, that can easily obtain end-points/hosts are:
ntop -f capture.pcap
tcpprof -nr capture.pcap
Wireshark Endpoints
flow-tools
You'll have to parse out the information you want, but I don't think that's too much trouble. I recommend taking a look at PCAP-NG if you can't work with this.