Bug#762097: nat-rtsp-dkms: not work

Eduardo

unread,

Sep 18, 2014, 8:30:02 AM9/18/14

to

Package: nat-rtsp-dkms
Version: 0.7+1.g2ea3cb6-1
Severity: important

Dear Maintainer,

get_skb_tcpdata does not return a pointer to the actual protocol
string. http://mike.it-loops.com/item/29
The following patch fixed it for me, http://pastebin.com/JGw6QKVN

-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nat-rtsp-dkms depends on:
ii dkms 2.2.0.3-1.2

nat-rtsp-dkms recommends no packages.

nat-rtsp-dkms suggests no packages.

-- no debconf information

--
Eduardo

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Julien Muchembled

unread,

Sep 20, 2014, 12:10:01 PM9/20/14

to

Control: tags -1 upstream

Hello,

Le 09/14/14 23:37, Eduardo a �crit :

> get_skb_tcpdata does not return a pointer to the actual protocol string. http://mike.it-loops.com/item/29
> The following patch fixed it for me, http://pastebin.com/JGw6QKVN

This is an upstream issue and I don't know this software well enough to help without more information.
The fact is nat-rtsp-dkms works for my use, so can you detail what does not work ? Step to reproduce, actual and expected results, from user point of view ? I read http://mike.it-loops.com/item/29 and I still don't understand the issue.

And let's find a better title for this bug report.

Julien

Eduardo

unread,

Sep 21, 2014, 5:30:03 AM9/21/14

to

El 20/09/14 a las #4, Julien Muchembled escribió:

> Control: tags -1 upstream
>
> Hello,

Hello
>
> Le 09/14/14 23:37, Eduardo a écrit :

>> get_skb_tcpdata does not return a pointer to the actual protocol string. http://mike.it-loops.com/item/29
>> The following patch fixed it for me, http://pastebin.com/JGw6QKVN
> This is an upstream issue and I don't know this software well enough to help without more information.
> The fact is nat-rtsp-dkms works for my use, so can you detail what does not work ? Step to reproduce, actual and expected results, from user point of view ? I read http://mike.it-loops.com/item/29 and I still don't understand the issue.

I have hired an IP TV service, it uses RTSP to control for the video
stream of recordings made on the network, or rent movies.

When I play a recording I don't see the video with the original nat-rtsp.
This is the debug log:

kernel: [202359.912728] conntrackinfo = 2
kernel: [202359.919492] IP_CT_DIR_REPLY
kernel: [202359.928582] IP_CT_DIR_REPLY
kernel: [202359.932686] conntrackinfo = 2
kernel: [202359.936438] found a setup message
kernel: [202359.936441] tran='Transport:
MP2T/H2221/UDP;unicast;client_port=27524-27524
kernel: [202359.936441] '
kernel: [202359.936444] lo port found : 27524
kernel: [202359.936445] incorrect range: 27524-27524, correcting
kernel: [202359.936447] udp transport found, ports=(1,27524,27525)
kernel: [202359.936453] setup expectation for rtcp
kernel: [202359.936456] expect_related 0.0.0.0:0-0-10.159.1.2:27524-27525
kernel: [202359.936457] NAT rtsp
help_out <------- help_out function
kernel: [202359.973795] IP_CT_DIR_REPLY
kernel: [202360.097380] IP_CT_DIR_REPLY
kernel: [202368.980570] teardown handled

When I do it with the patch applied works fine. This is de debug log:

kernel: [202452.534205] conntrackinfo = 2
kernel: [202452.540698] IP_CT_DIR_REPLY
kernel: [202452.546613] IP_CT_DIR_REPLY
kernel: [202452.550763] conntrackinfo = 2
kernel: [202452.552988] found a setup message
kernel: [202452.552991] tran='Transport:
MP2T/H2221/UDP;unicast;client_port=27577-27577
kernel: [202452.552991] '
kernel: [202452.552994] lo port found : 27577
kernel: [202452.552995] incorrect range: 27577-27577, correcting
kernel: [202452.552997] udp transport found, ports=(1,27576,27577)
kernel: [202452.553003] setup expectation for rtcp
kernel: [202452.553006] expect_related 0.0.0.0:0-0-10.159.1.2:27576-27577
kernel: [202452.553008] NAT rtsp help_out <------- help_out
function
kernel: [202452.553010] hdr: len=9, CSeq: 3
kernel: [202452.553012] hdr: len=25, User-Agent: MICA-IP-STB
kernel: [202452.553013] hdr: len=59, Transport:
MP2T/H2221/UDP;unicast;client_port=27577-27577 <-- working transport header
kernel: [202452.553015] hdr: Transport <-- transport header found
kernel: [202452.553016] stunaddr=10.159.1.2 (auto)
kernel: [202452.553037] nat expect_related
0.0.0.0:0-0-10.159.1.2:27576-27577
kernel: [202452.553039] multiple ports found, port 27577 ignored
kernel: [202452.553041] rep: len=59, Transport:
MP2T/H2221/UDP;unicast;client_port=27577-27577
kernel: [202452.553042] hdr: len=14, x-mayNotify:
kernel: [202452.588442] IP_CT_DIR_REPLY
kernel: [202452.724977] IP_CT_DIR_REPLY
kernel: [202452.997084] IP_CT_DIR_REPLY
kernel: [202453.249488] IP_CT_DIR_REPLY
kernel: [202461.594828] teardown handled

The difference between the two logs is that in the first help_out in
nf_nat_rtsp.c not find the Transport header. You can see in the lines
beginning with 'hdr:' after 'rtsp help out' and before IP_CT_DIR_REPLY.

The Troll says get_skb_tcpdata does not return a pointer to the actual
protocol string. So I try to retrieve the pointer using
skb_header_pointer. And the patch does.

> And let's find a better title for this bug report.

I titled it 'not work' because it does not work for me.
And, what about 'get_skb_tcpdata does not return a pointer to the actual
protocol string'?

Sorry, the patch is http://pastebin.com/XsyyCxzW

Sorry about my english.

> Julien

--
Eduardo

Julien Muchembled

unread,

Oct 6, 2014, 3:20:03 PM10/6/14

to

Thank you for the detail. And just an email to write what I've done so far.

If I'm going to contribute upstream, I prefer to first have a way to easily test things, so I started to write a unit test which sets up 3 nodes (server, router & client) using network namespaces.

However, I'm stuck because it works without nf_nat_rtsp loaded. I tried VLC & GStreamer as server. I discovered that UDP streams are initiated by the client and that both servers reply to correct source port so simple NAT is of course enough.

Just wondering why there are rtsp servers in the wild that don't simply work like that. I guess you don't know any server I could use to finish this unit test.

Julien Muchembled

unread,

Feb 22, 2015, 3:50:03 PM2/22/15

to

Le 12/26/14 09:22, Eduardo a écrit :
> El 25/12/14 a las 07:23, Eduardo escribió:
>> ...
>>
>> I have written a tiny rtsp server and client. I created, with kvm, three virtual machines, a firewall (router), a server and a client,
>> ...
>
> Sorry, there are some errors in server and client, try this new version.
>

I've just tested your scripts and unfortunately, I couldn't reproduce the reported bug.
But at least, they require nf_nat_rtsp on the router so I'll make a unit test from them.

2 attached files:
- The 'test' script must be run as root in the same directory as your scripts. It creates 3 machines using network namespaces and runs the server & client at the end. The test fails if the module is not loaded before.
- 'rtsp_output' is what I get on my machine. Server & client outputs are mixed.

rtsp_output

test