ebtables to perform MAC NAT ?

ebtables to perform MAC NAT ?

[DEMAINE Benoit-Pierre]

Hello (this is my first post on this list).

I want to use a small PC as Wireless Access-Point. The machine has this 
hardware:
00:07.0 Network controller: Intersil Corporation Prism 2.5 Wavelan 
chipset (rev 01)
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)

The system is Debian with Hostap package.

For a long time, I used to use it only as a NAT bridge, using Iptables 
script. But Iptables implies "one way only request", and two different 
unrouted networks, that are not very practical for users.

I have recently tried to convert the machine to a pure bridge, using 
brctl. It does not work. In fact, it's years I am warned brctl rarely 
works with wifi cards. Still, I think that modern tools can workaround 
the old limits.

What's available now:

br0       Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
           inet addr:192.168.0.203  Bcast:192.168.0.255  Mask:255.255.255.0
           inet6 addr: fe80::209:5bff:fe91:5608/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:1192127 errors:0 dropped:0 overruns:0 frame:0
           TX packets:1094443 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:296603610 (282.8 MiB)  TX bytes:272312079 (259.6 MiB)

br0:1     Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
           inet addr:192.168.0.204  Bcast:192.168.0.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0      Link encap:Ethernet  HWaddr 00:E0:C5:68:F9:6E
           inet6 addr: fe80::2e0:c5ff:fe68:f96e/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:553969 errors:0 dropped:0 overruns:0 frame:0
           TX packets:712094 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:51979425 (49.5 MiB)  TX bytes:270921240 (258.3 MiB)
           Interrupt:10 Base address:0xe000

eth1      Link encap:UNSPEC  HWaddr 
00-09-5B-91-56-08-30-3A-00-00-00-00-00-00-00-00
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:641464 errors:0 dropped:0 overruns:0 frame:0
           TX packets:531774 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:273746227 (261.0 MiB)  TX bytes:63487239 (60.5 MiB)
           Interrupt:11

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:4 errors:0 dropped:0 overruns:0 frame:0
           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:380 (380.0 b)  TX bytes:380 (380.0 b)

wlan0_ren Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
           inet6 addr: fe80::209:5bff:fe91:5608/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:641464 errors:0 dropped:0 overruns:0 frame:0
           TX packets:531774 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:262199875 (250.0 MiB)  TX bytes:59233047 (56.4 MiB)
           Interrupt:11


Gluton:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00095b915608       no              eth0
                                                         wlan0_rename

For obvious reasons, I run this during init:
echo 1 > /proc/sys/net/ipv4/ip_forward

Straight after setting up the bridge, the machine can be accessed by 
both sides, but nothing goes through. When one side (let say host A on 
the ethernet side) tries to ping the other side (let say host B in Wifi 
side), I see this in console:
Gluton:~# tcpdump -veni br0 arp
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 
bytes
07:49:29.152299 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
07:49:30.152305 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
07:49:31.152306 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
07:49:32.828278 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51

After
	 ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
	 --to-source 00:09:5B:91:56:08 --snat-arp ;
I get a bit more messages:

Gluton:~# tcpdump -veni br0 arp
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 
bytes
07:50:33.792127 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
07:50:33.797225 00:11:95:06:ee:3c > 00:09:5b:91:56:08, ethertype ARP 
(0x0806), length 46: arp reply 192.168.0.1 is-at 00:11:95:06:ee:3c
07:50:39.688119 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
07:50:39.693650 00:11:95:06:ee:3c > 00:09:5b:91:56:08, ethertype ARP 
(0x0806), length 46: arp reply 192.168.0.1 is-at 00:11:95:06:ee:3c
07:50:40.688125 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
07:50:40.692909 00:11:95:06:ee:3c > 00:09:5b:91:56:08, ethertype ARP 
(0x0806), length 46: arp reply 192.168.0.1 is-at 00:11:95:06:ee:3c

In both cases, the TX packet counter increases for the Wifi card; the RX 
packet counter increases only in the second case => as said in many 
forums: the Wifi card seems to be unable to send packets with a MAC 
different from it's own.

A=00:d0:b7:0a:4c:d0
G=00:09:5b:91:56:08
B=00:11:95:06:ee:3c

My snat command seems to improve things, since Gluton (G for gateway) 
now receive an answer; but, if i understand correctly, when G receives 
the answer, it is not forwarded to the querying host: A. As consequence, 
A's arp table remains empty: arp -n => "192.168.0.1 (incomplete)" .

So, i tried to force arp answers. After the following:
	ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
	 --to-source 00:09:5B:91:56:08 --snat-arp ; ebtables -t nat -A
	 PREROUTING -p arp -j arpreply --arpreply-mac 00:09:5B:91:56:08
all arp querries are answered, to the MAC of the bridge. As an 
advantage, traffic now goes through; as a problem, Gloton answers even 
for IPs that are not taken by any host of any side; this prevents 
systems to boot (before taking an IP, Windows and Linux make an arp 
who-has, and gluton answers, so, the OS complains the IP is already 
assigned to an other host). After forcing manually, or disconnecting 
Gluton for a few seconds, host can take their IPs.

??? Question: how to tell Gluton to always provide answers to arp 
querries when the host is available, and answer only when IP is not 
located on the same side as the question comes from ? In other words, I 
want Gluton to check if an IP is alive, and, if it is not on the same 
side as the question, it should answer it's own MAC.

Two people said they can use brctl with this MA301. I may not have the 
same firmware as they do. Still, I am certain there is an ebtables 
solution to this problem. I have been thinking about the redirect 
Target, but not sure where my packets goes. Snat obviously NAT correctly 
from A to B question, but not the answer from B to A.

Since IPs could move from one side to an other, I really need something 
dynamic (in the 1s to 10s range); I wondered if the --among-dst-file 
option reads file only when declaring the rule, or if it is read 
periodically from the disk; in the second case, I could periodically 
refresh some tables after a periodical compleet scan ...

NB: i don't mind at all about security; i am only trying to get traffic 
go through, as if it was a cheap AP.

You can assume I did not run any other basic command than "echo 1 > 
/proc/sys/net/ipv4/ip_forward".

I would love this machine to be IPv6 compliant in the coming months, so, 
please, try to avoid things that would limit this feature. But if, as I 
think, the problem is only around ARP, IPv6 should not be a problem 
(but, i may be wrong; there seem to be strange IPv6 specific discovery 
packets).

The whole problem lays in arp tables: if after
	 ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
	 --to-source 00:09:5B:91:56:08 --snat-arp ;
I declare arp tables manually on all hosts, everything works fine.

Thanks.

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Re: ebtables to perform MAC NAT ?

[Grant Taylor]

On 07/21/08 01:09, DEMAINE Benoit-Pierre wrote:
> Hello (this is my first post on this list).

Welcome.

> I want to use a small PC as Wireless Access-Point. The machine has this 
> hardware:
> 00:07.0 Network controller: Intersil Corporation Prism 2.5 Wavelan 
> chipset (rev 01)
> 00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL-8139/8139C/8139C+ (rev 10)
> 
> The system is Debian with Hostap package.

*nod*

> For a long time, I used to use it only as a NAT bridge, using Iptables 
> script. But Iptables implies "one way only request", and two different 
> unrouted networks, that are not very practical for users.

I can tell you from experience the problem is not with bridging or 
brctl.  If there is a problem it will be with one of the devices that is 
being bridged or rather said devices lack of ability to do what is needed.

