GSE deencapsulator

[cgavrila1]

Hi there,

Wanted to ask you if there is also a grc "deencapsulator" block available.

Thank you

[drmpeg]

Not yet. Mostly because there's no complete DVB-S2 receiver for GNU Radio. I do have some receiver blocks here:

https://github.com/drmpeg/gr-dvbs2rx

I am considering writing a Linux kernel driver that would support some newer hardware receivers that can output baseband frames. It would probably be added on to https://github.com/torvalds/linux/blob/master/drivers/media/dvb-core/dvb_net.c

[drmpeg]

I've added a "de-encapsulation" or sink block. It's still a work in progress, but mostly finished. Right now, I'm having trouble routing the packets from the block through the TAP interface.

[cgavrila1]

Oh wow, thank you very much, will give it o try. Thanks a lot.

[drmpeg]

I just pushed a test flow graph (dvbs2_rxip.grc). It depends on the gr-dvbs2rx blocks. You have to set up two TAP interfaces before running it.

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

and

sudo ip tuntap add dev tap1 mode tap
sudo ip link set dev tap1 address 02:00:48:55:4c:4c
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

Right now, the packets coming out of tap1 go into a black hole. You can only see them with wireshark. You can test with ping packets (ping 44.0.0.2) or netcat (netcat -u 44.0.0.2 4444).

[cgavrila1]

You are the best, thank you very much.

[drmpeg]

I figured out the packet routing issue. It had to do with using different MAC addresses for the two TAP interfaces. To make ping traffic work, the two TAP interfaces should have the same address. For the updated flow graph:

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

and

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

Also, you have to disable reverse path filtering:

sudo sysctl -w net.ipv4.conf.all.rp_filter=0
sudo sysctl -w net.ipv4.conf.tap1.rp_filter=0

Then a ping should work.

ping 44.0.0.2 -c 1

You can use ping flooding to determine the throughput of the flow graph. On my machine, I can sustain:

sudo ping 44.0.0.3 -f -i 0.001 -c 5000 -s 3300

Which gives about 4 Mbps of throughput.

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.

[drmpeg]

BTW, the MAC address that I added to the IP Packet Sink block is a bit superfluous. It can actually be set to any value, including all zeros (00:00:00:00:00:00). I just put it in so that the source MAC address can be set to a desired value.

[cgavrila1]

Oh wow, thank you very much for your update. Did some local testing as well -> everything went smooth.

I do have another small question, if I may. Basically what I am trying to do now is to split tx & rx on separate machines. So all the tx is on machine A (with tap0) and the rx is on machine B (with tap1). Currently I am directing the output of the DVB-S2X Modulator to a file, and then, on machine B, the file is provided as input for the LDPC decoder.

The problem is that there is no data (ping flooding enabled on machine A). I saved the output of the IP Packet Source to file and when I've opened it with a GHex there are only a lot of "0"s.

I know that this might be out of topic, but do you have any idea why this happens?

Thank you very much.

[drmpeg]

The output is not quite all zeros. When there's no IP traffic, the DVB-S2 link has to send something, so it sends an empty baseband frame. Here's what it looks like:

The 0x72 is the MATYPE field. It's signalling 01 = Generic continuous, 1 = single input stream, 1 = CCM, 0 = ISSYI not active, 0 = NPD = not-active, and 10 = roll-off = 0.20. The rest of the header fields are all zero and the CRC-8 is 0x17.

The next header is going to be kbch bits later in the stream. For the short frame 1/4 rate, kbch = 3072 bits or 384 bytes. 384 = 0x180, so the next header is at 0x180.

The MAC address of 02:00:48:55:4c:55 is set intentionally to be easy to search for in ghex, since it spells out HULU in ASCII. Here's a single ping packet much later in the file that I found with the Find function in ghex.

[cgavrila1]

Oh yes, you are right.

I'm doing something wrong. Could it have something to do with the fact that 2 machines are used (tap0 - machine A, tap1 - machine B?

In my case, it seems as there is no IP traffic even though ping flooding is enabled on machine A:

