The information that I'm seeing conflicts -- the wikipedia page on unicast flooding cites protected mode as a mechanism to block flooding, while Cisco's documentation says that switchport protected doesn't matter, and that switchport block unicast would still be needed to prevent flooding.
switchport protected is used to enforce privacy within a vlan... the command prevents ports from talking to other ports configured with switchport protected. This command reduces flooding as a side-effect of using it on all ports in a Vlan, but it does much more than "just" remove flooding from a switchport. Honestly, I think there are better ways to accomplish your goals.
switchport protected is useful if you're aggregating colocation customers in the same vlan; this command is one way to offer privacy between the customers without the complications of private vlans. The wikipedia article you mentioned, says you can "bounce" traffic off the default gateway (which should not be on a protected switchport) to reach those other destinations...
switchport block unicast does stop unknown unicast flooding; however, see below for why I think you shouldn't need this command.
However, I recently ran into an issue where on a 2950G running some relatively ancient 12.1(22) code, unicast flooding seemed to be completely broken for a protected port -- the aging time on the switch was 5 minutes, while the router's ARP timeout was 30 minutes, and the one TCP connection utilizing this interface had a tendency to sit dormant for 10 minutes at a time - and be non-functional when waking up after 10 minutes in this case.
As I mentioned in my comment, if there is any potential for an asymmetric routed path in this network, you either need unknown unicast flooding, or you need to match the CAM and ARP timers to ensure that CAM entries don't age out before the ARP entries.
In most cases, matching the ARP and CAM timers is the right way to fix the situation, but the choice is yours...
EDIT to respond to the comments:
Setting the timers to match is working great as a workaround - I just don't understand why the flooding isn't happening as expected.
Quoting from "CCIE Practical Studies, Volume 2", page 115 by Karl Solie, Leah Lynch, Charles Ragan:
If unknown unicast and multicast traffic is forwarded to a protected port, there could be security issues. To prevent unknown unicast or multicast traffic from being forwarded from one port to another, you can configure a port (protected or nonprotected) to block unknown unicast and multicast traffic.
3550_switch(config-if)#switchport block unicast
3550_switch(config-if)#switchport block multicast
I'm wondering why packets don't enter in the queue at all before being dropped.
Because they were errors: 8097 input errors, 7120 CRC, 894 frame It will not queue a packet that wasn't received properly -- or wasn't received completely (input queue is in software, you can still overrun the hardware queue, which you cannot change)
Best Answer
The Problem could be solved by doing a firmware update. After the update the scanning process works fine now.