> I have recently tried to convert the machine to a pure bridge, using 
> brctl. It does not work. In fact, it's years I am warned brctl rarely 
> works with wifi cards. Still, I think that modern tools can workaround 
> the old limits.

I had an Athros chipset based wireless card that I bridged with my eth0 
interface that I used as an AP for many months with out any problems. 
(I migrated away from it b/c there was a nice unused DW1000 (?) at the 
office and I needed to re-purpose the computer.)

> What's available now:
> 
> br0       Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
>           inet addr:192.168.0.203  Bcast:192.168.0.255  Mask:255.255.255.0
>           inet6 addr: fe80::209:5bff:fe91:5608/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> br0:1     Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
>           inet addr:192.168.0.204  Bcast:192.168.0.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> eth0      Link encap:Ethernet  HWaddr 00:E0:C5:68:F9:6E
>           inet6 addr: fe80::2e0:c5ff:fe68:f96e/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> eth1      Link encap:UNSPEC  HWaddr 00-09-5B-91-56-08-30-3A-00-00-00-00-00-00-00-00
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
> 
> wlan0_ren Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
>           inet6 addr: fe80::209:5bff:fe91:5608/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

The only thing I notice right a way is that you do not have a consistent 
binding of IP and IPv6 to your interfaces.  This may be a problem in and 
of its self.  Also, eth1 does not have any thing bound (directly) to it 
at all.

> Gluton:~# brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.00095b915608       no              eth0
>                                                         wlan0_rename

*nod*

> For obvious reasons, I run this during init:
> echo 1 > /proc/sys/net/ipv4/ip_forward

Ok...

> Straight after setting up the bridge, the machine can be accessed by 
> both sides, but nothing goes through. When one side (let say host A on 
> the ethernet side) tries to ping the other side (let say host B in Wifi 
> side), I see this in console:
> Gluton:~# tcpdump -veni br0 arp
> tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 
> bytes
> 
> After
>      ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
>      --to-source 00:09:5B:91:56:08 --snat-arp ;
> I get a bit more messages:
> 
> Gluton:~# tcpdump -veni br0 arp
> tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 
> bytes
> 
> In both cases, the TX packet counter increases for the Wifi card; the RX 
> packet counter increases only in the second case => as said in many 
> forums: the Wifi card seems to be unable to send packets with a MAC 
> different from it's own.

This sounds more like your wireless card can't properly go in to 
promiscuous mode like I'm accustom to seeing.

> My snat command seems to improve things, since Gluton (G for gateway) 
> now receive an answer; but, if i understand correctly, when G receives 
> the answer, it is not forwarded to the querying host: A. As consequence, 
> A's arp table remains empty: arp -n => "192.168.0.1 (incomplete)" .

*nod*

This is because the ARP reply is coming back to (destination MAC of) G. 
  G is not passing the ARP reply on like it possibly should.

> So, i tried to force arp answers. After the following:
>     ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
>      --to-source 00:09:5B:91:56:08 --snat-arp ; ebtables -t nat -A
>      PREROUTING -p arp -j arpreply --arpreply-mac 00:09:5B:91:56:08
> all arp querries are answered, to the MAC of the bridge. As an 
> advantage, traffic now goes through; as a problem, Gloton answers even 
> for IPs that are not taken by any host of any side; this prevents 
> systems to boot (before taking an IP, Windows and Linux make an arp 
> who-has, and gluton answers, so, the OS complains the IP is already 
> assigned to an other host). After forcing manually, or disconnecting 
> Gluton for a few seconds, host can take their IPs.

*nod*

You have now put something in place that functions much like (or at 
least my understanding of) Proxy ARP.

> ??? Question: how to tell Gluton to always provide answers to arp 
> querries when the host is available, and answer only when IP is not 
> located on the same side as the question comes from ? In other words, I 
> want Gluton to check if an IP is alive, and, if it is not on the same 
> side as the question, it should answer it's own MAC.

Now you are wanting EBTables / IPTables to act conditionally based on 
the state of something out side of the system they are running on.  To 
pull this off you will probably have to drop out of the kernel in to 
user space and have something monitor your target MACs.

> Two people said they can use brctl with this MA301. I may not have the 
> same firmware as they do. Still, I am certain there is an ebtables 
> solution to this problem. I have been thinking about the redirect 
> Target, but not sure where my packets goes. Snat obviously NAT correctly 
> from A to B question, but not the answer from B to A.

I'm sure you could do something with a series of MAC mappings, but 
(IMHO) that is just nasty.  I.e. any ethernet frames with a target MAC 
addresses that are on the other side of the bridge would have their 
source MAC address changed to that of the opposing interface in the bridge.

> Since IPs could move from one side to an other, I really need something 
> dynamic (in the 1s to 10s range); I wondered if the --among-dst-file 
> option reads file only when declaring the rule, or if it is read 
> periodically from the disk; in the second case, I could periodically 
> refresh some tables after a periodical compleet scan ...

I would think that your wireless MACs would always be on the wireless 
side of the bridge regardless of what IP they may have.  So you may be 
able to get away NATing the MAC address.  However this will get very nasty.

Let me do some thinking about how to make this happen in something even 
remotely reasonable.  (I.e. how to do what is usually a layer 3 
operation on layer 2 with the same layer 3 addresses on both side of the 
bridge.)

> NB: i don't mind at all about security; i am only trying to get traffic 
> go through, as if it was a cheap AP.

*nod*

> You can assume I did not run any other basic command than "echo 1 > 
> /proc/sys/net/ipv4/ip_forward".

'k

> I would love this machine to be IPv6 compliant in the coming months, so, 
> please, try to avoid things that would limit this feature. But if, as I 
> think, the problem is only around ARP, IPv6 should not be a problem 
> (but, i may be wrong; there seem to be strange IPv6 specific discovery 
> packets).

*nod*

> The whole problem lays in arp tables: if after
>      ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
>      --to-source 00:09:5B:91:56:08 --snat-arp ;
> I declare arp tables manually on all hosts, everything works fine.

Hum...



Grant. . . .

Re: ebtables to perform MAC NAT ?

[DEMAINE Benoit-Pierre]

(Grant sorry for double, I forgot to change the To: field)

Grant Taylor wrote:
> I can tell you from experience the problem is not with bridging or 
> brctl.  If there is a problem it will be with one of the devices that is 
> being bridged or rather said devices lack of ability to do what is needed.

As mentioned, i know the problem is 99% likely to be due to the MA301.

> I had an Athros chipset based wireless card that I bridged with my eth0 
> interface that I used as an AP for many months with out any problems. (I 
> migrated away from it b/c there was a nice unused DW1000 (?) at the 
> office and I needed to re-purpose the computer.)

Do all atheros chipsets work fine ? maybe I could buy one for cheap ?

> The only thing I notice right a way is that you do not have a consistent 
> binding of IP and IPv6 to your interfaces.  This may be a problem in and 
> of its self.  Also, eth1 does not have any thing bound (directly) to it 
> at all.

I dont really know what eth1 is; hostap always produce two interfaces
per NIC; never understood the real difference, but in my case, i know i
shall iwconfig/ifconfig on wlan0_rename. eth1 and wlan0_rename are both
the same NIC, managed by hostap (see how the MAC is very similar). Thus,
it is normal you think eth1 is unconnected (maybe you would have
understand if you better knew hostap, or if I joined iwconfig).

IPv6 is not today's problem.

