Tcp – how to capture only SMTP using latest Wireshark 2.2.6 or later

I will assume from your questions tag that you are using TCP.

A likely explanation that does require some assumptions about your code is that it's an interaction between Nagle's algorithm (an algorithm designed to prevent unnessacery small packets) and TCP delayed acknowlagements (an algorithm designed to avoid sending unnessacery bare acks when an ack could share a packet with application data).

Lets say your applicaiton sends data to the OS in two (or more) parts, first it sends a header, then it sends the actual data. I don't know for sure that this is what you are doing but it seems the most plausible explanation to me. For small messages the following sequence of events happens.

1. The client application sends the header to the client OS.
2. The client OS sends the header to the server.
3. The client application sends the body to the OS
4. Since there is unacknowlaged data in-flight Nagle's algorithm kicks in and the OS holds back the data hoping for more.
5. The server OS receives the header, since it's a single packet it holds back the ack hoping for an application response or a second packet to arrive from the client.
6. We now have something of a deadlock. The client doesn't want to send out another small packet because there is already unacknowlaged data in-flight. The server doesn't want to send out an ack because there has been no application response.
7. Eventually a timeout breaks the deadlock.

At larger message sizes the interaction changes. Depending on the exact rules the server uses for delayed acknowlagements there can still sometimes be delays but they don't seem to be too significant in your case.

Possible fixes for this problem include using the TCP_NODELAY socket option and/or reworking your application code to build the complete packet before sending it to the OS in one peice.

Great topic. I'd like to preface my answers with some relevant information, then answer your questions as you've asked. "Roaming" is defined as a wireless client migrating from one access point to another. "Seamless" roaming (aka Fast Roaming, aka Zero Handoff, aka IEEE 802.11r) is defined as a wireless client migrating from one base station to another in a fast, seamless, and "secure" manner.

Now to your questions. You asked, "I expect that somehow the new AP must inform the old one the station has roamed successfully and I suspect it must be done with packets sent through the switch. I really wanted to know: How It's done in practice?". Answer: The new AP does not inform the old ap that the station has roamed successfully. In fact, the two access points do not communicate to eachother at all. Even if they were the same model, they don't communicate to eachother. A wireless network designed as described above is not capable of "fast roaming", just "roaming". A real-world test to prove this to yourself is to connect a wireless VOIP phone to the wireless network, then have a phone conversation on it while roaming. You will hear a signifigant interruption in your conversation. Fast roaming would be achieved with another wireless design using a wireless controller (or a bridge). But your question is, "How is it done in practice" ("it" being how the communication occurs for a successful wireless client migration from one ap to another). Here's how it happens in the network you have designed, which is a normal SOHO network. The client is already connected to an access point. As it physically moves, the client wirelessly probes and finds that another access point also has the BSSID it uses AND has a stronger wireless signal (aka RSSI value) than the one it's currently connected to. Before we continue, let's state one fact. A wireless client can only be associated to one access point at a time. So knowing this, it must "disassociate" from the one it's connected to now before it can "associate" to the stronger one. So the wireless client sends it's current access point a "disassociation request" (aka Disassociation Frame) and disconnects from it. Then, the wireless client connects to the new access point by going through its association and authentication process. Once the wireless client is accepted onto the new access point, that access point communicates to the switch that the mac address can now be found on this switchport. The switch updates its mac address table and moves the wireless client's mac from the old access point's switchport (in the table) to the new switchport belonging to the new ap. At this point, the wireless client begins network communication. All of that was done and the two ap's did not communicate to eachother at all.

Your second question is: (translated) What would those packets look like? Answer: On your wireless client, load the latest version of Wireshark and begin a packet capture before you roam. After you roam, stop the capture. You can analyze your traffic to whatever degree you are comfortable with. NOTE: It would be best to make sure you have the latest wireless "driver" on your device first. You mentioned that you tried sniffing on the switch and saw nothing. You now know that to see the migration, you need to sniff on your wlan adapter.

Your last question is: "I read a CISCO networking book about this topic, but It only contains a recommendation about this process, and It says implementation depends on the manufacturer. But what if the APs made by different manufacturer?". Answer: Cisco is correct. The implementation does depend on the manufacturer. Each manufacturer thinks they have a better way for a wireless access point to handle clients. As such, they program their devices in their engineering vision. So if the ap's are made by a different manufacturer, that's OK. Here's why. The access points themselves do not have discussions with eachother in any way, no matter if they're "autonomous ap's" (like the ones you setup in your network) or "thin ap's" that are directed by a controller. So in your scenario, having two different ap manufacturer's is OK because both MUST follow IEEE standards when communicating with the wireless client(s) and the switch.

SOURCES CITED:

WIFI ROAMING ANALYSIS: http://www.revolutionwifi.net/revolutionwifi/2011/12/wi-fi-roaming-analysis-part-1.html

802.11 ASSOCIATION PROCESS EXPLAINED: https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11_Association_process_explained