ebtables-devel Mailing List for Ethernet bridge tables (Page 4)
Brought to you by:
bdschuym
Menu
▾
▴
ebtables-devel — Development questions, bugs, patches
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(5) |
Aug
(7) |
Sep
(13) |
Oct
(9) |
Nov
(11) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(13) |
Feb
(8) |
Mar
(32) |
Apr
(21) |
May
(15) |
Jun
(7) |
Jul
(35) |
Aug
(26) |
Sep
(29) |
Oct
(13) |
Nov
(4) |
Dec
(32) |
| 2004 |
Jan
(2) |
Feb
(20) |
Mar
(9) |
Apr
|
May
(7) |
Jun
(22) |
Jul
(7) |
Aug
(6) |
Sep
(15) |
Oct
(17) |
Nov
(12) |
Dec
(16) |
| 2005 |
Jan
(6) |
Feb
(15) |
Mar
(17) |
Apr
(27) |
May
(13) |
Jun
(43) |
Jul
(3) |
Aug
(12) |
Sep
(16) |
Oct
(12) |
Nov
(9) |
Dec
(10) |
| 2006 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(15) |
Aug
(2) |
Sep
(1) |
Oct
(5) |
Nov
(5) |
Dec
(10) |
| 2007 |
Jan
(2) |
Feb
(14) |
Mar
(19) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
(9) |
Sep
(6) |
Oct
(7) |
Nov
(4) |
Dec
|
| 2008 |
Jan
(11) |
Feb
(43) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tseng, Kuo-L. <kuo...@in...> - 2008-02-07 00:17:03
|
Two patches are attached. They add port based DNAT/SNAT feature for changing the dest or src MAC address in MAC header of IPv6 packets. (I couldn't get access to the ebtables cvs web interface, seems the interface is down, so the patches were generated based on the original ebtables-v2.0.8-2 and 2.6.18 netfilter.) Example dnat Usage: 1. Port based: ebtables -t nat -A PREROUTING --in-interface eth0 --protocol IPV6 --ip6-protocol "6" --ip6-destination-port 22 -j dnat --to-destination 00:13:20:F5:F1:28 --log-ip6 2. IP protocol-based: ebtables -t nat -A PREROUTING --in-interface eth0 --protocol IPV6 --ip6-protocol 58 -j dnat --to-destination 00:13:20:F5:F1:28 3. IPv6: ebtables -t nat -A PREROUTING --in-interface eth0 --protocol IPV6 -j dnat --to-destination 00:13:20:F5:F1:28 Similar usage can be applied for snat. Thanks Kuo >-----Original Message----- >From: Bart De Schuymer [mailto:bds...@pa...] >Sent: Friday, January 25, 2008 3:23 PM >To: Tseng, Kuo-Lang >Cc: ebt...@li... >Subject: Re: [Ebtables-devel] IPv6 support in ebtables > >Op vr, 25-01-2008 te 14:27 -0800, schreef Tseng, Kuo-Lang: >> >From: ebt...@li... >> [mailto:ebtables-devel- >> >bo...@li...] On Behalf Of Tseng, Kuo-Lang >> >Sent: Wednesday, January 23, 2008 4:11 PM >> >Hi, >> > >> >I would like to find out if there is any IPv6 support in ebtables for >> >replacing MAC address of the Ethernet header based on TCP or UDP port >> id >> >in IPv6 packets. I would appreciate it if there is anyone on this list >> >who knows of any prior work in ebtables to support IPv6. >> > >> >One such example usage I am looking for is: TCP Port based DNAT >> > >> >Current IPv4 Support: >> >-p IPv4 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst >> >0:13:20:f5:f1:1f --dnat-target ACCEPT >> > >> >Similar support for IPv6 packets I would like to use: >> >-p IPv6 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst >> >0:13:20:f5:f1:1f --dnat-target ACCEPT >> > >> >> I looked at version v2.0.8-2 of ebtables user space code and bridge >> netfilter kernel code from 2.6 and realized that v6 support is not >> there. >> >> Does anyone know if anyone is working (or planning) on adding this >> support? >> >> If not, I'd like to add this minimum support into ebtables for dnat on >> IPv6 packets and is it fine for me to send a patch for review? > >That's fine. I'm not sure what you mean, but dnat on the IPv6 addresses >of course doesn't belong in ebtables. > >cheers, >Bart > |
|
From: Bart De S. <bds...@pa...> - 2008-02-03 19:59:24
|
Op wo, 30-01-2008 te 19:30 +0100, schreef Jan Engelhardt: > According to http://marc.info/?l=netfilter-devel&m=120083920425755&w=2 > I need to expand these, so let's do that. Committed, thanks, Bart |
|
From: Jan E. <je...@co...> - 2008-01-30 18:31:05
|
According to http://marc.info/?l=netfilter-devel&m=120083920425755&w=2 I need to expand these, so let's do that. --- extensions/ebt_802_3.c | 2 +- extensions/ebt_among.c | 2 +- extensions/ebt_arp.c | 2 +- extensions/ebt_arpreply.c | 2 +- extensions/ebt_ip.c | 2 +- extensions/ebt_limit.c | 2 +- extensions/ebt_log.c | 2 +- extensions/ebt_mark.c | 2 +- extensions/ebt_mark_m.c | 2 +- extensions/ebt_nat.c | 4 ++-- extensions/ebt_pkttype.c | 2 +- extensions/ebt_redirect.c | 2 +- extensions/ebt_standard.c | 2 +- extensions/ebt_stp.c | 2 +- extensions/ebt_ulog.c | 2 +- extensions/ebt_vlan.c | 2 +- 16 files changed, 17 insertions(+), 17 deletions(-) Index: ebtables-v2.0.8-2/extensions/ebt_802_3.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_802_3.c +++ ebtables-v2.0.8-2/extensions/ebt_802_3.c @@ -130,7 +130,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match _802_3_match = { - .name = EBT_802_3_MATCH, + .name = "802_3", .size = sizeof(struct ebt_802_3_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_among.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_among.c +++ ebtables-v2.0.8-2/extensions/ebt_among.c @@ -476,7 +476,7 @@ static int compare(const struct ebt_entr } static struct ebt_u_match among_match = { - .name = EBT_AMONG_MATCH, + .name = "among", .size = sizeof(struct ebt_among_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_arp.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_arp.c +++ ebtables-v2.0.8-2/extensions/ebt_arp.c @@ -351,7 +351,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match arp_match = { - .name = EBT_ARP_MATCH, + .name = "arp", .size = sizeof(struct ebt_arp_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_arpreply.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_arpreply.c +++ ebtables-v2.0.8-2/extensions/ebt_arpreply.c @@ -122,7 +122,7 @@ static int compare(const struct ebt_entr static struct ebt_u_target arpreply_target = { - .name = EBT_ARPREPLY_TARGET, + .name = "arpreply", .size = sizeof(struct ebt_arpreply_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_ip.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_ip.c +++ ebtables-v2.0.8-2/extensions/ebt_ip.c @@ -327,7 +327,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match ip_match = { - .name = EBT_IP_MATCH, + .name = "ip", .size = sizeof(struct ebt_ip_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_limit.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_limit.c +++ ebtables-v2.0.8-2/extensions/ebt_limit.c @@ -201,7 +201,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match limit_match = { - .name = EBT_LIMIT_MATCH, + .name = "limit", .size = sizeof(struct ebt_limit_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_log.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_log.c +++ ebtables-v2.0.8-2/extensions/ebt_log.c @@ -193,7 +193,7 @@ static int compare(const struct ebt_entr static struct ebt_u_watcher log_watcher = { - .name = EBT_LOG_WATCHER, + .name = "log", .size = sizeof(struct ebt_log_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_mark.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_mark.c +++ ebtables-v2.0.8-2/extensions/ebt_mark.c @@ -161,7 +161,7 @@ static int compare(const struct ebt_entr static struct ebt_u_target mark_target = { - .name = EBT_MARK_TARGET, + .name = "mark", .size = sizeof(struct ebt_mark_t_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_mark_m.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_mark_m.c +++ ebtables-v2.0.8-2/extensions/ebt_mark_m.c @@ -110,7 +110,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match mark_match = { - .name = EBT_MARK_MATCH, + .name = "mark_m", .size = sizeof(struct ebt_mark_m_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_nat.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_nat.c +++ ebtables-v2.0.8-2/extensions/ebt_nat.c @@ -207,7 +207,7 @@ static int compare(const struct ebt_entr static struct ebt_u_target snat_target = { - .name = EBT_SNAT_TARGET, + .name = "snat", .size = sizeof(struct ebt_nat_info), .help = print_help_s, .init = init_s, @@ -220,7 +220,7 @@ static struct ebt_u_target snat_target = static struct ebt_u_target dnat_target = { - .name = EBT_DNAT_TARGET, + .name = "dnat", .size = sizeof(struct ebt_nat_info), .help = print_help_d, .init = init_d, Index: ebtables-v2.0.8-2/extensions/ebt_pkttype.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_pkttype.c +++ ebtables-v2.0.8-2/extensions/ebt_pkttype.c @@ -114,7 +114,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match pkttype_match = { - .name = EBT_PKTTYPE_MATCH, + .name = "pkttype", .size = sizeof(struct ebt_pkttype_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_redirect.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_redirect.c +++ ebtables-v2.0.8-2/extensions/ebt_redirect.c @@ -97,7 +97,7 @@ static int compare(const struct ebt_entr static struct ebt_u_target redirect_target = { - .name = EBT_REDIRECT_TARGET, + .name = "redirect", .size = sizeof(struct ebt_redirect_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_standard.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_standard.c +++ ebtables-v2.0.8-2/extensions/ebt_standard.c @@ -72,7 +72,7 @@ static int compare(const struct ebt_entr static struct ebt_u_target standard = { - .name = EBT_STANDARD_TARGET, + .name = "standard", .size = sizeof(struct ebt_standard_target) - sizeof(struct ebt_entry_target), .help = print_help, Index: ebtables-v2.0.8-2/extensions/ebt_stp.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_stp.c +++ ebtables-v2.0.8-2/extensions/ebt_stp.c @@ -326,7 +326,7 @@ static int compare(const struct ebt_entr static struct ebt_u_match stp_match = { - .name = EBT_STP_MATCH, + .name = "stp", .size = sizeof(struct ebt_stp_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_ulog.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_ulog.c +++ ebtables-v2.0.8-2/extensions/ebt_ulog.c @@ -169,7 +169,7 @@ static int compare(const struct ebt_entr static struct ebt_u_watcher ulog_watcher = { - .name = EBT_ULOG_WATCHER, + .name = "ulog", .size = sizeof(struct ebt_ulog_info), .help = print_help, .init = init, Index: ebtables-v2.0.8-2/extensions/ebt_vlan.c =================================================================== --- ebtables-v2.0.8-2.orig/extensions/ebt_vlan.c +++ ebtables-v2.0.8-2/extensions/ebt_vlan.c @@ -170,7 +170,7 @@ static int compare(const struct ebt_entr } static struct ebt_u_match vlan_match = { - .name = EBT_VLAN_MATCH, + .name = "vlan", .size = sizeof(struct ebt_vlan_info), .help = print_help, .init = init, |
|
From: Tseng, Kuo-L. <kuo...@in...> - 2008-01-28 18:34:40
|
>-----Original Message----- >From: Tseng, Kuo-Lang >Sent: Friday, January 25, 2008 3:31 PM >To: 'Bart De Schuymer' >Cc: ebt...@li... >Subject: RE: [Ebtables-devel] IPv6 support in ebtables > >>From: Bart De Schuymer [mailto:bds...@pa...] >>Sent: Friday, January 25, 2008 3:23 PM >>That's fine. I'm not sure what you mean, but dnat on the IPv6 addresses >>of course doesn't belong in ebtables. >> >>cheers, >>Bart >> >Thanks. The minimum support I was mentioning is dnat for changing >destination MAC address in MAC header of IPv6 packets. > >Thanks >Kuo Hi,=20 Just wanted to confirm if this makes sense to you and if it is fine, then I will work on a patch and send it out some time later this or next week. Thanks Kuo |
|
From: Tseng, Kuo-L. <kuo...@in...> - 2008-01-25 23:31:16
|
>From: Bart De Schuymer [mailto:bds...@pa...] >Sent: Friday, January 25, 2008 3:23 PM >That's fine. I'm not sure what you mean, but dnat on the IPv6 addresses >of course doesn't belong in ebtables. > >cheers, >Bart > Thanks. The minimum support I was mentioning is dnat for changing destination MAC address in MAC header of IPv6 packets.=20 Thanks Kuo |
|
From: Bart De S. <bds...@pa...> - 2008-01-25 23:22:39
|
Op vr, 25-01-2008 te 14:27 -0800, schreef Tseng, Kuo-Lang: > >From: ebt...@li... > [mailto:ebtables-devel- > >bo...@li...] On Behalf Of Tseng, Kuo-Lang > >Sent: Wednesday, January 23, 2008 4:11 PM > >Hi, > > > >I would like to find out if there is any IPv6 support in ebtables for > >replacing MAC address of the Ethernet header based on TCP or UDP port > id > >in IPv6 packets. I would appreciate it if there is anyone on this list > >who knows of any prior work in ebtables to support IPv6. > > > >One such example usage I am looking for is: TCP Port based DNAT > > > >Current IPv4 Support: > >-p IPv4 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst > >0:13:20:f5:f1:1f --dnat-target ACCEPT > > > >Similar support for IPv6 packets I would like to use: > >-p IPv6 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst > >0:13:20:f5:f1:1f --dnat-target ACCEPT > > > > I looked at version v2.0.8-2 of ebtables user space code and bridge > netfilter kernel code from 2.6 and realized that v6 support is not > there. > > Does anyone know if anyone is working (or planning) on adding this > support? > > If not, I'd like to add this minimum support into ebtables for dnat on > IPv6 packets and is it fine for me to send a patch for review? That's fine. I'm not sure what you mean, but dnat on the IPv6 addresses of course doesn't belong in ebtables. cheers, Bart |
|
From: Tseng, Kuo-L. <kuo...@in...> - 2008-01-25 22:28:01
|
>From: ebt...@li... [mailto:ebtables-devel- >bo...@li...] On Behalf Of Tseng, Kuo-Lang >Sent: Wednesday, January 23, 2008 4:11 PM >Hi, > >I would like to find out if there is any IPv6 support in ebtables for >replacing MAC address of the Ethernet header based on TCP or UDP port id >in IPv6 packets. I would appreciate it if there is anyone on this list >who knows of any prior work in ebtables to support IPv6. > >One such example usage I am looking for is: TCP Port based DNAT > >Current IPv4 Support: >-p IPv4 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst >0:13:20:f5:f1:1f --dnat-target ACCEPT > >Similar support for IPv6 packets I would like to use: >-p IPv6 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst >0:13:20:f5:f1:1f --dnat-target ACCEPT > I looked at version v2.0.8-2 of ebtables user space code and bridge netfilter kernel code from 2.6 and realized that v6 support is not there.=20 Does anyone know if anyone is working (or planning) on adding this support?=20 If not, I'd like to add this minimum support into ebtables for dnat on IPv6 packets and is it fine for me to send a patch for review? Kuo |
|
From: Bart De S. <bds...@pa...> - 2008-01-25 18:39:20
|
Op vr, 25-01-2008 te 19:18 +0100, schreef Michal Soltys: > Hello > > While adapting init script for Archlinux, I noticed two small bugs in it: > > - in two places where variables were tested, IPTABLES_* were used instead of > EBTABLES_* > > - if user chooses to save both text and binary formats, start function > will try to use table 'save' in one loop iteration. It's not > critical, but can be confusing for less experienced users. > > Apart for that, few trivial changes - cut and sed "merged" into one sed > call, ls quiet on stderr. Diff in attachment. Thanks, Bart |
|
From: Michal S. <so...@zi...> - 2008-01-25 18:18:48
|
Hello While adapting init script for Archlinux, I noticed two small bugs in it: - in two places where variables were tested, IPTABLES_* were used instead of EBTABLES_* - if user chooses to save both text and binary formats, start function will try to use table 'save' in one loop iteration. It's not critical, but can be confusing for less experienced users. Apart for that, few trivial changes - cut and sed "merged" into one sed call, ls quiet on stderr. Diff in attachment. |
|
From: Tseng, Kuo-L. <kuo...@in...> - 2008-01-24 00:12:20
|
Hi, I would like to find out if there is any IPv6 support in ebtables for replacing MAC address of the Ethernet header based on TCP or UDP port id in IPv6 packets. I would appreciate it if there is anyone on this list who knows of any prior work in ebtables to support IPv6.=20 One such example usage I am looking for is: TCP Port based DNAT=20 Current IPv4 Support:=20 -p IPv4 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst 0:13:20:f5:f1:1f --dnat-target ACCEPT Similar support for IPv6 packets I would like to use:=20 -p IPv6 -i peth0 --ip-proto 6 --ip-dport 22 -j dnat --to-dst 0:13:20:f5:f1:1f --dnat-target ACCEPT Thanks Kuo-lang Tseng |
|
From: Bart De S. <bds...@pa...> - 2008-01-21 21:23:15
|
Op vr, 18-01-2008 te 10:01 -0500, schreef Jonathan Thibault: > Hello list, > > I've already brought this up in ebtables-user and gotten a lot of > valuable input (you can have a peek at the archives for the saga) and > finally managed to narrow things down to either some obscure ARP/mac bug > in the bridge code itself, or something in the tg3 driver of the network > cards involved. Hi, is ebtables enabled? Try putting all values in /proc/sys/net/bridge/* on 0, if the problem remains then it's not ebtables or bridge-nf related. The best place to go then is br...@li... If it magically goes away however, do come back :) Cheers, Bart |
|
From: Jonathan T. <jon...@na...> - 2008-01-21 15:40:26
|
Grant Taylor wrote: > This is very odd. I'd be tempted to contact someone on the EBTables > developer mailing list to see what they have to say. You may have run > in to an obscure bug, either in bridging / EBTables or the Tigon network > driver. > > I've pondered this for a little while and I'm wondering... Given that it's always the same MACs that get affected, wouldn't this hint some sort of hashing issue? I don't know how the code works, but assuming that some hashing is done with the MAC address of the interface in the bridge and that both in.2 and in.3 have the same MAC, I can see how this could cause problems. I've CCed the dev list to see if any of them has some input on this. I can't really code myself so I may be talking nonsense here... Jonathan |
|
From: Jonathan T. <jon...@na...> - 2008-01-18 15:00:42
|
Hello list, I've already brought this up in ebtables-user and gotten a lot of valuable input (you can have a peek at the archives for the saga) and finally managed to narrow things down to either some obscure ARP/mac bug in the bridge code itself, or something in the tg3 driver of the network cards involved. Basically, I have a bunch of customers in vlan2 on an 'in' interface, which is bridged with an 'out' interface to the gateway. So basically: customers bridge isp vlan2 <--> (in.2-br0-out) <--> gateway This works quite well so long as I do not add another vlan interface to the bridge. I can have a test vlan (in.3) on up on the linux box itself, but adding it to the bridge brings forth strange behavior. It *mostly* works as it should, customers in both vlan2 and vlan3 can see the gateway, data goes through, etc. However the bridge seems to stop relaying arp replies from the gateway to some of our customers when in.3 is part of the bridge. I can see the arp requests and reply on every interface involved (tcpdump on in.2, br0 or out shows them) but if I check on the trunk wire itself (using a hub and another linux box) I only see the arp requests go through for those specific customers, they never seem to leave the 'in' network card. Overall, it looks like the bridge 'forgets' the mac address of those specific customers when in.3 gets added and never re-learns it. brctl showmacs br0 confirms this. On one test, it showed over 300 macs prior to adding in.3 and quickly dropped to 200 macs as soon as it entered forwarding state. This could be a strange coincidence, but I thought it was noteworthy. I know this is still fairly sketchy, but I would like some help in figuring out just where those vanishing arp replies go. This bug only shows up in our production environment so I would rather have the advice of devs in order to test things intelligently and with as little downtime as possible. Jonathan |
|
From: Syed M. A. R. <the...@ho...> - 2007-11-29 14:26:36
|
Hello All, I have been working on Ethernet Bridge using ebtables on kernel 2.6. What i wanted to know is how can i log the frame or traffic which i am getting into a file. The frames should be manipulated(modified with some algo) and retransmitted real time. Waiting for some replies! Thanks Syed Mujtaba _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From:
<ma...@gm...> - 2007-11-08 10:03:18
|
LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZyb206IFdlaS1UaW5nIFdh bmcgPHd0d3BldGVyQGdtYWlsLmNvbT4KRGF0ZTogMjAwNy8xMS84IOS4i+WNiCA1OjU5ClN1Ympl Y3Q6IEZ3ZDogQ2Fubm90IGRyb3AgcGFja2V0cyB2aWEgT1VUUFVUIGNoYWluPwoKCgpIZWxsbywK Ck15IExpbnV4IHZlcnNpb24gaXMgc2hvd24gYXMgZm9sbG93aW5nOgojIHVuYW1lIC1hCkxpbnV4 IChub25lKSAyLjQuMTdfbXZsMjEtNDE4OXJlZiAjMzcxIFdlZCBPY3QgMjQgMTQ6MzI6MTAgQ1NU IDIwMDcgbWlwcwp1bmtub3duCgpNeSBlYnRhYmxlcyB2ZXJzaW9uIGlzIHNob3duIGFzIGZvbGxv d2luZzoKIyBlYnRhYmxlcwplYnRhYmxlcyB2Mi4wLjgtMiAoTWF5IDIwMDcpCgpOb3csIEkgYW0g aW1wbGVtZW50aW5nIE1hYyBmaWx0ZXIgdXNpbmcgZWJ0YWJsZXMuIEFuZCBJIGNhbiBkcm9wCnBh Y2tldHMgdmlhIElOUFVUIGNoYWluLgplYnRhYmxlcyAtQSBJTlBVVCAtaSBldGgwIC1wIElQdjQg LXMgMDA6MEU6QTY6MEI6MTE6NkYgLWogRFJPUAplYnRhYmxlcyAtQSBJTlBVVCAtaSBldGgwIC1w IElQdjQgLWQgMDA6MDA6QUE6QkI6Q0M6RkYgLWogRFJPUAoKSG93ZXZlciwgYm90aCB0aGUgZm9s bG93aW5nIHR3byBjb21tYW5kcyBjYW4gd3JpdGUgaW50byBlYnRhYmxlIGJ1dApjYW5ub3QgZHJv cCBwYWNrZXRzIHZpYSBPVVRQVVQgY2hhaW4uIEluIGZhY3QsIEkgaGF2ZSBub3QgZHJvcHBlZCBh bnkKcGFja2V0cyB2aWEgT1VUUFVUIGNoYWluLgplYnRhYmxlcyAtQSBPVVRQVVQgLW8gZXRoMCAt cCBJUHY0IC1zIDAwOjAwOkFBOkJCOkNDOkZGIC1qIERST1AKZWJ0YWJsZXMgLUEgT1VUUFVUIC1v IGV0aDAgLXAgSVB2NCAtZCAwMDowRTpBNjowQjoxMTo2RiAtaiBEUk9QCgpUaGFua3MuCi0tClJl Z2FyZHMsCldlaS1UaW5nIFdhbmcK |
|
From: Wei-Ting W. <wtw...@gm...> - 2007-11-08 09:52:17
|
SGVsbG8sCgpTb3JyeSwgbGFzdCBwb3N0IGhhZCB3cm9uZyBlbmNvZGluZy4KCk15IExpbnV4IHZl cnNpb24gaXMgc2hvd24gYXMgZm9sbG93aW5nOgojIHVuYW1lIC1hCkxpbnV4IChub25lKSAyLjQu MTdfbXZsMjEtNDE4OXJlZiAjMzcxIFdlZCBPY3QgMjQgMTQ6MzI6MTAgQ1NUIDIwMDcgbWlwcyB1 bmtub3duCgpNeSBlYnRhYmxlcyB2ZXJzaW9uIGlzIHNob3duIGFzIGZvbGxvd2luZzoKIyBlYnRh YmxlcwplYnRhYmxlcyB2Mi4wLjgtMiAoTWF5IDIwMDcpCgpOb3csIEkgYW0gaW1wbGVtZW50aW5n IE1hYyBmaWx0ZXIgdXNpbmcgZWJ0YWJsZXMuIEFuZCBJIGNhbiBkcm9wCnBhY2tldHMgdmlhIElO UFVUIGNoYWluLgplYnRhYmxlcyAtQSBJTlBVVCAtaSBldGgwIC1wIElQdjQgLXMgMDA6MEU6QTY6 MEI6MTE6NkYgLWogRFJPUAplYnRhYmxlcyAtQSBJTlBVVCAtaSBldGgwIC1wIElQdjQgLWQgMDA6 MDA6QUE6QkI6Q0M6RkYgLWogRFJPUAoKSG93ZXZlciwgYm90aCB0aGUgZm9sbG93aW5nIHR3byBj b21tYW5kcyBjYW4gd3JpdGUgaW50byBlYnRhYmxlIGJ1dApjYW5ub3QgZHJvcCBwYWNrZXRzIHZp YSBPVVRQVVQgY2hhaW4uIEluIGZhY3QsIEkgaGF2ZSBub3QgZHJvcHBlZCBhbnkKcGFja2V0cyB2 aWEgT1VUUFVUIGNoYWluLgplYnRhYmxlcyAtQSBPVVRQVVQgLW8gZXRoMCAtcCBJUHY0IC1zIDAw OjAwOkFBOkJCOkNDOkZGIC1qIERST1AKZWJ0YWJsZXMgLUEgT1VUUFVUIC1vIGV0aDAgLXAgSVB2 NCAtZCAwMDowRTpBNjowQjoxMTo2RiAtaiBEUk9QCgpUaGFua3MuCgotLSAKUmVnYXJkcywK5rGq 5aiB5a6aIFdlaS1UaW5nIFdhbmcK |
|
From: Wei-Ting W. <wtw...@gm...> - 2007-11-08 06:45:20
|
SGVsbG8sCgpNeSBMaW51eCB2ZXJzaW9uIGlzIHNob3duIGFzIGZvbGxvd2luZzoKIyB1bmFtZSAt YQpMaW51eCAobm9uZSkgMi40LjE3X212bDIxLTQxODlyZWYgIzM3MSBXZWQgT2N0IDI0IDE0OjMy OjEwIENTVCAyMDA3IG1pcHMgdW5rbm93bgoKTXkgZWJ0YWJsZXMgdmVyc2lvbiBpcyBzaG93biBh cyBmb2xsb3dpbmc6CiMgZWJ0YWJsZXMKZWJ0YWJsZXMgdjIuMC44LTIgKE1heSAyMDA3KQoKTm93 LCBJIGFtIGltcGxlbWVudGluZyBNYWMgZmlsdGVyIHVzaW5nIGVidGFibGVzLiBBbmQgSSBjYW4g ZHJvcApwYWNrZXRzIHZpYSBJTlBVVCBjaGFpbi4KZWJ0YWJsZXMgLUEgSU5QVVQgLWkgZXRoMCAt cCBJUHY0IC1zIDAwOjBFOkE2OjBCOjExOjZGIC1qIERST1AKZWJ0YWJsZXMgLUEgSU5QVVQgLWkg ZXRoMCAtcCBJUHY0IC1kIDAwOjAwOkFBOkJCOkNDOkZGIC1qIERST1AKCkhvd2V2ZXIsIGJvdGgg dGhlIGZvbGxvd2luZyB0d28gY29tbWFuZHMgY2FuIHdyaXRlIGludG8gZWJ0YWJsZSBidXQKY2Fu bm90IGRyb3AgcGFja2V0cyB2aWEgT1VUUFVUIGNoYWluLiBJbiBmYWN0LCBJIGhhdmUgbm90IGRy b3BwZWQgYW55CnBhY2tldHMgdmlhIE9VVFBVVCBjaGFpbi4KZWJ0YWJsZXMgLUEgT1VUUFVUIC1v IGV0aDAgLXAgSVB2NCAtcyAwMDowMDpBQTpCQjpDQzpGRiAtaiBEUk9QCmVidGFibGVzIC1BIE9V VFBVVCAtbyBldGgwIC1wIElQdjQgLWQgMDA6MEU6QTY6MEI6MTE6NkYgLWogRFJPUAoKVGhhbmtz LgotLSAKUmVnYXJkcywKqEyrwql3IFdlaS1UaW5nIFdhbmcK |
|
From: Bart De S. <bds...@pa...> - 2007-10-21 07:36:29
|
Op vr, 19-10-2007 te 16:15 +0200, schreef Mark Ryden: > Hello, > I am writing a kernel module which changes the MAC address of a received UDP > packet so that it will be of a different machine on the same LAN and > so that the > packet will be forwarded to that machine. > Namely, I am trying to do fowarding in layer 2 using ebtables hook. > > I am catching the packet with NF_BR_PRE_ROUTING ebtable hook. > In this hook, I am changing its MAC address to 00:11:2F:93:E0:52 ; > this is the MAC > address of another machine which is on the same LAN (my ARP table > knows this MAC). > > The code is below; it is short; (only 100 lines). If someone can > take a look at it and give some advice it will be more than welcomed. > > I saw a posting in this mailing list a few days ago in which > somebody tried also to adjust a MAC address and it was suggested that > he should follow ebt_snat.c; so this is what I did. > > see: > http://sourceforge.net/mailarchive/forum.php?thread_name=6.1.2.0.2.20050218133252.04555610%40luna.tlmat.unican.es&forum_name=ebtables-devel > > More details: > When running the module and sending UDP packets on port 5555, I > see that I get the packets in the module; > Moreover, I see that the following if statement is valid: > if (skb_shared(*pskb) || skb_cloned(*pskb)) .. > > However, when I put a sniffer on that machine or the second machine I > **don't** see that a packet is sent to the second machine, > namely to 00:11:2F:93:E0:52. > > What is missing here ? should I add some ebtable forwarding hook? > > BTW, on my machine, there is a bridge defined thus (as far as I know,this > should be ok): > ifconfig eth0 0.0.0.0 > brctl addbr mybr > brctl addif mybr eth0 > ifconfig mybr up > ifconfig mybr 192.168.0.45 netmask 255.255.255.0 > > if( (*pskb)->protocol == ethpip && (*pskb)->nh.iph->protocol == IPPROTO_UDP) > { > struct udphdr *udp_header = (struct udphdr *)((*pskb)->data + > ((*pskb)->nh.iph->ihl *4)); You'll need to use skb_header_pointer() here, see ebt_ip.c. For debugging purpose, try returning EBT_CONTINUE instead of NF_ACCEPT and add an ebtables log rule after the rule containing your target. cheers, Bart |
|
From: Mark R. <mar...@gm...> - 2007-10-19 14:15:43
|
Hello, I am writing a kernel module which changes the MAC address of a received UDP packet so that it will be of a different machine on the same LAN and so that the packet will be forwarded to that machine. Namely, I am trying to do fowarding in layer 2 using ebtables hook. I am catching the packet with NF_BR_PRE_ROUTING ebtable hook. In this hook, I am changing its MAC address to 00:11:2F:93:E0:52 ; this is the MAC address of another machine which is on the same LAN (my ARP table knows this MAC). The code is below; it is short; (only 100 lines). If someone can take a look at it and give some advice it will be more than welcomed. I saw a posting in this mailing list a few days ago in which somebody tried also to adjust a MAC address and it was suggested that he should follow ebt_snat.c; so this is what I did. see: http://sourceforge.net/mailarchive/forum.php?thread_name=6.1.2.0.2.20050218133252.04555610%40luna.tlmat.unican.es&forum_name=ebtables-devel More details: When running the module and sending UDP packets on port 5555, I see that I get the packets in the module; Moreover, I see that the following if statement is valid: if (skb_shared(*pskb) || skb_cloned(*pskb)) .. However, when I put a sniffer on that machine or the second machine I **don't** see that a packet is sent to the second machine, namely to 00:11:2F:93:E0:52. What is missing here ? should I add some ebtable forwarding hook? BTW, on my machine, there is a bridge defined thus (as far as I know,this should be ok): ifconfig eth0 0.0.0.0 brctl addbr mybr brctl addif mybr eth0 ifconfig mybr up ifconfig mybr 192.168.0.45 netmask 255.255.255.0 Below is the code: // ebtable.c #include <linux/version.h> #include <linux/module.h> #include <linux/types.h> #include <linux/kernel.h> #include <linux/sched.h> #include <linux/mm.h> #include <linux/string.h> #include <linux/errno.h> #include <linux/init.h> #include <linux/kmod.h> #include <asm/uaccess.h> #include <asm/system.h> #include <linux/netfilter.h> #include <linux/netfilter_ipv4.h> #include <linux/skbuff.h> #include <linux/ip.h> #include <linux/in.h> #include <linux/kernel.h> #include <linux/inet.h> #include <linux/udp.h> #include <linux/netdevice.h> #include <linux/time.h> #include <linux/netfilter_ipv4/ip_nat.h> #include <net/ip.h> #include <net/checksum.h> #include <linux/netfilter_bridge/ebtables.h> #include <linux/netfilter_bridge/ebt_nat.h> #include <linux/netfilter_bridge.h> static unsigned short ethpip; static struct nf_hook_ops netfilter_ops_in; unsigned int main_hook(unsigned int hooknum, struct sk_buff** pskb, const struct net_device* in, const struct net_device* out, int (*okfn)(struct sk_buff*)) { static int counter; struct sk_buff *nskb; unsigned char *data; int i; counter++; if( (*pskb)->protocol == ethpip && (*pskb)->nh.iph->protocol == IPPROTO_UDP) { struct udphdr *udp_header = (struct udphdr *)((*pskb)->data + ((*pskb)->nh.iph->ihl *4)); int port = ntohs(udp_header->dest); if (port == 5555) { char a[] = { 0x00, 0x11, 0x2F, 0x93, 0xE0, 0x52 }; printk("changing IP dst address in %s\n", __FUNCTION__); if (skb_shared(*pskb) || skb_cloned(*pskb)) { struct sk_buff *nskb; // printk("in if if (skb_shared(*pskb) || skb_cloned(*pskb)) \n"); 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; } memcpy(eth_hdr(*pskb)->h_dest, a, ETH_ALEN); }// of if port = 5555 } return NF_ACCEPT; } static int __init ebtable_init(void) { int ret; ethpip = htons(ETH_P_IP); netfilter_ops_in.hook = main_hook; netfilter_ops_in.owner = THIS_MODULE, netfilter_ops_in.pf = PF_BRIDGE; netfilter_ops_in.hooknum = NF_BR_PRE_ROUTING; netfilter_ops_in.priority = NF_BR_PRI_FILTER_BRIDGED; ret = nf_register_hook(&netfilter_ops_in); if (ret < 0) { nf_unregister_hook(&netfilter_ops_in); return -1; } return 0; } static void __exit ebtable_exit(void) { nf_unregister_hook(&netfilter_ops_in); } module_init(ebtable_init) module_exit(ebtable_exit) MODULE_AUTHOR("MarkRyde"); MODULE_DESCRIPTION("ebtables changing mac address"); MODULE_LICENSE("GPL"); Regards, Mark |
|
From: Bart De S. <bds...@pa...> - 2007-10-17 19:43:25
|
Op wo, 17-10-2007 te 11:51 +0200, schreef Ian Brown: > Hello, > > Is it possible to change the source MAC address of packets using ebtables > hooks on a machine which is functioning as a router ? (I mean, > which forwards incoming packets ). Yes, you can make a bridge that only has one bridge port. See http://ebtables.sourceforge.net/examples.html#ex_nobridge cheers, Bart |
|
From: Ian B. <ia...@gm...> - 2007-10-17 09:52:02
|
Hello, Is it possible to change the source MAC address of packets using ebtables hooks on a machine which is functioning as a router ? (I mean, which forwards incoming packets ). What I mean is: suppose I am getting a packet from A and on machine B. I forward it to C using iptables forwarding rule. And suppose I want to change some of these packets so that the MAC address of them when trasnmitted from B to C will be the MAC address of A (instead of B). Can I do it with ebtables hook? which hook should I use ? Should it be NF_BR_PRE_ROUTING ? or NF_BR_FORWARD ? (remeber that my forwarding is based on layer 3, the network ip layer). Or should I use instead **only** ebtables forwarding, and change that MAC there ? Regards, Ian |
|
From: Bart De S. <bds...@pa...> - 2007-10-16 18:06:18
|
Op di, 16-10-2007 te 17:46 +0800, schreef YUNG-CHANG WANG <王勇璋>: > Recently I'm taking a survey on Linux packet QoS mechanisms, using > some parameters such as packet type, MAC, IP addr...etc, to replace > original Linux TC. However, I found the Linux QoS mechanism didn't > provide me a good solution. > > Here are the requirements: on the target machine, the packets from > input should be parsed to be examined their layer 2 (this is why I > need ebtableds) and layer 3 header, checking if these incoming packets > match the rules I defined. These rules decide which kinds of packets > should be put to different priority queues. What I mentioned here > "different priority queues" are quite different from the queues > defined in Linux kernel. They are HW queues. Don't worry about the HW > queues, they are implemented in the HW driver, so all I need is to > classify all the packets incoming, dispatch them to their proper > queues before they're forwarding (maybe encapsulate one more tag to > specify their priority). > > My problem is, I traced both userspace program and kernel space source > code, and it seemed there's no functions like what classification do. > What it was done is by parse, compare, and match to filter the > packets. If I would like to add the feature as I just mentioned, how > or where should I start? The ebtables seems to have less direct > connection with Linux RX and TX. If there's anyone who can give me > some clue or advice, I will be very appreciated. Just an idea... What you could do is make a virtual networking device (like the bridge or vlan). The code in that device then decides where things have to go. You can still do the filtering in ebtables if you want, then just mark the packets and use that mark in your virtual device. Ebtables wasn't really designed to let you alter the destination device but maybe things will keep working if you use an ebtables target that does this, dunno... Good luck, Bart |
|
From:
<ma...@gm...> - 2007-10-16 09:46:33
|
Recently I'm taking a survey on Linux packet QoS mechanisms, using some parameters such as packet type, MAC, IP addr...etc, to replace original Linux TC. However, I found the Linux QoS mechanism didn't provide me a good solution. Here are the requirements: on the target machine, the packets from input should be parsed to be examined their layer 2 (this is why I need ebtableds) and layer 3 header, checking if these incoming packets match the rules I defined. These rules decide which kinds of packets should be put to different priority queues. What I mentioned here "different priority queues" are quite different from the queues defined in Linux kernel. They are HW queues. Don't worry about the HW queues, they are implemented in the HW driver, so all I need is to classify all the packets incoming, dispatch them to their proper queues before they're forwarding (maybe encapsulate one more tag to specify their priority). My problem is, I traced both userspace program and kernel space source code, and it seemed there's no functions like what classification do. What it was done is by parse, compare, and match to filter the packets. If I would like to add the feature as I just mentioned, how or where should I start? The ebtables seems to have less direct connection with Linux RX and TX. If there's anyone who can give me some clue or advice, I will be very appreciated. |
|
From: Bart De S. <bds...@pa...> - 2007-10-09 20:58:58
|
Op vr, 28-09-2007 te 21:21 +0100, schreef Abhinav Srivastava: > Hi there, > > I have questions regarding the extension of ebtables > code to support target similar to QUEUE target. In my > project, I have a requirement of intercepting packets > inside ebtables and pass some information related to > packet to userspace tool. Ebtables code should wait to > receive reply from userspace tool and then drop or > accept packet. Since, ebtables code run in the context > of interrupt's bottom half, I cannot wait inside that > code path. > > To avoid that problem, I would like to create queues > inside ebtables so that I could put that packet into > the queue and start processing the next packet. I can > have other design where I send packets to userspace > and let userspace tool handle the packets. But, I do > not want to cross the user-kernel boundary for each > packet. > > I need help in order to achieve my first design: > > 1) Is my requirement very complex? Can it be achieved > easily? > > 2) What are the parts of ebtables code i should > change? > > 3) In case, userspace tool says accept the packet. How > I would implement the fucntionality of getting old > packets from queue and send them out of the network or > for incoming packets send to higher level protocols? > > 4) Is there any effective way for creating queues > inside ebtables? > > I would really appreciate any help or suggestions in > this regard? You need something similar to the QUEUE target in iptables. In net/netfilter/core.c::nf_hook_slow() nf_queue() is called if the target is queue. That function is in net/netfilter/nf_queue.c and __nf_queue() will call the family specific queue function. For IPv4 this is net/ipv4/netfilter/ip_queue.c::ipq_enqueue_packet() which is registered in net/ipv4/netfilter/ip_queue.c::ip_queue_init(). You will need to make code similar to that in net/ipv4/netfilter/ip_queue.c for PF_BRIDGE instead of PF_INET (put it in net/bridge/netfilter). Hope this helps... Good luck, Bart |
|
From: Abhinav S. <abh...@ya...> - 2007-09-28 20:21:41
|
Hi there,
I have questions regarding the extension of ebtables
code to support target similar to QUEUE target. In my
project, I have a requirement of intercepting packets
inside ebtables and pass some information related to
packet to userspace tool. Ebtables code should wait to
receive reply from userspace tool and then drop or
accept packet. Since, ebtables code run in the context
of interrupt's bottom half, I cannot wait inside that
code path.
To avoid that problem, I would like to create queues
inside ebtables so that I could put that packet into
the queue and start processing the next packet. I can
have other design where I send packets to userspace
and let userspace tool handle the packets. But, I do
not want to cross the user-kernel boundary for each
packet.
I need help in order to achieve my first design:
1) Is my requirement very complex? Can it be achieved
easily?
2) What are the parts of ebtables code i should
change?
3) In case, userspace tool says accept the packet. How
I would implement the fucntionality of getting old
packets from queue and send them out of the network or
for incoming packets send to higher level protocols?
4) Is there any effective way for creating queues
inside ebtables?
I would really appreciate any help or suggestions in
this regard?
Thanks,
Abhinav
Share files, take polls, and discuss your passions - all under one roof. Go to http://in.promos.yahoo.com/groups
|
4 messages has been excluded from this view by a project administrator.
