I'm using cocoaAsync to handle udp communication.
When i use the sendData API of cocoaAsync ,I'm sure sendto is success,from the log. But I can't see any output data from Wireshark .
This is not 100% reproducible, but very probably.
I can't figure out what could be the problem.
Thanks very much for any tips.
If you are sure that you are sending the packets right then following can be possibilites,
If you are sending and receiving on same machine then it is possible that your Wireshark do not capture. Try sending to some different destination than your machine.
Also there can be multiple network interfaces on your machine (e.g: eth0, eth1 etc...) for Wifi and Network-Card. Please make sure you are capturing packets on the right interface. You can select interface when you press the Capture button on Wireshark.
I hope this helps.
Related
I am trying to ping a host and capture the packets using Wireshark. I need to view the results in ICMP so I can view the IP addresses, but Wireshark keeps capturing the packets in ICMPv6 and as a result I can only see MAC addresses. Is there a way to change that?
I've tried looking in the options of my capture interfaces and didn't really find anything helpful. I'm not sure if it's a Wireshark issue or an issue with my system.
I'm trying to write a simple C code with WinPcap to broadcast a beacon packet and capture it in all nearby WiFi units. The code I'm using is very similar to the ones available at WinPcap[1].
The code runs fine if I create an ad-hoc network connection and join all the computers into it. However, this process of creating and joining to an ad-hoc network is cumbersome. It would be much better if, regardless of what network each computer is in, the beacon packets would be broadcasted and captured once the code is running.
As simple as this problem might sound, after some searching it seems that this is not possible to be done on windows (unless re-writing drivers or maybe the kernel):
Raw WiFi Packets with WinPcap[2]
Sending packets without network connection[3]
Does winpcap/libpcap allow me to send raw wireless packets?[4]
Basically, it would be necessary to use the WiFi in monitor mode, which is not supported in Windows[5]. Therefore, if the computers are not in the same network connection, the packets will be discarded.
1st Issue
I'm still intriguing, beacon and probe request packets are a normal traffic across the network. How they could be being sent and received constantly but the user is not allowed to write a program to do so? How to reconcile that?
2nd Issue
Does anyone has experience with Managed Wifi API[6]? I've heard that it might help.
3rd Issue
Acrylic WiFi[7] claims to have developed a NDIS driver which support monitor mode under Windows. Does anyone has experience with this software? Is it possible to integrate with C codes?
4th Issue
Is it possible to code such Wifi beacon on Linux? and on Android?
www.winpcap.org/docs/docs_412/html/main.html
stackoverflow.com/questions/34454592/raw-wifi-packets-with-winpcap/34461313?noredirect=1#comment56674673_34461313
stackoverflow.com/questions/25631060/sending-packets-without-network-connection-wireless-adapter
stackoverflow.com/questions/7946497/does-winpcap-libpcap-allow-me-to-send-raw-wireless-packets
en.wikipedia.org/wiki/Monitor_mode#Operating_system_support
managedwifi.codeplex.com/
www.acrylicwifi.com/
Couple questions I will try to answer. Mgmt and Ctrl packets are used for running a wifi network and don't contain data, I would not call these normal packets. Windows used to(I think still does) convert data packets into ethernet frames and pass it up the stack. Beacon and Probe Req pkts are not necessary for TCP/IP stack to work, ie. web browsers don't need beacon frames to get your web page. Most OS's need minimal info from mgmt/ctrl pkts to help a user interact with a wifi adapter, most mgmt/ctrl pkts only are useful to the driver(and low level os components) to figure how to interact with the network. This way the wifi adapters look and act like ethernet adapters to high level os components.
Never had any experience with Managed Wifi API or Acrylic, so can't give you any feedback.
Most analyzers that capture and send packets do it in 2-3 separate modes mainly because of hardware. Wifi adapters can be in listen mode(promiscuous mode and/or monitor mode) or adapter mode. To capture network traffic you need to listen and not send, ie. if someone sends a pkt while you are sending you miss that traffic. In order to capture(or send) traffic you will need a custom NDIS driver in windows, on linux many of them already do. Checkout wireshark or tshark, they use winpcap to capture pkts in windows and there are some adapters they recommend to use to capture pkts.
Yes it is possible to send a beacon on linux, ie. Aireplay. I know its possible to capture traffic on Android but you it needs to have rooted or custom firmware, which I would believe also means you can send custom pkts. If you are simply trying to send a pkt it might be easier to capture some traffic in tshark or wireshark and use something like aireplay to resend that traffic. You could also edit the packet with a hex editor to tune it to what you need.
I have a packet capture and I'm trying to find out which program a download was made with, where would I go in the packet to find this information?
Thanks all!
Instead of looking for answers within the packet, you may want to look at which port the download was done through. That could give you more information, and faster
I assume you know the destination ip address from where the file is downloaded. If it's something that you can catch while it's happening or you can trigger it then you could use netstat to determine the PID of the program that is handling that socket after filtering the netstat output based on the destination ip address.
Then you could use ps on Linux or TaskManager on Windows to know which program has that PID.
On windows: How to determine which program uses or blocks specific transmission control protocol ports in Windows
Alternative if the packet capture it's all you got and it's not a recurring event then if the download was done via HTTP you could check the headers of the HTTP request for info about the client in the User-Agent header.
Hope it helps.
I'm currently implementing my first application in Contiki on a Telos bmote and encountered a problem.
For my application (which utilises the uIP IPv4 stack) I need to be able to broadcast messages to all nodes.
I have looked through the source and found that in uip_over_mesh.c the packet is found to be for an external network and is then being sent to a gateway node on the network instead of being distributed to all nodes. If no gateway node is present it just drops the packet.
So in fact rather than the packet being broadcast to all the nodes in the network it's either just being dropped or being sent to just the gateway node and external network.
My problem is that I need it to broadcast to the other nodes in the network(as it should), is there a step I'm missing or am I doing something wrong?
Thanks :)
p.s. This is the rough code to get the message to send.
struct uip_udp_conn *udp_conn = udp_broadcast_new(UIP_HTONS(5001), state);
udp_bind(udp_conn,UIP_HTONS(5001));
uip_udp_packet_send(udp_conn, "hello",5);
Sorry that my question didn't seem clear. To clarify what I wanted to do was send an IPv4 UDP packet to the broadcast address i.e. send to all devices on the network using the all ones addr. But I found that the sending device would only forward the message to a gateway node if it was present on the network.
The question is not clear but what I understand from the question you want to broadcast a message anonymously to all neighbour motes. You have two choices to go.
If you are using RIME stack from contiki. There is already a code under example/rime/example-broadcast.c (have a look at line 79,80 ( packetbuf_copyfrom("Hello", 6); broadcast_send(&broadcast)); I have tested the code and it is working perfectly fine under teleosB. I strongly recommend you to go with uIP (IPv6) stack using RPL. For a large network it 'll be extremely hard to maintain rime stack.
You can use udp based ipv6 enable broadcast example from examples/ipv6/simple-udp-rpl. You do n't need to change anything for receiver function unless you want more additional features. This function 'll print receiver port, sender port and data length. You can add "addr" from "uip_ipaddr_t" in the receiver function if you want to print IP addresses. For sender the lines of code are (76-91). You do n't need to change for simple message like "hello". I tested the code and it works perfectly fine.
After lots more reading of the Contiki source I found that the problem lay in uip_over_mesh.c.
When a broadcast message(255.255.255.255) was being sent it was tripping up when the send function would check if the destination was within the local network (based on the netmask and destination address). Failing this it would then try to send it out to a local gateway(if one existed) to route it out of the network.
Although IPv4 UDP broadcast had been built into the api, I saw no evidence of it actually being implemented in the uip_over_mesh.c(I might be wrong and totally missed it). So to fix this I added a broadcast RIME channel and added a check for the all ones address where the previously mentioned gateway check was. A method to receive the broadcast messages was also implemented ensure broadcast message were correctly received and passed to the upper layers.
From what I gathered from here and the mailing list, IPv6 is where the focus is and not many people are knowledgeable or using the IPv4 uip stack. When I get some time I will dig up my modified uip_over_mesh.c and see if I can push the modifications, though I'm sure it's a bit of a hack and not of much use due to the above mentioned lack of interest.
I have an application that is designed and working that is receiving UDP broadcasts on a port. The application has been working just fine, but I have wanted to compare the packets received by the application with a Wireshark capture. I'm trying to make sure that I'm capturing as many of the packets as possible with minimal data loss.
I initially thought that I'd run Wireshark and compare the raw packets captured against the packets shown in our application. However, when I run Wireshark, the packets are never captured at the IP layer for that port. I see other traffic from the server, but I never see Wireshare packets for this specific port.
The application continues to capture the data just fine. When I look at the IP src/dest fields, the src looks correct, 10.12.10.42, however the destination IP address is 0.0.0.0. I would have expected something like 255.255.255.255 instead for the destination address.
I don't have access to the application that is broadcasting the data, but I did write a quick sample UDP broadcaster and receiver to make sure I my expectations were correct. the sample application worked as expected.
Any ideas on why a UDP broadcast would be received by an application, but not show up in a Wireshark capture? Does Wireshark ignore an address like 0.0.0.0 and not capture it all?
Wireshark only captures Ethernet frames that are going through an interface you are listening on. Thus, packets destined on loopback addresses are not captured. I would check your machine's routing tables to see where packets are actually going.