ebtables-devel — Development questions, bugs, patches

[Ebtables-devel] Ebtables port mirroring?

[Stephen H. <she...@os...>]

Has any one done a mirror target for ebtables? It would be a nice
clean way to do port mirroring in Intrusion Detection Systems.
I know about the mirror target in iptables (and some of it's problems),
but it might be possible to have a mirror to a device in a relatively
safe manner.

-- 
Stephen Hemminger <she...@os...>
"And in the Packet there writ down that doome"

Re: [Ebtables-devel] ebtables -X does not delete all unused chains

[Bart De S. <bds...@pa...>]

Op ma, 31-07-2006 te 10:03 -0600, schreef Alberto Trevi=C3=B1o:
> Needless to say I am playing with ebtables and I am finding a few bugs.=
 =20
> I don't know if the developers will be happy or if they will get tired=20
> of all my bug reports. :-)  I'm not trying to make the developer's life=
=20
> difficult.  I promise.

The period before I release the stable version is the ideal time to find
and report bugs. Thanks, I appreciate it.

> I am running 2.0.8-rc2 + segfault patch.  I am writing a script to=20
> program my bridge rules.  At the beginning of the script I have the=20
> following commands:
>=20
>     ebtables -F
>     ebtables -X
>=20
> In theory, ebtables should flush all the chains in the default table an=
d=20
> remove all unused user-defined chains.  I found the -X command,=20
> however, is not deleting all the user-defined chains.  It only deletes=20
> the odd-numbered ones (as given in the list) and the even ones remain=20
> intact.  Here is the example, starting from scratch:

The attached patch should fix it. Apply in the same way as before (on
top of the previous patch).

cheers,
Bart

[Ebtables-devel] ebtables -X does not delete all unused chains

[Alberto <al...@by...>]

Needless to say I am playing with ebtables and I am finding a few bugs. =20
I don't know if the developers will be happy or if they will get tired=20
of all my bug reports. :-)  I'm not trying to make the developer's life=20
difficult.  I promise.

I am running 2.0.8-rc2 + segfault patch.  I am writing a script to=20
program my bridge rules.  At the beginning of the script I have the=20
following commands:

    ebtables -F
    ebtables -X

In theory, ebtables should flush all the chains in the default table and=20
remove all unused user-defined chains.  I found the -X command,=20
however, is not deleting all the user-defined chains.  It only deletes=20
the odd-numbered ones (as given in the list) and the even ones remain=20
intact.  Here is the example, starting from scratch:

=2D------------------------------------------------
[root@slim-dev ~]# ebtables -N FIRST
[root@slim-dev ~]# ebtables -N SECOND
[root@slim-dev ~]# ebtables -N THIRD
[root@slim-dev ~]# ebtables -N FORTH
[root@slim-dev ~]# ebtables -N FIFTH
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: FIRST, entries: 0, policy: ACCEPT

Bridge chain: SECOND, entries: 0, policy: ACCEPT

Bridge chain: THIRD, entries: 0, policy: ACCEPT

Bridge chain: FORTH, entries: 0, policy: ACCEPT

Bridge chain: FIFTH, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -X
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: SECOND, entries: 0, policy: ACCEPT

Bridge chain: FORTH, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -X
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: FORTH, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -X
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
[root@slim-dev ~]#
=2D------------------------------------------------

This bug is not critical, since ebtables is still useable and I can work=20
around the bug.

Thanks again for your help.

=2D-=20
Alberto Trevi=F1o
al...@by...

Re: [Ebtables-devel] Segfaults when adding rules to custom chains (2.0.8-rc2)

[Bart De S. <bds...@pa...>]

Op wo, 26-07-2006 te 09:21 -0600, schreef Alberto Trevi=C3=B1o:
> I am experiencing segfaults when trying to add rules to user-defined=20
> chains in ebtables v2.0.8-rc2.  I saw some similar problems were fixed=20
> between rc1 and rc2, but apparently some still exist.  I provide the=20
> details further down.  I am using a custom-built system based on=20
> DIY-Linux (www.diy-linux.org) using kernel 2.6.17.6, glibc 2.4 and GCC=20
> 4.1.1 (definitely a bleeding-edge build).
>=20
> Here are the details on reproducing the problem.  You create a new=20
> chain, you add a rule to a default chain to jump to the new chain, then=
=20
> you add a rule to the new chain.  Adding a new rule to the new chain=20
> will segfault:

Hi,

Thanks for the report. The attached patch should solve your problem.
How to apply it: go to the source directory of ebtables, execute
'patch -p1 <file>' followed by make and make install (change <file> to
the file name of the saved patch). If you find more problems, don't
hesitate to report them...

cheers,
Bart

[Ebtables-devel] Segfaults while adding rules to user-defined chains

[Al T. <al...@my...>]

Please pardon me if you have received this message before.  This is my 3rd 
attempt to post this message.  I have reason to believe my previous two 
attempts have been unsuccessful.

I am experiencing segfaults when trying to add rules to user-defined chains 
in ebtables v2.0.8-rc2.  I saw some similar problems were fixed between rc1 
and rc2, but apparently some still exist.  I provide the details further 
down.  I am using a custom-built system based on DIY-Linux 
(www.diy-linux.org) using kernel 2.6.17.6, glibc 2.4 and GCC 4.1.1 
(definitely a bleeding-edge build).

Here are the details on reproducing the problem.  You create a new chain, 
you add a rule to a default chain to jump to the new chain, then you add a 
rule to the new chain.  Adding a new rule to the new chain will segfault:

-------------------------------------------------
[root@slim-dev ~]# ebtables --version
ebtables v2.0.8-rc2 (March 2006)
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -N MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -A FORWARD -j MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-j MY-NEW-CHAIN

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -A MY-NEW-CHAIN -j DROP
Segmentation fault
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-j MY-NEW-CHAIN

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]#
-------------------------------------------------

I then tried it in a slightly different manner.  Create the new chain, add 
the rule to the new chain, then add the rule to the default chain.  The 
result is a segfault when trying to add a rule to the default chain 
(skipping the "ebtables -L" for brevity):

-------------------------------------------------
[root@slim-dev ~]# ebtables -N MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -A MY-NEW-CHAIN -j DROP
[root@slim-dev ~]# ebtables -A FORWARD -j MY-NEW-CHAIN
Segmentation fault
[root@slim-dev ~]#
-------------------------------------------------

Thinking my rules might be the problem, I tried one of the examples on the 
website (Associate IP addresses to MAC addresses) with the same results:

-------------------------------------------------
[root@slim-dev ~]# ebtables -N MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A FORWARD -p IPv4 --among-dst 
00:11:22:33:44:55=172.16.1.4,00:11:33:44:22:55=172.16.1.5 -j 
MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A MATCHING-MAC-IP-PAIR -j DROP
Segmentation fault
[root@slim-dev ~]#
-------------------------------------------------

Changing the order did not resolve the issue:

