From: farshid <far...@gm...> - 2007-08-19 21:58:37
|
I installed the uhub and debugged the hub response to the BINF message sent. The problem is the Base 32 encoding that python uses , adds '=' padding in the end of the encoded string!!!. did you ever face such a problem of accepting the PID that has the padding in the end.? calling stack : hub.c : int hub_handle_info_check_cid this line : if (strlen(cid) != strlen(pid) || strlen(cid) != MAX_CID_LEN) it happens because the base 32 encoding in 40 byte instead of 39 ( 39 byte + 1 byte padding ) I am wondering why this was never brought up in the adc protocol or other bugs!! message sent from client to hub : BINF AAAB IDYKCLIRO4VG3ZLIPULHV5OIK3ATH5ZXXGO34GGAY= PDAVL4BPSGS4MP4ZBOUYH2BDJWMCU4FZC4YCQ4HQI= NInick DEdesc SL1 SS0 SF0 EMemail HN1 HR0 HO0 VE++\s0.699 US5242 I41.1.1.1 U41 SUTCP4,UDP4 uhub output : Sun 19 14:54:57 INFO: Starting server, listening on :::1511 Sun 19 14:55:59 INFO: Statistics NET: tx=0 KB/s, rx=0 KB/s, (acc=0/ cls=0/err=0) Sun 19 14:56:23 USER: Login FAIL YKCLIRO4VG3ZLIPULHV5OIK3ATH5ZXXGO34GGAY "nick" [127.0.0.1] (reason: cid/pid invalid, ua: ++ 0.699) Sun 19 14:57:00 INFO: Statistics NET: tx=0 KB/s, rx=0 KB/s, (acc=1/ cls=1/err=0) On Aug 19, 2007, at 1:58 PM, Jan Vidar Krey wrote: > If you can provide a more complete protocol dump I can certainly > help you pinpoint the problem. > If the BINF message is not a well formed ADC command then the > server might not even process it, and is therefore still waiting > for a valid BINF to arrive. But this is of course just guesswork. > > Did you try uhub? > > Cheers > > -janvidar > > > On 8/18/07, farshid <far...@gm... > wrote: > Hi, > > I am writing a dc client with python + cococa ( for mac osx ) .After > hub returns SID=xxxx , I am sending > BINF XXXX ID... PD... > but I dont get any response from the standard hubs ( hubs in dc++ > hublist) > Any clue why this can happen in a ADC hub? > I will appreciate your help. > > thanks, > farsh > > > > > > -- > Jan Vidar Krey |