[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible message multiplexing problem
On Wed, 25 Jun 2008 18:59:28 -0400
Ken Raeburn <raeburn@MIT.EDU> wrote:
> On Jun 25, 2008, at 18:14, Michael B Allen wrote:
> > So you can clearly see different pids (3303, 3307, 3301, ...) getting
> > the same port (60994). Later on in the log (not shown below) the ports
> > do start to change but still not correctly.
>
> In this trace, it looks to me like it's happening serially -- one
> process closes its socket on 60994, and then another grabs that port.
> In that case, there should never be more than one process listening on
> the port at a time, and only one pending request on that port (from
> the client's point of view), though if retransmissions are happening,
> or someone is forging packets to mess with you, the listening process
> may see packets that aren't responses to its request.
True.
But remember that the port numbers of all messages in my original post
were the same:
...
TGS-REQ
TGS-REP
AS-REQ (nonce: 2261734593)
AS-REQ (nonce: 2261734593)
KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
AS-REQ (nonce: 2261734593 + preauth)
KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
AS-REP
AS-REQ (nonce: 2260112736)
KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
...
All of the above messages were on UDP port 49165. So there is interleaving
and they are on the same port.
Now in theory, yes I suppose it is still possible for things to be
"happening serially" as you put it. But in the above example, the order
of packets would have to be changed in the kernel and/or wire quite a
bit to get that particular unfortunate sequence.
Even though technically the two separate sets of data (the capture file
shared with Love and the log fragment just provided) are separate, I
think the log supports the capture such that what we see in the capture
can be believed.
I'm not one to recite POSIX scripture but it seems to me the OS should
constantly be incrementing the port values. Even if things are "happening
serially", properly incrementing port numbers would have prevented this
issue (and a multiplex ID would probably have been equally effective).
Mike
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/