Bug 168842 - [tcp] FreeBSD hosts are sending TCP packets with FIN flag and no ACK set
Summary: [tcp] FreeBSD hosts are sending TCP packets with FIN flag and no ACK set
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.3-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-08 11:50 UTC by Nikolay Denev
Modified: 2020-12-18 14:48 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Denev 2012-06-08 11:50:13 UTC
It seems that our FreeBSD hosts are sending TCP packets with FIN flag and no ACK set, which is triggering
alerts on some firewalls.

[14:31]root@vpn1.location:/home/ndenev# tcpdump -s0 -vni em1 '(tcp[tcpflags] & tcp-ack == 0) && (tcp[tcpflags] & tcp-fin != 0)'
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:18:31.771578 IP (tos 0x0, ttl 62, id 44503, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.53083 > Y.Y.Y.Y.9998: Flags [F], cksum 0x29a6 (correct), seq 2205738519, win 65535, length 0
15:22:02.517922 IP (tos 0x0, ttl 62, id 56317, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.37719 > Y.Y.Y.Y.9998: Flags [F], cksum 0x192b (correct), seq 2125215587, win 65535, length 0
15:24:13.215171 IP (tos 0x0, ttl 62, id 36930, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.25125 > Y.Y.Y.Y.9998: Flags [F], cksum 0x6998 (correct), seq 1370309927, win 65535, length 0
15:25:17.010082 IP (tos 0x0, ttl 62, id 61513, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.48897 > Y.Y.Y.Y.9998: Flags [F], cksum 0x16c2 (correct), seq 2650795726, win 65535, length 0
15:29:19.979799 IP (tos 0x0, ttl 62, id 15471, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.31685 > Y.Y.Y.Y.9998: Flags [F], cksum 0x218d (correct), seq 2057063075, win 65535, length 0
15:35:50.005156 IP (tos 0x0, ttl 62, id 27760, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.50568 > Y.Y.Y.Y.9998: Flags [F], cksum 0x6df3 (correct), seq 2102571459, win 65535, length 0
15:38:28.252143 IP (tos 0x0, ttl 62, id 22995, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.30441 > Y.Y.Y.Y.9998: Flags [F], cksum 0xced9 (correct), seq 4232454280, win 65535, length 0
15:39:35.362371 IP (tos 0x0, ttl 62, id 46525, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.15067 > Y.Y.Y.Y.9998: Flags [F], cksum 0x9d94 (correct), seq 1322466127, win 65535, length 0
15:52:27.833978 IP (tos 0x0, ttl 62, id 30955, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.21254 > Y.Y.Y.Y.9998: Flags [F], cksum 0x36a1 (correct), seq 3524593365, win 65535, length 0

Where 10.16.1.5 runs 8.3-STABLE

I have a PCAP that I can send privately if needed.

Fix: 

none
How-To-Repeat: Haven't tracked it down yet.
Comment 1 Andre Oppermann freebsd_committer freebsd_triage 2012-06-13 14:14:40 UTC
Responsible Changed
From-To: freebsd-bugs->andre

Take over.
Comment 2 Andre Oppermann freebsd_committer freebsd_triage 2012-06-14 11:35:44 UTC
> Hi Nikolay
>
> please make the pcap available to me. From the tcpdump in the PR I can't
> analyze how this stray packet may come about.

OK, thanks for the pcap file which I've analyzed now.

> While certainly a bug it is not a security issue as any compliant tcp stack
> would drop such a packet on receipt.

The stray FIN happens on timeout of unsuccessful connection attempts (SYN_SENT).

There are a number of bugs for that case I've identified so far:

1. there is bug in the SYN_SENT inpcb teardown case that causes the wrong
    FIN to be sent.  It may be a residual of T/TCP.
2. the SYN retransmit is broken by sending the first after 3s, and then four
    in succession at 3.2s, the fifth comes at 6.2s, at 8s the application
    times out.
3. after the third SYN retransmit we turn off the tcp options, except that
    SACK_PERM stays on.

I'm working on fixes for each of these bugs.

-- 
Andre
Comment 3 Hiren Panchasara freebsd_committer freebsd_triage 2016-02-12 00:36:44 UTC
I wonder if these bugs still exist. 

Andre?
Comment 4 Hiren Panchasara freebsd_committer freebsd_triage 2016-12-23 06:28:32 UTC
Putting this back to the pool as I suspect the problems andre mentioned may still exist.

Nikolay, is it possible for you to check if you are still seeing the problem?
Comment 5 Nikolay Denev 2016-12-26 10:44:29 UTC
Unfortunately I no longer have access to these systems.
Comment 6 Michael Tuexen freebsd_committer freebsd_triage 2020-12-18 14:48:38 UTC
The bug was reported for 8.3, which is not maintained anymore. Please reopen, if the problem still exists.