Hello Stefan,
thank you very much for sharing your code.
Scared but seconds away from diving into the adventure of updating my
Cygwin environment and attempting to compile sipp, I've noticed the
keyword [file], and a quick test has shown that I can postpone that
adventure for future. So I state my final-for-the-moment,
compilation-free solution here.
As
- the file to which this keyword refers is read during scenario
execution (unlike e.g. the pcap files which require heavy pre-processing
so they are read at scenario compilation time), the name of the file can
be taken from a dynamically set variable,
- although the message is composed on the fly as the file size is not
known in advance, and even if the contents of the file is concatenated
with any string eventually placed in the scenario, eventual \0 bytes
inside the file and the result are handled correctly,
it is possible to use constructions similar to the following one:
...
<assignstr assign_to="dynamic_bin_part_file_name" value="[field19
file=\"testplan.txt\" line=\"[$line]\"]"/>
...
<send>
<![CDATA[
...
\x12\x23[file name="bin/part_a"][file
name="bin/[$dynamic_bin_part_file_name]"][field3 line="[$line]"]]]>
i.e. to concatenate \xx notation, binary files referenced by static
name, binary files referenced by mix of static and variable name, and
fields extracted from injection file, into a single binary body where
the eventual \0 bytes in the binary files are not causing unwanted effects.
What does NOT work is the shortcut
[file name="[field19 file=\"testplan.txt\" line=\"[$line]\"]"]
i.e. you have to first extract the dynamic part of the binary file name
from the injection file into a variable and then use the variable.
Pavel
Dne 19.10.2015 v 11:17 Stefan Elgåfoss napsal(a):
> Hello Pavel,
>
> I recently had a problem with binary content in the body (for
> application/ISUP support) and it seem like the fix
> to add support by using "\xx" notation works as long as the body content
> (with binary data) doesn't need to be changed (by injection).
> In my case I could send static binary content in a first INVITE but if
> this get rejected (e.g. by a 401) and I add authentication
> in the second INVITE the "auth" stuff gets internally injected. This
> causes SIPP to recalculate the body location (in memory) and this operation
> uses 'strlen', which of cause reads a binary content \00 as string
> termination, causing body size/location to be misinterpreted. I guess your
> case is similar in the sense that the body size/location need to be
> recalculated after injection of the file content. I believe I fixed my
> problem (in a 3.3.990 release) replacing one of the 'strlen' in a memmove
> operation; I made the changes indicated below...
> I'm not sure this solves your problem but I think it at least gives a hint
> where to look. I'm still to get registered to GitHub and
> potentially get this fix added ;-)
>
> Changes in call.cpp method createSendingMessage:
>
> Change1:
>
> char* call::createSendingMessage(SendingMessage *src, int P_index, char
> *msg_buffer, int buf_len, int *msgLen)
> {
> char * length_marker = NULL;
> char * auth_marker = NULL;
> MessageComponent *auth_comp = NULL;
> bool auth_comp_allocated = false;
> int len_offset = 0;
> char *dest = msg_buffer;
> bool supresscrlf = false;
> unsigned int content_length = 0; //fix for binary content/StefanE
>
> Change2:
> /* Fix up the length. */
> if (length_marker) {
> if (auth_marker > body) {
> ERROR("The authentication keyword should appear in the message
> header, not the body!");
> }
>
> if (body && dest - body > 4 && dest - body < 100004) {
> char tmp = length_marker[5];
> // Save content length for eventual move after authentication
> injection/StefanE
> content_length = (unsigned)(dest - body - 4 + len_offset);
> sprintf(length_marker, "%5u", content_length);
> length_marker[5] = tmp;
> } else {
> // Other cases: Content-Length is 0
> sprintf(length_marker, " 0\r\n\r\n");
> }
> }
>
> Change3:
>
> // The message body may contain binary data (e.g. containing '\0'),
> move using actual length of data/StefanE
> unsigned int move_bytes =
> body-auth_marker+auth_marker_len+content_length;
> /* Shift the end of the message to its rightful place. */
> // memmove(auth_marker + authlen, auth_marker + auth_marker_len,
> strlen(auth_marker + auth_marker_len) + 1);
> memmove(auth_marker + authlen, auth_marker + auth_marker_len,
> move_bytes+1);
>
> Hope this helps...
>
> Best Regards
> Stefan
>
>
>
>
>
>
> -----Ursprungligt meddelande-----
> Från: sindelka [mailto:sinde...@ttc.cz]
> Skickat: den 18 oktober 2015 09:47
> Till: sipp-users@lists.sourceforge.net
> Ämne: Re: [Sipp-users] SIPp: binary body part
>
> Hello SIPp team,
>
> I'm coming back to this old thread with an extended need, which is a
> possibility to inject the binary bodies from file, to support dynamic test
> scenarios where the contents of the binary body needs to be chosen from a set
> of predefined values.
>
> When the \xdd syntax is used in the injection file and then the reference to
> the field is used in the scenario file, the body contains literally
> "\","x","d","d".
> When the \xdd syntax is used in the scenario file to fill an in-memory
> injection file with the required values, like
> <insert file="binbody.table"
> value="[$binbody_id];\x03\x02\x03\x00\x05\xc3"/>
> the body contains the binary characters as needed but only up to the first
> null one.
>
> The tested equipment doesn't understand other than binary-encoded body so use
> of Content-Transfer-Encoding is not an option.
>
> Lacking knowledge about the internal interpretation of the string variables,
> I don't know what requires less effort to implement, whether interpretation
> of the \xdd syntax as late as when expanding [field1 file="binbody.table"
> line="[$binbody_id]"] or changing the string handling to allow the in-memory
> files (and string variables in general) to contain binary zero octets
> mid-string. In my current case, the number of body variants is up to ten so
> filling the in-memory injection file from inside the scenario is OK, but
> maybe someone else would need hundreds of different bodies, or would even
> like to compose the binary body dynamically from parts?
>
> Thank you for ideas or even solutions
> Pavel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sipp-users mailing list
> Sipp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
