[asterisk-bugs] [JIRA] (ASTERISK-21765) [patch] - FILE function's length argument counts from beginning of file rather than the offset

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225495#comment-225495 ] 

Matt Jordan commented on ASTERISK-21765:
----------------------------------------

So, as it turns out, this patch is not correct. The unit tests caught this with the "no length" tests:

{code}
        /* No length */
        { "123456789", "-5", "56789" },
        { "123456789", "4", "56789" },
{code}

When used with the patch, the length in the above scenarios is calculated as 9 - that is, {{4 + 9 - 4}}. That is because the length is the entire length of the buffer when unspecified - and as a result, we end up reading more than the 5 bytes available (which is what was previously calculated).

However, that doesn't mean the calculation is incorrect in the patch *when* it does not exceed the max length of the buffer. When doing mid-string searches - such as {{2,5}} - the calculation of {{length - off_i}} will incorrectly extract only 3 bytes, as opposed to starting at byte 2 and continuing for 5 bytes.

One easy was to fix this is to just watch to see if we have exceeded the total length of the file ({{flength}}) and, if so, only read up to that point. That can be done by using:

{{MIN(offset + length - off_i, flength - off_i)}}

I've added a few more additions to the unit test to cover the cases outlined by the issue.

> [patch] - FILE function's length argument counts from beginning of file rather than the offset
> ----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21765
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21765
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Functions/func_dialplan
>    Affects Versions: 11.2.1, 11.3.0
>         Environment: AsteriskNow64 3.0.0
> Asterisk 11.2.1 and Asterisk 11.3.0
>            Reporter: John Zhong
>         Attachments: file_read_390821.patch
>
>
> AsteriskNow64 3.0.0 running under VMWare workstation.
> There are two issues have been found while I am testing our HiTPM with AsteriskNow64 3.0.0 integration.
> Reproduce steps:
>   1) Install netcat
>   2) Create two test files as:
>      echo 0123456789 >/tmp/0123456789.txt
>      base64 -w 0 /var/lib/asterisk/sounds/en/vm-login.ulaw > /tmp/vm-login.ulaw.b64
>   3) Run: ifconfig;nc -l 4573
>   4) Add a peer for SIP client into sip.conf
>   5) Create an extension for an AGI(agi://[the_ip_address_of_nc_listen_on]) 
>   6) Call the AGI extension
>   7) If setup is correct, the nc windows should have AGI headers
>   8) Send following commands by nc:
> {noformat}
>      GET VARIABLE FILE("/tmp/0123456789.txt,2,5")
>      and 
>      GET VARIABLE FILE("/tmp/vm-login.ulaw.b64,4080,5100")
> {noformat}
>   9) Verify the result:
> {noformat}
>      GET VARIABLE FILE("/tmp/0123456789.txt,2,5")
>      200 result=1 (234)
> {noformat}
>      Base on previous version Asterisk and current document, it should
>      return (23456), the first argument is offset and the second argument
>      should be length, but it is the 1 before the end position now. 
> [Edit by Rusty Newton - removed secondary issue as you shouldn't file two bugs in one report. Filing a new issue report.]



--
This message was sent by Atlassian JIRA
(v6.2#6252)