I'm using a macbook air with osx 10.8.4 and i want to sniff the packets in with same Wi-Fi network.
I installed the tcpdump and i can get my own machine's packages. But i can not get the packages of my iphone which is in the same wifi network.
I have done some research and find that i should use a param -I to start monitor mode. So i write a command
sudo tcpdump -In -i en0 host 192.168.1.102
192.168.1.102 is the ip of my iphone in the network. And after running the cmd, the wifi icon on my computer in the top bar add 'an eye' on it.
But unfortunately, when i surf the internet with my iphone, the tcpdump still shows nothing. Why?
If you capture in monitor mode on a protected (WEP or WPA/WPA2) network:
filters used when capturing that apply above the link layer, such as host 192.168.1.102, will not work, because the filter will be used with encrypted packets;
unless the program reading the capture can decrypt the packets, they will just show up as 802.11 Data packets, not as, for example, HTTP-over-TCP-over-IP packets.
tcpdump doesn't support decryption of encrypted 802.11 packets. Wireshark does, but, as the Wireshark "how to decrypt 802.11" page indicates, you need to supply the password for the network, you must either be using WEP or be using WPA/WPA2 Personal/Pre-Shared Key mode (WPA/WPA2 Enterprise/802.1X mode isn't supported) and, for WPA/WPA2, you must have, for any machine whose traffic is to be decrypted, the initial EAPOL handshake for the machine.
Related
What network utility on a MAC can help me see what devices, printers are available, listening etc on my wifi. Netstat does not seem to show me my printer or Android device. For example,
My macbook pro with ip address 10.1.140.255 but I can't see my Android phone with ip 10.1.140.77 or a printer on 10.1.140.95.
Considering that some of your devices may be passively just sitting there with no active connections to your computer, you can't find them by examining your computer; you'll have to go actively looking for them. That typically means a network scanner.
Here's a list: https://www.softwaretestinghelp.com/network-scanning-tools/
I like Nmap (https://nmap.org) with the Zenmap GUI (https://nmap.org/zenmap)
Just make sure you do this in your own network. Scanning somebody else's network will trigger alarms and is more than likely illegal.
Try arp -a instead. Netstat doesn't scan the network, it just provides information about your own device's connection to the network.
Edit: Try ifconfig | grep broadcast | arp -a
When you're on LAN, connecting to an IP involves resolving the IP into a mac address. ARP keeps a cache of all resolved IP addresses. Doing a broadcast ping indirectly triggers a resolution for all IPs on the network.
https://superuser.com/questions/124453/how-can-i-scan-the-local-network-for-connected-devices-mac-os
I am building a Mini-Project and I came across this problem..I have to find MAC Addresses of all Devices that were in my Home Network .Here I got all the devices local IP addresses (I pinged from 1 to 255 and noted down all responded devices IP's).Here i am using Windows with python 2.7.x .I do also need the Network Card Manufacturer Name.
In other words I just want the raw data that the WI-FI Watcher shows.
My aim to get MAC and Network Card Manufacturer Name
First of all please make sure you ping all the hosts in your subnet. I would ping the broadcast address first, then just in case all of them, maybe some of them did not respond to your broadcast.
This way you will fill the local ARP cache of your machine. Then you can run this executable:
arp -a -v
Which will output information on all the IP addresses and their corresponding MAC address.
Then it's just a matter of looking up the OUI of the MAC address.
In pure python, as you mention in your comment, you can use "Scapy". you can find an ARP ping example here:
https://freezion.com/2009/01/22/arp-ping-using-scapy/
Basically:
from scapy import srp,Ether,ARP,conf
conf.verb=0
ans,unans=srp(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst=sys.argv[1]),
timeout=2)
For OUI lookup, you can use this small bit of code, although it has an external dependency:
import requests
for addr in ['88:53:2E:67:07:BE', 'FC:FB:FB:01:FA:21',
'D4:F4:6F:C9:EF:8D', '23:45:67']:
vendor = requests.get('http://api.macvendors.com/' + addr).text
print(addr, vendor)
Also, you can try the OUI parser lib from Wireshark.
NOTE: this does not work if ICMP is disabled on the destination hosts, in that case you have to run a traditional portscan and find open ports.
I'd like to check the option to debug my kernel driver installed over remote physical machine (since I don't have firewire cables). Reading the relevant documentation, I haven't seen any limitation about remote physical debugging medium, so I deduced both firewire cables and ip over wireless network should work.
I thought that lldb remote connection using kdp-remote <machine-ip> would do the trick, but I don't get any response.
From remote VM however, it succeed even though the VM can be located on remote physical machine.
My boot-args configuration are keepsyms=1 debug=0x144 -v
We figured out the problem in the comments (item 2 below), but for posterity, here's a list of things to check if xnu kernel debugging isn't working:
The target machine must have a physical ethernet port which is connected via PCIe or Thunderbolt, or you must use a direct firewire connection (optionally via Thunderbolt). USB to ethernet adapters will not work on the target end. The client machine is less fussy, you can use wifi or USB-ethernet there.
The protocol uses UDP, not TCP. Have you got a firewall running on your lldb machine which might be blocking UDP packets? (You could try sending udp packets from target to client with the nc (netcat) tool while the machine is not crashed.)
Is the ARP entry correct on the client machine? arp <target ip> should yield the target interface's MAC address.
The crashed Mac will NOT respond to pings, only to KDP packets via UDP. So not getting pings back doesn't mean anything.
As far as I'm aware the machine won't request a new DHCP lease when it crashes, so that shouldn't be the problem, but you can always try setting a static IP address just to be sure.
Did you reboot after setting the boot-args? They only take effect on a fresh boot.
If SIP is active, you can only set nvram variables from the recovery environment from OS X/macOS 10.11 onwards. You can run nvram boot-args to verify that the settings stuck.
My personal recommendation is to use FireWire for kernel debugging if possible, it seems to be the fastest and most reliable in my experience.
I have few devices connected to wifi router, but pcap_dispatch() always returns 0 for wifi interface while live capturing on Mac OS X. The same code captures response in case of wired interface. Please clarify if I have missed any flag here.
If you are capturing in monitor mode, you will be getting native 802.11 packets, which do not look like Ethernet packets, so filtering similarly to Ethernet will not work.
Furthermore, if you're capturing in monitor mode on a protected network, i.e. a network using WEP or WPA/WPA2, everything past the 802.11 header will be encrypted, and you will not be able to filter on it.
So:
if you're on an unprotected network, try a filter such as
wlan dst 70:73:cb:c1:7c:61 and (arp or (vlan and arp))
if you're on a protected network, try a filter such as wlan dst 70:73:cb:c1:7c:61, and make sure the program that reads the packets either just blindly writes them out to a capture file or is capable of decrypting WEP or WPA/WPA2 packets (the only program I know of that can decrypt them is Wireshark, although some others might be able to do it as well).
My firm produces some devices with a network interface. The devices are sent with a IP address = 0.0.0.0. The customers plugs the device on the private net in the field and, by using a tiny app written with VB6, discover it and set the correct IP address.
This working by using UDP messages: the app broadcast a "Who's there?" UDP message, read back the answer(s) containing the MAC address of the device(s), and the the user send another UDP message containing the new IP address for target MAC.
Now, for some unknown reasons, one of these device get its IP address set to 127.0.0.2. The problem is that now the VB app can't find (via UDP) the device anymore, making it impossible to change the IP address to a valid one.
Further analisys revealed than if the app is running on Windows XP it sees the device, but if the app is running on Windows 7 the UDP message does'nt arrive to to the "socket" (while Wireshark can see the answer from the device).
Now, there a solution to allow Win7 to let "pass" an UDP message sent from a 127.0.0.2 external address? If yes, we could avoid to ship around the world a replacement device with a correct IP address and all the trouble of phisically mounting it in the field.
Here's a Wireshark capture of the "question" and the "answer" not "detected" by the VB app:
cap.pcapng
Now, for some unknown reasons, one of these device get its IP address set to 127.0.0.2.
You need to fix that.
The 127/8 block is reserved for the "loopback" address (ie. localhost). No packets sent to 127.0.0.2 will leave your systems NIC. Unless there are bugs in the drives (or hardware): this could be the case with WinXP.