Nlbwmon: catching VoIP traffic

Barney · December 23, 2021, 6:20pm

I'm running nlbwmon (2020-04-11.1-34a18876-3) under OpenWrt 21.02.0.

After adding some more triples (IP protocol, port number, name of the mapped protocol) under Configuration/Protocol-Mapping I get a more detailed list under Display/Apllication-Protocols.

BUT: I'm not able to catch VoIP traffic.

I've added the following triple for the SIP traffic:

6 5060 SIP
17 5060 SIP

and it appears in the display list.

I've added furthermore the following triples for the RTP traffic:

6 40040 RTP
17 40040 RTP

but it doesn't appear in the display list (although tcpdump shows traffic with just this protocol and port number).

I fear, I'm missing something, but I don't know what?

Any experienced nlbwmon user near by?

anon50098793 · December 23, 2021, 6:54pm

looks ok... try trashing your existing database...

Barney · December 23, 2021, 8:00pm

Thanks for answering.

Just tested: nlbwmon stopped, moved database to a safe place, nlbwmon started. Result: no applications listed.

Did a call. nlbwmon doesn't list the traffic under RTP, but under other applications. According to nlbwmon's readme on github, it accounts all traffic under other, where there is no triple in the mapping table.

So the question is: why does nlbwmon ignore the triples

6 40040 RTP
17 40040 RTP

anon50098793 · December 23, 2021, 8:04pm

works for me: see voip

Barney · December 23, 2021, 8:20pm

Can you show me your triple for voip?

anon50098793 · December 23, 2021, 8:21pm

17 3478 voip
17 3479 voip
17 3480 voip
17 3481 voip
17 8801 voip
17 8802 voip
17 8803 voip
17 8804 voip
17 8805 voip
17 8806 voip
17 8807 voip
17 8808 voip
17 8809 voip
17 8810 voip
17 4244 voip
17 5222 voip
17 5228 voip
17 59234 voip
17 50318 voip
17 5242 voip
17 45395 voip
17 34784 voip
17 16384 voip
17 16385 voip
17 16386 voip
17 16387 voip
17 16393 voip
17 16394 voip
17 16395 voip
17 16396 voip
17 16397 voip
17 16398 voip
17 16399 voip
17 16400 voip
17 16401 voip
17 16402 voip
17 16609 voip
17 16610 voip
17 16611 voip
17 16612 voip
17 16613 voip
17 16615 voip
17 16616 voip
17 16618 voip
17 514 ntp
17 520 rip
89 0 ospf

Barney · December 23, 2021, 10:41pm

You have a lot of triples, they only differ in the port number. Why do you have so many triples?

I made some further tests. The procedure is: start tcpdump, start call, stop call, stop tcpdump, check nlbwmon.

tcpdump says:
UDP-Dest/Src-Port 41044 (depending on the direction)

and I have a triple
17 41044 RTP

But there is no RTP line under Display/Application-Protocol.

I have no explanation for this behaviour.

Barney · December 24, 2021, 10:11pm

May I ask you to share your /etc/config/nlbwmon with me?

Today I did some more tests and research to find out, why your config is working and mine not.

What I do not understand: although tcpdum clearly says, that the sent frames are UDP

tcpdump -vvvv -r tcpdump.nlbwmon.other.eth1.2021-12-24.16-01-37.out | tail
reading from file tcpdump.nlbwmon.other.eth1.2021-12-24.16-01-37.out, link-type EN10MB (Ethernet)
16:02:13.146589 IP (tos 0xb8, ttl 127, id 42783, offset 0, flags [none], proto UDP (17), length 200)
    100.89.223.47.4054 > 195.185.37.60.37284: [udp sum ok] UDP, length 172
16:02:13.149394 IP (tos 0xb8, ttl 127, id 44860, offset 0, flags [none], proto UDP (17), length 200)
    100.89.223.47.4056 > 195.185.37.60.23456: [udp sum ok] UDP, length 172

nlbwmon does not recognize these frames as UDP, but summarize those under other. Bug or intention?

With wireshark I can see, that the UDP frame contains RTP protocol data:

Perhaps nlbwmon has a problem with embedded protocols.

Besides the protocols tcp(6) and udp(17) I tried these other protocols: ip(4), irtp(28), dccp(33), ipip(94), sctp(132). But all with the same result: nlbwmon summarizes the VoIP traffic under other.

I could not find a protocol number for RTP. So I guess RTP data is mostly embedded in UDP frames. Right or wrong?

At the moment I'm at my wits' end.

slh · December 25, 2021, 3:05am

Just to ask the obvious, are you using offloading of any kind (offloaded traffic is not seen by the kernel)?

Barney · December 25, 2021, 9:22pm

I don't understand your question. What do you mean with "offloading"?

If you're talking about offloading under Network->Firewall->Routing/NAT Offloading, then the answer is NO (no kind of offloading is activated, neither software nor hardware offloading, btw hardware offloading is no option for my router device Archer C7 V5). Otherwise I ask you to be more detailed.

