February 2002 - SUSE Proxy Suite - openSUSE Mailing Lists

Problem with '...not allowed'!
by Peter Zabelt 22 Feb '02

22 Feb '02

Hallo! I'm using the proxy-suite to connect a 'parent'-ftp-proxy, which is one of M$! I don't know anything about it, but I have to use this proxy for a ftp-connection to the internet. After connecting to (e.g.) ftp.heise.de via proxy-suite (seems to work properly!) and the parent-ftp-proxy I get a connection with the well-known start-message "Welcome to the ftp-server ftp.heise.de.." (or so ;-) ). When I try to use some command like list, dir etc. I get an error message in the form of: ... 'TYPE': command not implemented. 500 'EPSV': command unrecognized. 227 Entering passive mode (...). 502 'LIST': command not implemented. ftp> ... In the log-file of the proxy-suite appears a line like this: LIST from <my_local_ip> not allowed What can I do? Where must I look for this problem? In the proxy-config? Thanks to all! If the ftp-proxy.conf is helpfull, I'll send it in the next mail! Bye! Peter.

2 2

Problem with FTP on SOCKS 5
by Daniel Hölbling 19 Feb '02

19 Feb '02

Hi, I have encountered some problems with FTP and SOCKS 5.. I am trying to programm a Socks 5 Proxy, currently i have ALPHA 2.. nearly finished BETA phase.. I just want to add GSS but thats not very urgent. My problem is FTP.. i use Globalscape Cute FTP Pro 2.0 to connect to my FTP Server (127.0.0.1). It opens a control connection to my Proxy, my proxy connects to my Bulletproof FTP. But nothing happens. I have tried to solve the Problem by logging all things the Client sends and the server replys. [<--] 220 collective2k2 [<--] 421 Connection timed-out ! That's all the Server sends and the Server is no reply from the Client. And the Client has received the 220 msg from the server.. but he is not replying, nor trying to open a new connection through the Proxy or even connect to the Proxy without sending Socks messages. He simply ignores it and the server sends a timeout... Hope there is someone who knows these problems with FTP better than me. Just to add: My Proxy works perfectly with IRC, but not with FTP.. and some programs i wrote by myself that are according perfectly to the RFC 1928 standard it would help me if you knew some more programs that are using proxys. ICQ is one of these but it uses a UDP connection and my proxy is currently not able to handle UDP.. first I wanted to add these dammn FTP .. cu daniel

1 0

More flexible LDAP handling, diff included
by Pascal Gienger 17 Feb '02

17 Feb '02

Why not define 2 additional LDAP Config-Options in the config file? Something like below has helped me very much, it defines LDAPDestAddrAttribute (which Attribute to look up for the Dest. Address) and LDAPDestPortAttribute (attribute describing which ftp control port to use) Changes are minimal, here is the diff: # diff ftp-ldap.c.orig ftp-ldap.c 336c336 < char str[MAX_PATH_SIZE], *p, *base, *idnt, *objc; --- > char str[MAX_PATH_SIZE], *p, *p2, *base, *idnt, *objc; 433c433,434 < p = ldap_attrib(ld, e, "DestinationAddress", "255.255.255.255"); --- > p2 = config_str(NULL,"LDAPDestAddrAttribute","DestinationAddress"); > p = ldap_attrib(ld, e, p2, "255.255.255.255"); 451c452,453 < p = ldap_attrib(ld, e, "DestinationPort", "ftp"); --- > p2 = config_str(NULL,"LDAPDestPortAttribute","DestinationPort"); > p = ldap_attrib(ld, e, p2, "ftp"); Sometimes, it is adviseable to have user-specific prefixes (for use with Windows 2000 AD LDAP) (e.g. you have Domain "HUGO" so you must log in as "HUGO\username", but for LDAP the cn is "username"). For this I added another config file option "UserPrefix". If it is set to "none" there is none. The diff to ftp-client.c looks like this: # diff ftp-client.c.orig ftp-client.c 728a729,731 > p = config_str(NULL,"UserPrefix", "none"); > p2 = config_str(ctx.username, "UserPrefix", p); > if (strcmp(p,"none")==0) { strcpy(p,""); } 731c734 < "USER %s\r\n", ctx.username); --- > "USER %s%s\r\n", p, ctx.username); So you log in as, saying, "hugo", ftp-ldap.c does a lookup on "cn=hugo", retrieves the Destination Address (and port, if defined) and connects with username "HUGO\hugo" when "UserPrefix HUGO\\" is defined (beware of the two backslashes, config_str() seems to use the backslash as escape character). For exceptions, UserPrefix is also valid in a per-user config (see the second line with "p2"). Any suggestions or flames? With these two extensions, the proxy package is running in a Windows AD enviromnment. The next thing I try to implement is strong Windows-2000-LDAP authentication via Kerberos 5 GSSAPI. My problem is that the MIT Kerberos 5 Package (which I am having as source) can not be downloaded outside the US, so it will work for me but probably not for others. Any hints? Pascal --

