I'm sorry for answering late.
Yutaka Sato wrote:
>On what OS are you runging the DeleGate ?
Red Hat Linux, Kernel 2.4
>FTP-DeleGate does not change the default socket buffer size of the socket
>for control-connection to a client, and it is expected to be large enough
>(at least 1Kbytes or more). So "780 bytes" restriction sounds strange.
>For confirmation, I tested FTP-DeleGate with a patch like follows (A).
>Observation with tcpdump shows that the window size is 64K and the
>openning banner message of 825 bytes are sent at a time (B).
>Shrinking the sending socket buffer to 512 bytes generates fragmentation
>of the message into two packets, but it is not like to be in usual
Well, we are running a complex VPN, so the reason for the shrinked
window size might be therein. So far, the workaroud (shortening the
banner) works for me. I can't point out exactly where the bug is;
CheckPoint's application intelligence, DeleGate or the kernel's ip stack.
I can't spend much time on this at the moment. May be that my logs are
delegate <--- before ---> firewall <--- after ---> vpn-gateway
All I can say, the firewall rejects processing of the second packet. It
/looks like/ there's no proper fragmentation done and the firewall is
working correct to drop it. (Such a bug is also known from an elderly
version of ipswitch's ws_ftp professional.)
*Benjamin Schweizer* | dsb AG
phone +49 7000 000-000f | fax +49 7000 000-000f
Konrad-Zuse-Strasse 16 | D-74172 Neckarsulm