I've checked the latest Scapy sources and there isn't any 802.1AD support, yet I have seen Scapy scripts referencing Dot1AD.
For the record, 802.1ad support was imported into Scapy master on July 30, 2016. So you don't need to get scapy-com (no longer maintained) and can use the "regular" Scapy. The associated layer is Dot1AD().
After some additional searching it turns out that Scapy community has created a fork of Scapy which supports 802.1AD. Here is a link. Scripts referencing Dot1AD use the scapy-com module.
You can do the following:
>>> packet = Ether(src='94:c6:91:1c:68:c3',dst='94:c6:91:1c:68:1d')
Then add a 802.1ad layer:
packet = packet/Dot1AD(vlan=20)
Then display the packet:
>>> packet.show()
###[ Ethernet ]###
dst= 94:c6:91:1c:68:1d
src= 94:c6:91:1c:68:c3
type= n_802_AD
###[ 802_1AD ]###
prio= 0
id= 0
vlan= 20
type= 0x0
Related
The information I'd like to automate retrieval of via Bash or Python is what's contained in the Packet Details pane for the last layer, when viewing DIS protocol captured packets.
So far I've gotten to the point where I can read the Packet Bytes pane information with the Scapy library in Python, but this is much harder for me to interpret/work with.
from scapy.all import sniff
capture = sniff(filter="dst 10.6.255.255 and port 3000", count=5)
packet = capture[0]
print(packet.show())
raw = packet.lastlayer()
from scapy.utils import hexdump
hexdump(raw)
Is there any way that I can get the Packet Details pane information instead with Python or Bash?
Have you tried things like:
tshark -r file.pcap -O dis
or even
tshark -r file.pcap -Y dis -T pdml > file.pdml
Refer to the tshark man page for more information on these options and to the Wireshark PDML wiki page for more information about the "Packet Description Markup Language".
Hope I don’t get the question wrong :/
You have a pretty cool packet.show() function which looks somewhat similar to wireshark
You can also try pdf-dumping packet.pdfdump() (or svg-dumping with github version)
I have a problem with rsyslog.It works as a log collector for some devices. When I check with TCP dump i see bellow line is coming.
Facility user (1), Severity info (6)
Msg: 1 2014-01-26T15:21:25.345+03:00 XXX_XXX-Node1 [|syslog]
15:21:37.526894 IP (tos 0x0, ttl 245, id 36018, offset 0, flags [none], proto UDP (17), length 708) xxx.syslog > xxx.syslog: SYSLOG, length: 680
Length is 680. Before we upgrade the remote end it was same length and it was working fine. Nothing changed except version of remote end ( log sender ) But there is a strange [|syslog] entry there and i can not see the message.
Does anybody before hit kind of issue ? Do you have any ideas why it could happen ?
Thanks
Suner
By default tcpdump does not capture the entire packet. If you read the tcpdump man page, you'll find information about the -s option, which says:
-s Snarf snaplen bytes of data from each packet rather than the
default of 65535 bytes. Packets truncated because of a limited
snapshot are indicated in the output with ``[|proto]'', where
proto is the name of the protocol level at which the truncation
has occurred...
Your output contains [|syslog], which indicates the packet was truncated. Try specifying a larger value (e.g., tcpdump -s 1500 ...).
I used wireshark to collect data from some sites, and then used tcpdump to get it as a text file. For the project I'm working on, I want to count how many DNS resolutions are involved in accessing a particular website, and what the nature of the DNS responses was. The problem is I don't really understand the output from wireshark or how to interpret it to find what I'm looking for. For instance, here is a line:
21:08:05.454852 IP 10.0.0.2.57512 > ord08s09-in-f21.1e100.net.https:
Flags [.], seq 1:1419, ack 55, win 65535, options [nop,nop,TS val
1348891674 ecr 2473250009], length 1418
What do the different parts of this mean, and what will the data I'm looking for look like? I'm worried I might be using Wireshark incorrectly without knowing it.
I used wireshark to collect data from some sites, and then used tcpdump to get it as a text file.
Most people who use both tools use them for the opposite purposes. :-) I.e., they use tcpdump to capture traffic into a file and then read the file with Wireshark. If you're only using Wireshark to capture traffic, that's probably overkill - you can do the same thing with dumpcap or possibly even tcpdump.
The output you're showing is text output, so, if you "used tcpdump to get it as a text file", it's output from tcpdump, not from Wireshark; text output from Wireshark would look different. If you "used wireshark to collect data from some sites, and then used tcpdump to get it as a text file", the output from Wireshark is either a pcap file or a pcap-ng file, which is a binary file, and is completely uninterpreted raw data. The interpretation of the data in your example is being done by tcpdump, not Wireshark.
What the output is saying is:
"21:08:05.454852": the packet arrived at 21:08:05 and a fraction of a second, local time.
"IP": the packet is an IPv4 packet.
"10.0.0.2.57512 > ord08s09-in-f21.1e100.net.https": the packet is from IP address 10.0.0.2, port 57512, to the IP address whose for which the host name is "ord08s09-in-f21.1e100.net", and the port for "https", which is port 443.
See the tcpdump man page, and a description of TCP, for details on the rest of the line.
The key point here is that this is NOT DNS traffic! It's probably "HTTP-over-SSL", or "https", traffic.
In tcpdump, DNS traffic would look like
11:06:25.247272 IP 10.0.1.3.50953 > 10.0.1.1.domain: 7088+ A? www.kernel.org. (32)
11:06:25.282723 IP 10.0.1.1.domain > 10.0.1.3.50953: 7088 3/0/0 CNAME pub.us.kernel.org., A 149.20.4.69, A 198.145.20.140 (85)
or
11:06:30.622744 IP 10.0.1.3.62767 > 10.0.1.1.domain: 2439+ A? e3191.c.akamaiedge.net.0.1.cn.akamaiedge.net. (62)
11:06:30.639279 IP 10.0.1.1.domain > 10.0.1.3.62767: 2439 1/0/0 A 184.85.109.15 (78)
"A?" means that a query is being done for an A record; "CNAME" means that a CNAME record is being returned (i.e., "www.kernel.org" is an alias for "pub.us.kernel.org", and "A" means that an A record is being returned, giving an IPv4 address.
In Wireshark or TShark, it would look like:
12.316361 10.0.1.3 -> 10.0.1.1 DNS Standard query 0xc2fa A 1.courier-sandbox-push-apple.com.akadns.net
12.332894 10.0.1.1 -> 10.0.1.3 DNS Standard query response 0xc2fa A 17.149.34.59 A 17.149.34.61 A 17.149.34.62 A 17.149.34.63 A 17.149.34.57
or
15.163941 10.0.1.3 -> 10.0.1.1 DNS Standard query 0x168c A www.gnu.org
15.176266 10.0.1.1 -> 10.0.1.3 DNS Standard query response 0x168c CNAME wildebeest.gnu.org A 208.118.235.148
If you're only trying to capture DNS packet, you should use a capture filter such as "port 53" or "port domain", so that non-DNS traffic will be discarded. That filter will work with Wireshark, TShark, or tcpdump (as they use the same libpcap code for packet capture).
How do I get the MAC address of the interface I am sending packets with?
I am trying to create a custom ARP packet, and I need to include my own MAC in it. I can not seem to find a way to get it.
Take a look at the get_if_hwaddr() function.
Doc: https://scapy.readthedocs.io/en/latest/routing.html
This code may help you :
my_macs = [get_if_hwaddr(i) for i in get_if_list()]
Cheers,
K.
You can easily by:
from scapy.all import Ether
print(Ether().src)
This prints the MAC address of the default interface you're using.
The Netifaces Python Package provides a great amount of information about the interfaces you are working with.
>>> netifaces.ifaddresses('en0')
{18: [{'addr': '00:12:34:56:78:9a'}], 2: [{'broadcast':
'10.255.255.255', 'netmask': '255.0.0.0', 'addr': '10.16.1.4'}],
30: [{'netmask': 'ffff:ffff:ffff:ffff::', 'addr':
'fe80::123:4567:89ab:cdef%en0'}]}
http://alastairs-place.net/projects/netifaces/
I have a third party dll, that is supposed to return machine name.
Sometimes it returns
\\John-PC
some other times it returns
\\192.168.1.120
and recently i discovered that it returns something like this
\\[ef80::32d6:2255:27dd:123c]
So what is the third option?
If it is not a bug or MAC orelse, could i convert it to \192.168.1.120 and get happy???
It is the IPv6 version of the IPv4 address 192.168.1.120
. It also amuses me how your DLL seems to be indecisive with what to return.
It's an IPv6 address. IPv6 allows you to leave out sections that are equal to 0, hence the ::.
The 3rd option is a IPv6 address