You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Paolo Patierno <pp...@live.com> on 2016/11/23 08:04:36 UTC

Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Hi,


enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid Dispatch Router, I need sometimes to know who is the remote peer is exchanging traced messages.


For example, considering these few lines of trace (running the Qpid Dispatch Router) :


Accepted from 127.0.0.1:48192
Accepted from 127.0.0.1:48190
[0x7fbc44016390]:  <- SASL
[0x7fbc44016390]:  -> SASL
[0x7fbc44003b70]:  <- SASL
[0x7fbc44003b70]:  -> SASL
[0x7fbc44016390]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7fbc44003b70]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]


The router accepts two connections from remote clients (we see IP and port) but then every message is related to an "identifier" (I guess it should be the file descriptor related to the used socket).

If I need to match these information with Wireshark (where I can see remote port) I don't know if remote clients using remote port 48192 is related to 0x7fbc44016390 or 0x7fbc44003b70.


I think it could be a good information to add into the trace at least showing the "identifier" after the accepted message, i.e. :


Accepted from 127.0.0.1:48192 [0x7fbc44016390]


It's also true, that messages related to something like [0x7fbc44016390] come from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch Router.


Thanks,

Paolo.



Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno<http://twitter.com/ppatierno>
Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
Blog : DevExperience<http://paolopatierno.wordpress.com/>

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Paolo Patierno <pp...@live.com>.
Hi Ganesh,