sudo ping 44.0.0.3 -f -i 0.001 -c 5000 -s 3300

[drmpeg]

The TAP interfaces are independent. A two machine setup should work as long as the IQ stream is getting across. You won't get a ping reply, unless you set up some kind of return path.

[cgavrila1]

On machine A, I route the output of the DVB-S2 modulator to a file sink, then on machine B I provide the file as input for LDPC decoder.

But from the looks of it, the IP Packet Source sends only empty baseband frames even if ping flooding is enabled. Maybe it's something machine A related (ubuntu 18.04)

[cgavrila1]

Hi again,

So in the end it was a linux related issue, not sure exactly what was the cause but I switched to another machine and I got valid bb frames.

Now I have another issue with the de-encapuslator, I always get "Baseband header crc failed". Here is a screenshot of the hex bb frame file:

To test I use the following flow graph:

To get those bb frames I've used ping flooding at tx: sudo ping 44.0.0.3 -f -i 1 -c 5000 -s 100

I've also attached a zip containing the out_bb_frames.bin out_bb_frames.zip

I know that there were some losses between tx & rx but I would expected that at least some of the packets to be sent to tap1 if.

I know that this is much to ask, but would it be possible for you to take a look on the provided file? Thank you very much

[drmpeg]

You have an extra 8 bytes in front of every baseband frame. 01 00 00 00 01 00 00 00.

[ninjallan]

Hi @drmpeg. New to the entire GNU Radio project, so please bear with me. I tried to compile the code from a fresh checkout on Ubuntu 20.04 following your guide, but I am met with the following error. Am I doing something wrong:

/gr-dvbgse/lib/bbheader_source_impl.cc: In static member function ‘static gr::dvbgse::bbheader_source::sptr gr::dvbgse::bbheader_source::make(gr::dvbgse::dvb_standard_t, gr::dvbgse::dvb_framesize_t, gr::dvbgse::dvb_code_rate_t, gr::dvbgse::dvbs2_rolloff_factor_t, gr::dvbgse::dvbt2_inband_t, int, int, gr::dvbgse::dvbt2_ping_reply_t, gr::dvbgse::dvbt2_ipaddr_spoof_t, char*, char*)’: /gr-dvbgse/lib/bbheader_source_impl.cc:39:9: error: could not convert ‘gnuradio::get_initial_sptr(T*) with T = gr::dvbgse::bbheader_source_impl’ from ‘boost::shared_ptrgr::dvbgse::bbheader_source_impl’ to ‘gr::dvbgse::bbheader_source::sptr’ {aka ‘std::shared_ptrgr::dvbgse::bbheader_source’} |
38 | return gnuradio::get_initial_sptr 39 | (new bbheader_source_impl(standard, framesize, rate, rolloff, inband, fecblocks, tsrate, ping_reply, ipaddr_spoof, src_address, dst_address)); |
boost::shared_ptrgr::dvbgse::bbheader_source_impl make[2]: *** [lib/CMakeFiles/gnuradio-dvbgse.dir/build.make:63: lib/CMakeFiles/gnuradio-dvbgse.dir/bbheader_source_impl.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:269: lib/CMakeFiles/gnuradio-dvbgse.dir/all] Error 2 make: *** [Makefile:141: all] Error 2

[drmpeg]

@ninjallan Probably a mismatch between versions of GNU Radio. For this repository, the master branch is for GNU Radio 3.9. If you're running GNU Radio 3.8, you have to checkout the maint-3.8 branch.

git checkout maint-3.8

[ninjallan]

The GRC says v. 3.9, but there might be a mismatch / issue when I updated from 3.8 to 3.9. I'll check it out

[drmpeg]

I just updated the repository for GNU Radio 3.9 on April 22 (six days ago). Make sure you're using a fresh clone.

[ninjallan]

@drmpeg It was an issue with the Ubuntu install. I purged the old GR installation, manually removed some references, made a fresh compile from GR-repo and then everything worked like a charm. Thanks for the help so far. Now comes the fun stuff working with the module.