I'm trying to analyse my Sniffer Capture and to get information about the STA, who sends deauth packets. Actually I'm doing it with my laptop and my AP to test my WLAN security
aireplay-ng [wlan inteface] --deauth 1000 -a {BSSID}
But where in this wireshark capture should I look for the MAC Adress from the station who sends deauth packets (my laptop)? All I can see here, it's like my AP sends packets to himself. Maybe it's a silly question, but I do not get it.
You send deauth to broadcast if command is used like this:
aireplay-ng [wlan inteface] --deauth 1000 -a {BSSID}
When this command is running from the laptop, packets will be sent with the AP address of the point specified in the "-a" option:
Source address = Transmitter Address = AP BSSID
Explanation of addresses:
Receiver Address: immediate recipient of the frame
Destination Address: final recipient of the data
Transmitter Address: STA that transmitted the frame
Source Address: source of the data
Related
Similar to How to set source address when sending using and UDP socket, but not identical:
I'm writing an experimental UDP packet relay.
The code works so far, but the problem is that the relayed packets have the address and port of the relay (instead of the original sender) as sending address in the outgoing packets, so any responses would also go to the relay, and not to the original sender.
Is there a standard way (without manipulating the packets directly) to do this?
Currently it has to work for IPv4 only.
I have a problem with UDP messages under Python3 on Windows10.
The UDP messages are a command/response scheme.
Example: CMD_TURN_ON_LIGHT_BULB, Bulb #4
Response: RSP_TURN_ON_LIGHT_BULB, Bulb #4 - OK.
My local Windows PC address is: 10.1.1.10
In all cases, the netmask here is 255.255.255.0
The remote device has 2 network addresses.
There are various routers between the PC and the remote device.
Device Address (A) is 10.2.2.10 (and is the "default route").
Device Address (B) is 10.3.3.10 (it is a backup interface)
Case 1: This works.
PC sends UDP to 10.2.2.10 (it uses "sendto()")
The remote device responds to the source address using sendto()
The PC receives the response, and the application receives the response.
The PC has a pending/waiting "recvfrom()"
Case 2: This does not work.
PC Sends UDP to 10.3.3.10 (the backup interface)
The remote device replies -
However - due to default route rules, the device replies from 10.2.2.10
The PC receives the reply (I see the reply/response in Wireshark)
The PC has the firewall 100% disabled
But - The application does not receive the UDP message from the remote device.
Any suggestions?
Stated differently:
This works: Transmit to UPD address (A), Port X - reply from: A, port Y
This fails: Transmit to UDP address (B), port X - reply from: A, port Y
The second case, the packet seems to be lost inside the bowels of Windows...
I'm doing this project, where I have to send a bunch of packets (using rte_eth_tx_burst) ,from one network card, to another network card. these 2 network cards are linked（by Fiber I guess? it was not me who linked them.）, so if I just use tcpdump to listen to the other network card, I can capture the whole thing, and store them into a pcap file.
My test environment:
1.a Linux machine, with 2 pairs of linked network cards: eth1 and eth2 are linked, eth3 and eth4 are linked also.
2.my program, listens to eth1.
3.I send a pcap file using eth2 (cmd: tcpreplay -i eth2 test.pcap)
4.my program gets the packet stream, frame by frame, for every frame it recieves, it sends it out, from eth3, using rte_eth_tx_burst() provided by dpdk.
5.I run tcpdump to listen to eth4(cmd:tcpdump -i eth4 -w recieve.pcap -B 1000)
My current problem is:
1. the frames are not in their original orders. (but the contents are the same.)
2. the time gap between frames are not the original gaps.(but I guess this is inevitable).
question:
1.does dpdk guarantees the send order for packets you put in the send queue.
2.perhaps it's because that tcpdump doesn't guarantee the order?
3.or is this problem unsolvable?
Yes, the order of packets send by tx_burst should be guaranteed, provided you're just using one queue.
The out of place packet you are seeing is a reply from eth4, as tcpdump also records outgoing traffic. Remember that the TCP stack is still working as usual on eth4.
Why not use DPDK to capture the packets too? It'd be more reliable and you'd only see incoming packets. Theres an utility for that: pdump. Or you can choose only incoming direction in tcpdump using -Q in.
Also, maybe you already know this, but there's an example app bundled with DPDK that does exactly what you're trying to do: L2FWD.
I am trying to learn something about sockets in Linux. I have small development board something like raspberry Pi with Linux running inside. Unfortunatly it doesn't have ethernet or usb port.
I have created a dummy network interface and used it like default gateway. I have written a small program using raw sockets listening on dummy interface (then sends all packets over serial line to computer where is program which send this packets to the internet and recieves answers a sends them back).
My problem is when i am trying to ping some public IP address i can see in tcpdump the ICMP requests and responses in both computer and development board. But the ping looks like it does recieve nothing.
I have tryed to use loopback interface instead of dummy interface, but in this case the pings gets looped and the device becomes unresponsible in a while :). But the ping did recieve ICMP response, and TCP connection didn't work.
I also have tryed to use 2 dummy interfaces and create bridge.
I would be very grateful for any advices.
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)