lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Thu, 14 Jan 2021 14:45:21 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 211175] New: gretap does not fragment packets regardless
 of the DF flag



Begin forwarded message:

Date: Wed, 13 Jan 2021 13:37:33 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.org
Subject: [Bug 211175] New: gretap does not fragment packets regardless of the DF flag


https://bugzilla.kernel.org/show_bug.cgi?id=211175

            Bug ID: 211175
           Summary: gretap does not fragment packets regardless of the DF
                    flag
           Product: Networking
           Version: 2.5
    Kernel Version: 5.10.4
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@...workplumber.org
          Reporter: pupilla@...mail.com
        Regression: No

Hello everyone,

I'm running linux 5.10.4 with iproute-5.10 on Slackware (64bit).

When I try to configure a gretap device with the "ignore-df" I getting this
error: 

ip link add testgre type gretap remote 10.42.44.6 local 10.86.44.6 ignore-df
RTNETLINK answers: Invalid argument

Instead, if I try to run the following command it is going to be executed:
ip link add testgre type gretap remote 10.42.44.6 local 10.86.44.6 noignore-df

Also I have noticed that the icmp datagrams with the DF=none are not fragmented
anyway.
For example this is a tcpdump capture showing a 1459 bytes lenght icmp packet
that is not going to be fragmented and delivered to the other remote gretap
linux box (running the same kernel version).

ethertype 802.1Q (0x8100), length 1477: vlan 802, p 0, ethertype IPv4, (flags
[none], proto ICMP (1), length 1459)
    192.168.1.247 > 192.168.1.1: ICMP echo request, id 10287, seq 0, length
1439


Is this expected?


This is my full gretap setup: eth0 mtu is 1500 bytes.

ip link add testgre type gretap remote 10.42.44.6 local 10.86.44.6
ip link set testgre up
ip link set eth0 up


ip link add name br0 type bridge
ip link set br0 up

ip link set testgre master br0
ip link set eth0 master br0


and this my 'ip a s' output:

13: testgre@...E: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc pfifo_fast
master br0 state UNKNOWN group default qlen 1000
    link/ether 5e:56:0a:0c:12:f0 brd ff:ff:ff:ff:ff:ff
14: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc noqueue state UP
group default qlen 1000
    link/ether 5e:56:0a:0c:12:f0 brd ff:ff:ff:ff:ff:ff

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