FW: Curiosity in IPFW/Freebsd bridge. [more] 802.1q VLAN at fault?

[Nickolay A. Kritsky]

Hello Andrew,

Friday, December 17, 2004, 12:47:46 PM, Andrew Seguin wrote:

AS> Looking through the ethereal dumps, I have spotted one difference.

AS> Packets for the console look like this:
AS>   Frame 1 (106 bytes on wire, 106 bytes captured)
AS>   Ethernet II, Src: MAC1, Dst: MAC2
AS>   Internet Protocol, Src Addr: MyPC, Dst Addr: FIREWALL
AS>   SSH Protocol

AS> Packets from the bridge look like this:
AS>   Frame 1 (64 bytes on wire, 64 bytes captured)
AS>   Ethernet II, Src: MAC1, Dst: MAC2
AS>   802.1q Virtual LAN
AS>   Internet Protocol, Src Addr: x, Dst Addr: y
AS>   Transmission Control Protocol, ...


AS> So it would seem that the part "802.1q Virtual LAN" in the protocol is
AS> stopping IPFW from investigating the traffic? (At times like this I wish I
AS> would have not studied computer engineering but networking for 4 years!).

AS> Question then:
AS>   What in IPFW is stopping it from reading into a VLAN tagged packet (if it
AS> is such that it can be called).

I cannot say for sure, because I do not have any 5.x filtering bridge
right now. But after reading some sources I think I understand what is
happening:

bdg_forward in bridge.c is calling ipfw or another packet filter:
        /*
         * NetBSD-style generic packet filter, pfil(9), hooks.
         * Enables ipf(8) in bridging.
         */
        if (!IPFW_LOADED) { /* XXX: Prevent ipfw from being run twice. */
        if (inet_pfil_hook.ph_busy_count >= 0 &&
            m0->m_pkthdr.len >= sizeof(struct ip) &&
            ntohs(save_eh.ether_type) == ETHERTYPE_IP) {

Note the last line: for VLAN tagged packet the field
save_eh.ether_type would be ETHERTYPE_VLAN instead of ETHERTYPE_IP and
no filtering will take place. That is what I think is going on. Who is
the current maintainer of bridge code in FreeBSD?

-- 
Best regards,
;  Nickolay A. Kritsky
; SysAdmin STAR Software LLC
; mailto:nkritsky at star-sw.com