On April 16th at Bunkyo Green Court, knok, gniibe, Ar, mhatta and I welcome Kai Hendry who visits Japan recently.

While we're talking one topic and another, gniibe noticed that his laptop PC running Debian can not connect with some network printer server (MELCO Wireless Print Server, Server Name: WS-363251, Server Model: LPV2-WS11GC) . He investigates this in more details, and he suspects the filter configured in this machines:

# Generated by iptables-save v1.2.11 on Thu Apr 14 11:43:29 2005
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p udp -m udp --sport 137 --dport 1024:65535 -j ACCEPT
COMMIT
# Completed on Thu Apr 14 11:43:29 2005

If this filter is not used (all ACCEPT), the there are no problem.

He finds that the network printer server opens TCP connection passively with TCP packets flagged with SYN,ACK and PSH. Note that in usual implementation of TCP, passive open uses a TCP packet flagged with SYN,ACK only without PSH flag. As TCP state transition, once a TCP packet flagged with SYN,ACK, a state transits to ESTABLISHED, so the connection will be accepted by this filter rule. However, the connection is DROPed. So, we suspect PSH flag is misused or conntrack doesn't handle this case correctly.

I reads linux kernel code, and suspects that this is because TCP flag SYN|ACK|PSH is not considered as valid in tcp_valid_flag in net/ipv4/netfilter/ip_conntrack_proto_tcp.c Do we need the TH_SYN|TH_ACK|TH_PSH should be valid (1) in tcp_valid_flag as well?

I googled and find similar topics:

• comp.protocols.tcp-ip: PSH Flag Set on SYN/ACK Segment?

Mon Apr 18 12:56:07 2005: gniibe posts this issues on netfilter-devel mailing-list.