Sorry for the bandwidth, I didn't realize the first dump was so large.


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, the Proxy server is
> 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
> 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:
>> 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

Reply via email to