> This sounds more like your wireless card can't properly go in to 
> promiscuous mode like I'm accustom to seeing.

It's what i have been said years ago; that's why 3y ago, when brctl
failed, i did not spend more than 10 minutes testing it, and moved *at
once* to (IP) NAT. And, IMHO, my tests confirm it again. So, the point
of this thread is to "workaround" this :)

> This is because the ARP reply is coming back to (destination MAC of) G. 
>  G is not passing the ARP reply on like it possibly should.

Yup, see question further :)

> You have now put something in place that functions much like (or at 
> least my understanding of) Proxy ARP.

Yup, kinda works. But, does not work "well". I dont know enough about
ARP, frames, bridging and so to dig further by myself, thus, coming to
chat. It works with very bad side effects.

>> ??? Question: how to tell Gluton to always provide answers to arp 
>> querries when the host is available, and answer only when IP is not 
>> located on the same side as the question comes from ? In other words, 
>> I want Gluton to check if an IP is alive, and, if it is not on the 
>> same side as the question, it should answer it's own MAC.
> 
> Now you are wanting EBTables / IPTables to act conditionally based on 
> the state of something out side of the system they are running on.  To 
> pull this off you will probably have to drop out of the kernel in to 
> user space and have something monitor your target MACs.

No, I simply want to solve my side effect. I have exposed the
limitations of the machine (try to keep hardware, that MA301 seems to
not enjoy brctl), and exposed some tests I did. Before the question I
exposed what I did, and know for sure. After, I exposed what I think, or
could do.

Maybe there is a magical ebtables option I did not remark, or a friend
tool specially dedicated to help brctl in this kind of configurations.
Many people bought MA301, so, I really hope this case have been met by
many people, and hopefully, some solved it.

> I'm sure you could do something with a series of MAC mappings, but 
> (IMHO) that is just nasty.  I.e. any ethernet frames with a target MAC 
> addresses that are on the other side of the bridge would have their 
> source MAC address changed to that of the opposing interface in the bridge.

I can remove the bridge if it can help. All I want is to remove the
IP-NAT thing, so that my network get unified => transform the machine
into a real transparent bridge, at least at the IP point of view. But,
if I remove brctl bridging, I will need to recreate an other way (or the
apckets will never go through ^^ ).

Facts are: I want bridging to gain homogeneous/unified network, but
MA301 is not bridge friendly.

>> The whole problem lays in arp tables: if after
>>      ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
>>      --to-source 00:09:5B:91:56:08 --snat-arp ;
>> I declare arp tables manually on all hosts, everything works fine.
> 
> Hum...

This is a very important point to me, because it shows that it's only an
ARP problem, and that brctl really helps a lot (it does actually forward
packets from side to side). But, messing up arp tables is something
really messy. I am surprised that this simple command does not work "as
well" as it's iptables equivalent: the iptablei NAT does NAT for both
questions and answers; I wonder why ...

In fact, I wonder if there could be two bugs in brctl:
- answer not coming back through
- bug in --snat-arp

I did not detailed this point in my first post, but after the simple
snat thing, host B get A's MAC in his ARP tables. Considering this
point, plus tcpdumps just means: my ebtables rule does forward the
question, but the question still contains A's MAC even when using
--snat-arp (that should IMHO work "inside" the question). I can send
details on this if you want within 24h. I would need to move two
machines in the network to do that.

I wondered if brctl was bothered by the fact the answer comes back with
it's own MAC as destination; once ARP tables are declared, all works
fine, maybe because of IP routing tables; ARP queries seem to be more in
trouble.

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Re: ebtables to perform MAC NAT ?

[Grant Taylor]

> (Grant sorry for double, I forgot to change the To: field)

No problem.  Someone (possibly me?) needs to suggest that the mailing 
list be tweaked to direct replies directly to it rather than the sender 
of the message being replied to.

On 07/21/08 10:58, DEMAINE Benoit-Pierre wrote:
> As mentioned, i know the problem is 99% likely to be due to the 
> MA311.

*nod*

> Do all atheros chipsets work fine ? maybe I could buy one for cheap ?

I don't know what chipsets work, take a look at the web page(s) for the 
Atheros chipsets under Linux, namely the MADWiFi driver.

> I dont really know what eth1 is; hostap always produce two interfaces 
> per NIC; never understood the real difference, but in my case, i know 
> i shall iwconfig/ifconfig on wlan0_rename. eth1 and wlan0_rename are 
> both the same NIC, managed by hostap (see how the MAC is very 
> similar). Thus, it is normal you think eth1 is unconnected (maybe you 
> would have understand if you better knew hostap, or if I joined 
> iwconfig).

*nod*

I have looked at HostAP but never messed with it.  I've always been able 
to do what I needed with iwconfig, ifconfig, and brctl.  Though if I 
recall, HostAP was needed if I wanted to do more than basic AP, i.e. 
going an infrastructure and / or use any thing like 802.1x.

> IPv6 is not today's problem.

*nod*  I was more concerned about the fact that IP(v4) was not bound to 
the interfaces that it needed to be bound to.

> It's what i have been said years ago; that's why 3y ago, when brctl 
> failed, i did not spend more than 10 minutes testing it, and moved 
> *at once* to (IP) NAT. And, IMHO, my tests confirm it again. So, the 
> point of this thread is to "workaround" this :)

*nod*

Is there a reason you did not look in to standard routing verses NAT?  I 
would think it would be trivial to get your workstations to connect 
through your system as a router?  Though, depending on what your 
internet router is, you may not be able to tell it that there is another 
subnet behind the system (Gluton) acting as the AP / Router.

> Yup, see question further :)

*nod*

> Yup, kinda works. But, does not work "well". I dont know enough about 
> ARP, frames, bridging and so to dig further by myself, thus, coming 
> to chat. It works with very bad side effects.

First, let's start with terminology.  Here's what things are called and 
the layer they are used on.

Data is what you are sending.

TCP send datagrams.  A datagram consist of a header with source and 
destination ports and the data to be sent.

IP sends packets.  A packet consist of a header with source and 
destination IP addresses and the TCP datagram to be sent.

EthernetEtherent sends frames.  A frame consist of a header with source 
and destination MAC addresses and the IP packet to be sent.

ARP uses special ethernet frames.  The ARP frame consists of source 
hardware address, source protocol address, target hardware address, and 
target protocol address.

(Remember that ARP is only used to find the hardware address of a device 
that is with in the local subnet.  If the device is not, then the router 
will be used.)

Proxy ARP (to the best of my knowledge) is a way for a two devices on 
separate non-connected networks to communicate with each other.  If the 
device being ARPed is in the same subnet but in another non-connected 
network one (or more) routers can be configured to Proxy ARP for it.  In 
this case a client will send an ARP requestreqeust for the target 
device, to which the router doing the Proxy ARP will respond with its 
own MAC address.  Thus the client sending the ARP request will have an 
answer and a target MAC address to send the traffic to.

When the client does send its traffic, it will do so with an ethernet 
frame with its own MAC as the source address and the router's MAC 
address as the destination address with an IP packet with the expected 
source and destination IP addresses.  The router doing the Proxy ARPing 
will then receive this packet and alter the source and destination MAC 
addresses and send a new ethernet frame on out to the next network 
segment containing an unmodified IP packet.

> No, I simply want to solve my side effect. I have exposed the 
> limitations of the machine (try to keep hardware, that MA311 seems to 
> not enjoy brctl), and exposed some tests I did. Before the question I 
> exposed what I did, and know for sure. After, I exposed what I think, 
> or could do.

