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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
