when i try to send command ifconfig im getting this
ath0 IEEE 802.11ng ESSID:"test" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:00:00:00:00:00
Bit Rate:0 kb/s Tx-Power=-4 dBm Sensitivity=16/16
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/94 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:475654423 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
how to get from this only part of lines for example
ESSID:""test
Frequency:2.412 GHz
Given your actual paste (and disregarding the malformed sample output):
$ cat ifconf
ath0 IEEE 802.11ng ESSID:"test" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:00:00:00:00:00
Bit Rate:0 kb/s Tx-Power=-4 dBm Sensitivity=16/16
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/94 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:475654423 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
$ grep -oE 'ESSID:"[^"]+"|Frequency:[^ ]+' ifconf
ESSID:"test"
Frequency:2.412
it's really just an extended RegEx, and grep's -o flag to ONLY output the exact match, rather than the matching line.
Related
I have two ethernet interfaces on my machine: one is for internet, and the other would be used for raw ethernet connection without tcp/ip. Also i have a program that uses this interface in promiscuous mode. However, sometimes this interface is used by linux to send broadcast telegrams. I don't know, what service exactly does this, but i need to be sure that there would be no packets on this interface except mine.
Output of sudo ifconfig -v enp2s0 is listed below.
enp2s0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet6 fe80::f137:afa0:2d44:f685 prefixlen 64 scopeid 0x20<link>
ether 54:bf:64:03:a8:76 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 197 bytes 27531 (26.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
As you can see, there is 197 TX packets, althougt i did not send anything in by app. My question is how to forbid any processes except one using this interface?
The interface is configured UP and has an address.
Arrange for it to not have an inet6 address, and no more broadcast datagrams will be sent.
In prior kernels and releases of Ubuntu, it was possible to use the hci socket interface to send an arbitrary set of 31 bytes as an advertising beacon, but in ubuntu 20.04 the hci bluetooth tools were deprecated, as were some elements of the socket API they were using.
The goal is to have some N number of devices broadcast 31 bytes of sensor data to each other at a rate of 5 Hz, and have all N read the packets from the other devices.
With the hci socket API being deprecated, the replacements are the DBus BlueZ API and the Management BlueZ API. The DBus API is limited and seems to only allow a max of 25 bytes. The Management API seems more capable, and it seems to work on Ubuntu 18.04/4.15 kernel (though even there the scan seemed to only pick up the advertisements sporadically when switching between scan and advertise every 100ms while with the hci api it was rock solid), but on Ubuntu 20.04/5.4 kernel, various issues crop up.
Using the hci socket API seems like it could still be possible, but even running something like hcitool lescan results in btmon saying Command Disallowed. I believe this might be due to LE Extended Advertising being enabled, but I have not figured out how to disable it yet.
Using the DBus API (or bluetoothctl) is still limited and doesn't allow the full use of the 31 bytes (or even 30 bytes + length)
Using the Management API leads to a Advertising Timeout shortly after setting the advertising data, which I think might be from LE Extended Advertising being enabled. This problem persists even if I explicitly set the timeout in the packet.
For example, running
btmgmt add-adv -c -d 1E000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D 1
to send an advertising packet at a fixed MAC with the advertising data being length:31 payload: 0-30 results in a btmon output of:
< HCI Command:... (0x08|0x0036) plen 25 #631 [hci0] 5676.358401
Handle: 0x01
Properties: 0x0013
Connectable
Scannable
Use legacy advertising PDUs: ADV_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Co.. (0x0e) plen 5 #632 [hci0] 5676.359321
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 7 dbm (0x07)
< HCI Command: L.. (0x08|0x0039) plen 6 #633 [hci0] 5676.359410
Extended advertising: Enabled (0x01)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 2000 ms (0xc8)
Max ext adv events: 0
> HCI Event: Command Co.. (0x0e) plen 4 #634 [hci0] 5676.361330
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
# MGMT Event: Com.. (0x0001) plen 4 {0x0003} [hci0] 5676.361372
Add Advertising (0x003e) plen 1
Status: Success (0x00)
Instance: 1
> HCI Event: LE Meta Ev.. (0x3e) plen 6 #635 [hci0] 5676.362333
LE Advertising Set Terminated (0x12)
Status: Advertising Timeout (0x3c)
Handle: 1
Connection handle: 65535
Number of completed extended advertising events: 0
Is there a good way to recreate the functionality that was available using the hci socket, or a way to disable extended advertising so that the hci socket works again?
This image from Jos Ryke might help explain what is going on. Of those 31 bytes, 3 were always used for setting the advertising flags.
Looking at the source code for btmgmt those flags are now set with the -g, and -l command line switches. Use general discoverable mode to advertise indefinitely.
static void add_adv_usage(void)
{
bt_shell_usage();
print("Options:\n"
"\t -u, --uuid <uuid> Service UUID\n"
"\t -d, --adv-data <data> Advertising Data bytes\n"
"\t -s, --scan-rsp <data> Scan Response Data bytes\n"
"\t -t, --timeout <timeout> Timeout in seconds\n"
"\t -D, --duration <duration> Duration in seconds\n"
"\t -P, --phy <phy> Phy type, Specify 1M/2M/CODED\n"
"\t -c, --connectable \"connectable\" flag\n"
"\t -g, --general-discov \"general-discoverable\" flag\n"
"\t -l, --limited-discov \"limited-discoverable\" flag\n"
"\t -n, --scan-rsp-local-name \"local-name\" flag\n"
"\t -a, --scan-rsp-appearance \"appearance\" flag\n"
"\t -m, --managed-flags \"managed-flags\" flag\n"
"\t -p, --tx-power \"tx-power\" flag\n"
"e.g.:\n"
"\tadd-adv -u 180d -u 180f -d 080954657374204C45 1");
}
The other 28 bytes must start with a byte declaring the length and a byte declaring what data type the rest of the bytes in the declared length are describing.
It is those 28 bytes that is being set with the -d option of btmgmt.
If 28 bytes are not enough, then common workarounds people use is to split the data over multiple adverts or use scan response packet.
There is more detail on the Advertising Data Format in the Core Specification where it defines an Advertising Packet as:
A packet containing an advertising PDU. See [Vol 6]
Part B, Section 2.3.1
More data is section:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C | 11 ADVERTISING AND SCAN RESPONSE DATA FORMAT
It has an example for ADV_NONCONN_IND packet type:
PDU Type: 2
ChSel: RFU
TxAdd: 1 (random)
RxAdd: RFU
AdvA: 0xC1A2A3A4A5A6 (a static device address)
AdvData: (3 octets) 0x01 0x02 0x03
Which starts with the flags data type.
I am having two (may be related) issues but I will describe the one mentioned in title first.
I am modifying the dummy network device driver to echo back the transmitted UDP packet to the transmitting interface. In the callback function of ndo_start_xmit, I have added following piece of code to echo back the transmitted packet:
struct sk_buff *skb2;
unsigned char *ptr;
skb2 = netdev_alloc_skb(dev, pkt_len + 2);
if(skb2)
{
ptr = skb_put(skb2 , pkt_len);
memcpy(ptr , (void*)skb->data, pkt_len);
/* Code to swap source and destination IP & Ports and increment tx rx counts here */
netif_rx(skb2);
}
Now if I assign IP to interface after inserting this module, send packets on this interface and then run ifconfig dummy0, I get following output:
dummy0 Link encap:Ethernet HWaddr 42:cd:19:7d:52:3f
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::40cd:19ff:fe7d:523f/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:4 errors:0 dropped:4 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:192 (192.0 B) TX bytes:258 (258.0 B)
Here we can see that along with packet TX and RX count, RX Drop count is also increasing. Can someone point to the reason why packets are being dropped?
Now coming to the second issue, if I try to run tcpdump to capture the packets, as soon as some packet arrives on RX of this dummy0 interface the whole virtual machine hangs (I guess the kernel panics). Is there something that I am missing in the code which causes this issue?
I was able to solve both issues by adding:
skb2->protocol = eth_type_trans(skb2, dev);
just before netif_rx(skb2).
I'm trying to measure the RSSI from a station connected to my AP which is running OpenWRT. I know that by using iw wlan0 station dump or iw wlan0 station get [MAC], I should be able to see it. Though for some reason it doesn't show the RSSI on my AP.
Here is the output that I get:
~# iw wlan0 station get 40:b0:fa:c1:75:41
Station 40:b0:fa:c1:75:41 (on wlan0)
inactive time: 75 ms
rx bytes: 17588
rx packets: 134
tx bytes: 10771
tx packets: 76
tx retries: 3
tx failed: 0
tx bitrate: 6.0 MBit/s
rx bitrate: 6.0 MBit/s
authorized: yes
authenticated: yes
preamble: short
WMM/WME: yes
MFP: no
TDLS peer: no
I'm running hostapd and dnsmasq. Any ideas of how I can get the RSSI? Maybe somehow in C?
Thanks!
UPDATE
I was checking the code of iw, and for some reason NL80211_STA_INFO_SIGNAL comes up NULL - If anyone has an idea of why this could be happening, would be a great help!
UPDATE 2
Apperently the source of iw in the project I was working was changed and the line with the RSSI for some reason has been commented. This change has never been documented. Thank you for everyone that answered this question.
Sounds like either your are using a radio card/driver that does not provide the RSSI to the kernel, or you are using an out-of-date kernel module (package mac80211)
Dit you try the command "iwinfo wlan0 assoc" ? You might have better luck with this.
although it was posted long ago.. may be helpful
did you try :
sudo iw dev wlan0 station get [MAC]
(change [MAC] to STA mac address)
there is field "signal" if that help you.
I have a Dell Latitude E6410, which uses an Intel Ultimate N-6300 Wireless card. iwconfig does not show the Noise level of the wireless interface , wlan0. Does anyone know the reason for that?
precise#ubuntu:~/Desktop/Work/transmitter$ iwconfig
lo no wireless extensions.
mon0 IEEE 802.11abgn Mode:Monitor Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
wlan0 IEEE 802.11abgn ESSID:"AirPennNet"
Mode:Managed Frequency:2.412 GHz Access Point: D8:C7:C8:D7:A6:C1
Bit Rate=130 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=65/70 Signal level=-45 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:800 Invalid misc:540 Missed beacon:0
eth0 no wireless extensions.
I tried to use cat /proc/net/wireless and got these results
Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 64. -46. -256 0 0 0 818 566 0
Is -256 the noise level? How do i interpret this in dBm?
The answer lies within your driver and wireless card support.
I have a similar Dell Latitude model but with an Intel(R) Centrino(R) Advanced-N 6200 AGN wireless card. After issuing the iwconfig command, the output also revealed something similar - the Noise parameter was missing (this was done while in connection to an access point, of course).
Not happy with that, I got out another wireless card (Winstron NeWeb AR9170+AR9104 802.11abgn - basically a Proxim Wireless 802.11a/b/g/n Wi-Fi USB dongle) and issued the same command. The output was still the same, the Noise parameter was not there!
This wasn't what I had expected since I knew very well that we had used the same Wi-Fi dongle to detect the noise level associated with access points using a proprietary software by Fluke Network called the AirMagnet WiFi Analyzer PRO. I even tried downloading and re-compiling the Linux Wireless Tools package from Jean Tourrilhes' but similar output was shown as before.
The next step I did was to verify again that the WiFi dongle actually does show the WiFi noise levels under the AirMagnet WiFi Analyzer software. Sure enough, it does (as depicted in the attached image below).
The blue column with the header 'N' refers to the noise level. Mind you, the WiFi dongle also came along with a proprietary driver when we bought the AirMagnet software along with it.
Having done that, I decided to see what it would show for our internal WiFi card (Intel(R) Centrino(R) Advanced-N 6200 AGN). Here are the results:
All of them are displaying values of -100! So, I believe it all has something to do with the driver/card capabilities.