'k  (I think.)

> Maybe there is a magical ebtables option I did not remark, or a 
> friend tool specially dedicated to help brctl in this kind of 
> configurations. Many people bought MA311, so, I really hope this case 
> have been met by many people, and hopefully, some solved it.

Faulty hardware is usually extremely tough to get around.

Seeing as how I believe the problem to be with the MA301 and bridging 
with its needed promiscuouspromiscious mode, I think you will have 
better luck with Proxy ARP.  With Proxy ARP all ethernet frames will be 
directly to the raw ethernet or MA301 MAC address.

I'm betting that Proxy ARP will also play a little nicer with some other 
things than having EBTables automatically reply to ARPs.  At least I'm 
hoping that Proxy ARP will try to take target device state in to account.

> I can remove the bridge if it can help. All I want is to remove the 
> IP-NAT thing, so that my network get unified => transform the machine 
> into a real transparent bridge, at least at the IP point of view. 
> But, if I remove brctl bridging, I will need to recreate an other way 
> (or the apckets will never go through ^^ ).

*nod*

Why not just use standard routing?

> Facts are: I want bridging to gain homogeneous/unified network, but 
> MA311 is not bridge friendly.

*nod*

> This is a very important point to me, because it shows that it's only 
> an ARP problem, and that brctl really helps a lot (it does actually 
> forward packets from side to side). But, messing up arp tables is 
> something really messy. I am surprised that this simple command does 
> not work "as well" as it's iptables equivalent: the iptablei NAT does 
> NAT for both questions and answers; I wonder why ...

Eh, IPTables goes a littlelitte further than it possibly should by 
providing the unNATing that it does.  However 99+% of the time this is 
desired so it is ok.

> In fact, I wonder if there could be two bugs in brctl:

Keep in mind that the ""problem is not with the brctl command (read: 
binary file).  Brctl is just the user space utility to adjust bridging 
in the kernel, much like IPTables is the user space utility to adjust 
firewalling in the kernel.

Also, this is not a problem with bridging so much as it is a problem 
with the MA311 ethernet device.  If you were using a different ethernet 
device we would not be having this discussion.

> - answer not coming back through

The answers do not come back through because you have altered the 
destination of the ARP reply (source of the modified ARP requestreqeust) 
to be the MAC address of the MA3111.  So by all rights bridging is not 
suppose to pass the ARP reply on.

> - bug in --snat-arp

No, I don't think so.  SNAT is doing what it is suppose to.  At least in 
so far as modifying the "source hardwarehardare address" with in the ARP 
request packet.  (You would probably want to modify the source MAC 
address of the ethernet frame carryingcarying the ARP requestreqeust too.)

In effect you are wanting a way to pass the ARP reply on to the internal 
system that initiated the original ARP request.  This is more of a 
stateful operation verses the stateless operation that the majority of 
this operatesopeates on.

> I did not detailed this point in my first post, but after the simple 
> snat thing, host B get A's MAC in his ARP tables. Considering this 
> point, plus tcpdumps just means: my ebtables rule does forward the 
> question, but the question still contains A's MAC even when using 
> --snat-arp (that should IMHO work "inside" the question). I can send 
> details on this if you want within 24h. I would need to move two 
> machines in the network to do that.

No, don't go to that trouble.  Do some reading on Proxy ARP first.

> I wondered if brctl was bothered by the fact the answer comes back 
> with it's own MAC as destination; once ARP tables are declared, all 
> works fine, maybe because of IP routing tables; ARP queries seem to 
> be more in trouble.

I don't think that the bridging portion of the kernel even considered 
passing the packet out the bridge because the destination MAC of the 
frame was to the bridge its self, not another system on the other side 
of the bridge.

Do some reading on Proxy ARP in the LARTC documentation:  Pseudo-bridges 
with Proxy-ARP (http://lartc.org/howto/lartc.bridging.proxy-arp.html)



Grant. . . .

Re: ebtables to perform MAC NAT ?

[DEMAINE Benoit-Pierre]

Grant Taylor wrote:
>> (Grant sorry for double, I forgot to change the To: field)
> 
> No problem.  Someone (possibly me?) needs to suggest that the mailing 
> list be tweaked to direct replies directly to it rather than the sender 
> of the message being replied to.

Adding a reply to is usually enough.

>> IPv6 is not today's problem.
> 
> *nod*  I was more concerned about the fact that IP(v4) was not bound to 
> the interfaces that it needed to be bound to.

Yup, hostap things made mess in your head; the only way for me to
understand which interface to use is to look at the MAC length: a long
MAC like the eth1's would never fit any network (802.3 or 802.11 :) ).
The only place where I have seen long MACs like this is ethernet over
FireWire.

>> It's what i have been said years ago; that's why 3y ago, when brctl 
>> failed, i did not spend more than 10 minutes testing it, and moved *at 
>> once* to (IP) NAT. And, IMHO, my tests confirm it again. So, the point 
>> of this thread is to "workaround" this :)
> 
> *nod*
> 
> Is there a reason you did not look in to standard routing verses NAT?  I 
> would think it would be trivial to get your workstations to connect 
> through your system as a router?  Though, depending on what your 
> internet router is, you may not be able to tell it that there is another 
> subnet behind the system (Gluton) acting as the AP / Router.

Yes: because i know what i would imply. Imagine a world where my house
would have 5 machines like Gluton; there would be at least a base
network/mask for the "root", and a different network/mask per zone
behind each machine; each bridge would be easier, cause they would be
simple routers; but this would require long routing tables. If a machine
in the middle zone wanted to be able to talk to any machine, it would
require to have a default net, a default gate, plus 4 local gates. It
easy to do manually for any good UNIX admin; it's way more difficult to
implement when you want to use a hardware DHCP and deliver zones to
Windows (i would not even be able to declare routes and gates in a Home
Windows).

=> to keep things simple, let me have a single homogeneous network.
Every one in the same network (yes there will be broadcasting problems;
in fact, i am already having ARP broadcast problems :) it's even the
only problem i have left to fix :D )

I could also buy hardware repeaters (like WDS machines), but they cost
130 euro each, and I got enough hardware to do it myself, so, let's try
the soft way before buying more stuff.

> First, let's start with terminology.  Here's what things are called and 
> the layer they are used on.

Thanks for the lecture :) I had computing lectures in my french, and,
math and electronic lectures in english, so, things are a bit mixed in
my head :) Words are important ... except you did not really specify the
layers :) nm

> Proxy ARP (to the best of my knowledge) is a way for a two devices on 
> separate non-connected networks to communicate with each other. 

Some people mentioned proxyarp, but i did not found so called package in
Debian or Gentoo; maybe the package has an other name ? as long as it
can help brctl to bridge correctly ... I am open minded.

> If the 
> device being ARPed is in the same subnet but in another non-connected 
> network one (or more) routers can be configured to Proxy ARP for it.  In 
> this case a client will send an ARP requestreqeust for the target 
> device, to which the router doing the Proxy ARP will respond with its 
> own MAC address.  Thus the client sending the ARP request will have an 
> answer and a target MAC address to send the traffic to.

ok

> When the client does send its traffic, it will do so with an ethernet 
> frame with its own MAC as the source address and the router's MAC 
> address as the destination address with an IP packet with the expected 
> source and destination IP addresses.  The router doing the Proxy ARPing 
> will then receive this packet and alter the source and destination MAC 
> addresses and send a new ethernet frame on out to the next network 
> segment containing an unmodified IP packet.

