[SR-Users] pipelimit: inexistent pipe error logs

Daniel-Constantin Mierla miconda at gmail.com
Tue Jan 21 17:30:48 CET 2020


Hello,

as I said, watch the traffic on port 8000 with ngrep or some other
network sniffer to see what data comes there. You can also start
kamailio with debug=3 in config, more debug logs should be printed to
syslog to get the context of what is processed at that time.

Cheers,
Daniel

On 21.01.20 16:31, Nuno Ferreira wrote:
> Hi Daniel,
>
> Thanks for your feedback.
> I have a dedicated listen directive for JSONRPC
> listen = 127.0.0.1:8000 <http://127.0.0.1:8000>
>
> and then an event_route for it:
> event_route[xhttp:request] {
>     if ($Rp != 8000) {
>         xhttp_reply("403", "Forbidden", "text/html",
> "<html><body>Forbidden</body></html>");
>         exit;
>     }
>     if ($hu =~ "^/RPC") {
>         jsonrpc_dispatch();
>     } else {
>         xhttp_reply("200", "OK", "text/html", "<html><body>Wrong URL
> $hu</body></html>");
>     }
>     return;
> }
>
> So, I'm already doing HTTP traffic only in port 8000.
> The interesting part is that if I use kamcmd pl.list pipe_INVITE, only
> the first log line is printed. Using curl, I see the other 2 logs all
> the time.
>
> Thank you
>
> On Tue, Jan 21, 2020 at 2:45 PM Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     can you want the traffic on port 8000 and see if there is no
>     "unexpected" traffic there? There should be no error message for
>     parsing the first line of an HTTP request.
>
>     The error message related the missing pipe can be made debug.
>
>     Cheers,
>     Daniel
>
>     On 21.01.20 15:34, Nuno Ferreira wrote:
>>     Hi all,
>>
>>     I'm using pipelimit with the "clean_unused" option to get rid of
>>     pipes that are not used for quite some time. At the same time we
>>     are monitoring pipelimit with a jsonrpc call similar to:
>>
>>     # curl --header 'Content-Type: application/json' --data-binary
>>     '{"id": 1, "jsonrpc": "2.0", "method": "pl.list", "params":
>>     ["pipe_INVITE"]' http://127.0.0.1:8000/RPC
>>
>>     Reply:
>>     {
>>        "jsonrpc": "2.0",
>>        "error": {
>>           "code": 400,
>>           "message": "Unknown pipe id pipe_INVITE"
>>        },
>>        "id": 1
>>     }
>>
>>     The above reply is valid because the pipe_INVITE was not loaded
>>     yet, but the request makes kamailio to log the following log
>>     messages:
>>
>>     Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit
>>     [pl_ht.c:519]: rpc_pl_list(): no pipe: pipe_INVITE
>>     Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: <core>
>>     [core/parser/parse_fline.c:262]: parse_first_line():
>>     parse_first_line: bad message (offset: 20)
>>     Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data]
>>
>>     Since the monitoring system does periodic requests, those log
>>     lines get a bit annoying and fill the log with ERROR messages
>>     that aren't really errors.
>>
>>     IMHO the first log line should be converted to DEBUG instead of
>>     ERROR, but I have some doubts about the one
>>     from parse_fline.c:262. parse_first_line() is used to process
>>     both SIP and HTTP. It makes sense to log ERROR if SIP but not in
>>     the case of HTTP...
>>     Regarding the "[466B blob data]" I really don't know from where
>>     it's coming from.
>>     I can submit a PR, but I would like to have first some feedback
>>     from you.
>>
>>     Thank you,
>>
>>     Nuno
>>
>>
>>     *Confidentiality Notice: The information contained in this e-mail
>>     and any
>>     attachments may be confidential. If you are not an intended
>>     recipient, you
>>     are hereby notified that any dissemination, distribution or
>>     copying of this
>>     e-mail is strictly prohibited. If you have received this e-mail
>>     in error,
>>     please notify the sender and permanently delete the e-mail and any
>>     attachments immediately. You should not retain, copy or use this
>>     e-mail or
>>     any attachment for any purpose, nor disclose all or any part of the
>>     contents to any other person. Thank you.*
>>
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com <http://www.asipto.com>
>     Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com <http://www.kamailioworld.com>
>
>
>
> *Confidentiality Notice: The information contained in this e-mail and any
> attachments may be confidential. If you are not an intended recipient, you
> are hereby notified that any dissemination, distribution or copying of
> this
> e-mail is strictly prohibited. If you have received this e-mail in error,
> please notify the sender and permanently delete the e-mail and any
> attachments immediately. You should not retain, copy or use this e-mail or
> any attachment for any purpose, nor disclose all or any part of the
> contents to any other person. Thank you.* 

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200121/62791bfa/attachment.html>


More information about the sr-users mailing list