3 2

Solaris 8 problem solved
by Pascal Gienger 14 Feb '02

14 Feb '02

But I don't know WHY Solaris has this behaviour. It is quite simple. To be short: A second I_NREAD ioctl is needed after one is failing with len=0. Funny isn'it ? So I tried this (on com-socket.c): # diff com-socket.c.orig com-socket.c 996c996 < int len, cnt, nsock; --- > int len, cnt, nsock, erg; 1043c1043 < if (ioctl(hls->sock, I_NREAD, &len) < 0) { --- > if ((erg=ioctl(hls->sock, I_NREAD, &len)) < 0) { 1048a1049,1059 > if ((erg==0) && (len==0)) > { > debug (1,"second read try, I_NREAD got %d bytes.",len); > usleep(10000); > if ((erg=ioctl(hls->sock, I_NREAD, &len)) < 0) { > hls->xerr = errno; > syslog_error("can't get num of bytes: %s %d=%s", > hls->ctyp, hls->sock, hls->peer); > return; > } > } 1069c1080 < if (len == 0) { --- > if ((len == 0) && (erg <= 0)) { And, suddenly, all works like it should. Connecting from slow clients to fast servers and vice-versa are working without having to modify MaxRecvSize. Is there an explanation for this besides a "bug"? Pascal --

2 1

Re: [proxy-suite] Solaris 8 / SPARC Problem persists, even with proxy-suite 200020128
by Marius Tomaschewski 14 Feb '02

14 Feb '02