Yup, all known, and works already this way when i do as said in my first
post:
> The whole problem lays in arp tables: if after
>      ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
>      --to-source 00:09:5B:91:56:08 --snat-arp ;
> I declare arp tables manually on all hosts, everything works fine. 

>> Maybe there is a magical ebtables option I did not remark, or a friend 
>> tool specially dedicated to help brctl in this kind of configurations. 
>> Many people bought MA311, so, I really hope this case have been met by 
>> many people, and hopefully, some solved it.
> 
> Faulty hardware is usually extremely tough to get around.

If we cant do it using ebtable/netfilter/proxyarp ... either I have to
revert IP-NAT, or buy an Atheros, or buy a Fonera or Linksys ...

> 
> Seeing as how I believe the problem to be with the MA301 and bridging 
> with its needed promiscuouspromiscious mode, I think you will have 
> better luck with Proxy ARP.  With Proxy ARP all ethernet frames will be 
> directly to the raw ethernet or MA301 MAC address.

What's the package name in distributions ?
or, do I have to install it manually ?

> Why not just use standard routing?

See higher: to day, I am *trying* to get unified network.

> Keep in mind that the ""problem is not with the brctl command (read: 
> binary file).  Brctl is just the user space utility to adjust bridging 
> in the kernel, much like IPTables is the user space utility to adjust 
> firewalling in the kernel.
> 
> Also, this is not a problem with bridging so much as it is a problem 
> with the MA311 ethernet device.  If you were using a different ethernet 
> device we would not be having this discussion.

Could things be different if I did stuff in PREROUTING ? maybe there is
a way to do things in the PREROUTING place, a way that would look like
an ARP proxy ... ?

>> - answer not coming back through
> 
> The answers do not come back through because you have altered the 
> destination of the ARP reply (source of the modified ARP requestreqeust) 
> to be the MAC address of the MA3111.  So by all rights bridging is not 
> suppose to pass the ARP reply on.

In IPtables NAT, the answers comes back with the gateway IP address as
destination, and then, the gateway rebuilds a packet with the LAN IP a
new destination. This is what I was expecting ebtables would do with
MACs when providing --snat-arp.

Maybe there is a workaround, still in rperouting: imagine we record the
... "frame" number sequence, and other parameters at the moment we do
SNAT; if we can predict what the answer should look like (sequence
number should be the same IMHO, but with a frame number incremented),
then we can identify the answer coming in, and then ... do DNAT in
PREROUTING ? we need to identfy whether an answer is coming back for
Gluton itself, or for a machine it is NATing ...

>> - bug in --snat-arp
> 
> No, I don't think so.  SNAT is doing what it is suppose to.  At least in 
> so far as modifying the "source hardwarehardare address" with in the ARP 
> request packet.  (You would probably want to modify the source MAC 
> address of the ethernet frame carryingcarying the ARP requestreqeust too.)

Maybe; that's the point where I say: I dont know enough about networking
to know what frames should look like, and the tools to check what they
actually look like :)

> In effect you are wanting a way to pass the ARP reply on to the internal 
> system that initiated the original ARP request.  This is more of a 
> stateful operation verses the stateless operation that the majority of 
> this operatesopeates on.

Like Iptables NAT would do.

>> I did not detailed this point in my first post, but after the simple 
>> snat thing, host B get A's MAC in his ARP tables. Considering this 
>> point, plus tcpdumps just means: my ebtables rule does forward the 
>> question, but the question still contains A's MAC even when using 
>> --snat-arp (that should IMHO work "inside" the question). I can send 
>> details on this if you want within 24h. I would need to move two 
>> machines in the network to do that.
> 
> No, don't go to that trouble.  Do some reading on Proxy ARP first.
> 
>> I wondered if brctl was bothered by the fact the answer comes back 
>> with it's own MAC as destination; once ARP tables are declared, all 
>> works fine, maybe because of IP routing tables; ARP queries seem to be 
>> more in trouble.
> 
> I don't think that the bridging portion of the kernel even considered 
> passing the packet out the bridge because the destination MAC of the 
> frame was to the bridge its self, not another system on the other side 
> of the bridge.

It's normal the broadcast goes through: it has destination different
than local MAC; that's why I think, if we change the destination of the
answer in PREROUTING, the answer should be routed back to the one who
asked the question :)

But if proxyarp already does that ... => how is it called in debian ?

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Re: ebtables to perform MAC NAT ?

[Oscar N]

Hi!

I looked into "MAC NAT" 1-2 years ago and actually got it to work, but it
included some nasty changes to how linux process arp. I therefor solved
the problem I had another way. The feature is still on the todolist on
ebtables: http://ebtables.sourceforge.net/documentation.html#todo

Anyway, this is some notes I had from back then if it's useful for someone:

There are at least 4 scenarios that need to work.
DNAT and SNAT are referring to NAT done in ebtables.

                                                   1.1.1.2 Client A
Gateway 1.1.1.1 ------------ eth0_Bridge_eth1 ---- 1.1.1.3 Client B
                                                   1.1.1.4 Client C

1. Client 1.1.1.2 broadcasts arp request for ip 1.1.1.1
Bridge should send an arp reply to the client with the mac of eth1.
Bridge should not broadcast the packet out eth0.


2. Gateway broadcasts arp request for ip 1.1.1.2
Bridge should forward the broadcast to all clients.
Client 1.1.1.2 answers with an arp reply.
Bridge should SNAT the reply with mac of eth0 before sending it to gateway.


3. Client 1.1.1.2 sends data to gateway 1.1.1.1
Bridge should SNAT packets with mac of eth0 before sending it to gateway.


4. Gateway 1.1.1.1 sends data to client 1.1.1.2
Bridge should DNAT the packets with mac of eth0.
Bridge will look in routingtable and send it out bridge interface again.
This causes bridge to broadcast an arp request if it needs to.
Bridge then send packets to client.

/Regards Oscar

