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:[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
