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
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
On Fri, May 06, 2011 at 09:35:50AM +0300, Alex Badea wrote:
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.
it happens on localhost, too.
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".
The other workaround is to use "nc -l -u -p 4729 >/dev/null" to create a process that listens on UDP port 4729 and sends all packets to /dev/null.
I've recently added a gsmtap_sink to libosmocore. Once we use this from our various projects like OsmocmBB, there will be no need for any of those kludges anymore.
baseband-devel@lists.osmocom.org