> Hello (this is my first post on this list).
>
> I want to use a small PC as Wireless Access-Point. The machine has this
> hardware:
> 00:07.0 Network controller: Intersil Corporation Prism 2.5 Wavelan
> chipset (rev 01)
> 00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
>
> The system is Debian with Hostap package.
>
> For a long time, I used to use it only as a NAT bridge, using Iptables
> script. But Iptables implies "one way only request", and two different
> unrouted networks, that are not very practical for users.
>
> I have recently tried to convert the machine to a pure bridge, using
> brctl. It does not work. In fact, it's years I am warned brctl rarely
> works with wifi cards. Still, I think that modern tools can workaround
> the old limits.
>
> What's available now:
>
> br0       Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
>            inet addr:192.168.0.203  Bcast:192.168.0.255
> Mask:255.255.255.0
>            inet6 addr: fe80::209:5bff:fe91:5608/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:1192127 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:1094443 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:296603610 (282.8 MiB)  TX bytes:272312079 (259.6 MiB)
>
> br0:1     Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
>            inet addr:192.168.0.204  Bcast:192.168.0.255
> Mask:255.255.255.0
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>
> eth0      Link encap:Ethernet  HWaddr 00:E0:C5:68:F9:6E
>            inet6 addr: fe80::2e0:c5ff:fe68:f96e/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:553969 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:712094 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:51979425 (49.5 MiB)  TX bytes:270921240 (258.3 MiB)
>            Interrupt:10 Base address:0xe000
>
> eth1      Link encap:UNSPEC  HWaddr
> 00-09-5B-91-56-08-30-3A-00-00-00-00-00-00-00-00
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:641464 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:531774 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:273746227 (261.0 MiB)  TX bytes:63487239 (60.5 MiB)
>            Interrupt:11
>
> lo        Link encap:Local Loopback
>            inet addr:127.0.0.1  Mask:255.0.0.0
>            inet6 addr: ::1/128 Scope:Host
>            UP LOOPBACK RUNNING  MTU:16436  Metric:1
>            RX packets:4 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:380 (380.0 b)  TX bytes:380 (380.0 b)
>
> wlan0_ren Link encap:Ethernet  HWaddr 00:09:5B:91:56:08
>            inet6 addr: fe80::209:5bff:fe91:5608/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:641464 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:531774 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:262199875 (250.0 MiB)  TX bytes:59233047 (56.4 MiB)
>            Interrupt:11
>
>
> Gluton:~# brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.00095b915608       no              eth0
>                                                          wlan0_rename
>
> For obvious reasons, I run this during init:
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> Straight after setting up the bridge, the machine can be accessed by
> both sides, but nothing goes through. When one side (let say host A on
> the ethernet side) tries to ping the other side (let say host B in Wifi
> side), I see this in console:
> Gluton:~# tcpdump -veni br0 arp
> tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 07:49:29.152299 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
> 07:49:30.152305 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
> 07:49:31.152306 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
> 07:49:32.828278 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
>
> After
> 	 ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
> 	 --to-source 00:09:5B:91:56:08 --snat-arp ;
> I get a bit more messages:
>
> Gluton:~# tcpdump -veni br0 arp
> tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 07:50:33.792127 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
> 07:50:33.797225 00:11:95:06:ee:3c > 00:09:5b:91:56:08, ethertype ARP
> (0x0806), length 46: arp reply 192.168.0.1 is-at 00:11:95:06:ee:3c
> 07:50:39.688119 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
> 07:50:39.693650 00:11:95:06:ee:3c > 00:09:5b:91:56:08, ethertype ARP
> (0x0806), length 46: arp reply 192.168.0.1 is-at 00:11:95:06:ee:3c
> 07:50:40.688125 00:d0:b7:0a:4c:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.51
> 07:50:40.692909 00:11:95:06:ee:3c > 00:09:5b:91:56:08, ethertype ARP
> (0x0806), length 46: arp reply 192.168.0.1 is-at 00:11:95:06:ee:3c
>
> In both cases, the TX packet counter increases for the Wifi card; the RX
> packet counter increases only in the second case => as said in many
> forums: the Wifi card seems to be unable to send packets with a MAC
> different from it's own.
>
> A=00:d0:b7:0a:4c:d0
> G=00:09:5b:91:56:08
> B=00:11:95:06:ee:3c
>
> My snat command seems to improve things, since Gluton (G for gateway)
> now receive an answer; but, if i understand correctly, when G receives
> the answer, it is not forwarded to the querying host: A. As consequence,
> A's arp table remains empty: arp -n => "192.168.0.1 (incomplete)" .
>
> So, i tried to force arp answers. After the following:
> 	ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
> 	 --to-source 00:09:5B:91:56:08 --snat-arp ; ebtables -t nat -A
> 	 PREROUTING -p arp -j arpreply --arpreply-mac 00:09:5B:91:56:08
> all arp querries are answered, to the MAC of the bridge. As an
> advantage, traffic now goes through; as a problem, Gloton answers even
> for IPs that are not taken by any host of any side; this prevents
> systems to boot (before taking an IP, Windows and Linux make an arp
> who-has, and gluton answers, so, the OS complains the IP is already
> assigned to an other host). After forcing manually, or disconnecting
> Gluton for a few seconds, host can take their IPs.
>
> ??? Question: how to tell Gluton to always provide answers to arp
> querries when the host is available, and answer only when IP is not
> located on the same side as the question comes from ? In other words, I
> want Gluton to check if an IP is alive, and, if it is not on the same
> side as the question, it should answer it's own MAC.
>
> Two people said they can use brctl with this MA301. I may not have the
> same firmware as they do. Still, I am certain there is an ebtables
> solution to this problem. I have been thinking about the redirect
> Target, but not sure where my packets goes. Snat obviously NAT correctly
> from A to B question, but not the answer from B to A.
>
> Since IPs could move from one side to an other, I really need something
> dynamic (in the 1s to 10s range); I wondered if the --among-dst-file
> option reads file only when declaring the rule, or if it is read
> periodically from the disk; in the second case, I could periodically
> refresh some tables after a periodical compleet scan ...
>
> NB: i don't mind at all about security; i am only trying to get traffic
> go through, as if it was a cheap AP.
>
> You can assume I did not run any other basic command than "echo 1 >
> /proc/sys/net/ipv4/ip_forward".
>
> I would love this machine to be IPv6 compliant in the coming months, so,
> please, try to avoid things that would limit this feature. But if, as I
> think, the problem is only around ARP, IPv6 should not be a problem
> (but, i may be wrong; there seem to be strange IPv6 specific discovery
> packets).
>
> The whole problem lays in arp tables: if after
> 	 ebtables -t nat -F ; ebtables -t nat -A POSTROUTING -j snat
> 	 --to-source 00:09:5B:91:56:08 --snat-arp ;
> I declare arp tables manually on all hosts, everything works fine.
>
> Thanks.
>
> --
>   >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
> If computing were an exact science, IT engineers would not have work \_o<
>
> "So all that's left, Is the proof that love's not only blind but deaf."
> (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ebtables to perform MAC NAT ?

[DEMAINE Benoit-Pierre]

Oscar N wrote:
> Hi!
> 
> I looked into "MAC NAT" 1-2 years ago and actually got it to work, but it
> included some nasty changes to how linux process arp. I therefor solved
> the problem I had another way. The feature is still on the todolist on
> ebtables: http://ebtables.sourceforge.net/documentation.html#todo
> 
> Anyway, this is some notes I had from back then if it's useful for someone:
> 
> There are at least 4 scenarios that need to work.
> DNAT and SNAT are referring to NAT done in ebtables.

*at least* ... as example, you forgpt the case where 1.1.1.2 wants to 
talk with 1.1.1.3 (case where broadcast is sent everywhere for 
discovery, unless ... )

But, you rougly understood how complex my problem is, from ARP point of 
view. I will have a look at your website.

***

after installing parprouted on Debian, from man parprouted:

> DESCRIPTION
>        parprouted is a daemon for transparent IP (Layer 3) proxy ARP bridging.
>        Unlike standard bridging, proxy ARP bridging allows to bridge Ethernet
>        networks behind wireless nodes. Normal L2 bridging does not work
>        between wireless nodes because wireless does not know about MAC
>        addresses used in the wired Ethernet networks. Also this daemon is use
>        ful for making transparent firewalls.

says long about my problem :)

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Re: ebtables to perform MAC NAT ?

[Grant Taylor]

On 07/21/08 18:09, DEMAINE Benoit-Pierre wrote:
> Adding a reply to is usually enough.

So long as you know that you need to do it and remember to do it, I'll 
agree.  However I specialize in making things easier for end users and 
IMHO they should not have to know that they have to much less remember 
that they have to.