-------------------------------------------------
[root@slim-dev ~]# ebtables -N MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A MATCHING-MAC-IP-PAIR -j DROP
[root@slim-dev ~]# ebtables -A FORWARD -p IPv4 --among-dst 
00:11:22:33:44:55=172.16.1.4,00:11:33:44:22:55=172.16.1.5 -j 
MATCHING-MAC-IP-PAIR
Segmentation fault
[root@slim-dev ~]#
-------------------------------------------------

Any help with this issue would be appreciated.

[Ebtables-devel] Segfaults with user-defined chains

[Alf <al...@my...>]

I am experiencing segfaults when trying to add rules to user-defined chains 
in ebtables v2.0.8-rc2.  I saw some similar problems were fixed between rc1 
and rc2, but apparently some still exist.  I provide the details further 
down.  I am using a custom-built system based on DIY-Linux 
(www.diy-linux.org) using kernel 2.6.17.6, glibc 2.4 and GCC 4.1.1 
(definitely a bleeding-edge build).

Here are the details on reproducing the problem.  You create a new chain, 
you add a rule to a default chain to jump to the new chain, then you add a 
rule to the new chain.  Adding a new rule to the new chain will segfault:

-------------------------------------------------
[root@slim-dev ~]# ebtables --version
ebtables v2.0.8-rc2 (March 2006)
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -N MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -A FORWARD -j MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-j MY-NEW-CHAIN

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -A MY-NEW-CHAIN -j DROP
Segmentation fault
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-j MY-NEW-CHAIN

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]#
-------------------------------------------------

I then tried it in a slightly different manner.  Create the new chain, add 
the rule to the new chain, then add the rule to the default chain.  The 
result is a segfault when trying to add a rule to the default chain 
(skipping the "ebtables -L" for brevity):

-------------------------------------------------
[root@slim-dev ~]# ebtables -N MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -A MY-NEW-CHAIN -j DROP
[root@slim-dev ~]# ebtables -A FORWARD -j MY-NEW-CHAIN
Segmentation fault
[root@slim-dev ~]#
-------------------------------------------------

Thinking my rules might be the problem, I tried one of the examples on the 
website (Associate IP addresses to MAC addresses) with the same results:

-------------------------------------------------
[root@slim-dev ~]# ebtables -N MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A FORWARD -p IPv4 --among-dst 
00:11:22:33:44:55=172.16.1.4,00:11:33:44:22:55=172.16.1.5 -j 
MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A MATCHING-MAC-IP-PAIR -j DROP
Segmentation fault
[root@slim-dev ~]#
-------------------------------------------------

Changing the order did not resolve the issue:

-------------------------------------------------
[root@slim-dev ~]# ebtables -N MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A MATCHING-MAC-IP-PAIR -j DROP
[root@slim-dev ~]# ebtables -A FORWARD -p IPv4 --among-dst 
00:11:22:33:44:55=172.16.1.4,00:11:33:44:22:55=172.16.1.5 -j 
MATCHING-MAC-IP-PAIR
Segmentation fault
[root@slim-dev ~]#
-------------------------------------------------

Any help with this issue would be appreciated.

-- 
Alf
@

[Ebtables-devel] Segfaults when adding rules to custom chains (2.0.8-rc2)

[Alberto <al...@by...>]

I am experiencing segfaults when trying to add rules to user-defined=20
chains in ebtables v2.0.8-rc2.  I saw some similar problems were fixed=20
between rc1 and rc2, but apparently some still exist.  I provide the=20
details further down.  I am using a custom-built system based on=20
DIY-Linux (www.diy-linux.org) using kernel 2.6.17.6, glibc 2.4 and GCC=20
4.1.1 (definitely a bleeding-edge build).

Here are the details on reproducing the problem.  You create a new=20
chain, you add a rule to a default chain to jump to the new chain, then=20
you add a rule to the new chain.  Adding a new rule to the new chain=20
will segfault:

=2D------------------------------------------------
[root@slim-dev ~]# ebtables --version
ebtables v2.0.8-rc2 (March 2006)
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -N MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -A FORWARD -j MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
=2Dj MY-NEW-CHAIN

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]# ebtables -A MY-NEW-CHAIN -j DROP
Segmentation fault
[root@slim-dev ~]# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
=2Dj MY-NEW-CHAIN

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: MY-NEW-CHAIN, entries: 0, policy: ACCEPT
[root@slim-dev ~]#
=2D------------------------------------------------

I then tried it in a slightly different manner.  Create the new chain,=20
add the rule to the new chain, then add the rule to the default chain. =20
The result is a segfault when trying to add a rule to the default chain=20
(skipping the "ebtables -L" for brevity):

=2D------------------------------------------------
[root@slim-dev ~]# ebtables -N MY-NEW-CHAIN
[root@slim-dev ~]# ebtables -A MY-NEW-CHAIN -j DROP
[root@slim-dev ~]# ebtables -A FORWARD -j MY-NEW-CHAIN
Segmentation fault
[root@slim-dev ~]#
=2D------------------------------------------------

Thinking my rules might be the problem, I tried one of the examples on=20
the website (Associate IP addresses to MAC addresses) with the same=20
results:

=2D------------------------------------------------
[root@slim-dev ~]# ebtables -N MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A FORWARD -p IPv4 --among-dst=20
00:11:22:33:44:55=3D172.16.1.4,00:11:33:44:22:55=3D172.16.1.5 -j=20
MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A MATCHING-MAC-IP-PAIR -j DROP
Segmentation fault
[root@slim-dev ~]#
=2D------------------------------------------------

Changing the order did not resolve the issue:

=2D------------------------------------------------
[root@slim-dev ~]# ebtables -N MATCHING-MAC-IP-PAIR
[root@slim-dev ~]# ebtables -A MATCHING-MAC-IP-PAIR -j DROP
[root@slim-dev ~]# ebtables -A FORWARD -p IPv4 --among-dst=20
00:11:22:33:44:55=3D172.16.1.4,00:11:33:44:22:55=3D172.16.1.5 -j=20
MATCHING-MAC-IP-PAIR
Segmentation fault
[root@slim-dev ~]#
=2D------------------------------------------------

Any help with this issue would be appreciated.

=2D-=20
Alberto Trevi=F1o
al...@by...

Re: [Ebtables-devel] =?utf-8?q?custom_target=3A_vlan=5Ft_extension_pr?= =?utf-8?q?oblem=2E?=

[simon P. <sim...@gm...>]

Dawid Ciężarkiewicz <dpc@...> writes:

> 
> Hi,
>  I'm trying to develop ebt-vlan_t extension for ebtables. It should change 
> vlan ID of ethernet frame. Having most of work already done I'm experiencing 
> problems with changing frame type from non-vlan to vlan.
> 
> I derived my work from ebt-mark so I just paste target function which 
> essential here:
> 

Hi, 

This is an interesting problem trying to change vlan tags if packets are already
in the kernel. I see a lot of interesting stuff you can do with this.

I try to get the patch working. I backported it to a 2.4.20 kernel, I get it
compiled and running.

To get it working, I was wondering to which table and chain you need to add this
rules.

I want to mark packets matching a certain mac address, with a certain vlan tag.

ebtables -t nat -A PREROUTING -s 0:d2:b3:51:37:d9 -j vlan_t --vlan-set 0x64
--vlan-target CONTINUE

