It turned out that any wireless Ethernet card's device driver in a non-promiscuous mode does not drop any Ethernet frame with the following destination MAC address:
YY:xx:xx:xx:xx:xx, where YY is an odd number (e.g., 0xE1, 0x11, 0x01, etc.)

Although the MULTICAST capability had been turned off with ifconfig eth1 -multicast, this behavior remains. Unfortunately, the BROADCAST capability could not be turned off with ifconfig eth1 -broadcast.

I write "any wireless Ethernet" as a generalization from what I have experienced with two wireless Ethernet cards from two different vendors: Ralink and Intel.

I also have tried this with two wired Ethernet cards from two different vendors: Realtek and Intel, but they did not exhibit this kind of behavior. They only received a frame with the normal broadcast address (i.e., FF-FF-FF-FF-FF-FF), the IETF multicast address (i.e., 01-00-05-xx-xx-xx), and their own MAC addresses, but not a frame whose first-byte of the MAC address is odd.

Furthermore, my friend helped me to turn of the BROADCAST capability that ifconfig reported with a kernel module whose code is as follows:

#include <asm/errno.h>
#include <asm/types.h>
#include <linux/ctype.h>
#include <linux/if_ether.h>
#include <linux/if_packet.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>

#include <linux/rtnetlink.h>
#include <linux/netdevice.h>


MODULE_LICENSE("GPL");
MODULE_AUTHOR("Cip");
MODULE_DESCRIPTION("Turning off the BROADCAST flag");
MODULE_SUPPORTED_DEVICE("netdevice");

void dev_getdevandchangeflag(void);

static int __init init_dev_own(void)
{
        dev_getdevandchangeflag();

        return 0;
}
module_init(init_dev_own);

static void __exit cleanup_dev_own(void)
{
}
module_exit(cleanup_dev_own);

void dev_getdevandchangeflag(void)
{
        struct net_device *dev;
        unsigned char *hw_addr = NULL;
        int i = 1;
        int j;

        rtnl_lock();
        for (dev = dev_base; dev; dev = dev->next) {
                printk(KERN_ALERT "%d\t", i);
                hw_addr = dev->dev_addr;
                for (j = 0; j < dev->addr_len; j++) {
                        printk("%02X", hw_addr[j]);
                        if (j != dev->addr_len - 1) {
                                printk(":");
                        }
                }
                dev_change_flags(dev, IFF_ALLMULTI);
                dev->flags &=~IFF_BROADCAST;
                dev_change_flags(dev, IFF_BROADCAST);

                printk("\n");
                printk("\t\tdev_get_flags(): %02X", dev_get_flags(dev));
                printk("\n");
                printk(" (%02X)", dev->flags);
                printk("\n");
                i++;
        }
        rtnl_unlock();
}

After running this code, ifconfig would report that the net devices had [NO FLAGS] like this:

eth1      Link encap:Ethernet  HWaddr 00:0E:35:32:B1:BB
          [NO FLAGS]  MTU:1500  Metric:1
          RX packets:2752 errors:0 dropped:0 overruns:0 frame:0
          TX packets:624 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x4000 Memory:cffff000-cfffffff

But, this condition did not alter the results. Even when the MULTICAST was turned back on with ifconfig eth1 multicast, the results were still the same. So, it can be concluded that the MULTICAST and the BROADCAST capabilities that ifconfig reports means nothing in this case.

Searching the Internet with Google revealed that the first bit of the MAC address indicates whether the MAC address is physical (0) or multicast (1).

This fact does not answer why a wireless Ethernet card's device driver does not drop a frame having a MAC address with an odd first-byte value. It is because to have an odd value, only the last bit of the first byte of the MAC address matters, not the first bit.

I wonder if there is a standard that says that the last bit of the first byte of a MAC address means something.

Archive: Linux Kernel's Networking Part (Ethernet Card)