Linux: Kernel: packet size is too short

[hfreire]

Hi,

I seem to be getting several of these when using nmap and other network scanning tools from my Raspberry Pi 3:

Mar 21 00:54:18 rpi8 kernel: [ 6369.882971] nmap: packet size is too short (42 <= 50)

All programs terminate with an error due to not being able to send packets.

Output of uname -a:
Linux rpi8 4.1.19-v7+ #853 SMP Wed Mar 9 18:09:16 GMT 2016 armv7l GNU/Linux

Note: I did test the same commands on a Raspberry Pi 2 and it did work. The output of uname -a on that one is:
Linux rpi3 4.1.7-v7+ #817 SMP PREEMPT Sat Sep 19 15:32:00 BST 2015 armv7l GNU/Linux

[pelwell]

You can help by giving an example command that you run that causes the error.

[hfreire]

root@rpi8 ~ # nmap 10.172.161.184

Starting Nmap 6.47 ( http://nmap.org ) at 2016-03-21 10:51 CET
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.87 seconds

[pelwell]

I can confirm it fails on WiFi:

pi@raspberrypi:~$ sudo nmap 10.3.15.93
Starting Nmap 6.47 ( http://nmap.org ) at 2016-03-21 09:54 GMT
[232941.973936] nmap: packet size is too short (42 <= 50)
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
[232942.174190] nmap: packet size is too short (42 <= 50)
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.74 seconds

but works on Ethernet:

pi@raspberrypi:~$ sudo nmap 10.3.14.167
Starting Nmap 6.47 ( http://nmap.org ) at 2016-03-21 09:54 GMT
Nmap scan report for 10.3.14.167
Host is up (0.0011s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs
MAC Address: 08:00:27:76:7C:99 (Cadmus Computer Systems)
Nmap done: 1 IP address (1 host up) scanned in 7.46 seconds

[hfreire]

That's an interesting finding...

Could it be something specific with the new WiFi hardware? I haven't tried with a USB WiFi dongle yet.

Are you aware of anyway of bypassing/overriding that packet size without a kernel modification?

[pelwell]

I suspect it's a problem with the driver for the WiFi interface. Broadcom have been alerted.

I'm not aware of any workarounds, but I'm not an expert - I can see that the MTUs for WiFi and Ethernet are both 1500 (as they should be), and that's my limit without a lot of digging through the networking stack and driver.

[pelwell]

I had a WiFi dongle to hand:

pi@raspberrypi:~$ sudo nmap 10.3.15.93
Starting Nmap 6.47 ( http://nmap.org ) at 2016-03-21 10:18 GMT
Nmap scan report for 10.3.15.93
Host is up (0.053s latency).
Not shown: 993 filtered ports
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2869/tcp open  icslap
3389/tcp open  ms-wbt-server
5800/tcp open  vnc-http
5900/tcp open  vnc
MAC Address: C4:D9:87:63:21:E4 (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 22.59 seconds

It's clearly not a problem common to all WiFi interfaces.

[clivem]

I suspect it's a problem with the driver for the WiFi interface. Broadcom have been alerted.

I don't think it's the driver. The brcmfmac driver works just fine with nmap and other bcm43xxx hardware. I just checked nmap from a Wandboard (bcm4329). It works as expected. (Only code difference in the driver is your one-liner to disable power management on the Pi.) Anyway, it needs Broadcom to investigate....... I'd say it is specific to the variant of the brcm43xxx chipset being used on the Pi.

[pelwell]

nmap works with the brcmfmac driver in the rpi-4.4.y tree (the current build tree). You could try a sudo rpi-update if you want to give it a try, or you can wait for the next sudo apt-get upgrade release.

[pelwell]

I've applied a Broadcom-supplied patch with the following commit message:

brcmfmac: use ndev->needed_headroom to reserve additional header space

When using nmap tool with FMAC, the nmap packets were be dropped by kernel
because the size was too short. The kernel message showed like
"nmap: packet size is too short (42 <= 50)". It is caused by the packet
length is shorter than ndev->hard_header_len. According to LL_RESERVED_SPACE()
and hard_header_len definition, we should use hard_header_len to reserve L2
header, like ethernet header(ETH_HLEN) in our case and use needed_headroom for
the additional headroom needed by hardware.