R: Re: lost dump ?!?!?

historical

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 at gmail.com
>Data: 6-mag-2011 8.35
>A: "screaming-pain at libero.it"<screaming-pain at libero.it>
>Cc: <baseband-devel at lists.osmocom.org>
>Ogg: Re: lost dump ?!?!?
>
>On Thu, May 5, 2011 at 5:28 PM, screaming-pain at libero.it
><screaming-pain at 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
>
>