then I create a vlan interface with vlantag 0x64(100) and I expected to see some
packets coming in but none did.

Is this the correct way to use it?

thanks 

Simon

Re: [Ebtables-devel] custom target: vlan_t extension problem.

[Dawid C. <dp...@as...>]

On Friday, 7 July 2006 12:58, bds...@pa... wrote:
> The code doesn't look bad. Apart from the below line you forgot to paste 
from
> __vlan_put_tag() I don't directly see a problem.
> skb->protocol = __constant_htons(ETH_P_8021Q);
> What isn't happening as expected?

After long fight I have managed to get this piece of code to work. :)

The problem was that __vlan_put_tag() is expecting skb->data pointer to point 
in other place then it is in ebtables. As for me - whole __vlan_put_tag() is 
broken or I just don't get it.

Because of very low traffic on this list I've decided to post my work on 
netdev mailing list. I thought that if ebtables is now part of 2.6 kernel it 
may be more appropriate place to ask - especially when I've got working 
target.

http://marc.theaimsgroup.com/?l=linux-netdev&m=115212914212035&w=2

^^^ Here you can see my working (but now well tested yet) ebt_vlan_t target. 
Some people already helped me improve it - i fixed unportable types (unsigned 
short), droped info->target, replaced "two bytes" with "four bytes" etc., but 
nobody has commented whole functionality yet.



As you can see I almost rewritten __vlan_put_tag(). My objections are placed 
inside comments.

What I'd like to point out is - (use this link to kernel source):
http://lxr.xensource.com/lxr/source/linux-2.6.16-xen/include/linux/if_vlan.h#L221

Line 241:
veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN);

