Re: 5.4 -- bridging, ipfw, dot1q

2005-08-14 Thread Julian Elischer
Dan Mahoney, System Admin wrote: should be in -net not -hackers cc's changed accordingly.. After all, the demuxing is nothing more than ignoring a few extra bits at the beginning of the packet. Which all my BPF stuff is doing nicely. Snort, trafshow, etc all work fine and don't seem to

Re: 5.4 -- bridging, ipfw, dot1q

2005-08-13 Thread Dan Mahoney, System Admin
On Fri, 12 Aug 2005, Luigi Rizzo wrote: On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: Hi, I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to

Re: 5.4 -- bridging, ipfw, dot1q

2005-08-12 Thread Luigi Rizzo
I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something like

Re: 5.4 -- bridging, ipfw, dot1q

2005-08-12 Thread Jeremie Le Hen
Hi, I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something

Re: 5.4 -- bridging, ipfw, dot1q

2005-08-12 Thread Luigi Rizzo
On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: Hi, I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most