Wireless Bridge, aaarrgghhh

Tim Writer tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org
Sun Jan 4 19:19:10 UTC 2004


Peter King <peter.king-H217xnMUJC0sA/PxXw9srA at public.gmane.org> writes:

>  
> Any help would be appreciated; I've tried looking in all the obvious
> places first. Even some less obvious ones. At the moment I'm greying
> quickly...
> 
> What I'd like to do is bridge two wired networks -- call them NET0 and 
> NET1 -- using a Linux laptop with built-in ethernet (eth0) and a wireless
> PCMCIA card (eth1). I have the laptop wired into NET0 via eth0. Now each 
> interface works fine all by itself. From the laptop I can ping machines 
> on NET0 with no problem, and from other machines on NET0 I can ping both
> eth0 and eth1. Likewise, from the laptop I can ping machines on NET1 via
> eth1, and use the internet connection on NET1. Great.
> 
> So eth0 = 192.168.0.12 on NET0 (192.168.0.xxx)
>    eth1 = 192.168.0.22 on NET0

That doesn't look right.  Why do you have two interfaces on the same network
(i.e. with same netmask and broadcast address).  Unless you're using advanced
routing tools to do load balancing or some such, this won't work.

> and traffic through eth1 is translated into 192.168.1.xxx addresses for
> NET1.

This suggests you want:

    eth1 = 192.168.1.22 on NET1

> The routing table on the laptop suggests that everything is fine:
> both eth0 and eth1 have destination 192.168.0.0 as routes, and there is
> only a single default gateway, defined on eth1, to 192.168.0.254 (which
> does the NAT).

That doesn't sound fine to me.  Unless you're doing something special (and it
doesn't sound like you are), different interfaces should have distinct
addresses and routes, and your default route should be reachable via only one
interface.

> What I can't seem to do is get the packets from NET0 to NET1, unless they
> originate on the laptop. And I can't figure out why.

Unless I'm not understanding your setup, I think it's your addressing.  As
you've described it, there's no reason of Linux to forward packets between
eth0 and eth1 since they're on the same network.

> I've tried a variety of configurations of iptables on the laptop; none of 
> them have yet worked. The most promising script ran something like this:
> 
> /sbin/iptables -F
> /sbin/iptables -A INPUT -i lo -j ACCEPT
> /sbin/iptables -A INPUT -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> /sbin/iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
> /sbin/iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
> /sbin/iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> /sbin/iptables -P INPUT DROP
> /sbin/iptables -P FORWARD DROP
> /sbin/iptables -P OUTPUT ACCEPT

Get your addressing and routing straightened out before installing any packet
filters.  If you can't route between these two networks w/o iptables, you
won't be able to do it with iptables.

> After flushing the tables and enabling the loopback device, then it allows
> everything from eth0 (and hence NET0) in, to be forwarded to eth1 (and hence
> NET1). It only allows established connections back. But it doesn't work; each
> time I try to ping an address outside of 192.168.0.xxx from NET0, it fails,
> and tells me there is no route to the address (or hostname lookup failure if
> I tried using name resolution). The resolv.conf files are the same on the
> laptop and on machines on NET0.
> 
> After a failed attempt to ping something, I run iptables -v -L and I can see that
> the INPUT and OUTPUT chains have seen the ping packets, but not the FORWARD chain.

With iptables, INPUT, OUTPUT, and FORWARD chains are completely separate.
That is, packets which are to be forwarded (based on a routing decision)
never hit the INPUT or OUTPUT tables (unlike with ipchains and ipfwadm).  The
fact that these packets are hitting your INPUT and OUTPUT chains is strong
evidence you have a basic addressing/routing problem as I've suggested.

Now, I may have misunderstood what you're trying to do.  Perhaps you can
follow up with some ASCII art and include your netmasks as well as a dump of
your routing table.

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
905.771.0017 ext. 225                           thornhill, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list