Bug 115031 - IP-over-DDP packets dropped when 'ipddp' module is compiled but not loaded
Summary: IP-over-DDP packets dropped when 'ipddp' module is compiled but not loaded
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-20 19:16 UTC by Adam Seering
Modified: 2016-03-23 13:54 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.4
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Adam Seering 2016-03-20 19:16:29 UTC
When a kernel is compiled with "ipddp" loaded as a module, but the module is not loaded, DDP packets of type 22 (IP-over-DDP) are silently dropped.

Steps to reproduce:
1. Compile a kernel with 'ipddp' as a module.  Do not load the module; make sure it is not loaded, just compiled.
2. Open up a DDP listening socket for packets of type 22, on any supported network interface.  (Tested with Ethernet.)
3. Attempt to connect to and send data to this socket

Expected behavior:
- If module is loaded, packets will be unwrapped by the kernel and emitted as IP packets (so will not be received by the listening DDP socket)
- If module is not present, packets will be passed through to the listening DDP socket

Actual behavior:
- If module is not present but was compiled during the kernel build process, packets are silently discarded by the kernel
- If module is not present and was not compiled during the kernel build process, packets are passed through as expected
Comment 1 Adam Seering 2016-03-20 19:32:06 UTC
I ran into this issue while working on the port of `MacIPGW` from FreeBSD:
https://github.com/zero2sixd/macipgw

The issue is caused by code in "net/appletalk/ddp.c" -- there's some code whose implementation is conditional on "defined(CONFIG_IPDDP) || defined(CONFIG_IPDDP_MODULE)" that appears to me to behave as if the module is not only configured but loaded.

I submitted a patch a month ago to the netdev list; it has not been accepted, but I think it accurately points out the relevant bit of code:  (I tested the patch and it fixes my problem.)

https://patchwork.ozlabs.org/patch/586876/

I CC'ed Arnaldo Carvalho de Melo (listed in MAINTAINERS as the maintainer of the AppleTalk Network Layer) but his listed e-mail address bounces.  My interpretation of David Miller's response is that he prefers a userspace solution?  But I don't understand how to solve this in userspace.

Note You need to log in before you can comment on or make changes to this bug.