Bug 1524180 - "fou" decapsulation port appears to just not work
Summary: "fou" decapsulation port appears to just not work
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-10 14:25 UTC by Dale R. Worley
Modified: 2018-03-25 00:57 UTC (History)
20 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-03-25 00:57:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
This is the "pktsend" program used in the "Additional info" section. (3.92 KB, application/x-perl)
2017-12-10 14:25 UTC, Dale R. Worley
no flags Details

Description Dale R. Worley 2017-12-10 14:25:19 UTC
Created attachment 1365630 [details]
This is the "pktsend" program used in the "Additional info" section.

Description of problem:
Creating and using a simple "fou" decapsulation port ("ip fou port add ...") reports success, and the port is reported in netstat output, but sending a packet to the port results in an ICMP "protocol 17 unreachable" message.

Version-Release number of selected component (if applicable):
4.13.16-202.fc26.x86_64

How reproducible:
reliably reproducible

Steps to Reproduce:
1. sudo modprobe fou
2. sudo ip fou add port 50100 ipproto 4
3. Send packet to port 50100, whose payload is a UDP-in-IP packet.

Actual results:
ICMP "protocol 17 unreachable" message generated, encapsulated packet is not extracted and processed

Expected results:
Encapsulated packet is extracted and forwarded to process listening on the UDP destination port specified in the packet, no ICMP message

Additional info:
details of how I reproduce the problem:

$ # Identify the kernel version.
$ uname -r
4.13.16-202.fc26.x86_64
$ cat /etc/redhat-release
Fedora release 26 (Twenty Six)
$ 

$ # Set up a fou decap port on 50100 and a simple UDP listener on 49000.
$ sudo modprobe fou
$ sudo ip fou add port 50100 ipproto 4
$ # Log all IP traffic.
$ PARMS='-v -s 1500 -l -nn -x'
$ sudo tcpdump $PARMS -i lo >logs/lo &
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 1500 bytes
[1] 2991
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 1500 bytes
$ nc -u -l 127.0.0.1 49000 &
[2] 2993
$ # netstat shows both ports set up for listening.
$ sudo netstat -n --udp -a -p
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp        0      0 0.0.0.0:35075           0.0.0.0:*                           812/avahi-daemon: r 
udp        0      0 127.0.0.1:323           0.0.0.0:*                           837/chronyd         
udp        0      0 0.0.0.0:50100           0.0.0.0:*                           -                   
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           812/avahi-daemon: r 
udp        0      0 127.0.0.1:49000         0.0.0.0:*                           2993/nc             
udp        0      0 192.168.124.1:53        0.0.0.0:*                           1186/dnsmasq        
udp        0      0 0.0.0.0:67              0.0.0.0:*                           1186/dnsmasq        
udp6       0      0 ::1:323                 :::*                                837/chronyd         
udp6       0      0 :::5353                 :::*                                812/avahi-daemon: r 
udp6       0      0 :::54610                :::*                                812/avahi-daemon: r 
$ # Run simple sender of an encapsulated packet.
$ # This program is attached to this bug report as "pktsend".
$ ./pktsend 127.0.0.1:48000 test-1
03:37:21.362856 response:
03:37:21.363030 packet underlay: 127.0.0.1:48000 -> 127.0.0.1:50100
03:37:21.363030 overlay: 127.0.0.1:48000 -> 127.0.0.1:49000
03:37:21.363030 payload: test 1
03:37:21.363030     45 00 00 22   00 00 00 00   ff 11 bd c8   7f 00 00 01   
03:37:21.363030     7f 00 00 01   bb 80 bf 68   00 0e 7c de   74 65 73 74   
03:37:21.363030     20 31 

$ # Show the tcpdump output.
$ cat logs/lo
03:37:21.362801 IP (tos 0x0, ttl 64, id 13023, offset 0, flags [DF], proto UDP (17), length 62)
    127.0.0.1.48000 > 127.0.0.1.50100: UDP, length 34
	0x0000:  4500 003e 32df 4000 4011 09ce 7f00 0001
	0x0010:  7f00 0001 bb80 c3b4 002a fe3d 4500 0022
	0x0020:  0000 0000 ff11 bdc8 7f00 0001 7f00 0001
	0x0030:  bb80 bf68 000e 7cde 7465 7374 2031
03:37:21.362842 IP (tos 0xc0, ttl 64, id 57444, offset 0, flags [none], proto ICMP (1), length 90)
    127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 protocol 17 unreachable, length 70
	IP (tos 0x0, ttl 64, id 13023, offset 0, flags [DF], proto UDP (17), length 54, bad cksum 9ce (->9d6)!)
    127.0.0.1.48000 > 127.0.0.1.50100: UDP, bad length 34 > 26
	0x0000:  45c0 005a e064 0000 4001 9b7c 7f00 0001
	0x0010:  7f00 0001 0302 7f87 0000 0000 4500 0036
	0x0020:  32df 4000 4011 09ce 7f00 0001 7f00 0001
	0x0030:  bb80 c3b4 002a fe3d 4500 0022 0000 0000
	0x0040:  ff11 bdc8 7f00 0001 7f00 0001 bb80 bf68
	0x0050:  000e 7cde 7465 7374 2031
$ 

( BB80 == 48000, C3B4 == 50100 )

Comment 1 Laura Abbott 2017-12-11 18:47:28 UTC
This is best reported directly to the networking maintainers upstream. Has this ever worked in the past? (i.e. is this a regression)

Comment 2 Dale R. Worley 2017-12-13 04:44:17 UTC
(In reply to Laura Abbott from comment #1)
> This is best reported directly to the networking maintainers upstream.

That sounds good, but I have no idea how to contact "the networking maintainers upstream".  I did search a bit for possible contacts, but found none.

> Has this ever worked in the past? (i.e. is this a regression)

I've never attempted to use it before.  There are a number of online blog/journal articles which speak as if the feature has already been delivered.  I have not personally communicated with anyone who says they've used it.

Comment 3 Laura Abbott 2018-02-28 03:46:42 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs.
 
Fedora 26 has now been rebased to 4.15.4-200.fc26.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27.
 
If you experience different issues, please open a new bug report for those.


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