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