Re: Trouble with extensions

On Wed, 21 Dec 2005, Ben Zarboni wrote:

> On Wed, 2005-21-12 at 22:32 +0200, Alexander Piavka wrote:
> >  It would help if you send also your routing table
> > and your bridge interfaces setup.
> > > I would like *ALL* frames from my wireless IF to be broadcast.
> > Why do you want to broadcast the unicast traffic too?
> >
>
> I'm part of a team adapting studying the effects of putting one of our
> HF technologies over 802.11. The routing layer sitting above 802.11
> requires that all frames (even data) be broadcast.
> As far as routing table goes I haven't played with it too much. I have a
> wired and a wireless interface (eth0 and wlan0 right now). It looks
> like:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0
> eth0
> 192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0
> wlan0
> 0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0
> eth0
>
> no bridged interfaces. Is this a requirement?

 yes ebtables sees traffic which is recieved or to be sent on a bridge
enslaved interfaces. Since you box looks like a router for two
different LANs it's a bad idea to enslave both wlan0 and eth0 to a bridge.
Since you want to mac dnat outgiong traffic to the wlan0 device you can
enslave only the wlan0 interface to a brigde(say br0 interface).
Give the wlan0 null ip 0.0.0.0 and the br0 the ip of the wlan0 interface.

 Now the bridging decision goes like this:
*  bridge it, if the destination MAC address is on another side of the bridge;
* flood it over all the forwarding bridge ports, if the position of
	the box with the destination MAC is unknown to the bridge;
* pass it to the higher protocol code (the IP code), if the
	destination MAC address is that of the bridge or of one of its ports;
* ignore it, if the destination MAC address is located on the same side of the bridge.

Thus you should drop all incoming traffic on br0 (the wlan0) interface,
except the traffic really destined for the box. (I don't know anythong of
802.11 or wireless world) But in case all traffic is broadcasted on 802.11 LAN
then the ebtables rules should change the dest broadcast mac to mac of the
br0 interface before the routing decision takes place, so that the box
recieves the broadcast packets but don't forward them back to br0
interface. (But maybe i'm wrong and bringing code is smart enough
and if it recieves a broadcast packet, then it does forwards it only to
the second side and also accepts it locally, but since in your case there
is no second side it would just accept it locally and you don't need to do
anything. But you can check it easily.)

ps. also your routing table should have br0 instead of wlan0.
>
> Thanks again,
>
> Ben Z
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Ebtables-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
>

            _.-..
          ,'9 )\)`-.,.--.
          `-.|   Piavlo  `.
             \, Alexander \)
              `.  )._\   (\
               |//   `-,//
               ]||    //"
               ""     ""



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click