Hello again,
I am sorry to write so late, unfortunately I didn't have time to do
more debugging and try to find the cause this bug. But I finally got
to it and here is my idea.
I started adding debugs in the send_packets function, for example I
printed the destination IP taken from the function argument
(play_args's to member). Normally my prints showed the correct IP
address. But each time the error occurred, the destination IP for
instance had values such as 0.0.0.0 or similar. I realized that
probably play_args is modified somewhere else by some other thread.
But I also printed its value in the send_wrapper function (in
call.cpp) and there the prints always showed a correct value.
So I changed the send_packets to use an argument passed by value
instead of by reference. I changed it from this:
send_packets (play_args_t * play_args)
to this
send_packets (play_args_t play_args)
also changing some lines that needed to be changed for this.
I am not an experienced programmer and my solution might not be the
best one. Passing thus struct variable by value might affect
performance. Also, the pcap member of the structure is a pointer so
the address value will be copied so if it gets changed in the
meanwhile the change will still affect its content.
I tested sipp after the change and the rtp packages still seem
correct. And the error no longer occurs. I attach my patch.
Best regards,
Catalina
2009/4/16 Dmitry Goncharov <dgoncha...@unison.com>:
>
>
> catalina oancea wrote:
>
> Hi,
>
> Thanks for the idea.
>
> What I see using strace is that normal sendto looks like this:
>
> sendto(14, "\...@$&\0\264>z\200\0\31\345\0'\273T\21S3\17vvswwvwsvy}\376"...,
> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
> sendto(14,
> "\...@$&\0\264-Q\200\0\31\346\0'\273\364\21S3\17~\177\374\375\375\376\376\374\371\367\372\366"...,
> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
> sendto(14,
> "\...@$&\0\264\26=\200\0\31\347\0'\274\224\21S3\17\177}\177\375\374\376\376\372\374\177\375\373"...,
> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
> sendto(14, "\...@$&\0\264\263\35\200\0\31\350\0'\2754\21S3\17qxyvtvy~}x~|"...,
> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
> sendto(14,
> "\...@$&\0\264?\347\200\0\31\351\0'\275\324\21S3\17\364\364\365\371\370\365\364\363\363\365\371\367"...,
> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
>
>
> And the one that causes the error looks like this:
>
> sendto(14,
> "\...@$&\0\264T\234\200\0\31\352\0'\276t\21S3\17xyuy}\377\374\367\373\376\372\373"...,
> 180, MSG_DONTWAIT, {sa_family=0x2e32 /* AF_??? */,
> sa_data="168.13.13\r\nCSe"}, 16) = -1 EAFNOSUPPORT (Address family not
> supported by protocol)
>
> Is this a bug in the way the parameters are sent?
>
>
>
>
> To me this looks like a bug (assuming you properly compiled and linked
> sipp). Why don't you add some logging around the failing syscall and figure
> out what went wrong?
> BR, Dmitry
>
>
>
> You can run sipp under strace and find out which particular syscall fails.
> Just run strace -ff -o strace.log sipp ...
> Where ... should be replaced with sipp args.
> Then read and analyze the strace log files.
>
>
> I would also try to increase the number of open file descriptors per
> process. Like this ulimit -n <some big number>.
>
> HTH, Dmitry
>
>
>
>
diff -Naur sipp_old/call.cpp sipp_new/call.cpp
--- sipp_old/call.cpp 2009-09-10 11:22:32.000000000 +0300
+++ sipp_new/call.cpp 2009-09-10 11:22:40.000000000 +0300
@@ -4039,7 +4039,7 @@
// ERROR("Can't set RTP play thread realtime parameters");
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
- send_packets(s);
+ send_packets(*s);
pthread_exit(NULL);
return NULL;
}
diff -Naur sipp_old/send_packets.c sipp_new/send_packets.c
--- sipp_old/send_packets.c 2009-09-10 11:22:32.000000000 +0300
+++ sipp_new/send_packets.c 2009-09-10 11:22:40.000000000 +0300
@@ -114,7 +114,7 @@
struct timeval *, struct timeval *);
int
-send_packets (play_args_t * play_args)
+send_packets (play_args_t play_args)
{
int ret, sock, port_diff;
pcap_pkt *pkt_index, *pkt_max;
@@ -122,10 +122,10 @@
struct timeval didsleep = { 0, 0 };
struct timeval start = { 0, 0 };
struct timeval last = { 0, 0 };
- pcap_pkts *pkts = play_args->pcap;
+ pcap_pkts *pkts = play_args.pcap;
/* to and from are pointers in case play_args (call sticky) gets modified! */
- struct sockaddr_storage *to = &(play_args->to);
- struct sockaddr_storage *from = &(play_args->from);
+ struct sockaddr_storage *to = &(play_args.to);
+ struct sockaddr_storage *from = &(play_args.from);
struct udphdr *udp;
struct sockaddr_in6 to6, from6;
char buffer[PCAP_MAXPACKET];
diff -Naur sipp_old/send_packets.h sipp_new/send_packets.h
--- sipp_old/send_packets.h 2009-09-10 11:22:32.000000000 +0300
+++ sipp_new/send_packets.h 2009-09-10 11:22:40.000000000 +0300
@@ -122,7 +122,7 @@
{
#endif
int parse_play_args (char *, pcap_pkts *);
- int send_packets (play_args_t *);
+ int send_packets (play_args_t );
#ifdef __cplusplus
}
#endif
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
