John, I'm glad to hear that you're no longer seeing any trust issues. Even with the scenario as you had it, I would expect bono to still challenge (and accept authentication for) a REGISTER and, once authenticated, accept any other requests. Are you sure that you were seeing bono rejecting messages other than that initial SUBSCRIBE? (The examples you showed were all SUBSCRIBEs.) If so, we can investigate further.
With regard to sprout apparently not receiving the messages, this is because you're running with less logging on sprout - if you increase the log level for sprout, I'm sure you'll see these logs - as you say, bono is sending the requests off to sprout and subsequently is receiving responses back. The "odd sequencing" you're seeing is actually correct. * sipp sends a REGISTER to bono without any authentication * bono forwards the REGISTER onto sprout and, to indicate that the subscriber is not already authenticated, adds an Authorization header containing "integrity-protected=no" - note that the rest of this header is largely empty, in particular, there is no "response" field that would contain the hashed digest used for authentication * sprout challenges this REGISTER (as it is not authenticated), sending a 401 Unauthorized back to bono with a WWW-Authenticate challenge * bono forwards the 401 Unauthorized to sipp * sipp responds to the challenge with a new REGISTER containing a complete Authorization header, bono passes this on to sprout, which accepts it and responds with a 200 OK. Does that make sense? Matt From: John Letourneau [mailto:[email protected]] Sent: 07 November 2013 20:21 To: Matt Williams Cc: [email protected] Subject: Re: [Clearwater] Bono rejecting request from untrusted source Matt, it could very well be that I am confused on how scenarios and the protocol are suppose to work 8-) Yes, the scenario started with a SUBSCRIBE, however it was expecting a 403, after which it would send in a REGISTER, expect a 401 challenge, then send another REGISTER with the digest filled in. I would not have expected bono to start un-trusting because of this series. [btw - that was a bono log I sent] At any rate, I did remove the SUBSCRIBE and now start the scenario with a REGISTER, 401, REGISTER. From the bono log it seems that there are no trust issues now, however processing is far from expected. I have attached a tar with logs from bono, sprout, and homestead. I have confirmed that timestamps from all machines are very close to the same [within a second as they should be]. The bono log shows that it intends to contact sprout [as I interpret them], yet I do not see messages in sprout to that effect [hmmm, I shall repeat some of those tests with log level 5 on sprout]. bono also shows some odd sequencing, perhaps an artifact of how logging is implemented? For example it shows sequences like: REGISTER, REGISTER[digest], 401. So, this is all very confusing to me. Sorry! I could begin with a much simpler scenario, but it seems this is failing in the early stages. Guidance is appreciated. -John On Thu, Nov 7, 2013 at 5:34 AM, Matt Williams <[email protected]<mailto:[email protected]>> wrote: John, Thanks for providing those sprout logs. They show that sprout is receiving a SUBSCRIBE request on a flow that has not yet been authenticated. The scenario.xml file shows that we are indeed sending a SUBSCRIBE before the REGISTER on which authentication takes place. Please can you try changing your scenario to send the SUSBCRIBE after the REGISTER and see if that helps? Note that sprout only challenges REGISTERs - all other SIP methods are immediately rejected with a 403 Forbidden. Thanks, Matt From: John Letourneau [mailto:[email protected]<mailto:[email protected]>] Sent: 06 November 2013 13:53 To: Matt Williams Cc: [email protected]<mailto:[email protected]> Subject: Re: [Clearwater] Bono rejecting request from untrusted source Hi Matt, thanks as always for providing guidance in debugging etc. I boosted the log level to 5, restarted bono, and re-ran my SIPp scenario [which btw came from the CW testing folder you directed me to last week...I tweaked it just a bit to make run in my EC2 deployment. I shall attach it to this post] The bono process continues to reject my un-trusted messages, here is one example of the plethora of rejections: 06-11-2013 18:29:54.031 Debug pjsip: tdta0x7fcf3401 Destroying txdata Response msg 403/SUBSCRIBE/cseq=1 (tdta0x7fcf340116e0) 06-11-2013 18:29:54.031 Debug pjsip: tdta0x7fcf3400 Destroying txdata Request msg SUBSCRIBE/cseq=1 (tdta0x7fcf3400e7d0) 06-11-2013 18:29:54.031 Debug stack.cpp:164: Worker thread completed processing message 0x7fcf48184458 06-11-2013 18:29:54.031 Debug stack.cpp:170: Request latency = 4362us 06-11-2013 18:29:54.031 Debug stack.cpp:162: Worker thread dequeue message 0x7fcf48188358 06-11-2013 18:29:54.031 Debug pjsip: sip_endpoint.c Distributing rdata to modules: Request msg SUBSCRIBE/cseq=1 (rdata0x7fcf48188358) 06-11-2013 18:29:54.031 Debug stateful_proxy.cpp:236: Proxy RX request 06-11-2013 18:29:54.031 Debug stateful_proxy.cpp:689: Request received on non-trusted port 5060 06-11-2013 18:29:54.031 Debug stateful_proxy.cpp:880: Perform edge proxy routing for SUBSCRIBE request 06-11-2013 18:29:54.031 Debug stateful_proxy.cpp:995: Message received on non-trusted port 5060 06-11-2013 18:29:54.031 Debug flowtable.cpp:137: Find flow for transport tcps0x7fcf48255398 (2), remote address 54.221.31.166:50786<http://54.221.31.166:50786> 06-11-2013 18:29:54.031 Warning stateful_proxy.cpp:1186: Rejecting request from untrusted source 06-11-2013 18:29:54.031 Debug pjsip: endpoint Response msg 403/SUBSCRIBE/cseq=1 (tdta0x7fcf340116e0) created 06-11-2013 18:29:54.031 Verbose stack.cpp:215: TX 368 bytes Response msg 403/SUBSCRIBE/cseq=1 (tdta0x7fcf340116e0) to TCP 54.221.31.166:50786<http://54.221.31.166:50786>: --start msg-- SIP/2.0 403 Forbidden^M Via: SIP/2.0/TCP 10.29.191.120:5069;rport=50786;received=54.221.31.166;branch=z9hG4bK-25849-312-2-7770000622-^M Call-ID: 7770000622///[email protected]<mailto:[email protected]>^M From: <sip:[email protected]<mailto:sip%[email protected]>>;tag=25849SIPpTag00312^M To: <sip:[email protected]<mailto:sip%[email protected]>>;tag=z9hG4bK-25849-312-2-7770000622-^M CSeq: 1 SUBSCRIBE^M Content-Length: 0^M ^M --end msg-- 06-11-2013 18:29:54.031 Debug pjsip: tdta0x7fcf3401 Destroying txdata Response msg 403/SUBSCRIBE/cseq=1 (tdta0x7fcf340116e0) 06-11-2013 18:29:54.032 Debug pjsip: tdta0x7fcf3400 Destroying txdata Request msg SUBSCRIBE/cseq=1 (tdta0x7fcf3400e7d0) This seemed to be working OK for 20 or so accounts...now I am moving this up to 1,000 [a short stepping stone to larger configurations]. Yes, there were other issues that resulted in many rejections [bad passwords etc], so I can see where some smart DoS detector might want to block me 8-) However in a testing environment things like that happen, and as such I need to be able to 'reset' the heuristic to be able to trust my address once again. -John On Tue, Nov 5, 2013 at 9:10 PM, Matt Williams <[email protected]<mailto:[email protected]>> wrote: John, Thanks for your email. What are you seeing in bono's log file? Please can you share them? If you're not already running with detailed logs (log level 5), it would be useful to enable this - see https://github.com/Metaswitch/clearwater-docs/wiki/Troubleshooting-and-Recovery#bono for details. Incidentally, what's the sip script you're running? Bear in mind that bono rejects INVITEs on flows that have not previously been authenticated using a REGISTER. Please let me know. Thanks, Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of John Letourneau Sent: 05 November 2013 12:49 To: [email protected]<mailto:[email protected]> Subject: [Clearwater] Bono rejecting request from untrusted source Hi, during some testing I have gotten into the situation where calls stop going through. I check the bono log to find all my SIPp request are getting canned. How can I gain the trust of the system again? A restart of the bono service did not help matters. Thanks! -John
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
