well, it is unwanted situation, but I have to live with that. Let me explain...
My scenario: ~~~~~~~~~~~~
~~~~~(wi)|WD|(ei)---(eth0)|Linux RT|(eth1)-----|hostA|
where:
wi - wireless interface ei - ethernet interface WD - wireless device, client bridge (better say, pseudobridge) RT - router (eth0=10.18.241.1/24;eth1=10.18.63.254/24;dgw=10.18.241.254) hostA - an ordinary host (ip=10.18.63.249/24;dgw=10.18.63.254)
Now, the problem: ~~~~~~~~~~~~~~~~~
First, what need to be said is, that WD is doing some sort of an ARP proxying, and it CAN'T be turned off. It is deep in a firmware of the device.
Consider, that some router from the left side of wireless network want to send something to hostA. From his routing table he found, that for this purpose RT router with 10.18.241.1 has to be used.
So he starts an ARP request, asking "who has 10.18.241.1". WD receives this on (wi) interface and repeats out byt (ei). RT will accept request and respond claiming, that he has a mentioned IP address.
WD receives that reply by his (ei), but before he retransmits that ethernet frame to wireless part of the network, he replaces source MAC address (RT's MAC) with HIS OWN MAC address, belonging to (wi) interface. Also, in the same time, WD records an IP=10.18.241.1-MAC=RT pair to some table (I'm not sure about this, only guessing). So when later any packet from wireless net will be directed to 10.18.241.1 it will be able to send it to correct MAC address from (ei).
Are you still at me?? OK, let's proceed futher....
So now, the host which want to send a packet to 10.18.63.249 host has a MAC address of RT (actually, WD's MAC) and packs an IP packet (sourceIP his own, dest IP=10.18.63.249) into ethernet frame with his own source MAC address, and destination MAC is of WD (he thinks, that RT).
WD receives that frame by (wi), looks into table and what? WD is searching his table from top to bottom, from bottom to top, but in no direction he is able to find a record for 10.18.63.249 (because he never saw a packet with such IP). He doesn't discard that packet, no no, he simply replace frame's destination MAC address (his own) with ff:ff:ff:ff:ff:ff and send out by (ei) interface!!!
That is the real problem, that router RT is suddenly facing to good IP packets, but sitting in a strange wagons.
So, again the question. Is there any mechanism, to let linux kernel start routing such packets?
There is some way out, that I can start Proxy ARP on RT's eth0 interface, and with some playing with subnet masking, make the network behind RT a part of network on the left side. But, it is unrealistic, if some other routers will be located behind the RT. :-(
Any help, RTFM pointers, whatever will be much appreciated
mARTin
John W. Linville wrote:
Martin Rusko wrote:
<snip>
0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: icmp: echo request (DF)
Please notice, that echo request packets are in ethernet frames, heading to broadcast address (ff:ff:ff:ff:ff:ff).
<snip>
Any help will be much appreciated. Also, when more info, why I see such packets is needed, I'm ready to serve.
OK, I'll bite. Why would you need to do this? It seems that you would just setup the interface on your Linux box to have an IP address (e.g. 192.168.7.1), assign the default route on the 192.168.7.11 box to point to the Linux box, and then be happy. The 192.168.7.11 device would ARP for the Linux box, then send unicast frames for the Linux box's interface. Why is this insufficient?
John
P.S. As to the initial inquiry, perhaps you could proxy the ARP requests? Surely the 192.168.7.11 starts by ARPing for 10.18.63.249?
-- Martin Rusko PhD student Department of Automation and Measurement Faculty of Mechanical Engineering Slovak University of Technology -- E-mail: rusko@sunsite.mine.nu Web: http://sunsite.mine.nu/~rusko -- motto: We are Microsoft! Resistance is futile. Open your source code and prepare for assimilation. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