after the connection is accepted there is no other way to print the proton transport reference for the couple IP/port ? In order to have just one line of trace for it (even if we can't write it near the "Accepted ..." message).


If not, I agree that the trace could be big printing the IP/port for every line; could be it conditional ? (i.e. using an env variable for tracing)


I'm just saying that in order to have a correlation between what I see from the proton trace and Wireshark.


Thanks,

Paolo.



Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno<http://twitter.com/ppatierno>
Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
Blog : DevExperience<http://paolopatierno.wordpress.com/>


________________________________
From: Ganesh Murthy <gm...@redhat.com>
Sent: Wednesday, November 23, 2016 2:14 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port



----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 7:58:48 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
>
> On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
> > Hi,
> >
> >
> > enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
> > Dispatch Router, I need sometimes to know who is the remote peer is
> > exchanging traced messages.
> >
> >
> > For example, considering these few lines of trace (running the Qpid
> > Dispatch Router) :
> >
> >
> > Accepted from 127.0.0.1:48192
> > Accepted from 127.0.0.1:48190
> > [0x7fbc44016390]:  <- SASL
> > [0x7fbc44016390]:  -> SASL
> > [0x7fbc44003b70]:  <- SASL
> > [0x7fbc44003b70]:  -> SASL
> > [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> > [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >
> >
> > The router accepts two connections from remote clients (we see IP and port)
> > but then every message is related to an "identifier" (I guess it should be
> > the file descriptor related to the used socket).
> >
>
> I think the 'identifier' will actually relate to the proton transport,
> e.g its address, since the engine doesnt know about the socket.
>
> > If I need to match these information with Wireshark (where I can see remote
> > port) I don't know if remote clients using remote port 48192 is related to
> > 0x7fbc44016390 or 0x7fbc44003b70.
> >
> >
> > I think it could be a good information to add into the trace at least
> > showing the "identifier" after the accepted message, i.e. :
> >
> >
> > Accepted from 127.0.0.1:48192 [0x7fbc44016390]
I don't think we can display the proton transport reference (0x7fbc44016390) next to the host/ephemeral port because we don't have a transport yet. Dispatch router code is accepting the connection in src/driver.c function qdpn_listener_accept() and proton is not in the picture yet.
> >
> >
> > It's also true, that messages related to something like [0x7fbc44016390]
> > come from Qpid Proton and messages like "Accepted ..." come from Qpid
> > Dispatch Router.
> >
>
> Yep, by setting PN_TRACE_FRM it is Proton doing that logging, and it
> doesnt know about the host/port/socket and is just dealing with bytes
> in/out.
>
> That said, I beleive you can set a 'tracer' used to output the
> message, e.g to your own log stream, which could also allow augmenting
> it with more information.

Yes, Dispatch does set a tracer by calling proton's pn_transport_set_tracer function and passing it a callback function like this in src/server.c

pn_transport_set_tracer(tport, qd_transport_tracer);

static void qd_transport_tracer(pn_transport_t *transport, const char *message)
{
    qd_connection_t *ctx = (qd_connection_t*) pn_transport_get_context(transport);
    if (ctx)
        qd_log(ctx->server->log_source, QD_LOG_TRACE, "[%"PRIu64"]:%s", ctx->connection_id, message);
}

As you can see above, Dispatch has access to qd_connection_t *ctx and it is adding its own connection_id to the proton message. We could potentially display the host and the port on every trace message but that would lead to large trace messages particularly in cases where the hostname is long.

Thanks.
>
> >
> > Thanks,
> >
> > Paolo.
> >
> >
> >
> > Paolo Patierno
> > Senior Software Engineer (IoT) @ Red Hat
> > Microsoft MVP on Windows Embedded & IoT
> > Microsoft Azure Advisor
> >
> > Twitter : @ppatierno<http://twitter.com/ppatierno>
> > Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
> > Blog : DevExperience<http://paolopatierno.wordpress.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Paolo Patierno <pp...@live.com>.
Hi Ganesh,


here it is : https://issues.apache.org/jira/browse/DISPATCH-572


Thanks !

Paolo.


Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno<http://twitter.com/ppatierno>
Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
Blog : DevExperience<http://paolopatierno.wordpress.com/>


________________________________
From: Ganesh Murthy <gm...@redhat.com>
Sent: Wednesday, November 23, 2016 3:11 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Paolo, can you please enter a JIRA for this. Thanks.

----- Original Message -----
> From: "Paolo Patierno" <pp...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 10:00:28 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
>
> Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted
> ..." line but it's not necessary.
>
>
> So just a new log line after that when the transport reference is available
> to the router.
>
>
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor
>
> Twitter : @ppatierno<http://twitter.com/ppatierno>
> Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
> Blog : DevExperience<http://paolopatierno.wordpress.com/>
>
>
> ________________________________
> From: Ted Ross <tr...@redhat.com>
> Sent: Wednesday, November 23, 2016 2:56 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and
> remote IP/port
>
>
>
> On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Robbie Gemmell" <ro...@gmail.com>
> >> To: users@qpid.apache.org
> >> Sent: Wednesday, November 23, 2016 7:58:48 AM
> >> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier
> >> and remote IP/port
> >>
> >> On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
> >>> Hi,
> >>>
> >>>
> >>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the
> >>> Qpid
> >>> Dispatch Router, I need sometimes to know who is the remote peer is
> >>> exchanging traced messages.
> >>>
> >>>
> >>> For example, considering these few lines of trace (running the Qpid
> >>> Dispatch Router) :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192
> >>> Accepted from 127.0.0.1:48190
> >>> [0x7fbc44016390]:  <- SASL
> >>> [0x7fbc44016390]:  -> SASL
> >>> [0x7fbc44003b70]:  <- SASL
> >>> [0x7fbc44003b70]:  -> SASL
> >>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>>
> >>>
> >>> The router accepts two connections from remote clients (we see IP and
> >>> port)
> >>> but then every message is related to an "identifier" (I guess it should
> >>> be
> >>> the file descriptor related to the used socket).
> >>>
> >>
> >> I think the 'identifier' will actually relate to the proton transport,
> >> e.g its address, since the engine doesnt know about the socket.
> >>
> >>> If I need to match these information with Wireshark (where I can see
> >>> remote
> >>> port) I don't know if remote clients using remote port 48192 is related
> >>> to
> >>> 0x7fbc44016390 or 0x7fbc44003b70.
> >>>
> >>>
> >>> I think it could be a good information to add into the trace at least
> >>> showing the "identifier" after the accepted message, i.e. :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> > I don't think we can display the proton transport reference
> > (0x7fbc44016390) next to the host/ephemeral port because we don't have a
> > transport yet. Dispatch router code is accepting the connection in
> > src/driver.c function qdpn_listener_accept() and proton is not in the
> > picture yet.
>
> If we could issue a log once the transport is created that has the
> transport reference and the host/port, that would solve the problem.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Ganesh Murthy <gm...@redhat.com>.
Paolo, can you please enter a JIRA for this. Thanks.

----- Original Message -----
> From: "Paolo Patierno" <pp...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 10:00:28 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
> 
> Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted
> ..." line but it's not necessary.
> 
> 
> So just a new log line after that when the transport reference is available
> to the router.
> 
> 
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor
> 
> Twitter : @ppatierno<http://twitter.com/ppatierno>
> Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
> Blog : DevExperience<http://paolopatierno.wordpress.com/>
> 
> 
> ________________________________
> From: Ted Ross <tr...@redhat.com>
> Sent: Wednesday, November 23, 2016 2:56 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and
> remote IP/port
> 
> 
> 
> On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Robbie Gemmell" <ro...@gmail.com>
> >> To: users@qpid.apache.org
> >> Sent: Wednesday, November 23, 2016 7:58:48 AM
> >> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier
> >> and remote IP/port
> >>
> >> On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
> >>> Hi,
> >>>
> >>>
> >>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the
> >>> Qpid
> >>> Dispatch Router, I need sometimes to know who is the remote peer is
> >>> exchanging traced messages.
> >>>
> >>>
> >>> For example, considering these few lines of trace (running the Qpid
> >>> Dispatch Router) :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192
> >>> Accepted from 127.0.0.1:48190
> >>> [0x7fbc44016390]:  <- SASL
> >>> [0x7fbc44016390]:  -> SASL
> >>> [0x7fbc44003b70]:  <- SASL
> >>> [0x7fbc44003b70]:  -> SASL
> >>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>>
> >>>
> >>> The router accepts two connections from remote clients (we see IP and
> >>> port)
> >>> but then every message is related to an "identifier" (I guess it should
> >>> be
> >>> the file descriptor related to the used socket).
> >>>
> >>
> >> I think the 'identifier' will actually relate to the proton transport,
> >> e.g its address, since the engine doesnt know about the socket.
> >>
> >>> If I need to match these information with Wireshark (where I can see
> >>> remote
> >>> port) I don't know if remote clients using remote port 48192 is related
> >>> to
> >>> 0x7fbc44016390 or 0x7fbc44003b70.
> >>>
> >>>
> >>> I think it could be a good information to add into the trace at least
> >>> showing the "identifier" after the accepted message, i.e. :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> > I don't think we can display the proton transport reference
> > (0x7fbc44016390) next to the host/ephemeral port because we don't have a
> > transport yet. Dispatch router code is accepting the connection in
> > src/driver.c function qdpn_listener_accept() and proton is not in the
> > picture yet.
> 
> If we could issue a log once the transport is created that has the
> transport reference and the host/port, that would solve the problem.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Paolo Patierno <pp...@live.com>.
Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted ..." line but it's not necessary.


So just a new log line after that when the transport reference is available to the router.


Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno<http://twitter.com/ppatierno>
Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
Blog : DevExperience<http://paolopatierno.wordpress.com/>


________________________________
From: Ted Ross <tr...@redhat.com>
Sent: Wednesday, November 23, 2016 2:56 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port



On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
>
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <ro...@gmail.com>
>> To: users@qpid.apache.org
>> Sent: Wednesday, November 23, 2016 7:58:48 AM
>> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
>>
>> On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
>>> Hi,
>>>
>>>
>>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
>>> Dispatch Router, I need sometimes to know who is the remote peer is
>>> exchanging traced messages.
>>>
>>>
>>> For example, considering these few lines of trace (running the Qpid
>>> Dispatch Router) :
>>>
>>>
>>> Accepted from 127.0.0.1:48192
>>> Accepted from 127.0.0.1:48190
>>> [0x7fbc44016390]:  <- SASL
>>> [0x7fbc44016390]:  -> SASL
>>> [0x7fbc44003b70]:  <- SASL
>>> [0x7fbc44003b70]:  -> SASL
>>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>>
>>>
>>> The router accepts two connections from remote clients (we see IP and port)
>>> but then every message is related to an "identifier" (I guess it should be
>>> the file descriptor related to the used socket).
>>>
>>
>> I think the 'identifier' will actually relate to the proton transport,
>> e.g its address, since the engine doesnt know about the socket.
>>
>>> If I need to match these information with Wireshark (where I can see remote
>>> port) I don't know if remote clients using remote port 48192 is related to
>>> 0x7fbc44016390 or 0x7fbc44003b70.
>>>
>>>
>>> I think it could be a good information to add into the trace at least
>>> showing the "identifier" after the accepted message, i.e. :
>>>
>>>
>>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> I don't think we can display the proton transport reference (0x7fbc44016390) next to the host/ephemeral port because we don't have a transport yet. Dispatch router code is accepting the connection in src/driver.c function qdpn_listener_accept() and proton is not in the picture yet.

If we could issue a log once the transport is created that has the
transport reference and the host/port, that would solve the problem.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Ted Ross <tr...@redhat.com>.

On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
>
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <ro...@gmail.com>
>> To: users@qpid.apache.org
>> Sent: Wednesday, November 23, 2016 7:58:48 AM
>> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
>>
>> On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
>>> Hi,
>>>
>>>
>>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
>>> Dispatch Router, I need sometimes to know who is the remote peer is
>>> exchanging traced messages.
>>>
>>>
>>> For example, considering these few lines of trace (running the Qpid
>>> Dispatch Router) :
>>>
>>>
>>> Accepted from 127.0.0.1:48192
>>> Accepted from 127.0.0.1:48190
>>> [0x7fbc44016390]:  <- SASL
>>> [0x7fbc44016390]:  -> SASL
>>> [0x7fbc44003b70]:  <- SASL
>>> [0x7fbc44003b70]:  -> SASL
>>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>>
>>>
>>> The router accepts two connections from remote clients (we see IP and port)
>>> but then every message is related to an "identifier" (I guess it should be
>>> the file descriptor related to the used socket).
>>>
>>
>> I think the 'identifier' will actually relate to the proton transport,
>> e.g its address, since the engine doesnt know about the socket.
>>
>>> If I need to match these information with Wireshark (where I can see remote
>>> port) I don't know if remote clients using remote port 48192 is related to
>>> 0x7fbc44016390 or 0x7fbc44003b70.
>>>
>>>
>>> I think it could be a good information to add into the trace at least
>>> showing the "identifier" after the accepted message, i.e. :
>>>
>>>
>>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> I don't think we can display the proton transport reference (0x7fbc44016390) next to the host/ephemeral port because we don't have a transport yet. Dispatch router code is accepting the connection in src/driver.c function qdpn_listener_accept() and proton is not in the picture yet.

If we could issue a log once the transport is created that has the 
transport reference and the host/port, that would solve the problem.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Ganesh Murthy <gm...@redhat.com>.

----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 7:58:48 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
> 
> On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
> > Hi,
> >
> >
> > enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
> > Dispatch Router, I need sometimes to know who is the remote peer is
> > exchanging traced messages.
> >
> >
> > For example, considering these few lines of trace (running the Qpid
> > Dispatch Router) :
> >
> >
> > Accepted from 127.0.0.1:48192
> > Accepted from 127.0.0.1:48190
> > [0x7fbc44016390]:  <- SASL
> > [0x7fbc44016390]:  -> SASL
> > [0x7fbc44003b70]:  <- SASL
> > [0x7fbc44003b70]:  -> SASL
> > [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> > [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >
> >
> > The router accepts two connections from remote clients (we see IP and port)
> > but then every message is related to an "identifier" (I guess it should be
> > the file descriptor related to the used socket).
> >
> 
> I think the 'identifier' will actually relate to the proton transport,
> e.g its address, since the engine doesnt know about the socket.
> 
> > If I need to match these information with Wireshark (where I can see remote
> > port) I don't know if remote clients using remote port 48192 is related to
> > 0x7fbc44016390 or 0x7fbc44003b70.
> >
> >
> > I think it could be a good information to add into the trace at least
> > showing the "identifier" after the accepted message, i.e. :
> >
> >
> > Accepted from 127.0.0.1:48192 [0x7fbc44016390]
I don't think we can display the proton transport reference (0x7fbc44016390) next to the host/ephemeral port because we don't have a transport yet. Dispatch router code is accepting the connection in src/driver.c function qdpn_listener_accept() and proton is not in the picture yet.
> >
> >
> > It's also true, that messages related to something like [0x7fbc44016390]
> > come from Qpid Proton and messages like "Accepted ..." come from Qpid
> > Dispatch Router.
> >
> 
> Yep, by setting PN_TRACE_FRM it is Proton doing that logging, and it
> doesnt know about the host/port/socket and is just dealing with bytes
> in/out.
> 
> That said, I beleive you can set a 'tracer' used to output the
> message, e.g to your own log stream, which could also allow augmenting
> it with more information.

Yes, Dispatch does set a tracer by calling proton's pn_transport_set_tracer function and passing it a callback function like this in src/server.c

pn_transport_set_tracer(tport, qd_transport_tracer);

static void qd_transport_tracer(pn_transport_t *transport, const char *message)
{
    qd_connection_t *ctx = (qd_connection_t*) pn_transport_get_context(transport);
    if (ctx)
        qd_log(ctx->server->log_source, QD_LOG_TRACE, "[%"PRIu64"]:%s", ctx->connection_id, message);
}

As you can see above, Dispatch has access to qd_connection_t *ctx and it is adding its own connection_id to the proton message. We could potentially display the host and the port on every trace message but that would lead to large trace messages particularly in cases where the hostname is long.

Thanks.
> 
> >
> > Thanks,
> >
> > Paolo.
> >
> >
> >
> > Paolo Patierno
> > Senior Software Engineer (IoT) @ Red Hat
> > Microsoft MVP on Windows Embedded & IoT
> > Microsoft Azure Advisor
> >
> > Twitter : @ppatierno<http://twitter.com/ppatierno>
> > Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
> > Blog : DevExperience<http://paolopatierno.wordpress.com/>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Robbie Gemmell <ro...@gmail.com>.
On 23 November 2016 at 08:04, Paolo Patierno <pp...@live.com> wrote:
> Hi,
>
>
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid Dispatch Router, I need sometimes to know who is the remote peer is exchanging traced messages.
>
>
> For example, considering these few lines of trace (running the Qpid Dispatch Router) :
>
>
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>
>
> The router accepts two connections from remote clients (we see IP and port) but then every message is related to an "identifier" (I guess it should be the file descriptor related to the used socket).
>

I think the 'identifier' will actually relate to the proton transport,
e.g its address, since the engine doesnt know about the socket.

> If I need to match these information with Wireshark (where I can see remote port) I don't know if remote clients using remote port 48192 is related to 0x7fbc44016390 or 0x7fbc44003b70.
>
>
> I think it could be a good information to add into the trace at least showing the "identifier" after the accepted message, i.e. :
>
>
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
>
>
> It's also true, that messages related to something like [0x7fbc44016390] come from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch Router.
>

Yep, by setting PN_TRACE_FRM it is Proton doing that logging, and it
doesnt know about the host/port/socket and is just dealing with bytes
in/out.

That said, I beleive you can set a 'tracer' used to output the
message, e.g to your own log stream, which could also allow augmenting
it with more information.

>
> Thanks,
>
> Paolo.
>
>
>
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor
>
> Twitter : @ppatierno<http://twitter.com/ppatierno>
> Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
> Blog : DevExperience<http://paolopatierno.wordpress.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Posted by Adel Boutros <Ad...@live.com>.
+1


Regards,

Adel

________________________________
From: Paolo Patierno <pp...@live.com>
Sent: Wednesday, November 23, 2016 9:04:36 AM
To: users@qpid.apache.org
Subject: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Hi,


enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid Dispatch Router, I need sometimes to know who is the remote peer is exchanging traced messages.


For example, considering these few lines of trace (running the Qpid Dispatch Router) :


Accepted from 127.0.0.1:48192
Accepted from 127.0.0.1:48190
[0x7fbc44016390]:  <- SASL
[0x7fbc44016390]:  -> SASL
[0x7fbc44003b70]:  <- SASL
[0x7fbc44003b70]:  -> SASL
[0x7fbc44016390]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7fbc44003b70]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]


The router accepts two connections from remote clients (we see IP and port) but then every message is related to an "identifier" (I guess it should be the file descriptor related to the used socket).

If I need to match these information with Wireshark (where I can see remote port) I don't know if remote clients using remote port 48192 is related to 0x7fbc44016390 or 0x7fbc44003b70.


I think it could be a good information to add into the trace at least showing the "identifier" after the accepted message, i.e. :


Accepted from 127.0.0.1:48192 [0x7fbc44016390]


It's also true, that messages related to something like [0x7fbc44016390] come from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch Router.


Thanks,

Paolo.



Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno<http://twitter.com/ppatierno>
Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
Blog : DevExperience<http://paolopatierno.wordpress.com/>