On Mon, Feb 04, 2002 at 10:44:56AM +0100, Pascal Gienger wrote: > A typical FTP session goes like this: > > ftp> dir > 200 PORT command successful. > 150 Opening ASCII mode data connection for /bin/ls. > 226 Transfer complete. > ftp> dir > 200 PORT command successful. > 150 Opening ASCII mode data connection for /bin/ls. > 226 Transfer complete. > ftp> pwd > 257 "/" is current directory. > ftp> cd pub > 250 CWD command successful. > ftp> get 8_Recommended.zip > 200 PORT command successful. > 150 Opening BINARY mode data connection for 8_Recommended.zip (54820860 bytes). > 426 Data connection: Connection reset by peer. > local: 8_Recommended.zip remote: 8_Recommended.zip > 1696312 bytes received in 2.8 seconds (600.33 Kbytes/s) > ftp> quit > 221 Goodbye. > > > Funny enough, I tried it on Solaris 8 x86 and it works. > Is there an ugly bug lying around in Solaris? :( It seems to be one, yes. FIONREAD works for a while, than it returns invalid values. > Funny: > If you compile Debug-Support in (-DCOMPILE_DEBUG) and you set the level > to highest verbosity, no error appears... set "umask 0" before you start the proxy: u=$(umask) ; umask 0 ; ftp-proxy ; umask $u > is there a Problem with speed regarding Solaris libraries? Hmm.. if I run (same machine) the proxy on OpenBSD, FreeBSD or Linux, it runs fine/fast, but on Solaris 8 x86 it is much slower. IMHO the network driver that Solaris runs with 10MBit only? I'll test it the next weekend again... > With verbosity level 3 (debug 3), I get this in ftp-debug.log: > > 10:40:34 < 687> Srv-Data -> Cli-Data > 10:40:34 < 687> ll_write Cli-Data 6=134.34.1.61: 1460/10741740 bytes > 10:40:34 < 687> ll_read Srv-Data 5=134.34.3.2: 1460/10743200 bytes > 10:40:34 < 687> Srv-Data -> Cli-Data > 10:40:34 < 687> ll_write Cli-Data 6=134.34.1.61: 1460/10743200 bytes > 10:40:34 < 687> closed: Srv-Data 5=134.34.3.2 > 10:40:34 < 687> about to destroy Srv-Data > 10:40:34 < 687> config_bool: s='(nil)' n='FailResetsPasv' d=0 > 10:40:34 < 687> config_bool: result=0 > 10:40:34 < 687> deleting HLS Srv-Data -1=134.34.3.2:9186 > 10:40:34 < 687> about to destroy Cli-Data > 10:40:34 < 687> USER-INF Transfer for 134.34.1.61 completed: RETR '8_Recommend > ed.zip' read 10743200/10 byte/sec > 10:40:34 < 687> deleting HLS Cli-Data -1=134.34.1.61:51905 > 10:40:34 < 687> ll_read Srv-Ctrl 3=134.34.3.2: 48/2382 bytes > 10:40:34 < 687> gets Srv-Ctrl 3=134.34.3.2: 46 bytes '426 Data connection: Con > nection reset by peer.' > 10:40:34 < 687> TECH-DBG from Server-PI (3): '426 Data connection: Connection > reset by peer.' > 10:40:34 < 687> from Server-PI (3): '426 Data connection: Connection reset by > peer.' > 10:40:34 < 687> printf Cli-Ctrl 0=134.34.1.61: 48 bytes '426 Data connection: > Connection reset by peer.' > 10:40:34 < 687> ll_write Cli-Ctrl 0=134.34.1.61: 48/2198 bytes > 10:40:40 < 687> ll_read Cli-Ctrl 0=134.34.1.61: 6/397 bytes > > > You see the "closed: Srv-Data 5=134.34.3.2" even when the file is not fully > transferred. What is going wrong here? :( socket_ll_read gets called only, if select says there _is_ data avaliable to read. if I_NREAD returns >=0 and len=0 a close will be called (no error and no data ==> EOF). /* ** Get the number of bytes waiting to be read */ len = 0; #if defined(I_NREAD) && (defined(sun) || !defined(FIONREAD)) if (ioctl(hls->sock, I_NREAD, &len) < 0) { hls->xerr = errno; syslog_error("can't get num of bytes: %s %d=%s", hls->ctyp, hls->sock, hls->peer); return; } #if defined(COMPILE_DEBUG) debug(4, "ll_read: I_NREAD reported %d bytes for %s", len, hls->ctyp); #endif #else if (ioctl(hls->sock, FIONREAD, &len) < 0) { hls->xerr = errno; syslog_error("can't get num of bytes: %s %d=%s", hls->ctyp, hls->sock, hls->peer); return; } #if defined(COMPILE_DEBUG) debug(4, "ll_read: FIONREAD reported %d bytes for %s", len, hls->ctyp); #endif #endif /* ** Check if the socket has been closed */ if (len == 0) { #if defined(COMPILE_DEBUG) debug(1, "closed: %s %d=%s", hls->ctyp, hls->sock, hls->peer); #endif close(hls->sock); hls->sock = -1; return; } > When a LIST ("dir") gives no output, the same thing happens but no > "426 Data connection: Connection reset by peer." appears. > > Any hints left? No... not at the moment. The proxy should pass the response from server to client... Gruesse, Marius Tomaschewski <mt(a)suse.de> -- SuSE Linux AG, Nürnberg - SuSE Labs, Product Developement PGP public key available: http://www.suse.de/~mt/mt.pgp Fprint: EA 1F 92 75 1A F9 82 07 A1 28 DE 7A 32 E8 97 18

1 0

Re: [proxy-suite] Investigating I_NREAD ioctl on Solaris 8 (dropped connections)
by Marius Tomaschewski 14 Feb '02

14 Feb '02

On Mon, Feb 04, 2002 at 11:35:33AM +0100, Pascal Gienger wrote: > I think the problem lies in here, com-socket.c, line 1069: > > if (len = 0) { > #if defined(COMPILE_DEBUG) > debug(1, "closed: %s %d=%s", > hls->ctyp, hls->sock, hls->peer); > #endif > close(hls->sock); > hls->sock = -1; > return; > } > > Is it really like this that the ioctl(fd,I_NREAD,&len) returns 0 as "len" when > the connection is terminated? What happens if just the network is too slow > and the input buffer does not get filled in time (latency et.al.)? > > I tried to change the "if (ioctl(hls->sock,I_NREAD,&len) < 0)" to > "if ((erg=ioctl(...))<0)" to be able to watch the result value of the > ioctl call. > > Result: When the connection breaks, then len AND erg are zero: > > 11:23:53 < 993> ll_read Srv-Data 5=134.34.3.2: 1460/42630844 bytes > 11:23:53 < 993> Srv-Data -> Cli-Data > 11:23:53 < 993> ll_write Cli-Data 6=134.34.1.61: 1460/42630844 bytes > 11:23:53 < 993> ll_read Srv-Data 5=134.34.3.2: 22548/42653392 bytes > 11:23:53 < 993> Srv-Data -> Cli-Data > 11:23:53 < 993> ll_write Cli-Data 6=134.34.1.61: 22548/42653392 bytes > 11:23:53 < 993> closed: Srv-Data 5=134.34.3.2 > 11:23:53 < 993> len, erg: 0,0 <--- (debug line inserted by myself) > 11:23:53 < 993> about to destroy Srv-Data > > So this is a bug in the Solaris streamsio-Interface, isn't it? > When the file is really transferred entirely it also returns "0" > as len and "0" as erg. Yes. This is also what the manpage says (man streamio ?). > So your program really thinks the file has finished. But > WHY Solaris 8 does issue 0/0 also in the middle of a connection? Don't ask me... ??? > Sorry if I am posting too much, I'll stop it if it annoys you. This is realy fine, that you post! Go on! > I just wanted to give some detailed bug description. Perhaps > somebody knows a "trick"... Gruesse, Marius Tomaschewski <mt(a)suse.de> -- SuSE Linux AG, Nürnberg - SuSE Labs, Product Developement PGP public key available: http://www.suse.de/~mt/mt.pgp Fprint: EA 1F 92 75 1A F9 82 07 A1 28 DE 7A 32 E8 97 18

1 0

Re: [proxy-suite] ipchains compatibility module
by Marius Tomaschewski 14 Feb '02

14 Feb '02

On Fri, Jan 25, 2002 at 09:54:00PM +0100, fchabaud(a)free.fr wrote: > > Hi, ReHi! Hmm... it seems I've forgot to take proxy-suite into Cc... > I've downloaded 1.8 proxy-suite and tried to test it agains SuSE 7.2 > using a set of rules I have defined. As I use ipchains and SuSE > 2.4.4-4GB kernel I had to insert ipchains compatibility module. I was > unable to make transparent proxying with proxy-ftp. MagicUser was OK but > not transparent connexion. > > After several tests and recompilation, I tried to install 2.2.19 SuSE > kernel and everething became OK without any recompilation nor any > reconfiguration. Was this bug (?) of ipchains compatibility module known > or is that an incompatibility ? Yes, 'ipchains emulation' in iptables doesn't support the (broken) transparent proxying hooks, ipchains has used. No way -> use iptables or a 2.2 kernel. Kind regards, Marius Tomaschewski <mt(a)suse.de> -- SuSE Linux AG, Nürnberg - SuSE Labs, Product Developement PGP public key available: http://www.suse.de/~mt/mt.pgp Fprint: EA 1F 92 75 1A F9 82 07 A1 28 DE 7A 32 E8 97 18

1 0

ipchains compatibility module
by fchabaud＠free.fr 06 Feb '02

06 Feb '02

Hi, I've downloaded 1.8 proxy-suite and tried to test it agains SuSE 7.2 using a set of rules I have defined. As I use ipchains and SuSE 2.4.4-4GB kernel I had to insert ipchains compatibility module. I was unable to make transparent proxying with proxy-ftp. MagicUser was OK but not transparent connexion. After several tests and recompilation, I tried to install 2.2.19 SuSE kernel and everething became OK without any recompilation nor any reconfiguration. Was this bug (?) of ipchains compatibility module known or is that an incompatibility ? Apart from that I like to set port plages... nice job. -- Florent Chabaud ___________________________________ SGDN/DCSSI/SDS/LTI | florent.chabaud(a)polytechnique.org http://www.ssi.gouv.fr | http://fchabaud.free.fr

1 1

Unknown destination address proxy-suite 1.8
by Christo Papadoulis 04 Feb '02

04 Feb '02

Hi List, I have some problems doing transparent proxying with suse proxy-suite 1.8. I always always get Unknown destination address Here is my config: #################################### ftp-proxy.conf: [-Global-] ServerType standalone LogDestination daemon Listen 194.97.137.1 AllowTransProxy yes AllowMagicUser yes UseMagicChar % PortResetsPasv yes DestinationTransferMode pasive LogLevel DBG #################################### SuSE 7.3 ipchains-1.3.9-310 k_deflt-2.4.16-22 eth2= internal if (194.xx.xx.1) eth0= exteranl if (194.xx.yy.2) No NAT $IPCHAINS $LOG -A input -i eth0 -d xx.xx.xx.1 21 -p tcp -j DENY $IPCHAINS $LOG -A input -i eth2 -d ! xx.xx.xx.1 21 -p tcp -j REDIRECT 21 ##################################################### xx@xxxxx:/usr/home/xx> ftp ftp.suse.de Connected to ftp.suse.de. 220 xx FTP server (Version 1.8 - 2002/01/14 20:09:00) ready. Name (ftp.suse.de:xx) : ftp 501 Unknown destination address. ftp: Login failed. ftp> bye 221 Goodbye. #################################################### lpchains log tring to connect to ftp.suse.de (213.95.15.211) Feb 1 12:50:31 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=60 S=0x00 I=17917 F=0x4000 T=64 SYN (#27) Feb 1 12:50:31 xx ftp-child[31457]: USER-INF connect from xx.xx.xx Feb 1 12:50:31 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=52 S=0x00 I=17918 F=0x4000 T=64 (#27) Feb 1 12:50:31 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=52 S=0x10 I=17919 F=0x4000 T=64 (#27) Feb 1 12:50:47 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=62 S=0x10 I=17920 F=0x4000 T=64 (#27) Feb 1 12:50:47 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=52 S=0x10 I=17921 F=0x4000 T=64 (#27) Feb 1 12:50:54 xx ftp-child[31457]: USER-INF 'QUIT' from xx.xx.xx Feb 1 12:50:54 xx ftp-child[31457]: USER-INF closing connect from xx.xx.xx after 23 secs - read 0/0, sent 0/0 byte/sec Feb 1 12:50:54 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=58 S=0x10 I=17922 F=0x4000 T=64 (#27) Feb 1 12:50:54 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=52 S=0x10 I=17923 F=0x4000 T=64 (#27) Feb 1 12:50:54 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=52 S=0x10 I=17924 F=0x4000 T=64 (#27) Feb 1 12:50:54 xx kernel: Packet log: input REDIRECT 21 eth2 PROTO=6 xx.xx.xx:39287 213.95.15.211:21 L=52 S=0x10 I=17925 F=0x4000 T=64 (#27) Tanks, Christo Papadoulis -- Christo Papadoulis Tel: +49(0)89 544 628-99 Director Information Systems Fax: +49(0)89 544 628-29 blaxxun interactive http://www.blaxxun.com

2 1

Investigating I_NREAD ioctl on Solaris 8 (dropped connections)
by Pascal Gienger 04 Feb '02

04 Feb '02

I think the problem lies in here, com-socket.c, line 1069: if (len = 0) { #if defined(COMPILE_DEBUG) debug(1, "closed: %s %d=%s", hls->ctyp, hls->sock, hls->peer); #endif close(hls->sock); hls->sock = -1; return; } Is it really like this that the ioctl(fd,I_NREAD,&len) returns 0 as "len" when the connection is terminated? What happens if just the network is too slow and the input buffer does not get filled in time (latency et.al.)? I tried to change the "if (ioctl(hls->sock,I_NREAD,&len) < 0)" to "if ((erg=ioctl(...))<0)" to be able to watch the result value of the ioctl call. Result: When the connection breaks, then len AND erg are zero: 11:23:53 < 993> ll_read Srv-Data 5=134.34.3.2: 1460/42630844 bytes 11:23:53 < 993> Srv-Data -> Cli-Data 11:23:53 < 993> ll_write Cli-Data 6=134.34.1.61: 1460/42630844 bytes 11:23:53 < 993> ll_read Srv-Data 5=134.34.3.2: 22548/42653392 bytes 11:23:53 < 993> Srv-Data -> Cli-Data 11:23:53 < 993> ll_write Cli-Data 6=134.34.1.61: 22548/42653392 bytes 11:23:53 < 993> closed: Srv-Data 5=134.34.3.2 11:23:53 < 993> len, erg: 0,0 <--- (debug line inserted by myself) 11:23:53 < 993> about to destroy Srv-Data So this is a bug in the Solaris streamsio-Interface, isn't it? When the file is really transferred entirely it also returns "0" as len and "0" as erg. So your program really thinks the file has finished. But WHY Solaris 8 does issue 0/0 also in the middle of a connection? Sorry if I am posting too much, I'll stop it if it annoys you. I just wanted to give some detailed bug description. Perhaps somebody knows a "trick"... Pascal --

1 0