irontec/sngrep

Match Expression Doesn't Work on Latest Version

pksml85 opened this issue · 7 comments

TL/DR: Match expressions are not properly parsed from the command line in v. 1.7.0, but do work correctly in v. 1.4.8.

I have been beating my head against a wall trying to figure out how to use match expressions. They seem simple enough...

First of all, I'm using v. 1.7.0 and my OS is Debian 11 (Bullseye).

sngrep - 1.7.0
Copyright (C) 2013-2018 Irontec S.L.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

  • Compiled with GnuTLS support.
  • Compiled with Wide-character support.
  • Compiled with Perl Compatible regular expressions support.
  • Compiled with IPv6 support.
  • Compiled with EEP/HEP support.

Written by Ivan Alonso [aka Kaian]

My command is simple enough: sngrep -L udp:127.0.0.1:9072 'mysite.net'

The sngrep interface doesn't load and it produces this error: Couldn't install filter mysite.net : can't parse filter expression: syntax error

Here's where things get really weird... If I have sngrep running, bound to port 9072, and I run the exact same command in another terminal window, obviously STDOUT prints Error binding address: Address already in use, but prior to that, sngrep loads up and inserts mysite.net in as the filter expression as I'd expect.

Now if I use an older version, everything works perfectly. I run the exact same command and have no issues using v. 1.4.8 of sngrep:

sngrep - 1.4.8
Copyright (C) 2013-2018 Irontec S.L.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

  • Compiled with GnuTLS support.
  • Compiled with Wide-character support.
  • Compiled with Perl Compatible regular expressions support.
  • Compiled with IPv6 support.
  • Compiled with EEP/HEP support.

Written by Ivan Alonso [aka Kaian]

+1

Kaian commented

Hi!

This problem occurs when using HEP listen as source for packets.

The way match expression is used in sngrep has been taken from ngrep.

sngrep [match expression] [BPF filter]

So if you try something like

sngrep host 127.0.0.1 and port 5060

The code first checks if 127.0.0.1 and port 5060 is a BPF filter (in which case host will be a match expression). If not, then tries host 127.0.0.1 and port 5060 as BPF filter. BPF filters are only valid for libpcap captures, so to determine if the filter is valid, a pcap capture input (interface or file) is required.

In the given scenario, sngrep was checking BPF filters against a HEP input source, giving the error can't parse filter expression: syntax error. Above commit should fix the problem.

The error Error binding address: Address already in use is probably because there is another sngrep listening for HEP packets in the requested port.

Thanks for reporting!!!

Best Regards

@Kaian In my use case, the latest commit seems to be working properly. And I was surprised it was such a small change needed to address this functionality. Thanks a bunch!

Quick question: First off, I don't know much about git... To download the source code, I usually use git clone https://github.com/irontec/sngrep.git. But this seemingly downloads the latest release rather than the latest commit. How can I get git to download a particular commit so I can build the software? I've tried googling many different queries for the answer, but to no avail. (My workaround solution was to download the ZIP file for the latest commit.)

Kaian commented

@pksml85 Sorry for the late response, I easily forget about closed issues. Feel free to open another issue if you're not getting any answer (also better for not mixing topics)

I usually use git clone https://github.com/irontec/sngrep.git. But this seemingly downloads the latest release rather than the latest commit.

Hmm that strange, it should download all project and leave you in the latest commit of the main branch (master in this case). Then you can change to another commit with git reset --hard commit-id (beware this will undo changes in all files in case you edited something), but by default you should be already in the latest one.

$ git clone https://github.com/irontec/sngrep.git
Cloning into 'sngrep'...
remote: Enumerating objects: 12316, done.
remote: Counting objects: 100% (532/532), done.
remote: Compressing objects: 100% (231/231), done.
remote: Total 12316 (delta 320), reused 453 (delta 285), pack-reused 11784
Receiving objects: 100% (12316/12316), 6.32 MiB | 4.95 MiB/s, done.
Resolving deltas: 100% (10041/10041), done.
$ cd sngrep/
$ git rev-parse HEAD
71e454c687c1ccb26687854115e935dd6a5d6e7f

If you already have the project cloned git pull should download the latest commit.

Hello @Kaian. I just built version 1.7 and I still can't use the inverted match expression to filter out OPTIONS packets.

Do I just need to use version 1.4.8 or the special commit you made for me? ( 85bc492 )

Thanks.

And thanks for this great piece of software that you wrote and maintain!

root@voip-box:~ # sngrep -iv "cseq: [0-9]+ options" -L udp:127.0.0.1:9076
Couldn't install filter cseq: [0-9]+ options : can't parse filter expression: syntax error
root@voip-box:~ # sngrep --v
sngrep - 1.7.0
Copyright (C) 2013-2018 Irontec S.L.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
 * Compiled with OpenSSL support.
 * Compiled with Wide-character support.
 * Compiled with Perl Compatible regular expressions support.
 * Compiled with IPv6 support.
 * Compiled with EEP/HEP support.

Written by Ivan Alonso [aka Kaian]
Kaian commented

Hi @pksml85

This change is not in any release, so until 1.7.1 is released an packaged, this fix can only be used building sngrep from the sources.

If I have some spare time, I'll try to make a new version during december to include these and all pending changes.

Regards

Ok. Thank you! Just now I noticed that the last release was from March, so there's no way the new code would be implemented in version 1.7.0. Thanks for your quick reply and I'll keep my eye out for the next release. No rush though :)