On 802.11 if I send a unicast frame, receiver will acknowledge by sending an ACK frame. But what about a broadcast frame? For example, A want to send a broadcast frame. A sends it to AP, AP acknowledges. Then AP broadcasts the frame. Does the AP listen for ACKs?
What about 802.3 Ethernet? Does Ethernet broadcasts ask for ACKs?
Thanks!
No, the AP will not listen for acks when it broadcasts your (broadcast) frame. And no, 802.3 Ethernet does not ack broadcasts either.
No. For broadcast data/frame AP won't expect and listen acks. In 802.3 Ethernet also it doesn't give ack for broadcast frame
Related
When I use Wireshark to capture traffics with my wlan card with monitor mode already set, it only displays 802.11 frames. However, if I use Wireshark with managed mode wlan(promiscuous mode), it certainly displays 802.3 frames.
I searched for some related information and found out that 'network bridging' allows devices to convert 802.11 wireless packets to 802.3 packets. In case of packet capturing, pcap allows conversion.
(link: How to real time convert wireless packet(802.11) to Ethernet packet(802.3) in windows?)
So, Why is 802.11 to 802.3 frame conversion impossible when using monitor mode(not associated to the wireless network)?
Below are pictures of the situation. Thank you in advance.
Promiscuous mode packet capture
Monitor mode packet capture
For one thing, not all 802.11 packets have Ethernet equivalents; only data packets do. In monitor mode, in addition to data packets, control and management packets can be captured - you're seeing those types of packets in your monitor-mode capture.
For another thing, when capturing in monitor mode on a "protected" network (WEP, WPA), data packets are encrypted (to protect them from being sniffed), and can't be converted to Ethernet packets until they're decrypted. Under some circumstances, Wireshark can decrypt them, but Wireshark doesn't do any conversion from 802.11 to 802.3 in any circumstances - when not capturing in monitor mode, the 802.11 adapter converts data packets to 802.3 packets after decrypting them, and doesn't show non-data packets to the host.
After setting up promiscuous mode on my wlan card, I started capturing packets with wireshark. But only broadcast packets or packets destined to my localhost were captured. I cannot find the reason why.
Also, after changing to monitor mode, captured packets all had 802.11 headers unlike promiscuous mode where Ethernet frames were captured. I know devices communicate with 802.11 protocols when wireless. But how is it possible that packets captured in wireshark is displayed in Ethernet frames? (when not in monitor mode)
I am a Wireshark learner and currently I am using Tshark to sniff my network packages. Currently my local IP is 192.168.0.114 and my collegue is 192.168.0.102.
However when I start capturing packets, I receive some packets with source IP 192.168.0.102 and destination IP 192.168.0.255. I am not the sender nor the receiverWhy am I seeing those packets? Here is my code just in case>
capture = pyshark.LiveCapture(interface='eth0')
capture.sniff(timeout=50)
capture
192.168.0.255 seems to by the broadcast IP address : 192.168.0.102 send this message to all other hosts on the network, your computer is receiving it as a member of this subnet.
The mask is probably 255.255.255.0 :)
wireshark/tcpdump in Ubuntu, was capturing all 802.11 wifi packets ( beacon, probrequest, probresponse, association request/response and data packets). Now only beacon, prob response packets capturing. pls help, what is the problem for capturing other packets.
On an iPhone I have created a UDP socket and bound it to the WLAN interface. I enabled SO_BROADCAST and I am able to send broadcast packets to the network (confirmed by a client running on my notebook.) But the UDP socket on the iPhone is unable to receive broadcast packets.
In my opinion this is a kernel bug, because not allowing a socket with SO_BROADCAST enabled to receive any broadcast packet, is a bad design decision.
The problem is further described here and here. The most popular solution to this problem is to bind to INADDR_ANY. However, it would be nice to be able to bind an UDP socket to only one interface while still receiving broadcast packets! Is there really no way to achieve this?
(When I bind a socket to 192.168.1.7 on a class C net (/24), it should accept packets sent to 192.168.1.7 and packets sent to 192.168.1.255!)
Thanks!
pls check below link may be it's helpful.
Receive udp broadcast packets ios
iPhone UDP broadcast and response
iOS UDP broadcast vs. PHP UDP broadcast
https://github.com/robbiehanson/CocoaAsyncSocket