is IMHO plain wrong. skb_push() returns sbk->data pointer, while `struct 
vlan_ethhdr *' should be made from mac.raw pointer IMO. 

Line 254:
skb->nh.raw -= VLAN_HLEN;

Is wrong too - this header hasn't moved - we moved mac header four bytes left, 
so ip headers are still in good place.

But as you can see I'm very novice and little to ashamed to point out bugs in 
real, working kernel code. It'd be good if somebody could review my opinions.

Regards,

Re: [Ebtables-devel] custom target: vlan_t extension problem.

[<bds...@pa...>]

>----- Oorspronkelijk bericht -----
>Van: Dawid Ci??arkiewicz [mailto:dp...@as...]
>Verzonden: dinsdag, juli 4, 2006 01:36 PM
>Aan: ebt...@li...
>Onderwerp: [Ebtables-devel] custom target: vlan_t extension problem.
>
>Hi,
> I'm trying to develop ebt-vlan_t extension for ebtables. It should change 
>vlan ID of ethernet frame. Having most of work already done I'm experiencing 
>problems with changing frame type from non-vlan to vlan.
>
>While the second part (when (*pskb)->protocol == 
>__constant_htons(ETH_P_8021Q)) works perfectly fine and frame VID is changed, 
>the first one is now mix of my tries not to hang kernel.
>
>At the beginning I was going to use  vlan_put_tag(*pskb, info->id); or 
>__vlan_put_tag(*pskb, info->id);
>, but they hang. So I tried many combinations of hand made and 
>found&look-promising code in kernel source.
>
>I'm probably not aware of many facts, because I'm totally kernel newbie. What 
>I'd like to ask especially is:
>- can ebt target modify pskb or substitute it with another one (struct sk_buff 
>**pskb is used for that, I suppose); are there any additional conditions 
>(chains, tables etc.)?

Yes, you can do that. No additional conditions...

>- are there any other limitations for ebt target (locks, interupts ...)?

Nope.

>Of course if anybody can point me anything interesting, like comments and 
>advices (especially about pasted piece of code) I'd be most thankful. I'm not 
>afraid of reading code so please point me function&file if you think I should 
>read it more carefully.

The code doesn't look bad. Apart from the below line you forgot to paste from
__vlan_put_tag() I don't directly see a problem.
skb->protocol = __constant_htons(ETH_P_8021Q);
What isn't happening as expected?

cheers,
Bart

Re: [Ebtables-devel] PPPoE ip extraction

[<bds...@pa...>]

>----- Oorspronkelijk bericht -----
>Van: Marek Jawurek [mailto:Mar...@gm...]
>Verzonden: donderdag, juli 6, 2006 01:12 PM
>Aan: bds...@pa...
>CC: ebt...@li...
>Onderwerp: Re: [Ebtables-devel] PPPoE ip extraction
>
>Thx Bart, i figured it out yesterday the other way around.
>I moved the rest of the packet down in order to overwrite the ppp
>header.
>
>This is what I intended to write:
>
>The skb->data pointer just points to the start of the current protocol
>header. This is the first Layer encapsulated in the Ethernet packet for
>the ebtables code. As changing the data pointer apparantly does not help
>I just overwrote the pppoe+ppp header and copied the IP Proto field into
>the Ethernet header:
>
>memcpy(eth_hdr(*pskb)->h_dest, in->dev_addr, ETH_ALEN);
>eth_hdr(*pskb)->h_proto=htons(ETH_P_IP);
>memcpy((*pskb)->data,(*pskb)->datasizeof(pppoe),(*pskb)->end-(*pskb)->data);

I think the best thing you can do is to skb_pull the data and then copy the
Ethernet header. You must make sure that the packet length is decreased by the 
size of the ppp header.

>Ok this seems to work. In general, I see that I lack a great deal of
>kernel-programming-experience ;-)
>
>One question though, I manage to extract the IP packet but apparently it
>then (after the REDIRECT in ebtables) the INPUT table of the netfilter ?

?

>Would it be possible to direct it to the PREROUTING where I could use
>the iptables REDIRECT to a local port ? 

I don't know where you are doing this modification. But it's very likely you
need to change skb->protocol to htons(ETH_P_IP).

cheers,
Bart

Re: [Ebtables-devel] PPPoE ip extraction

[Marek J. <Mar...@gm...>]

Thx Bart, i figured it out yesterday the other way around.
I moved the rest of the packet down in order to overwrite the ppp
header.

This is what I intended to write:

The skb->data pointer just points to the start of the current protocol
header. This is the first Layer encapsulated in the Ethernet packet for
the ebtables code. As changing the data pointer apparantly does not help
I just overwrote the pppoe+ppp header and copied the IP Proto field into
the Ethernet header:

memcpy(eth_hdr(*pskb)->h_dest, in->dev_addr, ETH_ALEN);
eth_hdr(*pskb)->h_proto=htons(ETH_P_IP);
memcpy((*pskb)->data,(*pskb)->datasizeof(pppoe),(*pskb)->end-(*pskb)->data);

Ok this seems to work. In general, I see that I lack a great deal of
kernel-programming-experience ;-)

One question though, I manage to extract the IP packet but apparently it
then (after the REDIRECT in ebtables) the INPUT table of the netfilter ?

Would it be possible to direct it to the PREROUTING where I could use
the iptables REDIRECT to a local port ? 

Marek





Am Donnerstag, den 06.07.2006, 11:03 +0000 schrieb bds...@pa...:
> >----- Oorspronkelijk bericht -----
> >Van: Marek Jawurek [mailto:Mar...@gm...]
> >Verzonden: dinsdag, juli 4, 2006 07:22 PM
> >Aan: ebt...@li...
> >Onderwerp: [Ebtables-devel] PPPoE ip extraction
> 
> >It's me again,
> >now I have more time to deal with the described problem and I have been
> >successfull as far as I can see. I'll submit a patch when the code is of
> >better quality. But on my way I figured that the match code is not the
> >only thing I need to change. I want to extract IP packets from a PPPoE
> >stream that goes through my bridge. Therefore I want to write a target
> >similar to the redirect target but which additionally extracts the IP
> >from the PPP. For starters I copied the ebt_redirect.c code and tried to
> >strip the PPPoe+PPP header off using skb_pull() and changing the
> >skb_buff -ethernet proto to IP. But I ran into 2 problems:
> >
> >1. in ebt_redirect.c/ebt_extract.c in ebt_target_extract there is a
> >check whether the supplied skbuffer is a cloned/shared one, if it is it
> >is copied and further operations are applied to the copy. When can this
> >happen ? Is there a schematic how all packets traverse the differnt
> >functions of the ebtables/kernel socket code ? 
> 
> Packets can be shared as long as they are not altered. If you want to alter a shared packet, you must instead make a private copy of it first and then continue. That's because the other code that is sharing it, isn't expecting it to change. When you run tcpdump f.e., it will share the packet. Usually, you won't be sharing it with anything though. I don't think this has anything to do with your problem.
> 
> >The next problem might be connected to this one, If the packet I work on
> >is a copy then it could explain the strane behaviour:
> >
> >2. Although I managed to change the ethernet proto to IP and although
> >the call to skb_pull is successfull (the debug output tells me that the
> >data pointer in the skbuffer has been raised by sizeof(PPPoe+PPP header)
> >[8byte] apparantly the skb is passed to the local machiene as it was
> >before except for the changed ethernet proto field. 
> 
> If I understand you correctly, you want to send out a packet with an Ethernet header followed by the IP stuff (dropping the ppp header). Then you'll need to copy the Ethernet header so that it is situated right before the IP header (overwriting the ppp header), and you'll need to update the skb->mac.raw pointer.
> 
> cheers,
> Bart
> 
> 
> 
-- 
Marek Jawurek <Mar...@gm...>

Re: [Ebtables-devel] PPPoE ip extraction

[<bds...@pa...>]

>----- Oorspronkelijk bericht -----
>Van: Marek Jawurek [mailto:Mar...@gm...]
>Verzonden: dinsdag, juli 4, 2006 07:22 PM
>Aan: ebt...@li...
>Onderwerp: [Ebtables-devel] PPPoE ip extraction

>It's me again,
>now I have more time to deal with the described problem and I have been
>successfull as far as I can see. I'll submit a patch when the code is of=

>better quality. But on my way I figured that the match code is not the
>only thing I need to change. I want to extract IP packets from a PPPoE
>stream that goes through my bridge. Therefore I want to write a target
>similar to the redirect target but which additionally extracts the IP
>from the PPP. For starters I copied the ebt_redirect.c code and tried to=

>strip the PPPoe+PPP header off using skb_pull() and changing the
>skb_buff -ethernet proto to IP. But I ran into 2 problems:
>
>1. in ebt_redirect.c/ebt_extract.c in ebt_target_extract there is a
>check whether the supplied skbuffer is a cloned/shared one, if it is it
>is copied and further operations are applied to the copy. When can this
>happen ? Is there a schematic how all packets traverse the differnt
>functions of the ebtables/kernel socket code ? 

Packets can be shared as long as they are not altered. If you want to alt=
er a shared packet, you must instead make a private copy of it first and =
then continue. That's because the other code that is sharing it, isn't ex=
pecting it to change. When you run tcpdump f.e., it will share the packet=
. Usually, you won't be sharing it with anything though. I don't think th=
is has anything to do with your problem.

>The next problem might be connected to this one, If the packet I work on=

>is a copy then it could explain the strane behaviour:
>
>2. Although I managed to change the ethernet proto to IP and although
>the call to skb_pull is successfull (the debug output tells me that the
>data pointer in the skbuffer has been raised by sizeof(PPPoe+PPP header)=

>[8byte] apparantly the skb is passed to the local machiene as it was
>before except for the changed ethernet proto field. 

If I understand you correctly, you want to send out a packet with an Ethe=
rnet header followed by the IP stuff (dropping the ppp header). Then you'=
ll need to copy the Ethernet header so that it is situated right before t=
he IP header (overwriting the ppp header), and you'll need to update the =
skb->mac.raw pointer.

cheers,
Bart

[Ebtables-devel] PPPoe IP extraction

[Marek J. <ma...@is...>]

Sorry it should have been sent to the ml. And with my other email
address.


Am Dienstag, den 20.06.2006, 10:47 +0000 schrieb bds...@pa...:
> >----- Oorspronkelijk bericht -----
> >Van: Marek Jawurek [mailto:ma...@is...]
> >Verzonden: maandag, juni 19, 2006 11:52 PM
> >Aan: ebt...@li...
> >Onderwerp: [Ebtables-devel] IP over PPPoe:PPP extraction
> >
> >Hi there,
> >
> >I found a post of this mailinglist here:
>
>http://article.gmane.org/gmane.linux.network.bridge.ebtables.devel/413/=
match=3Dppp
> >
> >It appears that this patch has never made it into the code. I am very
> >interested in this functionality and would be willing to code if
> >provided with some ideas/hints. (I am know kernel insider -- yet ;-)
but
> >I think using the tutorial online it can't be so difficult).
> >
> >First, here is what I need: A way to extract and redirect certain IP
> >packets (depending on the IP header) from an Ethernet:PPPoe:PPP:
stream.
> >
> >>From Barts answer I deduct that a general solution would be better
than
> >to add this PPPoE/PPP extraction to every embeddeble protocol and
every
> >embedding protocol. I had a look through the tutorial and the
sourcecode
> >but from what I gathered the functionalities of different filters are
> >not easily combinable ? If I understand the approach that Thomas
> >ESTASECCA wanted to patch-in: apply the PPPoe:PPP extraction first
and
> >then test for the usual IP header/fields against the rule spec. 
> 
> That's not really what I meant. It's just that the same functionality
can be obtained without having to add new flags to ebtables' kernel
space ip match struct.
> This is how:
> The ebt_filter_ip() function doesn't check the MAC protocol type
because that's  done elsewhere. This allows us to add the functionality
without having to use new flags (in kernel space).
> 
> What we could do is add the userspace --embedded-proto flag.
> Valid rules:
> ebtables -p IPv4 --ip-proto x -j ACCEPT
> ebtables -p PPoE --embedded-proto --ip-proto x -j ACCEPT
> invalid rule (providing backwards compatibility):
> ebtables -p PPoE --ip-proto x -j ACCEPT
> 
> This can then be translated to kernel space, without having a new flag
(the --embedded-proto flag is only necessary in userspace).
> Of course, ebtables' kernel ip match function will need to be altered
in a similar way as Estasecca did.
> If the rule
> ebtables -p PPoE --embedded-proto --ip-proto x -j ACCEPT
> is given to a kernel that doesn't have this functionality, the kernel
(i.e. the check function of the ebtables ip match module) will not
accept it, so there's no danger there either.
> 
> cheers,
> Bart

It's me again,
now I have more time to deal with the described problem and I have been
successfull as far as I can see. I'll submit a patch when the code is of
better quality. But on my way I figured that the match code is not the
only thing I need to change. I want to extract IP packets from a PPPoE
stream that goes through my bridge. Therefore I want to write a target
similar to the redirect target but which additionally extracts the IP
from the PPP. For starters I copied the ebt_redirect.c code and tried to
strip the PPPoe+PPP header off using skb_pull() and changing the
skb_buff -ethernet proto to IP. But I ran into 2 problems:

1. in ebt_redirect.c/ebt_extract.c in ebt_target_extract there is a
check whether the supplied skbuffer is a cloned/shared one, if it is it
is copied and further operations are applied to the copy. When can this
happen ? Is there a schematic how all packets traverse the differnt
functions of the ebtables/kernel socket code ? 

The next problem might be connected to this one, If the packet I work on
is a copy then it could explain the strane behaviour:

2. Although I managed to change the ethernet proto to IP and although
the call to skb_pull is successfull (the debug output tells me that the
data pointer in the skbuffer has been raised by sizeof(PPPoe+PPP header)
[8byte] apparantly the skb is passed to the local machiene as it was
before except for the changed ethernet proto field. 
Here is my code of ebt_extract.c:


struct pppoehdr {
  char pppoe[6];
  uint16_t ppp_protocol;
};

static int ebt_target_extract(struct sk_buff **pskb, unsigned int
hooknr,
   const struct net_device *in, const struct net_device *out,
   const void *data, unsigned int datalen)
{
  struct ebt_extract_info *info =3D (struct ebt_extract_info *)data;
  struct pppoehdr pppoe;

/* Struggle with this later
  if (skb_shared(*pskb) || skb_cloned(*pskb)) {
    struct sk_buff *nskb;
    printk("\nit is copied");
    nskb =3D skb_copy(*pskb, GFP_ATOMIC);
    if (!nskb)
      return NF_DROP;
    if ((*pskb)->sk)
      skb_set_owner_w(nskb, (*pskb)->sk);
    kfree_skb(*pskb);
    *pskb =3D nskb;
  }*/
  if (hooknr !=3D NF_BR_BROUTING)
  {
    printk("\n hook : %i",hooknr);
    memcpy(eth_hdr(*pskb)->h_dest,
           in->br_port->br->dev->dev_addr, ETH_ALEN);
  }
  else
  {
    printk("\n second ");
    memcpy(eth_hdr(*pskb)->h_dest, in->dev_addr, ETH_ALEN);
    eth_hdr(*pskb)->h_proto=3Dhtons(ETH_P_IP);
    printk("\n before%p",(*pskb)->data);
    printk("\n size %i",sizeof(pppoe));
    printk("\npull error %p",skb_pull_rcsum(*pskb,sizeof(pppoe)));
    printk("\n after %p",(*pskb)->data);
  }
  (*pskb)->pkt_type =3D PACKET_HOST;
  return info->target;


What am I missing here ? This is the first time I am messing with the
kernel and I am no C professional but I read different skb related pages
and looked into the skbuff.c sourcecode. I just don't get it.

Any hint/url/comment is appreciated.

Marek
PS: Dawid, good luck with your coding ;-)


-- 
Mit freundlichen Gr=C3=BC=C3=9Fen

Marek Jawurek
Informatiksysteme Aachen GmbH
http://www.is-ac.de

[Ebtables-devel] PPPoE ip extraction

[Marek J. <Mar...@gm...>]

Sorry it should have been sent to the ml.


Am Dienstag, den 20.06.2006, 10:47 +0000 schrieb bds...@pa...:
> >----- Oorspronkelijk bericht -----
> >Van: Marek Jawurek [mailto:ma...@is...]
> >Verzonden: maandag, juni 19, 2006 11:52 PM
> >Aan: ebt...@li...
> >Onderwerp: [Ebtables-devel] IP over PPPoe:PPP extraction
> >
> >Hi there,
> >
> >I found a post of this mailinglist here:
>
>http://article.gmane.org/gmane.linux.network.bridge.ebtables.devel/413/match=ppp
> >
> >It appears that this patch has never made it into the code. I am very
> >interested in this functionality and would be willing to code if
> >provided with some ideas/hints. (I am know kernel insider -- yet ;-)
but
> >I think using the tutorial online it can't be so difficult).
> >
> >First, here is what I need: A way to extract and redirect certain IP
> >packets (depending on the IP header) from an Ethernet:PPPoe:PPP:
stream.
> >
> >>From Barts answer I deduct that a general solution would be better
than
> >to add this PPPoE/PPP extraction to every embeddeble protocol and
every
> >embedding protocol. I had a look through the tutorial and the
sourcecode
> >but from what I gathered the functionalities of different filters are
> >not easily combinable ? If I understand the approach that Thomas
> >ESTASECCA wanted to patch-in: apply the PPPoe:PPP extraction first
and
> >then test for the usual IP header/fields against the rule spec. 
> 
> That's not really what I meant. It's just that the same functionality
can be obtained without having to add new flags to ebtables' kernel
space ip match struct.
> This is how:
> The ebt_filter_ip() function doesn't check the MAC protocol type
because that's  done elsewhere. This allows us to add the functionality
without having to use new flags (in kernel space).
> 
> What we could do is add the userspace --embedded-proto flag.
> Valid rules:
> ebtables -p IPv4 --ip-proto x -j ACCEPT
> ebtables -p PPoE --embedded-proto --ip-proto x -j ACCEPT
> invalid rule (providing backwards compatibility):
> ebtables -p PPoE --ip-proto x -j ACCEPT
> 
> This can then be translated to kernel space, without having a new flag
(the --embedded-proto flag is only necessary in userspace).
> Of course, ebtables' kernel ip match function will need to be altered
in a similar way as Estasecca did.
> If the rule
> ebtables -p PPoE --embedded-proto --ip-proto x -j ACCEPT
> is given to a kernel that doesn't have this functionality, the kernel
(i.e. the check function of the ebtables ip match module) will not
accept it, so there's no danger there either.
> 
> cheers,
> Bart

It's me again,
now I have more time to deal with the described problem and I have been
successfull as far as I can see. I'll submit a patch when the code is of
better quality. But on my way I figured that the match code is not the
only thing I need to change. I want to extract IP packets from a PPPoE
stream that goes through my bridge. Therefore I want to write a target
similar to the redirect target but which additionally extracts the IP
from the PPP. For starters I copied the ebt_redirect.c code and tried to
strip the PPPoe+PPP header off using skb_pull() and changing the
skb_buff -ethernet proto to IP. But I ran into 2 problems:

1. in ebt_redirect.c/ebt_extract.c in ebt_target_extract there is a
check whether the supplied skbuffer is a cloned/shared one, if it is it
is copied and further operations are applied to the copy. When can this
happen ? Is there a schematic how all packets traverse the differnt
functions of the ebtables/kernel socket code ? 

The next problem might be connected to this one, If the packet I work on
is a copy then it could explain the strane behaviour:

2. Although I managed to change the ethernet proto to IP and although
the call to skb_pull is successfull (the debug output tells me that the
data pointer in the skbuffer has been raised by sizeof(PPPoe+PPP header)
[8byte] apparantly the skb is passed to the local machiene as it was
before except for the changed ethernet proto field. 
Here is my code of ebt_extract.c:


struct pppoehdr {
  char pppoe[6];
  uint16_t ppp_protocol;
};

static int ebt_target_extract(struct sk_buff **pskb, unsigned int
hooknr,
   const struct net_device *in, const struct net_device *out,
   const void *data, unsigned int datalen)
{
  struct ebt_extract_info *info = (struct ebt_extract_info *)data;
  struct pppoehdr pppoe;

/* Struggle with this later
  if (skb_shared(*pskb) || skb_cloned(*pskb)) {
    struct sk_buff *nskb;
    printk("\nit is copied");
    nskb = skb_copy(*pskb, GFP_ATOMIC);
    if (!nskb)
      return NF_DROP;
    if ((*pskb)->sk)
      skb_set_owner_w(nskb, (*pskb)->sk);
    kfree_skb(*pskb);
    *pskb = nskb;
  }*/
  if (hooknr != NF_BR_BROUTING)
  {
    printk("\n hook : %i",hooknr);
    memcpy(eth_hdr(*pskb)->h_dest,
           in->br_port->br->dev->dev_addr, ETH_ALEN);
  }
  else
  {
    printk("\n second ");
    memcpy(eth_hdr(*pskb)->h_dest, in->dev_addr, ETH_ALEN);
    eth_hdr(*pskb)->h_proto=htons(ETH_P_IP);
    printk("\n before%p",(*pskb)->data);
    printk("\n size %i",sizeof(pppoe));
    printk("\npull error %p",skb_pull_rcsum(*pskb,sizeof(pppoe)));
    printk("\n after %p",(*pskb)->data);
  }
  (*pskb)->pkt_type = PACKET_HOST;
  return info->target;


What am I missing here ? This is the first time I am messing with the
kernel and I am no C professional but I read different skb related pages
and looked into the skbuff.c sourcecode. I just don't get it.

Any hint/url/comment is appreciated.

Marek
PS: Dawid, good luck with your coding ;-)





-- 
Marek Jawurek <Mar...@gm...>

[Ebtables-devel] custom target: vlan_t extension problem.

[Dawid <dp...@as...>]

Hi,
 I'm trying to develop ebt-vlan_t extension for ebtables. It should change 
vlan ID of ethernet frame. Having most of work already done I'm experiencing 
problems with changing frame type from non-vlan to vlan.

I derived my work from ebt-mark so I just paste target function which 
essential here:

-- BEGIN --
static int ebt_target_vlan(struct sk_buff **pskb, unsigned int hooknr,
   const struct net_device *in, const struct net_device *out,
   const void *data, unsigned int datalen)
{
    struct ebt_vlan_t_info *info = (struct ebt_vlan_t_info *)data;
    struct vlan_hdr* vh, frame;
    unsigned short vlan_TCI;
    struct sk_buff *nskb;
    struct sk_buff *skb;
    struct vlan_ethhdr * veth;

    if ((*pskb)->protocol != __constant_htons(ETH_P_8021Q)) {
        printk("no vlan pskb - changing...\n");

        /* TODO: is this part needed? */
        /* TRY2 - BEGIN */
         if (skb_shared(*pskb) || skb_cloned(*pskb)) {
            printk("skb_shared(*pskb) || skb_cloned(*pskb)\n");

            nskb = skb_copy(*pskb, GFP_ATOMIC);
            if (!nskb)
                return EBT_DROP;
            if ((*pskb)->sk)
                skb_set_owner_w(nskb, (*pskb)->sk);
            kfree_skb(*pskb);
            *pskb = nskb;
         }

        if (skb_headroom(*pskb) < VLAN_HLEN) {
            printk("skb_headroom(*pskb) < VLAN_HLEN\n");
            nskb = *pskb;
            *pskb = skb_realloc_headroom(nskb, VLAN_HLEN);
            if (*pskb == NULL) {
                *pskb = nskb;
                printk(KERN_ERR "vlan: failed to realloc headroom\n");
                return EBT_DROP;
            }
            kfree_skb(nskb);
        }
        
        /* this mechanism is taken c&p from __vlan_put_tag() */
        veth = vlan_eth_hdr(skb_push(skb, VLAN_HLEN));

        /* Move the mac addresses to the beginning of the new header. */
        memmove(veth, veth + VLAN_HLEN, 2 * VLAN_ETH_ALEN);

        /* first, the ethernet type */
        veth->h_vlan_proto = __constant_htons(ETH_P_8021Q);

        /* now, the tag */
        veth->h_vlan_TCI = htons(info->id);

        veth->h_vlan_proto= __constant_htons(ETH_P_8021Q);
        skb->mac.raw -= VLAN_HLEN;
        skb->nh.raw -= VLAN_HLEN;
        
        /* TRY1 - BEGIN */
        /*
        nskb = __vlan_put_tag(*pskb, info->id);
        if (nskb == NULL) {
            printk("failed - dropping...\n");
            return EBT_DROP;
        } 
        *pskb = nskb;
        */

    } else {
        vh = skb_header_pointer(*pskb, 0, sizeof(frame), &frame);

        //printk("vlan_t - old TCI : %hx\n", vh->h_vlan_TCI);
        vlan_TCI = ntohs (vh->h_vlan_TCI) & ~VLAN_VID_MASK;

        //printk("vlan_t - applying id : %hx\n", info->id);
        //printk("vlan_t - new TCI: %hx\n", vlan_TCI | info->id);
        vh->h_vlan_TCI = htons(vlan_TCI | info->id);
    }
    return info->target;
}
--- END ---

While the second part (when (*pskb)->protocol == 
__constant_htons(ETH_P_8021Q)) works perfectly fine and frame VID is changed, 
the first one is now mix of my tries not to hang kernel.

At the beginning I was going to use  vlan_put_tag(*pskb, info->id); or 
__vlan_put_tag(*pskb, info->id);
, but they hang. So I tried many combinations of hand made and 
found&look-promising code in kernel source.

I'm probably not aware of many facts, because I'm totally kernel newbie. What 
I'd like to ask especially is:
- can ebt target modify pskb or substitute it with another one (struct sk_buff 
**pskb is used for that, I suppose); are there any additional conditions 
(chains, tables etc.)?
- are there any other limitations for ebt target (locks, interupts ...)?

Of course if anybody can point me anything interesting, like comments and 
advices (especially about pasted piece of code) I'd be most thankful. I'm not 
afraid of reading code so please point me function&file if you think I should 
read it more carefully.

Best Regards,
Dawid

Re: [Ebtables-devel] IP over PPPoe:PPP extraction

[<bds...@pa...>]

>----- Oorspronkelijk bericht -----
>Van: Marek Jawurek [mailto:ma...@is...]
>Verzonden: maandag, juni 19, 2006 11:52 PM
>Aan: ebt...@li...
>Onderwerp: [Ebtables-devel] IP over PPPoe:PPP extraction
>
>Hi there,
>
>I found a post of this mailinglist here:
>http://article.gmane.org/gmane.linux.network.bridge.ebtables.devel/413/match=ppp
>
>It appears that this patch has never made it into the code. I am very
>interested in this functionality and would be willing to code if
>provided with some ideas/hints. (I am know kernel insider -- yet ;-) but
>I think using the tutorial online it can't be so difficult).
>
>First, here is what I need: A way to extract and redirect certain IP
>packets (depending on the IP header) from an Ethernet:PPPoe:PPP: stream.
>
>>From Barts answer I deduct that a general solution would be better than
>to add this PPPoE/PPP extraction to every embeddeble protocol and every
>embedding protocol. I had a look through the tutorial and the sourcecode
>but from what I gathered the functionalities of different filters are
>not easily combinable ? If I understand the approach that Thomas
>ESTASECCA wanted to patch-in: apply the PPPoe:PPP extraction first and
>then test for the usual IP header/fields against the rule spec. 

That's not really what I meant. It's just that the same functionality can be obtained without having to add new flags to ebtables' kernel space ip match struct.
This is how:
The ebt_filter_ip() function doesn't check the MAC protocol type because that's  done elsewhere. This allows us to add the functionality without having to use new flags (in kernel space).

What we could do is add the userspace --embedded-proto flag.
Valid rules:
ebtables -p IPv4 --ip-proto x -j ACCEPT
ebtables -p PPoE --embedded-proto --ip-proto x -j ACCEPT
invalid rule (providing backwards compatibility):
ebtables -p PPoE --ip-proto x -j ACCEPT

This can then be translated to kernel space, without having a new flag (the --embedded-proto flag is only necessary in userspace).
Of course, ebtables' kernel ip match function will need to be altered in a similar way as Estasecca did.
If the rule
ebtables -p PPoE --embedded-proto --ip-proto x -j ACCEPT
is given to a kernel that doesn't have this functionality, the kernel (i.e. the check function of the ebtables ip match module) will not accept it, so there's no danger there either.

cheers,
Bart

[Ebtables-devel] IP over PPPoe:PPP extraction

[Marek J. <ma...@is...>]

Hi there,

I found a post of this mailinglist here:
http://article.gmane.org/gmane.linux.network.bridge.ebtables.devel/413/match=ppp

It appears that this patch has never made it into the code. I am very
interested in this functionality and would be willing to code if
provided with some ideas/hints. (I am know kernel insider -- yet ;-) but
I think using the tutorial online it can't be so difficult).

First, here is what I need: A way to extract and redirect certain IP
packets (depending on the IP header) from an Ethernet:PPPoe:PPP: stream.

>From Barts answer I deduct that a general solution would be better than
to add this PPPoE/PPP extraction to every embeddeble protocol and every
embedding protocol. I had a look through the tutorial and the sourcecode
but from what I gathered the functionalities of different filters are
not easily combinable ? If I understand the approach that Thomas
ESTASECCA wanted to patch-in: apply the PPPoe:PPP extraction first and
then test for the usual IP header/fields against the rule spec. 

The general approach that I thought of would be: Define a Matcher that
identifies PPPoE:PPP combinations, then define a Target or a Table where
the payload(y) of the x:PPPoE:PPP:y packet can be examined further using
existing filters like IP with its existing code. I am sorry if I mix
terms up (like Table and Target) but I am still at the beginning to
understand the code and the inner workings. To my knowledge there are
Targets that manipulate the packets like DNAT,SNAT,... but what would be
needed here is an approach to filter PPPoe:PPP out and then run the
other matchers against the payload.

I would appreciate any help or infos regarding an elegant and general
solution. Please forgive my shallow knowledge of this matter.


Marek Jawurek

Re: [Ebtables-devel] --arpreply-mac AUTO and Mac Masquerading

[<os...@ki...>]

First of all. I wrote the previous mail like 6am without sleeping so the
text was confusing at some points. Can't even understand it completly
myself when I'm reading it ;) sorry about that...

Really short summary, and hopefully more understandable:
The customers could have 1 or more IPs. The customers don't have static
IPs. The customers macaddress could be anything. IP addresses should never
change.

IP1 ---- eth0 - br0 - eth1.101 ---- IP2(customer)
                      eth1.102 ---- IP3,IP4(customer with 2 IPs)

<-IP = iptables mangle, mark with incoming vlannumber, ebtables snat
markvalue with predefined macaddress(one mac for each customer).
->IP = ebtables redirect-target
<-ARPrequest = Bridge need to answer from arpcache if possible.
Otherwise(or always) snat the packet and let it through. ebtables
redirect-target the arpreply and bridge will install in arpcache.
->ARPrequest = Bridge need to answer from cache if possible. Otherwise(or
always) let the packet through. ebtables redirect-target the arpreply and
bridge will install in arpcache.

>
> Sorry, I don't quite see why you need to snat their traffic...
>

Why I would like to snat their traffic is because when you have lots of
customers it's really great if you could easily be sure of who the true
source is. Otherwise it's really timeconsuming to hunt down a single user
that's spamming the network with useless data.
And I also read some other old thread about "Dynamic source MAC-NAT?"
which seems to be the same thing as I'm talking about.

>>
>> So in conclusion, the only thing that needs to be done for this whole
>> thing to work. That's to make the --arpreply-mac AUTO check in the
>> bridge
>> fdb for an entry. Read about some timer issues in the old thread. But is
>> that really necessary. Doesn't the bridge fdb take care of all that?
>
> I was probably thinking that the arp entries would be cached by the
> arpreply target. That way you don't need the arp code. But you can add a
> new entry into the arp cache without having to actually redirect the
> packet (something like that would then best be put in a watcher module,
> so the user can decide which arp packets can be used to fill the arp
> cache).

A watcher module seems like a good idea. It shouldn't matter if the arp
request continues all the way to the target, even though the bridge
already has(if entry exist) answered the sender from the cache.

Another solution I'm thinking of is to use some modified arpd/farpd. What
do you think is the preferred method?

/Regards Oscar

Re: [Ebtables-devel] --arpreply-mac AUTO and Mac Masquerading

[<os...@ki...>]

First of all. I wrote the previous mail like 6am without sleeping so the
text was confusing at some points. Can't even understand it completly
myself when I'm reading it ;) sorry about that...

Really short summary, and hopefully more understandable:
The customers could have 1 or more IPs. The customers don't have static
IPs. The customers macaddress could be anything. IP addresses should never
change.

IP1 ---- eth0 - br0 - eth1.101 ---- IP2(customer)
                      eth1.102 ---- IP3,IP4(customer with 2 IPs)

<-IP = iptables mangle, mark with incoming vlannumber, ebtables snat
markvalue with predefined macaddress(one mac for each customer).
->IP = ebtables redirect-target
<-ARPrequest = Bridge need to answer from arpcache if possible.
Otherwise(or always) snat the packet and let it through. ebtables
redirect-target the arpreply and bridge will install in arpcache.
->ARPrequest = Bridge need to answer from cache if possible. Otherwise(or
always) let the packet through. ebtables redirect-target the arpreply and
bridge will install in arpcache.

>
> Sorry, I don't quite see why you need to snat their traffic...
>

Why I would like to snat their traffic is because when you have lots of
customers it's really great if you could easily be sure of who the true
source is. Otherwise it's really timeconsuming to hunt down a single user
that's spamming the network with useless data.
And I also read some other old thread about "Dynamic source MAC-NAT?"
which seems to be the same thing as I'm talking about.

>>
>> So in conclusion, the only thing that needs to be done for this whole
>> thing to work. That's to make the --arpreply-mac AUTO check in the
>> bridge
>> fdb for an entry. Read about some timer issues in the old thread. But is
>> that really necessary. Doesn't the bridge fdb take care of all that?
>
> I was probably thinking that the arp entries would be cached by the
> arpreply target. That way you don't need the arp code. But you can add a
> new entry into the arp cache without having to actually redirect the
> packet (something like that would then best be put in a watcher module,
> so the user can decide which arp packets can be used to fill the arp
> cache).

A watcher module seems like a good idea. It shouldn't matter if the arp
request continues all the way to the target, even though the bridge
already has(if entry exist) answered the sender from the cache.

Another solution I'm thinking of is to use some modified arpd/farpd. What
do you think is the preferred method?

/Regards Oscar

Re: [Ebtables-devel] --arpreply-mac AUTO and Mac Masquerading

[Bart De S. <bds...@pa...>]

Op za, 08-04-2006 te 06:14 +0200, schreef os...@ki...:
> Since we want IP traffic to also be mac masqueraded we need 2 more things
> on the bridge. First we need to setup the bridge to send out arpreplies
> for the preconfigures macs. And second, we need to snat all the traffic
> from the customers with their preconfigured mac. This i solved by marking
> the packets in iptables mangle prerouting and the matching in ebtables
> postrouting.

Sorry, I don't quite see why you need to snat their traffic...

> So in conclusion, the only thing that needs to be done for this whole
> thing to work. That's to make the --arpreply-mac AUTO check in the bridge
> fdb for an entry. Read about some timer issues in the old thread. But is
> that really necessary. Doesn't the bridge fdb take care of all that?

I was probably thinking that the arp entries would be cached by the
arpreply target. That way you don't need the arp code. But you can add a
new entry into the arp cache without having to actually redirect the
packet (something like that would then best be put in a watcher module,
so the user can decide which arp packets can be used to fill the arp
cache).
Of course, probably someone somewhere will need this --arpreply-mac-auto
option but without it filling the arp cache...


How about something like this for your setup:
The bridge replies to all (or some) arp requests from the customers by
telling them the corresponding mac address is the bridge's mac address.
So, all customers will send their packets with the bridge's mac as
destination. Then just use iptables masquerading on the bridge. See the
example setup discussed in
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
Of course, the drawback is that you need to assign the bridge an ip
address.

cheers,
Bart

[Ebtables-devel] --arpreply-mac AUTO and Mac Masquerading

[<os...@ki...>]

Stumbled across this superold thread about --arpreply-mac AUTO
http://article.gmane.org/gmane.linux.network.bridge.ebtables.devel/193/match=auto
I can't seem to find any patch or code anywhere, I guess this feature
never was written, or???

Anyway, I have this interesting theory about how you can do some
masquerading with mac. Because it is so easy to spoof packets on a network
I want to somehow always know exactly from what customer the packets are
being generated from.

A-D are IPs, A is the gateway and B-D are customers on own interfaces.
The customers B-D also get their own macs binded to them, lets say
0:0:0:0:0:B 0:0:0:0:0:C and 0:0:0:0:0:D

                         |---- B
A --(backbone)--| Bridge |---- C
                         |---- D

When the bridge recieves and arp request it does as explained with the
suggested --arpreply-mac AUTO. It checks the bridge fdb for an ip that
matches the arp destination payload.
If a record is found on other side of the bridge it will send an arpreply
back and drop the packet, and if a record not was found it will continue
to forward the packet as usual.
The target of the arp request will then recieve the packet and answer back
as usual with a reply. The reply arrives at the bridge, here we can choose
to redirect the reply to the bridge itself (who will install in fdb) and
then drop the packet(the source ip will send out more arp requests and the
bridge can now answer from the fdb). Or we can copy the packet to the
bridge and the source ip that sent out the request.
This should result in that the source "knows" the targets preconfigured
mac, for an example 0:0:0:0:0:B.
The bridge will know both the source and targets real mac.
The target will know the real mac of the source.

Since we want IP traffic to also be mac masqueraded we need 2 more things
on the bridge. First we need to setup the bridge to send out arpreplies
for the preconfigures macs. And second, we need to snat all the traffic
from the customers with their preconfigured mac. This i solved by marking
the packets in iptables mangle prerouting and the matching in ebtables
postrouting.

So in conclusion, the only thing that needs to be done for this whole
thing to work. That's to make the --arpreply-mac AUTO check in the bridge
fdb for an entry. Read about some timer issues in the old thread. But is
that really necessary. Doesn't the bridge fdb take care of all that?

I appreciate thoughts and ideas about all this :)

/Oscar N

[Ebtables-devel] Hi,ebt-arp-snat module

[lin l. <lk...@gm...>]

Hi,every one,I'm very glad to join the ebtables e-mail list.

Here I have a question described as following:

Ebtables apply a NAT moudle which can be used to modify the IP packets
source mac address,

but this feature need I must add the ebtables rules every time I want to do
the mac-snat.I write a

moule named ebt-arp-snat module,which will snat the IP packets source mac
address,but the mac

address will not be added in the ebtables rule,but in ARP cache,every time
when the packet came

into arp_snat target module,the module will find the source IP address's
coresponding MAC address

and replace the mac address to the source IP address's real MAC address.

Is there any questions about this idear?

Thx a lot for yours help.:)

[Ebtables-devel] tc filter unoperable

[Luis L. M. d. C. <lu...@gm...>]

Hello Dear Developer,

 

I successfully compile the kernel 2.4.31 with ebtables patch and made some
test on brouting, and it works perfect. Unfortunlly the tc filters (of
IPROUTE) became unoperable, when I set up a filter it does not shows any
error, but it does not create it.

 

Regards

Luis Lopez

 

Re: [Ebtables-devel] kernel oops on 2.4.29 with ebtables-brnf-9 patch

[Bart De S. <bds...@pa...>]

Op ma, 16-01-2006 te 11:59 +0530, schreef Arinjay Jain:
> Hi,
> I have applied the ebtables-brnf-9_vs_2.4.29.diff patch on kernel
> 2.4.29 and am getting OOPS in netif_receive_skb.
> The 2.4.29 kernel I have is already patched with some skbuff headroom
> and tailroom changes. I have pasted the diff.

> Will this patch cause any problem with the ebtables-br-nf patch that I
> am using.

It wouldn't surprise me, although I can't give you an exact reason
without having to look over the code...

cheers,
Bart