Changeset 29c1456
- Timestamp:
- 2008-05-06T00:13:37Z (17 years ago)
- Branches:
- master
- Children:
- d56ee38
- Parents:
- 4358b10
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
protocols/jabber/s5bytestream.c
r4358b10 r29c1456 466 466 return FALSE; 467 467 468 if ( ret < sizeof( socks5_reply ) )468 if ( ret < 5 ) /* header up to address length */ 469 469 return TRUE; 470 else if( ret < sizeof( struct socks5_message ) ) 471 { 472 /* Either a buggy proxy or just one that doesnt regard the SHOULD in XEP-0065 473 * saying the reply SHOULD contain the address */ 474 475 ASSERTSOCKOP( ret = recv( fd, &socks5_reply, ret, 0 ), "Dequeuing after MSG_PEEK" ); 476 } 470 477 471 478 if( !( socks5_reply.ver == 5 ) || 472 !( socks5_reply.cmdrep.rep == 0 ) || 473 !( socks5_reply.atyp == 3 ) || 474 !( socks5_reply.addrlen == 40 ) ) 479 !( socks5_reply.cmdrep.rep == 0 ) ) 475 480 return jabber_bs_abort( bt, "SOCKS5 CONNECT failed (reply: ver=%d, rep=%d, atyp=%d, addrlen=%d", 476 481 socks5_reply.ver, … … 478 483 socks5_reply.atyp, 479 484 socks5_reply.addrlen); 485 486 /* usually a proxy sends back the 40 bytes address but I encountered at least one (of jabber.cz) 487 * that sends atyp=0 addrlen=0 and only 6 bytes (one less than one would expect). 488 * Therefore I removed the wait for more bytes. Since we don't care about what else the proxy 489 * is sending, it shouldnt matter */ 480 490 481 491 if( bt->tf->ft->sending ) … … 743 753 /* using a proxy, abort listen */ 744 754 755 if ( tf->watch_in ) 756 { 757 b_event_remove( tf->watch_in ); 758 tf->watch_in = 0; 759 } 760 745 761 closesocket( tf->fd ); 746 762 tf->fd = 0; … … 824 840 return XT_HANDLED; 825 841 } 842 843 imcb_log( tf->ic, "File %s: SOCKS5 handshake and activation successful! Transfer about to start...", tf->ft->file_name ); 826 844 827 845 /* handshake went through, let's start transferring */
Note: See TracChangeset
for help on using the changeset viewer.