I am trying to capture the live packets from available interface. My code is developed in go lang and for capturing purpose, I am using google's go packet library.
I am able to capture packets but I am unable to get precise timestamp.
If I run the below command and see the timestamp in wireshark, I am getting accurate difference between timestamps.
tcpdump -i device0 -j adapter_unsynced -w captureOnMachine.pcap
But, If I generate tcp dump using go packet library there is no precision.
I looked over the internet about adapter_unsynced command and saw
PCAP_TSTAMP_ADAPTER_UNSYNCED - adapter_unsynced
Time stamp provided by the network adapter on which the cap-
ture is being done. This is a high-precision time stamp; it
is not synchronized with the host operating system's clock.
Can we get same setting in docker or go packet library.
Related
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 need to analyze the wireless traffic occurring in Ch 1 of 802.11g. I have captured all the traffic logs using NETMON as test.cap file.
Q: How can extract the information using tshark to suitable format so that it can be used for further post processing?
I have captured all the activity in Ch11 but in wireshark it shows only 802.11 in protocol.
That usually means "the traffic is encrypted and Wireshark doesn't have enough information to decrypt it"; it does represent activity.
So if you're capturing on channel 11, an I/O graph in Wireshark, rather than anything extracted using TShark and further processed, should suffice to show the level of activity on that channel. You'd only have to dissect it if you want to see what type of traffic, at a higher level, that activity is, but it sounds as if you just care about activity, no matter what the packets are.
I am using Axibase Time Series Database Community Edition, version 10379. I try to store my data that comes from a force sensor and save it every 2 milliseconds, how can I configure the portal to accept this time resolution?
I made an attempt to send the data in that rate by using an Arduino board with WiFi shield but the TCP connection disconnected after sending a little data.
Time resolution in Axibase Time-Series Database is 1 millisecond by default, so the problem is probably occurring for other reasons such as:
Invalid timestamp
Missing end-of-line character at the end of the series command
Same timestamp for multiple commands with the same entity/metric/tags. For example, these commands are duplicates and one of the them will be discarded:
series ms:1445762625574 e:e-1 m:m-1=100
series ms:1445762625574 e:e-1 m:m-1=125
Overflow of receiving queue in ATSD. This can occur if ingestion rate is higher than disk write speed for long period of time. Open ATSD portal in the GUI and check the top right chart if rejected_count metric is greater than zero. This can be addressed by changing default configuration settings.
Other reasons specified in https://axibase.com/docs/atsd/api/data/#errors
I would recommend starting netcat in server mode and recording data from the Arduino board to file to see exactly what commands are sent into ATSD.
Stop ATSD with ./atsd-tsd.sh stop
Launch netcat in server mode and record received data to command.log file:
netcat -lk 8081 > command.log
Restart Arduino and send some data into ATSD (now netcat). Review command.log file
Start ATSD with ./atsd-tsd.sh start
Disclosure: I work for Axibase.
Setup and observation
I have a PC equipped with an Intel i350 T2 NIC where I would like to capture on both interfaces simultaneously using tcpdump. Both interfaces are connected to a 100mbit HUB (sic!) which forwards various traffic from an external traffic source to both interfaces at the "same time", so I can measure the difference of the timestamps done by the respective ethernet MACs.
Capturing simultaneously with:
user#rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth2 -w test_eth2.pcap
user#rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth3 -w test_eth3.pcap
After that I merge the two files together to compare the timestamps:
user#rt:~$ mergecap -F nseclibpcap -w merged.pcap test_eth2.pcap test_eth3.pcap
Wireshark then shows me, that for a few packets I get a timestamp diff of the duplicate frames of around 20-40nsec (which is nice and sufficient for my application!).
But there are also lots of frames which show a difference of up to tens of microseconds when comparing the respective duplicates.
Environment
user#rt:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
user#rt:~$ uname -r
3.19.0-28-generic
user#rt:~$ lscpu | grep "Model name"
Model name: Intel(R) Core(TM) i7-4790 CPU # 3.60GHz
Questions
How/Who does the syncing of the adapter clock to CLOCK_REALTIME (I presume)
How often does this syncing occur.
Is there some room for tweaking without too much effort?
Is it possible to use e.g. phc2sys to sync all adapter clocks to CLOCK_REALTIME?
Would (4) interfere with the mechanisms done by (1)?
THX for help or pointing out my mistakes!
From a quick glance at igb_ethtool.c your NIC indeed seems to be capable of hardware timestamping. The jitter you observe (20-40ns) is just in the range of the expected PHY jitter from synchronizing to the Ethernet clock. (For 100Mbit the clock is 25MHz or 40ns.)
So far looking great, thanks to Intel. Not many NICs/drivers have this capability.
Now the bad part: I doubt anything is syncing CLOCK_REALTIME to the NIC adapter clock at the moment. The clocks are probably free-running at a slightly different frequencies. Those oscillators are usually specified at 50ppm, typical drifts will be around 5ppm, which means they will drift apart by ~5us every second, varying with room temperature. Keep that in mind when using the nanosecond precision. If your system uses NTP you may even see NTP drift adjustments happening.
But the good news is that you probably don't need to synchronize them, unless you really want absolute timestamps. The main reason why your NIC supports hardware timestamping at all is probably to support IEEE1588 PTP (precision time protocol). If you need absolute time with sub-microsecond precision, you should look look at this protocol and/or buy a GPS receiver.
If you just need relative timestamps, you could try -j adapter_unsynced instead of -j adapter, or maybe you could try to stop NTP from trying to drift-correct your system clock. If all this fails, you could try to start linuxptp, which may have the capbability to properly sync NIC and system time even if you don't have a PTP network.
And finally... you are using a HUB, which means Ethernet is running in half-duplex mode, which means... collisions. Unless your NIC is absolutely quiet. I guess in theory this shouldn't matter because you observe the same collisions in both NICs, and frames aren't delayed or queued differently depending on which path they take. But since half-duplex is so rare these days it may be that NIC timestamping support wasn't implemented with that in mind. Typical bugs in such implementations are e.g. returning the timestamp of the previous frames instead of the current one.
Chapter 7.9 of the Intel i350 Datasheet may help you with your 3rd question. It provides the set of PTP registers you can configure in the igb driver.
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-controller-i350-datasheet.pdf
I would like to capture the "incoming" interface and "outgoing" interface for packets transiting through a software switch (assume it has 10 ports and I want to know which of those 10 interfaces a particular packet came from). I can't seem to find any way to get "tcpdump -i any" to output the arriving or outgoing interfaces. It only gives fields of the packet. Is there any other derivative of tcpdump (like tshark perhaps?) which will enable extracting the port information? The intention is tracing a packet flow path through a network. Regards.
tcpdump 4.10 should include this feature (hasn't been released as of today).
Meanwhile you can use Sebastian Haas's script.