New submission from Philipp Tölke <toelke...@model.in.tum.de>:
While researching some strange logs from out firewall and narrowing it
down to a biff-like imap-client written in python we found the following:
To reproduce:
Start a network-sniffer like wireshark on the loopback-interface
In one shell start some network-listener:
$ nc -l -p 12345
In python, connect to it and send some data:
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(("127.0.0.1", 12345))
>>> s.send("Hallo\n");
6
The other shell now looks like:
$ nc -l -p 12345
Hallo
Type in anything and press <Enter> to send. Then quit the nc with C-c.
Then:
>>> s.close()
What I see here is the following:
The two messages are exchanged and nc sends his FIN-Package when
quitting. Python ACKnowledges this package (though intrestingly enough,
with a ack-number one to far (8 instead of 7 in my example)). At the
Moment of the s.close(), it sends another package, containing the same
ACK-Number, the same SEQ-Number(!) and this time the RST-Flag as well.
If I understand correctly, it sends RST, because not everything from the
connection was read by python. Why does it resend the ACK? Why is the
ACK-Number one to high? Why does it reuse the SEQ-Number?
And now to imaplib.IMAP4_SSL. The behavior here seems to me even more
strange:
If I invoke .logout(), the server sends his "BYE" message and after that
a FIN, which python ACKnowledges. At the moment, that the
IMAP4_SSL-object gets out of scope, a RST/ACK-Package is send, that
again re-ACKs the FIN and has the same sequence-number, that the ACK
package had!
Why does .logout() not send a FIN? Why does it not read the complete
Buffer, so that the Socket could close with FIN? And, why does it wait
until getting out of scope with sending this RST? (I assume, that is
when the Object is garbage-collected)
Thank you!
----------
components: Library (Lib)
messages: 84175
nosy: toelke
severity: normal
status: open
title: Strange behavior when I logout() with IMAP4_SSL
versions: Python 2.5
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5565>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
