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
|
