Hi, I'm trying to use wireshark's gsmtap as a logging facility for my program. From what i have read, I need to send udp 4729 packets to my loopback for gsmtap to capture and display them. After launching: -> sudo wireshark -k -f udp -Y gsmtap -i lo I get 2 problems: 1) I don't see any udp listening ports at 4729 with netstat: -> sudo netstat -lnp -u -4 | grep 4729 2) After successfully sending first packet any subsequent ones err with errno: 111, "Connection refused" What am I doing wrong? Where can I read more about the gsmtap API? TIA Nikos asked 15 Jul '16, 10:10  nibal edited 15 Jul '16, 10:42 |
One Answer:
If you are sending packets to UDP port 4729 on some particular host, and there is no process running on that host that is actively listening for packets being sent to UDP port 4729, that host will probably send back an ICMP Port Unreachable message. If you've connected the socket on which you're sending the sockets, so that the socket has a local port number of 4729, the second attempt to send a packet on that socket will probably return ECONNREFUSED if the host on which your program is running received the ICMP Port Unreachable sent by the host to which you sent the packet. If Wireshark is capturing traffic, it is not actively listening for packets - not even if it's running with a filter of "udp port 4729"! You will need to have a program that creates a UDP socket, binds it to port 4729, and runs in a loop receiving packets from the socket; that program must run on the host to which you're sending the packets. The GSMTAP page mentions netcat as an example of programs that can be used for that purpose. In your case, you would run netcat on the same host as Wiretap and your program; just have it discard the packets it receives. (Ideally, libpcap would have modules to support "remote capture", including a module to which GSMTAP packets could be sent; that module would create a UDP socket, bind it to the specified port or port 4729 by default, and provide the received packets with the same APIs it used to provide local packets; Wireshark could be changed to support that, in which case you would be able to a remote GSMTAP capture from within Wireshark, and it'd Just Work. Support for remote capture in that fashion is a work in progress, so it's not yet available. Another alternative would be to have a Wireshark extcap program to do the same thing. Nobody's written such a program yet, however. You might be able to make your program into an extcap program for Wireshark. Both of those, however, would require that a pcap/pcapng link-layer header type value be assigned to GSMTAP; you would ask [email protected] for that assignment. Wireshark could then be modified to recognize that link-layer header type and hand the packets to the GSMTAP dissector.) answered 15 Jul '16, 18:29  Guy Harris ♦♦ edited 15 Jul '16, 18:34 Thanks Guy, Your post goes a long way explaining what my problem is. I should expect that wireshark behaves like other capturing utilities like snoop and tcpdump. It is a bit messy starting another process just to listen to these packets. I will see how other programs use gsmtap to do it, but I'll probably need to create a gsmtap server from within my program. It seems a hassle, though, for fake packets that my own program creates in the first place :( That was my first post in this forum, and I hope i did everything right. I only had 6 rep points to award :( BR Nikos (16 Jul '16, 01:53) nibal Taking one of @Guy Harris' suggestions a small bit further, my approach to the task would be to add, in front of the GSMTAP header you already generate, a byte string constant - a fake ethernet + IP + UDP header obtained by exporting the capture of the first packet your application could send, and save the frames into a file with a pcap header and format. As you wrote that you are interested in use of the result for logging, that should be enough, but if you need to watch the traffic in Wireshark "online", the same format can be used to feed Wireshark's input pipe, which is also the key part of the extcap API. Ethernet FCS is normally not part of the capture of a frame so Wireshark does not complain if it is absent; IP and UDP checksums are part of the capture so unless you would want to calculate them (I wouldn't), you'd have to tell Wireshark to ignore them. Something is even telling me, but I am not sure, that setting them to 0 makes Wireshark not attempt to check them as these fields cannot be 0 normally. The "drawback" (in terms that you have to code more) of any libpcap/WinPcap-replacing method is that if you need time information, you'd have to generate the timestamps, which is what libpcap/Winpcap normally does for you. The advantage is that this way, your application may run alone, i.e. you do not need to start the blackhole application opening the UDP/4729 socket and Wireshark before starting your application. (16 Jul '16, 06:14) sindy
It does. Wireshark and tcpdump both capture using libpcap, which uses the OS's native packet capture mechanism; snoop uses the native packet capture mechanism directly.
Any program using the native capture mechanism, rather than directly receiving packets sent to port 4729, will have the exact same issue. (16 Jul '16, 10:13) Guy Harris ♦♦ |
Seems that gsmtap is maintained by osmocom http://bb.osmocom.org/trac/wiki/GSMTAP. It is a pseudo header that must be included in front of the udp packets. I was hoping to use wireshark to help in dissecting the GSM packets in my program, but since I must create myself the pseudo headers displayed in wireshark, looks like It will be of limited utility :(
BR, Nikos
The GSMTAP header provides information that is not part of the actual GSM packet data; it's not as if Wireshark could have constructed that information from the packet contents, if that's what you were hoping it would do.
If your program has that information, it should add it. If it doesn't have that information, perhaps Wireshark could attempt to do some dissection without the GSMTAP header.
Thanks Guy,
My program doesn't have any more information than what already is in those packets, except for the frequency and therefore the ARFCN. Gsmtap information has to come from those packets (Channel type, frame number, timeslot, etc.). These are the raw packets and wireshark doesn't understand much. Will have to try again after demodulating them for better insight.
Until then, original gsmtap problem still persists, even after applying all of the API requirements.
1) I still don't see anyone listening to udp 4729 using netstat, therefore I'm still wondering how this capturing works...
2) No matter what I do (connect before each write, or just once) I still get "Connection refused" at the second packet
Any help is appreciated
Nikos