> Yup, hostap things made mess in your head; the only way for me to 
> understand which interface to use is to look at the MAC length: a 
> long MAC like the eth1's would never fit any network (802.3 or 802.11 
> :) ). The only place where I have seen long MACs like this is 
> ethernet over FireWire.

I've not payed much attention to the MAC length.  I usually do very 
little with MAC addresses.  Well at least not as long as I'm not doing 
special things (read layer 3 and layer 2 firewalling on bridging VLAN 
interfaces off of a trunked bond interface that has two or more physical 
ethernet ports).

> Yes: because i know what i would imply. Imagine a world where my 
> house would have 5 machines like Gluton; there would be at least a 
> base network/mask for the "root", and a different network/mask per 
> zone behind each machine; each bridge would be easier, cause they 
> would be simple routers; but this would require long routing tables. 
> If a machine in the middle zone wanted to be able to talk to any 
> machine, it would require to have a default net, a default gate, plus 
> 4 local gates. It easy to do manually for any good UNIX admin; it's 
> way more difficult to implement when you want to use a hardware DHCP 
> and deliver zones to Windows (i would not even be able to declare 
> routes and gates in a Home Windows).

Heh.  Sounds like your home network is more of a daisy chain of 
computers with multiple network cars in them or something else equally 
as strange.

You can add persistent routes to Windows via the route command.  Though 
I'm not sure how well those will play with DHCP.

> => to keep things simple, let me have a single homogeneous network. 
> Every one in the same network (yes there will be broadcasting 
> problems; in fact, i am already having ARP broadcast problems :) it's 
> even the only problem i have left to fix :D )

*nod*

> I could also buy hardware repeaters (like WDS machines), but they 
> cost 130 euro each, and I got enough hardware to do it myself, so, 
> let's try the soft way before buying more stuff.

*nod*

> Thanks for the lecture :) I had computing lectures in my french, and, 
> math and electronic lectures in english, so, things are a bit mixed 
> in my head :) Words are important ... except you did not really 
> specify the layers :) nm

Heh.  I was trying to make things simpler.  The IP network model is four 
layers where as the OSI network model is 7 and there is not really a 
good mesh between the two.  Here's a quick run down for you though.

IP          data name   OSI
app         (other)     session (5) / presentation (6) / app (7)
transport   datagram    transport (4)
internet    packet      network (3)
link        frame       physical (1) / data (2)

These are rough correlations, which can and will be argued.

> Some people mentioned proxyarp, but i did not found so called package 
> in Debian or Gentoo; maybe the package has an other name ? as long as 
> it can help brctl to bridge correctly ... I am open minded.

That's because it's not a package per say.  Proxy ARP is a feature of 
the kernel that has to be enabled, much like routing and IP forwarding.

Rather than me re-typing how to do it, take a look at the write up about 
it in the Linux Advanced Routing and Traffic Control HowTo - 
Pseudo-bridges with Proxy-ARP 
(http://lartc.org/howto/lartc.bridging.proxy-arp.html).

> Yup, all known, and works already this way when i do as said in my 
> first post:

*nod*

> If we cant do it using ebtable/netfilter/proxyarp ... either I have 
> to revert IP-NAT, or buy an Atheros, or buy a Fonera or Linksys ...

If the root of the problem is that the MA311 can not send using MAC 
addresses other than its own, I think Proxy ARP will work just fine.

> What's the package name in distributions ? or, do I have to install 
> it manually ?

(See above.)

> See higher: to day, I am *trying* to get unified network.

*nod*

> Could things be different if I did stuff in PREROUTING ? maybe there 
> is a way to do things in the PREROUTING place, a way that would look 
> like an ARP proxy ... ?

I don't think so, or at least not much so.  You will still have to deal 
with hardware that does not do what it needs to do.  So, you will need 
to change what you are wanting to do.  Can you hack around things by 
very carefully choosing where you do things, I don't know.  However if 
you back up and re-evaluate the problem and go a different direction 
with the hardware limitation in mind, I think you will find a solution.

> In IPtables NAT, the answers comes back with the gateway IP address 
> as destination, and then, the gateway rebuilds a packet with the LAN 
> IP a new destination. This is what I was expecting ebtables would do 
> with MACs when providing --snat-arp.

Unfortunately (or fortunately depending on how you look at it) no. 
IPTables is predominately an OSI layer 3 technology.  I.e. it will alter 
  the IP address and to some extent the transport layer address (ports). 
  IPTables has some backwards hacking for layer 2 stuff, but it is not 
nearly as functional as the layer 3 and 4 stuff.

Remember that IP addresses and TCP / UDP ports are meant to work across 
multiple local segments, which is where MAC addresses are confined to. 
Thus you have different tools considering the scope of where you are 
working.

> Maybe there is a workaround, still in rperouting: imagine we record 
> the ... "frame" number sequence, and other parameters at the moment 
> we do SNAT; if we can predict what the answer should look like 
> (sequence number should be the same IMHO, but with a frame number 
> incremented), then we can identify the answer coming in, and then ... 
> do DNAT in PREROUTING ? we need to identfy whether an answer is 
> coming back for Gluton itself, or for a machine it is NATing ...

The problem with that idea is that on the link layer there is nothing 
other than local systems.  There is only the small pond that things are 
connected to, no concept of any thing out side of it.  So there would be 
no concept of any machine that Gluton is NATing for, only Gluton and the 
rest of the systems in the small pond.

Take a look at Wikipedia's write up on Ethernet 
(http://en.wikipedia.org/wiki/Ethernet) for some more information on 
ethernet frames.  You will find that there is no sequence number in 
ethernet.

> Maybe; that's the point where I say: I dont know enough about 
> networking to know what frames should look like, and the tools to 
> check what they actually look like :)

*nod*

Do some reading about IP and Ethernet.

> Like Iptables NAT would do.

Correct.

> It's normal the broadcast goes through: it has destination different 
> than local MAC; that's why I think, if we change the destination of 
> the answer in PREROUTING, the answer should be routed back to the one 
> who asked the question :)

Eh.  I think the problem has more to do with the source MAC address and 
the fact that the MA311 apparently can not alter the source MAC address 
of frames that it sends.

> But if proxyarp already does that ... => how is it called in debian?

Read the (above) referenced section of the LARTC documentation.



Grant. . . .

Re: ebtables to perform MAC NAT ?

[Oscar N]

> Oscar N wrote:
> But, you rougly understood how complex my problem is, from ARP point of
> view. I will have a look at your website.

I've nothing to do with ebtables more than using it. I guess they are
thinking of solving it in a nice fashion. They way it got it to work was
nothing fancy at all ;)

/Regards Oscar

Re: ebtables to perform MAC NAT ?

[DEMAINE Benoit-Pierre]

Grant Taylor wrote:
> Heh.  Sounds like your home network is more of a daisy chain of 
> computers with multiple network cars in them or something else equally 
> as strange.

This is a very good point of view of my topology. But offtopic.

