Hello Yutaka,

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
>environment.
>
>
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
of interest:

network architecture:
delegate <--- before ---> firewall <--- after ---> vpn-gateway

sniffer logs:
http://www.dsb.net/~schweizer/dvg_before_firewall-2005-06-28.cap
http://www.dsb.net/~schweizer/dvg_after_firewall-2005-06-28.cap

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.)


regards

--
*Benjamin Schweizer* | dsb AG

phone +49 7000 000-000f | fax +49 7000 000-000f
Konrad-Zuse-Strasse 16 | D-74172 Neckarsulm