 | 1 | initial version |
my new MacBook Air
There's your problem.
the en0 set with promiscuous mode and monitor mode checked, I see nothing.
Newer MacBook models apparently have AirPort adapters that can't run in monitor mode when they're associated with a network; Apple apparently "helpfully" "protect" users from disconnecting from their network by having monitor mode, when selected the normal way, capture any traffic. The sniffer in Wireless Diagnostics disconnects from all networks and then fires up tcpdump with the -I flag, so that it puts the adapter in monitor mode.
unchecking the monitor mode shows my MacBook communicating with the wifi.
That's just getting packets to and from the adapter; as it's not in monitor mode, that's all you'll see.
(And you won't get 802.11 headers or radio information, you'll get fake Ethernet headers; the only way to get 802.11 headers and radio information is to capture in monitor mode.)
if I manually airport -z and then airport a specific channel (or run wireless diagnostics and put the sniffer on that specific channel), I see the packets of the smartphone but that's it. nothing coming back to the smartphone from the printer.
That's odd. You probably have an access point on your network, with all network traffic going through the access point, in which case the packets would go from the smartphone to the access point and the access point sends them to the printer, or they would go from the printer to the access point and the access point sends them to the smartphone.
(I captured in monitor mode on my recent MacBook Pro (which has the same issue), and had another Mac ping my iPhone, and the capture appears to show both the ping going from the Mac to the access point and the same ping going from the access point to the phone (I didn't set up the capture to have the initial "EAPOL handshakes" for the Mac and the iPhone, so I couldn't get Wireshark to decrypt them). So you would probably see both of those packets.)
If your access point is using multiple channels, and the phone is using one channel and the printer is using another channel, and you're capturing on the first channel, you wouldn't see traffic between the access point and the printer. However, you should see traffic between the access point and the phone - including the replies from the printer being sent from the access point.
How are you determining whether the traffic involves the smartphone or the printer? If you're looking at MAC addresses, check the destination and source addresses; a packet that was sent from the printer to the access point, intended to go to the smartphone, will have the printer's MAC address as the source and transmitter address, will have the phone's MAC address as the destination address, and will have the access point's MAC address as the receiver address. The version of that packet that the access point forwards to the phone will have the printer's MAC address as the source address, will have the access point's MAC address as the transmitter address, and will have the phone's MAC address as the destination address and the receiver address.
also the packets are all wifi
If you're seeing Data or QoS Data packets, that's probably because your network is a "protected" network, with encrypted traffic, and Wireshark doesn't have the information necessary to decrypt the traffic. See the Wireshark Wiki's "How to decrypt 802.11" page for information on how to provide that information (it's more than just supplying the network password, for almost all networks; you may have to disconnect the phone and the printer from the network, by putting them to sleep, and then getting them to reconnect, by waking them up, while the capture is in progress, so Wireshark has the initial "EAPOL handshakes").
whereas in the past, I was able to see IPP and other type of packets.
Perhaps either the network wasn't protected then, or you supplied the password and, for newer forms of encryption, you got the "EAPOL handshakes".
