Thanks Alex,

I actually played a bit with the code and found out that exactly half of the times the write() call in the function gsmtap_fd_cb() (gsmtap_util.c) fails because of EAGAIN or EWOULDBLOCK. I implemented a retransmission in this case and this solve the problem: all the gsmtap are successfully sent and received. Though, I suspect is impacting negatively on the rest of the mobile program. Anyway I do not have a real evidence of this only the fact that after the modification I have never had a successful location update. Do you think this is plausible? am I degrading the overall performances when trying to get all the gsmtap? Can i solve this problem?

Thanks Alex and list, Loretta

----Messaggio originale---- Da: vamposdecampos@gmail.com Data: 6-mag-2011 8.35 A: "screaming-pain@libero.it"screaming-pain@libero.it Cc: baseband-devel@lists.osmocom.org Ogg: Re: lost dump ?!?!?

On Thu, May 5, 2011 at 5:28 PM, screaming-pain@libero.it screaming-pain@libero.it wrote:

...

Hi list,

I know I am very slow in understanding osmocom-bb, anyway this is just a

quick

...

question. Is it possible that some of the gsmtap messages are getting lost? For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the 'mobile' application log but there aren't the corresponding messages in the wireshark capture, though this does not always happen, I mean I had captures of location

updates

...

other times, this is why I am wondering if they are getting lost and what

it

...

does depend on. for what I understood the gsmtap functions utilities are in gsmtap_util.c

and

...

the one to send the messages on the socket is called by l1ctl.c am I right? Can you help me understanding why I cannot see all the messages?

thank you in advance Loretta

Hi,

I've had this happen to me when I wasn't receiving the gsmtap packets.

Specifically, I had the gsmtap packets sent over the network (i.e., non-localhost). There was no UDP listener on the receiving end, such that ICMP port-unreachable replies were being sent back. It would appear that this causes the sender's kernel to snub some of the outgoing packets. I don't know if the same happens on localhost.

If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j DROP", or something like "nc -l -u 4729 > /dev/null".

Cheers, Alex