On Tue, Aug 24, 2010 at 10:36 PM, Dale <rdalek1...@gmail.com> wrote: > BRM wrote: >> >> Wireshark will show you the raw packet data, and decode only a little of >> it - >> enough to identify the general protocol, senders, etc. >> So to understand the packet, you will need to understand the application >> layer >> protocol - in this case HTTP - yourself as Wireshark won't help you there. >> >> But yet, Wireshark, nmap, and nessus security scanner are the tools, less >> so >> nessus as it really is more of a port scanner/security hole finder than a >> debug >> tool for applications (it's basically an interface for nmap for those >> purposes). >> >> HTH, >> >> Ben >> >> >> > > If finally did it again, and is doing it as I type. I captured some of the > traffic with Wireshark. Can someone tell me what to do with it now? This > is one frame of it: > > Frame 4 (881 bytes on wire, 881 bytes captured) > Arrival Time: Aug 24, 2010 21:03:35.518314000 > [Time delta from previous captured frame: 0.000383000 seconds] > [Time delta from previous displayed frame: 0.000383000 seconds] > [Time since reference or first frame: 0.010995000 seconds] > Frame Number: 4 > Frame Length: 881 bytes > Capture Length: 881 bytes > [Frame is marked: False] > [Protocols in frame: eth:ip:tcp:http] > [Coloring Rule Name: HTTP] > [Coloring Rule String: http || tcp.port == 80] > Ethernet II, Src: ArchtekT_81:d5:d3 (00:01:53:81:d5:d3), Dst: > Motorola_aa:96:e4 (00:1d:6b:aa:96:e4) > Destination: Motorola_aa:96:e4 (00:1d:6b:aa:96:e4) > Address: Motorola_aa:96:e4 (00:1d:6b:aa:96:e4) > .... ...0 .... .... .... .... = IG bit: Individual address (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > Source: ArchtekT_81:d5:d3 (00:01:53:81:d5:d3) > Address: ArchtekT_81:d5:d3 (00:01:53:81:d5:d3) > .... ...0 .... .... .... .... = IG bit: Individual address (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > Type: IP (0x0800) > Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 98.136.112.30 > (98.136.112.30) > Version: 4 > Header length: 20 bytes > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) > 0000 00.. = Differentiated Services Codepoint: Default (0x00) > .... ..0. = ECN-Capable Transport (ECT): 0 > .... ...0 = ECN-CE: 0 > Total Length: 867 > Identification: 0xe5fb (58875) > Flags: 0x02 (Don't Fragment) > 0.. = Reserved bit: Not Set > .1. = Don't fragment: Set > ..0 = More fragments: Not Set > Fragment offset: 0 > Time to live: 64 > Protocol: TCP (0x06) > Header checksum: 0xbd48 [correct] > [Good: True] > [Bad : False] > Source: 192.168.1.2 (192.168.1.2) > Destination: 98.136.112.30 (98.136.112.30) > Transmission Control Protocol, Src Port: 43281 (43281), Dst Port: http (80), > Seq: 0, Ack: 1, Len: 815 > Source port: 43281 (43281) > Destination port: http (80) > [Stream index: 1] > Sequence number: 0 (relative sequence number) > [Next sequence number: 815 (relative sequence number)] > Acknowledgement number: 1 (relative ack number) > Header length: 32 bytes > Flags: 0x18 (PSH, ACK) > 0... .... = Congestion Window Reduced (CWR): Not set > .0.. .... = ECN-Echo: Not set > ..0. .... = Urgent: Not set > ...1 .... = Acknowledgement: Set > .... 1... = Push: Set > .... .0.. = Reset: Not set > .... ..0. = Syn: Not set > .... ...0 = Fin: Not set > Window size: 92 > Checksum: 0x0d09 [validation disabled] > [Good Checksum: False] > [Bad Checksum: False] > Options: (12 bytes) > NOP > NOP > Timestamps: TSval 177975147, TSecr 3960038659 > [SEQ/ACK analysis] > [Number of bytes in flight: 815] > Hypertext Transfer Protocol > GET /v1/displayImage/custom/yahoo/<screen name was here>?redirect=0 > HTTP/1.1\r\n > [Expert Info (Chat/Sequence): GET > /v1/displayImage/custom/yahoo/<screen name was here>?redirect=0 > HTTP/1.1\r\n] > [Message: GET /v1/displayImage/custom/yahoo/<screen name was > here>?redirect=0 HTTP/1.1\r\n] > [Severity level: Chat] > [Group: Sequence] > Request Method: GET > Request URI: /v1/displayImage/custom/yahoo/<screen name was > here>?redirect=0 > Request Version: HTTP/1.1 > Host: rest-img.msg.yahoo.com\r\n > Connection: close\r\n > User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4; Linux > 2.6.30-gentoo-r8; X11; i686; en_US) KHTML/4.4.5 (like Gecko)\r\n > Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, > image/*;q=0.9, */*;q=0.8\r\n > Accept-Encoding: x-gzip, x-deflate, gzip, deflate\r\n > Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5\r\n > Accept-Language: en-US, en\r\n > [truncated] Cookie: B=ailkv295qsqnr&b=3&s=dn; > Y=v=1&n=bt77n8119ils3&l=30b4a_rzwx/o&p=m2316qt013000000&jb=16|47|&r=eg&lg=en-US&intl=us&np=1; > T=z=b/fcMBbF1cMBqnoHCK8Lm6qNDAxBjU0NDE0MjVPMzI-&a=YAE&sk=DAAgQw54KM2VAc&ks=EAAQtPQ3LsapOyL9MIqyK3.8 > \r\n > > No. Time Source Destination Protocol > Info > 5 0.152339 98.136.112.30 192.168.1.2 HTTP > HTTP/1.1 401 Authorization Required (text/html) > > > I changed the screen name to protect the innocent. She is a red head with > attitude. Anyway, looking at more than one frame here, it looks like it is > trying to get info, image perhaps, for that contact but it fails so it keeps > trying. Been going at it for half hour or more so far. It looks to me like > Yahoo would eventually say "bugger off"!! LOL > > I remember that Yahoo removed images and some kind of profile thingy a while > back. Could that be what it is trying to find but that no longer exists? > > Thoughts? > > Dale > > :-) :-)
Well, glancing at the GET request it's making there, as well as the API google points me to when I look it up... http://developer.yahoo.com/messenger/guide/ch03s02.html#d4e4628 You're right that it's after an image from their profile, but the cause of the failure appears to be related to some sort of credentials Yahoo wants the messenger to provide. You might poke Kopete's bugtracker to see if they've a related bug on file already, and if they don't, throw one their way. The API Yahoo appears to be using there (based on a response I got back in poking lightly) is, or is based on, OAuth, which according to this: http://oauth.net/core/1.0/#http_codes specifies that a request should give a 401 response (Authorization Required vs Unauthorized is purely the choice of phrase used in the program decoding the numerical code, i.e. wireshark in your example of it there) in the following cases: HTTP 401 Unauthorized * Invalid Consumer Key * Invalid / expired Token * Invalid signature * Invalid / used nonce Yahoo, essentially, *does* give a "bugger off"!! with that response, but Kopete simply takes it, considers it a brief instant, then decides "Maybe the answer will change if I try again *now*!"... at which point it proceeds to introduce its proverbial cranium to the proverbial brick and mortar vertical surface one might term "the wall." Repeatedly. -- Poison [BLX] Joshua M. Murphy
