problem with WiFi connection [solved] [INACTIVE]

[wifi_problem]

I have been using BrazilFW for sharing a "Wireless DSL" Internet connection for several months now. Until recently, all that was needed was wired Ethernet connections. The set-up is an old Dell computer using a floppy boot with 3 Ethernet cards; eth0-LOCAL, eth1-WAN(Internet), and eth2-LOCAL2. LOCAL and LOCAL2 are seperate networks (no bridging). This set up has been working very well for months, the BrazilFW has shown to be very reliable and easy to administer. Now a wireless card has been added for a 3rd network. It is a TRENDnet TEW-443PI PCI card using the Atheros chipset(Atheros 5212). By just adding the iwtools.tgz and the ath.tgz available from BrazilFW.com.br (this was done by setting up a "dual floppy" boot for more disk space), the wireless card was detected and initialized without any problem. I then used the information provided by the BrazilFW_WiFi_HowTo to make minor editing changes to the ath package (but, this is a seperate network, I am not using a bridge set-up).

The Problem: even though I can connect to the BrazilFW router through the new WiFi network, the router will not route Internet traffic to the wireless network. I can access the web interface and log on as root, as well as log on using the putty terminal through port 22, but I can't access the Internet. Both of the Ethernet networks are still working fine, but the new wireless network is not.

Some details: All networks use manually assigned IP (NAT) addresses, DHCP is not running on the router, except as a client on the WAN connection. The ifconfig command shows the ath0 interface UP with the properly assigned IP and NETMASK. There is also a wifi0 which has no IP, but has the same hardware address as ath0, but the hardware address is followed by -00-00-00-00-00-00-00-00-00-00. One clue I have found is that when I run dnsmasq without any options, it spits out the following message: "dnsmasq: failed to bind listening socket for xxx.xxx.xxx.xxx: address already in use", where xxx.xxx.xxx.xxx is the IP address for ath0. This implies to me that dnsmasq is not relaying traffic from the wireless network to the Internet, but I haven't found any documentation that tells me what to do about it.

Any suggestions or recommendations will be appreciated.

[bobbb]

Can you post the Active Firewall Rules - nat. I suspect there may not be an entry like this for the IP of the WiFi

Código: Selecionar todos

MASQUERADE  all  --  *      ppp0    192.168.01.0/24      0.0.0.0/0

There should be one for each network.

This would handle all and I guess that should be the default because I have tested a situation where packets can leak out to the Internet unNATted

Código: Selecionar todos

MASQUERADE  all  --  *      ppp0    0.0.0.0/0     0.0.0.0/0

[wifi_problem]

Bob,

Thanks for the recommendation. There is not a major security concern with the Internet connection here, it is behind several layers of NAT addressing. I have not made any changes to the default firewall rules which comes with the BrazilFW software. Here is a copy and paste of the current file:

# Firewall Access Configuration File
#
# This file contains entries in the following format:
# type active permit|deny protocol source[/mask] destination[/mask] port
#
# type = access # Control access THROUGH the Firewall
# type = admin # Control access TO the Firewall
# active = Y or N

access N deny all 192.168.0.44 any all #Example - Deny internet access to this IP
access N deny all 192.168.0.50/23 any all #Example - Deny internet access to these IP
access N deny tcp any any 21 #Example - Deny access to FTP sites

The code example you have provided does not seem to fit the syntax of the examples provided with this file. Is this the file your talking about, or is there another firewall configuration file?

[bobbb]

Yes different.

Log on to Webadmin and click Diagnostic Tools->Active Firewall Rules - nat
Then post just the Chain POSTROUTING rules.

[wifi_problem]

Okay, thanks. Here is the Chain POSTROUTING rules from that file:

Chain PREROUTING (policy ACCEPT 11212 packets, 1381K bytes)
pkts bytes target prot opt in out source destination
11212 1381K nat-acl all -- * * 0.0.0.0/0 0.0.0.0/0
11212 1381K dns-preroute all -- * * 0.0.0.0/0 0.0.0.0/0
11212 1381K auto-forward all -- * * 0.0.0.0/0 0.0.0.0/0
11212 1381K port-forward all -- * * 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 922 packets, 77068 bytes)
pkts bytes target prot opt in out source destination
4964 277K dns-postroute all -- * * 0.0.0.0/0 0.0.0.0/0
4964 277K nat-masks all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 908 packets, 76212 bytes)
pkts bytes target prot opt in out source destination

