Bug 562220

This was actually found on:

Fedora 10 (Cambridge)
kernel Linux 2.6.75.5-117.fc.10.i686

(In reply to comment #1)
> This was actually found on:
> 
> Fedora 10 (Cambridge)
> kernel Linux 2.6.75.5-117.fc.10.i686    

hi,

could you please specify kernel version it works for you?

I'm running hping like:
hping -V -I eth0 -1x server

and I dont see any ICMP packet in tcpdump output
on the quite fresh upstream kernel 2.6.34-rc7

I think you're right the raw socket should put it on the device
regardless the MF flag.

jirka

It worked on Ubuntu 9.04 which uses the 2.6.28-11.37 kernel, where I did not see any packets dropped due to packet contents.

I have not seen it work on RedHat/Fedora systems. I think the issue is in a transmit module which is shared by both raw sockets and non-raw sockets, with flags directing processing according to whether it is a raw socket transmission or not in the transmit module. 

The raw socket path may benefit from a seperate transmit module so that only raw socket handling is ever used in transmission.

Created attachment 415713 [details]
netfilter patch for raw socket

the packet is eaten by netfilter code, the attached patch fixes the issue
for me in the current upstream kernel

I'm building RHEL5 kernel and will test/attach for you to test as
soon as it's done

since I'm out next week I'll send the change to upstream the week after

the patch did not fix the issue in RHEL5 for me.. not sure why,
will be back in a week

jirka

hi,

please check http://people.redhat.com/jolsa/562220/

I prepared the kernel rpm with the fix, let me know
if it works for you

thanks,
jirka

plz check http://marc.info/?l=linux-netdev&m=127592257324084&w=2
for the latest news

jirka

it's got to the upstream
http://marc.info/?l=linux-netdev&m=127732148621511&w=2

I have the patch for the hping to use the kernel change,
but I'm not sure how much trouble will it be to get it to hping upstream.

let me know if you're interested (I can try push the hping change as well)
or the kernel change is enough

I'll follow up next week, based on answer

wbr,
jirka

Thanks,

 I am interested in both the kernel and the hping, thanks. When you can.

Bob

I put both kernel and hping3 rpms for x86_64 in here:
http://people.redhat.com/jolsa/562220/


let me know if it works for you

thanks,
jirka

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

in kernel-2.6.18-219.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

(In reply to comment #15)
> in kernel-2.6.18-219.el5
> You can download this test kernel from http://people.redhat.com/jwilson/el5
> 
> Detailed testing feedback is always welcomed.

unable to reproduce... testing using hping as described in comment 2, tcpdump shows the outgoing ICMP packets on unpatched kernel.

terminal 1:
[root@xxx ~]# hping -V -I eth0 -c 5 -1x www.redhat.com 
using eth0, addr: 10.16.64.129, MTU: 1500
HPING www.redhat.com (eth0 10.4.127.15): icmp mode set, 28 headers + 0 data bytes

--- www.redhat.com hping statistic ---
5 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
terminal 2:
[root@xxx~]# tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
05:51:58.806691 IP xxx > 10.4.127.15: ICMP echo request, id 3344, seq 0, length 8
05:51:59.807584 IP xxx > 10.4.127.15: ICMP echo request, id 3344, seq 256, length 8
05:52:00.808597 IP xxx > 10.4.127.15: ICMP echo request, id 3344, seq 512, length 8
05:52:01.809613 IP xxx > 10.4.127.15: ICMP echo request, id 3344, seq 768, length 8
05:52:02.810625 IP xxx > 10.4.127.15: ICMP echo request, id 3344, seq 1024, length 8

5 packets captured
5 packets received by filter
0 packets dropped by kernel
[root@xxx ~]# uname -ri
2.6.18-215.el5 x86_64

hping3 192.168.1.10 -x

  --yields no packets transmitted from the kernel, effectively eliminating the
capability to transmit over a raw socket.

(In reply to comment #18)
> hping3 192.168.1.10 -x
> 
>   --yields no packets transmitted from the kernel, effectively eliminating the
> capability to transmit over a raw socket.

Bob, can you please confirm this works as expected on your Ubuntu 9.04?

I've used hping3 from source(http://www.hping.org/hping3-20051105.tar.gz) and no packets are actually transmitted. The behaviour is same on unpatched 2.6.18-215.el5 x86_64, patched 2.6.18-219.el5 x86_64 and RHEL6 2.6.32-71.el6.x86_64.

I want to be sure this is rhel kernel issue, not hping3 fault.

hi,

you need both kernel and hping with IP_NODEFRAG option feature.
kernel has it, but hping3 does not..

they have not accepted the patch I sent them yet..
it needs some more redo work..

I made the hping3 rpm with the patch, take it from:
http://people.redhat.com/jolsa/562220/

jirka

After discussion with Jiri and retesting moving to verified.
The rights hping3 option schould be -1x. Using the patched hping3 and unpatched kernel, hping3 complains it can't set IP_NODEFRAG option. Although the packet is transmitted anyway. This verifies in -219 kernel this option was added.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0017.html