What happens if a sender changes the TCP window size over multiple packets that have the same ACK number?

I’m currently doing research on evasion attacks that seek to bypass a Deep-learning based Network Intrusion Detection System.

In order to achieve this, I need to know what the constraints are for the TCP window size field in the TCP packet header. Imagine a client has just sent the last TCP-ACK packet to a server in order to complete the 3-way handshake. He then immediately proceeds to send a GET request to the server (these 2 packets are thus sent one after the other, and contain the same ACK-number).

What happens if the TCP window size in the TCP-ACK packet does not match the window size in the TCP packet containing the GET request? Will the receiver simply observe the last value for the window size that he obtained? Or will there be a violation in the TCP protocol in any way? You can assume that the change in window size is very small, and will not cause the buffer to be full.

More generally, if the client sends N uninterrupted packets (e.g. a heavy-load POST request), can he change the window size in each packet header without repercussions?

Malformed packets for OpenVPN

I have setup OpenVPN on pfsense 2.4.5, and captured sample data for my OpenVPN traffic. However, I observed that most of packets captures for OpenVPN is malformed.

What are the possible reasons? Below is a screenshot of the capture for reference. Any suggestion is helpful!

Thanks! Openvpn Sample Capture

Packets contained no EAPOL data; unable to process this AP

I’m trying to hack my own WiFi using aircrack but have had no success. With aircrack I cannot achieve a successful handshake as the deauth doesn’t seem to have any effect on my targeted devices. This is what it outputs:

root@RPI02:~# aircrack-ng -w password.lst *.cap Opening WIFI_APPLE.cap-01.cap.. Read 180751 packets.     #  BSSID              ESSID                     Encryption     1  F1:2E:DG:F2:EE:0F  WIFI APPLE                WPA (0 handshake)  Choosing first network as target.  Opening WIFI_APPLE.cap-01.cap.. Read 180751 packets.  1 potential targets  **Packets contained no EAPOL data; unable to process this AP.** 

What exactly means this line?

Packets contained no EAPOL data; unable to process this AP.

man-in-the-middle’d packets have bad and incorrect checksums on localhost, how to find the malware?

Am trying to fix a man-in-the-middle’d macOS Catalina machine. Have been viewing packets with tcpdump and noticed, on connecting to any web address, there are legit packet that gets sent to the DNS server… then… there are packets that get sent from (or some port) to — the packet headers are labelled with incorrect checksum (cksum -> incorrect). Also, there are packets (or some other port) -> labelled bad checksum (bad udp cksum). And, again localhost, -> again with bad checksum (bad udp cksum). All this traffic is on the lo0 adapter.

Example of a man-in-the-middle incident on the machine:

Legit: Wiki article on different machine and different network Wiki article on man-in-the-middle'd machine

MITM: Wiki article on man-in-the-middle’d machine Wiki article on different machine and different network

Packet traces

Incorrect checksum destination Incorrect checksum destination

Bad checksum destination Bad checksum destination

Bad checksum source destination Bad checksum source destination

Attempts to find process:

sudo lsof -i sudo lsof -i

netstat netstat

My guess is this is related to some corruption with mDNSResponder? Welcoming and appreciate any tips or suggestions on how to solve.

Many thanks

Local Burp Proxy not showing routed packets

I created a hotspot on wlp2s0 and connected an android device, whose IP is

I am trying to route my all packets from my wlp2s0 interface to burp proxy which running on 8080 and I also enabled invisible proxy, but still no luck

I am routing packets using this firewall rule

iptables -t nat -A PREROUTING -s -p tcp -j REDIRECT --to-ports 8080 

After enabling this rule Internet access on device stops working means rule is working, but burp proxy is not showing any data flow.

Please anybody point out what I am doing wrong, I wasted many hours in this.

Update: I was trying Burp Proxy on PC browser and was playing with proxy settings like Socks5 and resolve dns over Socks5 and then burp proxy stopped working even on PC browser. So I think when I route packets through Burp then it not resolves DNS queries and then my android stucks at DNS requests and there is no flow of TCP packets, that’s why Burp Not showing anything. So, I think main question is how we can resolve DNS queries through Burp Proxy.

Why Do All Capture Packets Have 802.11 Prorocol and Broadcast Destination? [closed]

I am new to networking and packet sniffing. I have wireshark installed on my ubuntu machine. I am capturing packets but they all have 802.11 as protocol and Broadcast destination. I have enabled promiscuous mode and I set my network interface to monitor mode using airmon-ng check kill and then airmon-ng start wls1. I am listenning on wls1mon on wireshark. I don’t know what is causing this. I also tried to be on the same network as my test PC. But when I do this, I don’t capture packets even though the PC is youtube and having traffic coming over. I tried with tshark and it is the same problem. When I watched some videos on youtube about this, they all captured packets with different protocols. However, I didn’t pay attention wether they were on monitor or managed mode? Can someone please help me? What I am doing wrong?

how to prevent multicast packets from being snooped

As we know, any user can send IGMP to join a multicast group, which means an unauthirized user can capture any multicast packets in a traditional LAN.

I want to prevent the multicast packets from being snooped by unauthorized user, is there any technology for this?

I know IGMP snooping is a mechanism to analyze IGMP protocols at layer 2, but I am not sure if IGMP snooping can be set to forward the multicast packets only to the authorized LAN switch ports.

thank you in advance


Capture macOS/IOS system HTTPS packets

I tried to analyze the https traffic of apps on my MacBook and iPhone with Charles with SSL proxy (I use HTTP proxy for IOS and installed and trusted Charles certificate). I managed to decrypt most HTTPS traffic, however, when I discovered that I cannot connect to App Store on my iPhone when I was on the proxy, I realized none of apple’s traffic (AppStore, iCloud, etc) are decrypted by Charles (Charles was able of detecting those traffic by showing the domain name, but it said the client SSL handshake failed, same on macOS as well as IOS).

My speculation is that instead of relying on the system certificates, Apple uses a different, more restricted set of certificates to verify their own services (system level). I also heard about a technology called SSL pinning, which can achieve this feature.

I am not sure whether this is the case, if it is, how can we bypass this restriction?