Chain auto-forward (1 references)
pkts bytes target prot opt in out source destination

Chain dns-postroute (1 references)
pkts bytes target prot opt in out source destination

Chain dns-preroute (1 references)
pkts bytes target prot opt in out source destination

Chain nat-acl (1 references)
pkts bytes target prot opt in out source destination

Chain nat-masks (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth1 192.168.2.0/28 0.0.0.0/0
2393 118K MASQUERADE all -- * eth1 192.168.1.0/24 0.0.0.0/0
30 1499 MASQUERADE all -- * eth1 192.168.0.0/24 0.0.0.0/0

Chain port-forward (1 references)
pkts bytes target prot opt in out source destination


NOTE: This is the whole file. I showed the whole file because it shows all 3 of the networks in the chain nat-masks. As you can see, the first 2 networks are working great, but the 3rd network (192.168.2.0/28) is dead.

[bobbb]

I'll try to go by process of elimination.

You can login to BFW. So this says TCP/IP is fine and you have a correct default gateway of 192.168.2.1 for WiFi and the netmasks are correct unless you connect to BFW with 192.168.2.1:8180. ??

When you say no Internet from WiFi I presume you are testing using basic commands link ping and tracert. You mention dsnmasq so I presume you use DNS cache and workstations use BFW as DNS. Do domain names get resolved on WiFi? Ping google.com should tell you the IP it is trying. BFW will do that resolve for itself so it will not be a forward from WiFi or it will have it in cache. Either way we can now confirm DNS.

Your POSTROUTING chain shows no traffic for WiFi. This must be true. Either no traffic makes it there from WiFi because it does not make it to the router or it gets blocked somewhere before going to POSTROUTING. So post the Active firewall rules. x out any sensitive info if any.

I see 4964 packets entering nat-masks and only 2423 making it to MASQUERADE. Now I wonder where all those remaining packets went. On my system the numbers add up. Were the counters zeroed?

One clue I have found is that when I run dnsmasq without any options, it spits out the following message: "dnsmasq: failed to bind listening socket for xxx.xxx.xxx.xxx: address already in use.

Does that mean it is OK normally or did you change something? In either case dnsmasq is for DNS cache and DHCP server. BFW can run without either or both.

Everything is hard-coded on the workstations so I would make sure they all conform to the specs for normal operation. Is that /28 correct on BFW and workstations.

I have been using BrazilFW for sharing a "Wireless DSL" Internet connection for several months now.

Now a wireless card has been added for a 3rd network.

This gets my attention too. It tells me there is another wireless device somewhere. Is BFW behind a wireless router like a D-Link.

I am not really solving your problem. Just asking questions. Maybe something will jump out for you.

[wifi_problem]

Bob,

No, you really are solving my problem. Thank you for the effort you've made, having me look at these files has provided the insight to understand the problem. Well, I really don't fully understand the problem, but I have found how to make things work.

First, to answer some of your questions. You presumed correctly on all of your statments. What is confusing is that I "complicated" things when I added the WiFi interface. The 1st network set up on my BFW installation just used the defaults in the software (network 192.168.0.0 - 255.255.255.0). I added a 2nd network on another Ethernet interface of 192.168.1.1, also 255.255.255.0, or /24. But, on the Wifi interface recently installed, I attempted to create a subnet of the 192.168.2.0 block of NAT IPs by using 192.168.2.160 - 255.255.255.240, or 192.168.2.160/28. This seemed to work as the WiFi interface was automatically assigned the correct broadcast address of 192.168.2.175. But, what I don't understand is why automatic masquerade entry was for network 192.168.2.0/28. I could log on through SSH on port 22 by using the assigned gateway address of 192.168.2.161, but I could not get any dns forwarding, no domain resolution. Also, I could access the BFW web interface through the WiFi by using the 192.168.0.1:8180 default address.

Anyway, I just finished changing the set up to use the entire 192.168.2.0/24 IP block and everything works just fine. Workstations can now get domain resolution through the WiFi without any problem.

Oh, and the BFW installation is not really behind a wireless router, but it is connected to a "Wireless DSL". I'm not really sure what protocol is being used by the ISP, but this is a rural location where there is no cable or wired DSL available. This service is provided through exclusive hardware provided by the ISP, the connection to the router is through standard Ethernet (DHCP addressed). This is a small rural rental community and the landlord wishes to provide this service through WiFi to the tenants (this is allowed by the contract since the ISP regulates the service according to Bytes per month).

I would like to add that using the two floppy boot-up on the BFW installation works really well. It makes it easy to add the additional WiFi software to BFW without having to do any custom work to the software. Just use it "out-of-the-box", or as dowloaded from the website.

Thanks again

[bobbb]

But, what I don't understand is why automatic masquerade entry was for network 192.168.2.0/28

That's easy. You just found a bug. I checked the code and there is a cut and paste error. Line 93 of /etc/rc.d/rc.masquerade contains this line eval `ipcalc -n $WLAN_IPADDR $LOCAL2_NETMASK` and it should be eval `ipcalc -n $WLAN_IPADDR $WLAN_NETMASK` It works well when you use the same mask as LAN2. In your case the masquerade would be effective for 192.168.2.0 through 192.168.2.15

I could log on through SSH on port 22 by using the assigned gateway address of 192.168.2.161

That's because both are on the same network. Gets handled by INPUT.

I could access the BFW web interface through the WiFi by using the 192.168.0.1:8180 default address.

That's because the gateway was correct on WiFi and it's a local IP to BFW itself. Gets handled by INPUT.

I could not get any dns forwarding, no domain resolution.

If you mean real DNS forwarding then it's because of the bug above. And I bet the packets went out your WAN unmasqueraded and had nowhere to return to or got dropped by a router on the Internet because it had a private source IP. You should have gotten something if you were using BFW DNS cache.

the connection to the router is through standard Ethernet (DHCP addressed).

That's what I meant.

I submitted the bug.

two floppy boot-up on the BFW installation... Just use it "out-of-the-box", or as dowloaded from the website.

Where's this?

[wifi_problem]

two floppy boot-up on the BFW installation... Just use it "out-of-the-box", or as dowloaded from the website.

Where's this?

Not sure what your asking. What I mean by "out-of-the-box" is that I have not had to do any work with the software that requires experience or understanding of Linux or FOSS. The entire set up I'm currently using here was done just using MS Windows. While I personally work and use Linux systems for myself (even building LFS a couple of times), I wanted to be able to tell others how to do this without having to have a Linux system available or having to build (compile) custom configurations. It's just been a matter of downloading the software files available on the BFW website, using the neat MS Windows based boot floppy builder and then connecting to the BFW web based configuration utility and putting desired values into the dialog boxes.

Now, as you know, that was all that was required for the initial Ethernet only configuration, but to add the WiFi software requires more disk space than is available on a single floppy, even with the 1720kb packed floppy. I saw the posting by Triorieel a while back about using a CD-ROM to boot the kernel and initrd file from, then maintaining all the configuration and add-ons on fd0. Well, that still requires another kernel with IDE support for the CD-ROM. By just putting second old floppy drive on the system I did the same thing. I just put this "boot B:" code in the boot sector of the floppy in A: (fd0) drive. This code causes the computer to reboot on the B: (fd1) drive. In the B: drive is the floppy with syslinux, the kernel and the initrd (the floppy produced with the Windows based boot floppy builder) and all the configuration files and *.tgz packages (except root.tgz, of course) are copied to the floppy that's in the A: drive. This, as Triorieel pointed out in his post, leaves plenty of room for lots of extra add-ons. In operation the computer powers up, the BIOS boots the A: drive and reads this special "boot B:" code in the boot sector, this causes the computer to reboot but is directed to the B: drive, syslinux boots the kernel which loads the root.tgz into the ramdisk, it then goes to fd0 (the A: drive) to load the configuration files and add-ons. Configuration changes made to BFW are still saved to the floppy in fd0, so everything works just like it is configured to do by the BFW development team. No need to use a hard drive or any other hardware which isn't supported by the basic kernel.

[bobbb]

saw the posting by Triorieel a while back

Did not know this trick but will try it.