17 Mar
2019
17 Mar
'19
10:54 p.m.
Thanx for the reply. In hindsight, I now know that's true. I ended up
instrumenting the kernel with printk's (actually the new scheme,
pr_info) to trace where the packets were getting dropped.
As it turns out, the problem was an artifact of my test setup. In order
to simulate the DVB-S2 RF link on one host, I ended up with two TAP
interfaces. Without thinking about it, I assigned each TAP interface a
unique MAC address.
For testing, I use ping packets (which I find incredibly useful). Inside
the simulation, I modify ping requests into ping replies to simulate a
remote host. But for this setup, the ping packets were coming in on tap0
but being returned on tap1. Since tap1 has a different MAC address, the
network stack drops the packets with status PACKET_OTHERHOST. Doh!
Easy fix, just use the same MAC address on both TAP interfaces. The ping
trick also requires setting net.ipv4.conf.all.rp_filter=0, but I already
knew that from earlier projects.
I did learn some cool stuff about the Linux networking stack, so it
wasn't a complete waste of time. But building the Ubuntu kernel with the
"Debian way" is pretty tedious.
Ron W6RZ
On 3/17/19 12:59, Rob Janssen wrote:
I'm
writing a DVB-GSE receiver block for GNU Radio. It will be used
in a future software defined DVB-S2 receiver. I've pretty much
completed the block, but I'm stuck on how to forward packets written
to the TAP interface into the Linux network stack.
That happens automatically. The tap interface has two sides, one
exists as
a Linux network interface that you configure just as any network
interface
and the other side is accessed via the socket in your application.
Forwarding is done as on any network: you assign IP addresses and
subnet masks
to either side and send your packets to addresses living on the other
side.
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net