Sorry for the bandwidth, I didn't realize the first dump was so large. --Steve
On 9/15/04 8:33 AM, "Steven Stratford" <[EMAIL PROTECTED]> wrote: > networktraffic is a complete traffic dump for a Software Update. My computer > is 10.2.2.44, the Proxy server is 10.2.0.2 > > networktraffic1 is a dump of Software Update that is interrupted by turning > Authoxy off after about 10 seconds. > > networktraffic2 is a dump of Software Update that is interrupted by > canceling Software Update after about 10 seconds. > > I looked over the dumps with Ethereal. Looks to me like a "HTTP/1.1 407 > Proxy Authentication Required" response is received from 10.2.0.2 > immediately, but then I could be reading it incorrectly. > > --Steve > > > On 9/13/04 11:45 PM, "Heath Raftery" <[EMAIL PROTECTED]> wrote: > >> Hey guys, >> >> Very interesting thread, and I'm happy you're helping each other out, >> because the fact is I really am inexperienced when it comes to NTLM >> authentication. Nonetheless, I'll offer my comments from the developers >> point of view. >> >> Incidentally, the two sites mentioned before: >> http://www.innovation.ch/java/ntlm.html >> http://davenport.sourceforge.net/ntlm.html >> are two of the resources I relied on most during development, so are a >> great place to decipher what appears in the logs! >> >> As you've clearly noted, the delay appears to occur at Step 2, so I'll >> break down what happens around that point: >> >> Before entering Step 1, Authoxy breaks into two processes, one to >> handle the client->server connection and another to handle >> server->client. In Step 1, one of the processes sends the client >> request (eg. a call to the Software Update servers to check for >> updates) as normal to the proxy. Well, almost as normal - NTLM requires >> persistant connections (basically means that the connection must be >> held open between requests for the authentication to work), so if the >> client requested non-persistant connections (by supplying the >> Connection: close header), Authoxy strips it out and remembers that is >> the case, before passing the request on. >> >> The process then informs the other pauses itself waiting for the other >> process to complete Step 2. The other process then starts Step 2, and >> waits for the proxy to return a HTTP code 407 Unauthorized back. If >> something arrives from the proxy which is not a 407, Authoxy will >> report "Unexpected server response in NTLM authentication Step 2. >> Giving up.". That doesn't appear to be what is happening here - instead >> the proxy doesn't respond for 120 seconds. If the process does receive >> a 407, it *will* report "Step 2 is complete" and I'm not seeing that at >> all in the logs you've posted. >> >> If you cancel the request, that will close the connection on the client >> side. This should kill both processes and go back to waiting for >> another connection. Before the processes are killed though, they are >> both unpaused, to make sure you don't get stopped processes pilling up. >> Perhaps this is when one of the processes runs away and attempts to >> complete the rest of the connection. All the flags which appear from >> then on seem normal to me. >> >> So as far as I can tell, the issue appears to be that the proxy server >> is not returning the 407 error response when it should. This is a >> fairly fundamental step and actually occurs before any of the >> credentials are passed or even consulted, so should be a clear place to >> investigate. >> >> On the topic of credentials and which are appropriate or required, I am >> very sorry to say that you know much more than I do! I honestly don't >> know which credentials are necessary and what they relate to in the >> Windows/NTLM world. The only contact I've had with them, besides >> reports from users, is from reading the protocol documentation as >> described in the links mentioned above. Best bet there is probably >> experimentation, or consulting with your friendly local Windows >> administrator (hahaha). >> >> Back to the issue with the server responding - you'll get a lot more >> information and I'll have a lot more idea of what is going on, if you >> could capture the tcp dump. I'm not sure if you're familiar with the >> tools (or even if this is appropriate in your situation), but OS X >> comes built in with a (command line) program called tcpdump, which >> dumps the raw network traffic to a file. You can then analyse the >> traffic with various tools (Ethereal being my favourite). Here's how to >> dump the information necessary to file: >> >> In an administrator account on the OS X machine, type this at the >> prompt in the Terminal (where % is your prompt): >> >> % sudo tcpdump -p -s 0 -i en0 -w networktraffic >> It should prompt you for your password, by which it means your >> admin/login password. You might get a message about not having enough >> permissions to access /dev/bpf0 or something. In that case, use this >> command first: >> % sudo chmod 777 /dev/bpf* >> to change permissions on the files required by tcpdump. >> >> Here's a breakdown of the command: >> - sudo means to "do" the command as the "su" (super user), ie. the all >> powerful root user. >> - tcpdump is an application with "sniffs" network traffic. It will >> record all traffic in and out of your computer. >> - -p turns off "promiscuous" mode so you don't see the traffic of other >> computers on the network. >> - -s 0 sets the packet collection size to unlimited, so you get all the >> data. >> - -i en0 means to use the first Ethernet interface for collection. This >> will be your built-in Ethernet connection which I'm assuming you are >> connecting to the Internet through. >> - -w networktraffic means to write the raw data to the file named >> networktraffic (make sure you don't happen to have a file already by >> that name in your home directory!). The raw data can later be >> interpreted by other applications. >> >> After entering the command, you should get a confirmation message and >> then nothing. At this point, tcpdump is recording traffic. Hopefully >> your network is not too busy with traffic, which would make the output >> rather complicated. In any case, quickly jump into Software Update and >> do an update. To start with, it might be worth waiting out the delay. >> Then jump back to the Terminal and press Control-C to stop tcpdump. You >> can start is again with another file name (say -w networktraffic2) and >> then try and update followed by a cancel. >> >> If you have any network geeks handy, get them to have a look at the >> output produced by tcpdump. If not, send it to me and I'll definately >> have a look. Just remember that the tcpdump will dump all network >> traffic coming to or from your computer. Any sensitive information is >> probably encrypted anyway, and if you make sure you're not doing >> anything else at the same time, there should be nothing in there which >> couldn't be sent via email. It might be worth considering the >> organisation's policy just to be sure though! >> >> Well I'm sure that's plenty of rambling on my behalf for now. Good luck >> in your future investigations! >> Heath >
