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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net