I think the kernel (and therefore nlbwmon too) sees the VoIP traffic, but nlbwmon is assigning it to the wrong category. Because of the protocol mapping (17 4054 RTP) nlbwmon should assign the traffic to the category RTP. But it assigns the traffic to the category other. That's the problem.

slh · December 25, 2021, 9:25pm

Yes, I was referring to software- or hardware flow-offloading (respectively NSS on ipq806x/ ipq807x).

pavelgl · December 26, 2021, 11:50am

nlbwmon classifies the traffic based on the protocol and destination port number, defined in the /usr/share/nlbwmon/protocols file. In your case it has to be the remote RTP port, offered by your VoIP provider's server during the SDP negotiation.

Usually these ports are dynamically selected from a wide range. For example an asterisk server is configured by default to offer ports from 10000 to 20000 for RTP traffic.

I don’t think nlbwmon supports port ranges. You'll have to find out what is the port range, offered by your service provider and create a separate match for each port (as in the wulfy23’s example). Seems like mission impossible to me.

Right.

17 10000 RTP
17 5060 SIP

Barney · December 26, 2021, 6:03pm

Okay. BUT: voip traffic is bi-directional and nlbwmon watches up- and download traffic.

My voip phone sends data to my voip provider via a port number I do not know in advance. Therefore I can't define a mapping rule and as a consequence nlbwmon can't assign this traffic to a defined category, but only to the category other.

On the other side my voip provider sends also data to my voip phone via port numbers I defined in the phone (in my case 4050-4058). For these ports I also defined mapping rules (17 405[0-8] RTP). So, when the provider sends data to my phone via port 4054, nlbwmon should be able to catch this traffic and assign it to the category RTP. But nlbwmon assigns it to the category other. Why?

pavelgl · December 26, 2021, 6:14pm

6 443 HTTPS

Your source port is random, but nlbwmon doesn’t care about it to classify the traffic as HTTPS. It only cares about the destination port.

Barney · December 26, 2021, 10:01pm

I do not understand how your posting relates to my previous posting. Please explain more detailed (specially: how relates the mapping rule 6 443 HTTPS to voip traffic).

pavelgl · December 27, 2021, 7:58am

Please excuse me, I was in a hurry last night and tried to express myself in fewer words, obviously vaguely.

I meant knowing the source port doesn't help you to classify the traffic, because it is classified only based on the target port. If you know that you'll make a HTTPS request using for example source port 49350 an change the default entry to 6 49350 HTTPS, you'll never see HTTPS traffic on the chart.

Let me show you.
SIP signaling

src_port 5070 -> dest_port 5060
09:09:31.276411  In 00:00:5e:00:01:e8 37.157.xx.xx.5070 > 46.10.xx.xx.5060: UDP, length 980
09:09:31.276838 Out 00:c0:f0:6c:b3:53 46.10.xx.xx.5060 > 37.157.xx.xx.5070: UDP, length 563

nlbwmon settings

17 10000 RTP
17 5070 SIP70

There is no any signalling traffic. Now let's use the destination port.

17 10000 RTP
17 5060 SIP60

If you are willing to make some tests, I'll open temporarily my firewall and send you via PM credentials to register to my VoIP server. You will see, that knowing in advance the correct destination RTP port will make nlbwmon to classify the traffic corectly.

Barney · December 27, 2021, 10:08pm

Okay, I got it: the only thing, that matters is the destination/target port.

pavelgl:

1. src_port 5070 -> dest_port 5060
2. 09:09:31.276411  In 00:00:5e:00:01:e8 37.157.xx.xx.5070 > 46.10.xx.xx.5060: UDP, length 980
3. 09:09:31.276838 Out 00:c0:f0:6c:b3:53 46.10.xx.xx.5060 > 37.157.xx.xx.5070: UDP, length 563

In the 2nd line the destination/target port is 5060, in the 3rd line the destination/target port is 5070. What I do not understand: why doesn't SIP70 appear in nlbwmon's chart list? 5070 is destination/target port and there is a rule for 5070.

That's really confusing for me: we have 5060 and 5070 as destination/target ports with corresponding mapping rules. In the case of 5060 the traffic appears in the chart, in the case of 5070 it does not. In my view both 5060 and 5070 should appear in the chart list, because for both there is a mapping rule. What I really do not understand: why appears 5060, but 5070 does not (although both are destination/target ports). Can you explain?

Sorry, but I'm unable to recognize any legality. Nevertheless, thanks a lot for your time and your detailed explanation.

pavelgl · December 28, 2021, 2:34pm

The classification is based only on the router’s outgoing connections destination port. Port 5070 is a destination port, but in the reply and it is not taken into account for classification. What matters here is again the initial outgoing destination port (5060), which becomes a “reply” port and it is used in the traffic measurement.

BTW, tcpdump was run on the VoIP server and that's why In and Out in the dump are reversed.

Barney · December 29, 2021, 11:24pm

I think, that was the missing link for me. The destination port alone is not enough. What matters is the destination port of the first/initial request. The traffic of following replies is attributed to the first/initial request (independent of the destination port of the replies).

Is this really valid only for outgoing connections? What about incoming connections (e.g. my voip provider signals a new incoming call)?