> That's because it's not a package per say.  Proxy ARP is a feature of 
> the kernel that has to be enabled, much like routing and IP forwarding.
> 
> Rather than me re-typing how to do it, take a look at the write up about 
> it in the Linux Advanced Routing and Traffic Control HowTo - 
> Pseudo-bridges with Proxy-ARP 
> (http://lartc.org/howto/lartc.bridging.proxy-arp.html).

I will read that soon.

[...]

For now, i have tested parprouted (see message dated 22/07/08 18:01 
(west Europe)). Fact is: it solves the arp problem at one condition: I 
have to shutdown completely the bridge.

parprouted does not work at all with br0; it works properly only for 
eth0+wlan0_rename ... and only when br0 is off ("brctl delbr br0"); 
then, all ARP tables are set up as desired (real mac of the machine 
within the segment; IPs of machines from other segments are aliased to 
Gluton's MAC). Et the time i do "brctl addbr br0 && brctl addif br0 
eth0", arp resolution stops working (after cache expiry, or manual 
deletion).

So, my problem is not to get the right arp resolution, and find a way to 
bridge interfaces so that it wont prevent arp to work as required. This 
is an offtopic problem for now; i have a new path to walk, and i got new 
ideas for google keywords to search for. I ll give feedback in few days 
(either giving a solution, or with new problems :D ). I have to find why 
parprouted and brctl seem incompatible ... or how people do the bridging 
when using parprouted around ...

***

I am open minded for changing the software approach, as long as we keep 
trying to use my actual hardware.

I now have things to work on my side.

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Re: ebtables to perform MAC NAT ?

[DEMAINE Benoit-Pierre]

Works at last.

Question was: I have cheap hardware, and want to build a Wifi access 
point: i need to do transparent bridging between eth0 and wlan1.

Bad point for me (technical issue) was: after a few tests, as for many 
other people, my wifi card does not seem to enjoy brctl at all. I have 
an MA311, that is said to work for other people, but for me, brctl does 
not work nice. Maybe it is a firmware issue.

This trick allowed to get working network, the "bad" way:
> ifconfig eth0 192.168.0.205
> iwconfig wlan1 mode managed
> iwconfig wlan1 essid benoit
> iwconfig wlan1 key 0123-4567-89
> iwconfig wlan1 sens 2
> ifconfig wlan1 192.168.0.206
> echo 1 > /proc/sys/net/ipv4/ip_forward
> sleep 1
> ifconfig eth0 0.0.0.0 up
> ifconfig wlan1 0.0.0.0 up
> brctl addbr br0
> brctl addif br0 eth0
> brctl addif br0 wlan1
> ifconfig br0 192.168.0.205
> ifconfig br0:1 192.168.0.206
> sleep 1
> ebtables -t nat -F
> ebtables -t nat -A POSTROUTING -j snat --to-source 00:09:5b:48:d6:ab --snat-arp
> ebtables -t nat -A PREROUTING -p arp -j arpreply --arpreply-mac 00:09:5b:48:d6:ab
> route add default gw 192.168.0.1
> (echo -e "\t* sleeping 16s ... waiting for brige to build ..." ; sleep 16 ; beep -f 2000 -l 50 -r 3 ; echo -e "\t* bridge r
> eady !!!" ; ) &

Advantage of this: ARP get answered nicely, and all frames go through as 
wanted

Bad point: the router answers to all ARP requests, meaning, it virtually 
owns all IPs (even those outside the network), so that when machines 
like DHCP, Windows and Linux check if an IP is free before using it, the 
router already use it, and no IP is even free.

My actual solution that work way better:
> ifconfig eth0 192.168.0.205 netmask 255.255.255.255
> echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
> iwconfig wlan1 mode managed
> iwconfig wlan1 essid benoit
> iwconfig wlan1 key 0123-4567-89
> iwconfig wlan1 sens 2
> ifconfig wlan1 192.168.0.206 netmask 255.255.255.255
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo 1 > /proc/sys/net/ipv4/conf/wlan1/proxy_arp
> sleep 1
> 
> parprouted -d eth0 wlan1 &
> 
> while true
> do
> 
> echo "Waiting for default route to go away ..."
> while route -n |cut -d " " -f1 |grep "0.0.0.0" >/dev/null
> do
>         sleep 1
> done
> 
> echo "Trying to add default route ... until it's here."
> until route -n |cut -d " " -f1 |grep "0.0.0.0" >/dev/null
> do
>         /bin/ping -c1 -w1 192.168.0.1 >/dev/null 2>&1
>         sleep 1
>         /sbin/route add default gw 192.168.0.1
>         sleep 1
> done 
> 
> /bin/echo "* Added default route"
> 
> done

Of course, the last part can not be encoded in system conf file for 
network, it has to be put in an independent script.

It has to be a double loop, in case we loose the default route ( I am 
99,999% sure there are cases where we can loose it, if we loose it's 
MAC, what could happen if during a reboot of the gateway, we expire the 
timeout of the ARP cache).

This rely on the ability of parprouted to automatically update routes in 
the kernel (see reference below): use /32 masks, and hope for the best. 
Just assign any IP to each interface, in any network, and apply the 
255.255.255.255 mask.

Minus: Discovery takes time: it can take up to 12s from experience: it 
means, when you try to reach a machine for the first time, you are 
likely to have lost, and errors at the beginning. Having a machine down 
for longer than the ARP timeout will be a problem. Trying to reach an IP 
that is not up will flood parprouted queues.

But once we found where an IP is, everything seems stable (because 
parprouted refreshes ARP before the timeout, so that they never expire).

***

Problems yet to fix:
- add DHCP relay
- check that IPv6 goes through

References:
http://lists.shmoo.com/pipermail/hostap/2005-January/009412.html => 
means brctl can work on MA311

http://www.atomicmpc.com.au/forums.asp?s=2&c=16&t=4705
MA311 as Master

http://ebtables.sourceforge.net/examples.html#real ebtables examples

http://www.linuxfoundation.org/en/Net:Bridge#It_doesn.27t_work_with_my_Wireless_card.21 
  says that it is common for a wifi card to not work with brctl

http://wiki.xensource.com/xenwiki/XenWifi
the first guide saying that ebtables can be used to fix this kind of MAC 
problem

http://osdir.com/ml/network.bridge.ebtables.user/2005-03/msg00012.html
ebtables to iptables on a transparent bridge

http://freshmeat.net/articles/view/1433/

http://wiki.openwrt.org/OpenWrtDocs/WhiteRussian/TransparentFirewall
more scripts

http://lartc.org/howto/lartc.bridging.proxy-arp.html
proxyarp

http://tldp.org/HOWTO/Wireless-HOWTO-5.html
the page that says parprouted creates automatically routes for any 
discovered machine, so that, in the end, we can assign to the machine 
any IP with the mask /32.

http://www.faqs.org/docs/Linux-mini/Proxy-ARP-Subnet.html

http://linux.die.net/man/8/parprouted
parprouted man page

> Unlike standard bridging, proxy ARP bridging allows to bridge Ethernet networks behind wireless nodes. Normal L2 bridging does not work between wireless nodes because wireless does not know about MAC addresses used in the wired Ethernet networks. Also this daemon is useful for making transparent firewalls.

> By automatically adding appropriate /32 routes to Linux kernel IP routing table for the hosts learned via ARP , daemon ensures that the Linux kernel will be able to route the packets to the destination host when it receives them without any need routing/subnetting manually.

http://www.usenet-forums.com/linux-security/124068-simple-proxy-arp-setup-needed.html
dont forget to add
> echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
> echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
> echo 1 > /proc/sys/net/ipv4/ip_forward

***

For ref, this problem is also discussed in
http://forums.gentoo.org/viewtopic-t-695507-start-0-postdays-0-postorder-asc-highlight-.html?sid=90c8f519d6237940b01ea7bcf08a3ce5

Thanks Grant for help. I will unsubscribe this ML in 48h.

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)