-
Notifications
You must be signed in to change notification settings - Fork 5
/
README
161 lines (114 loc) · 5.18 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
# Copyright 2016,2019 Ron Economos
#
# This file is part of gr-dvbgse
#
# gr-dvbgse is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# gr-dvbgse is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with gr-dvbgse; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
gr-dvbgse
======
Author: Ron Economos
Email: <[email protected]>
The goal of this project is to build GNU Radio blocks that implement
the ETSI TS 102 606-1 V1.2.1 Generic Stream Encapsulation standard:
http://www.etsi.org/deliver/etsi_ts/102600_102699/10260601/01.02.01_60/ts_10260601v010201p.pdf
Requirements:
A DVB-S2 receiver that supports the DVB-GSE protocol. This module was
tested with an Ayecka SR1 DVB-S2 receiver. Note that a special order SR1
is required. The stock SR1 only does MPE protocol. The DVB-S2 receiver
is connected to the DVB-S2 transmitter with a coaxial cable and 40 dB
attenuator for loopback testing.
http://www.ayecka.com/products-SR1.php
Usage:
Because the Pcap library is used to capture raw packets, the capabilities
of the Python interpreter need to be increased. This only needs to be
done once. Note that the specific version of Python 3 on your computer
needs to be specified (for example, python3.8 for Ubuntu 20.04).
sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/python3.x
CAUTION: This allows any Python program to open network interfaces.
The current implementation of the block uses a TAP network interface
named tap0.
To add a TAP interface (with ip(8) commands):
sudo ip tuntap add dev tap0 mode tap
sudo ip link set dev tap0 address 02:00:48:55:4c:4b
sudo ip addr add 44.0.0.1/24 broadcast 44.0.0.255 dev tap0
sudo ip link set tap0 up
sudo ip link set tap0 arp off
To forward packets received in the tap0 IP address range
to the default network interface (replace eth0 with your
default device name):
sudo sysctl -w net.ipv4.conf.all.rp_filter=0
sudo sysctl -w net.ipv4.conf.eth0.rp_filter=0
Note: This is required for the ping reply test feature
described below:
To delete the TAP interface:
sudo ip tuntap del dev tap0 mode tap
Testing features:
In order to test this block with just a single transmitter and
receiver, two optional testing modes are available.
The first is a ping reply feature. In this mode, the block modifies
incoming ping requests into ping replies and swaps the source
and destination IP addresses. This allows a normal ping command
to complete. Ping packets are very useful for testing since the
size and rate can be adjusted. Also, packet latency can be easily
measured.
The second feature is IP address spoofing for UDP packets. In this
mode the block modifies the source and destination IP address of
UDP packets to selected values. This allows for a loopback test
of video/audio over RTP using VLC. The destination IP address is
set to the host that the VLC RTP decoder is running on. Video is
useful for testing since dropped packets will cause bit-stream
errors (that VLC will report if you start it on the command line).
Here's what my video loopback flow looks like:
VLC RTP streaming to 44.0.0.3 -> tap0 interface -> DVB-GSE block ->
GNU Radio DVB-S2 transmitter -> Ettus B210 -> 40 dB attenuator ->
Ayecka SR1 receiver -> eth0 -> VLC RTP decoder from host address.
Both of the features should be shut off for normal full-duplex
operation.
Update 03/20/2019: A DVB-GSE sink block has been added for support
of a future DVB-S2 receiver in GNU Radio. The sink block can be
tested with the flow graph dvbs2_rxip.grc in the /apps directory.
This flow graph depends on the DVB-S2 receiver block in gr-dvbs2rx.
https://github.com/drmpeg/gr-dvbs2rx
The test flow requires two TAP interfaces to be configured:
sudo ip tuntap add dev tap0 mode tap
sudo ip link set dev tap0 address 02:00:48:55:4c:55
sudo ip addr add 44.0.0.1/24 broadcast 44.0.0.255 dev tap0
sudo ip link set tap0 up
sudo ip link set tap0 arp off
sudo ip tuntap add dev tap1 mode tap
sudo ip link set dev tap1 address 02:00:48:55:4c:55
sudo ip addr add 44.0.1.1/24 broadcast 44.0.1.255 dev tap1
sudo ip link set tap1 up
sudo ip link set tap1 arp off
sudo sysctl -w net.ipv4.conf.all.rp_filter=0
sudo sysctl -w net.ipv4.conf.tap1.rp_filter=0
Traffic can be generated with ping packets.
ping 44.0.0.2
Throughput can be tested with a ping flood. Adjust the size parameter
(-s 3300) to control the rate. The printed dots should be relatively
stable, If the dots increase slowly (or quickly) you're going faster
than the simulated link can handle (and the size parameter should be
reduced). -s 3300 corresponds to a rate of about 4 Mbps.
sudo ping 44.0.0.2 -f -i 0.001 -c 5000 -s 3300
Dependencies:
libpcap-dev
Build instructions:
mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig
Contributions are welcome!