<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Tcp-Segmentation on Inliniac</title>
    <link>https://inliniac.net/blog/tag/tcp-segmentation/</link>
    <description>Recent content in Tcp-Segmentation on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Mon, 31 Jan 2011 20:51:25 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/tcp-segmentation/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Suricata IPS improvements</title>
      <link>https://inliniac.net/blog/2011/01/31/suricata-ips-improvements/</link>
      <pubDate>Mon, 31 Jan 2011 20:51:25 +0000</pubDate>
      <guid>https://inliniac.net/blog/2011/01/31/suricata-ips-improvements/</guid>
      <description>&lt;p&gt;January has been a productive month for Suricata, especially for the IPS part of it. I&amp;rsquo;ve quite some time on adding support to the stream engine to operate differently when running inline. This was needed as dropping attacks found in the reassembled stream or the application layer was not reliable. Up until now the stream engine would offer the reassembled stream to the detection engine as soon as it was ACK&amp;rsquo;d. This meant that by definition the packets containing the data had already passed the IPS device. Simply switching to sending un-ACK&amp;rsquo;d data to the detection engine would have it&amp;rsquo;s own set of issues.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Snort_inline and TCP Segmentation Offloading</title>
      <link>https://inliniac.net/blog/2007/04/20/snort_inline-and-tcp-segmentation-offloading/</link>
      <pubDate>Fri, 20 Apr 2007 16:36:55 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/04/20/snort_inline-and-tcp-segmentation-offloading/</guid>
      <description>&lt;p&gt;Since a short while I have a gigabit setup at home. My laptop has a e1000 Intel NIC, my desktop a Broadcom NIC.While playing with Snort_inline and netpipe-tcp, I noticed something odd. I got tcp packets that had the &amp;lsquo;Don&amp;rsquo;t Fragment&amp;rsquo; option set, but were still bigger than the mtu size of the link. Snort_inline read packets of up to 26kb from the queue, and wireshark and tcpdump were seeing the packets as well. This was only for outgoing packets on the e1000 NIC. The receiving pc saw the packets split up in multiple packets that were honoring the mtu size. This got me thinking that some form of offloading must be taking place and indeed this was the case:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
