LinuxQuestions.org - [SOLVED] Successful wireless connection but no internet access

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Successful wireless connection but no internet access (https://www.linuxquestions.org/questions/slackware-14/successful-wireless-connection-but-no-internet-access-4175442275/)

Successful wireless connection but no internet access

After upgrading my laptop to Slackware 14.0 64-bit, I have successfully used networkmanager to establish a connection to my wireless network.

The problem is that I can't access any internet sites - whether from a web browser or a email client.

When I use the "ping" command I get a "sendmsg: permission denied" response - even as root.

There is no problem when I use Slacko-puppy which is also installed on the laptop.

Is that the exact error message you are getting? I ask because I know a firewall rule blocking ICMP requests will result in the following:

Code:

ping: sendmsg: Operation not permitted

rather than "permission denied".

If you really are getting "permission denied" it may not be a firewall rule, but you may want to look at something else you may be running on your system that could have a similar effect.

You are correct. It is "Operation not permitted".

Since ping fails on both ethernet or wireless, that is definitely a firewall rule (another problem for another day).

When connected via ethernet, I have no problem accessing the internet. On wireless, I can't.

The only other unusual thing is that when I click on the networkmanager icon in the task bar, it shows a small (locked) padlock near the wireless symbol opposite the wireless name.

Do you know for sure if you have any firewall rules in place? I'd hate to have you chasing down non-existent problems. By default Slackware has no netfilter configuration, allowing all connections. If you are unsure, as root run the following from the command line:

Code:

iptables -L -n

If you do indeed have something in place it is possible it is set up to only allow traffic for your wired interface and not your wireless interface.

As for the lock icon show by NetworkManager, the GTK+ applet (used by XFCE, for example) shows a lock for secured connections. That is normal.

Although I don't see any clues here, this is the output from "iptables -L -n":

Code:

Chain INPUT (policy DROP)

target    prot opt source              destination        

ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0          

bad_packets  all  --  0.0.0.0/0            0.0.0.0/0          

DROP      all  --  0.0.0.0/0            224.0.0.1          

ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

tcp_inbound  tcp  --  0.0.0.0/0            0.0.0.0/0          

udp_inbound  udp  --  0.0.0.0/0            0.0.0.0/0          

icmp_packets  icmp --  0.0.0.0/0            0.0.0.0/0          

DROP      all  --  0.0.0.0/0            0.0.0.0/0            PKTTYPE = broadcast

LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 3 LOG flags 0 level 4 prefix "INPUT packet died: "



Chain FORWARD (policy DROP)

target    prot opt source              destination        



Chain OUTPUT (policy DROP)

target    prot opt source              destination        

DROP      icmp --  0.0.0.0/0            0.0.0.0/0            state INVALID

ACCEPT    all  --  127.0.0.1            0.0.0.0/0          

ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0          

ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0          

LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 3 LOG flags 0 level 4 prefix "OUTPUT packet died: "



Chain bad_packets (1 references)

target    prot opt source              destination        

LOG        all  --  0.0.0.0/0            0.0.0.0/0            state INVALID LOG flags 0 level 4 prefix "Invalid packet: "

DROP      all  --  0.0.0.0/0            0.0.0.0/0            state INVALID

bad_tcp_packets  tcp  --  0.0.0.0/0            0.0.0.0/0          

RETURN    all  --  0.0.0.0/0            0.0.0.0/0          



Chain bad_tcp_packets (1 references)

target    prot opt source              destination        

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW LOG flags 0 level 4 prefix "New not syn: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x00 LOG flags 0 level 4 prefix "Stealth scan: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x00

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x3F LOG flags 0 level 4 prefix "Stealth scan: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x3F

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x29 LOG flags 0 level 4 prefix "Stealth scan: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x29

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x37 LOG flags 0 level 4 prefix "Stealth scan: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x37

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x06 LOG flags 0 level 4 prefix "Stealth scan: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x06

LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x03/0x03 LOG flags 0 level 4 prefix "Stealth scan: "

DROP      tcp  --  0.0.0.0/0            0.0.0.0/0            tcpflags: 0x03/0x03

RETURN    tcp  --  0.0.0.0/0            0.0.0.0/0          



Chain icmp_packets (1 references)

target    prot opt source              destination        

LOG        icmp -f  0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "ICMP Fragment: "

DROP      icmp -f  0.0.0.0/0            0.0.0.0/0          

DROP      icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8

ACCEPT    icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 11

RETURN    icmp --  0.0.0.0/0            0.0.0.0/0          



Chain tcp_inbound (1 references)

target    prot opt source              destination        

RETURN    tcp  --  0.0.0.0/0            0.0.0.0/0          



Chain tcp_outbound (0 references)

target    prot opt source              destination        

ACCEPT    tcp  --  0.0.0.0/0            0.0.0.0/0          



Chain udp_inbound (1 references)

target    prot opt source              destination        

DROP      udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:137

DROP      udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:138

ACCEPT    udp  --  0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

RETURN    udp  --  0.0.0.0/0            0.0.0.0/0          



Chain udp_outbound (0 references)

target    prot opt source              destination        

ACCEPT    udp  --  0.0.0.0/0            0.0.0.0/0

Is your wireless connection static or via dhcp?

Can you post the output of:

# route -n

cheers,

Are you loading both rc.networkmanager and rc.wicd in /etc/rc.d/ ?
If so, delete or rename rc.wicd and try again.
Just a thought.

Quote:

Originally Posted by psionl0 (Post 4854261)

Although I don't see any clues here, this is the output from "iptables -L -n":

I forgot to have you use the "-v" option as well so we could see which interface(s) the rules applied are to. Your policies for INPUT and OUTPUT are DROP, so if your ruleset only applies to your wired interface, no traffic is going to be allowed on the wireless interface.

For the time being it may be easier to flush your rule set and set the policies of INPUT, OUTPUT, and FORWARD to ACCEPT (in other words, return netfilter to its default state of allowing all traffic). If you can then access remote hosts when using your wireless interface you know the problem lies somewhere in your firewall script.

NOW I am making some progress. When I temporarily disabled the firewall, internet access was enabled.

I originally generated the rc.firewall in Jan 2011 from Alien Bob's easy firewall generator which is available at http://connie.slackware.com/~alien/efg/. This generator has not been updated since 05/11/2005 so other users using this generator will have the same problem.

The output from iptables -L -n -v mentions "eth0" a number of times but not "wlan0".

The relevant section of rc.firewall seems to be as follows:

Code:

# Internet Interface

INET_IFACE="eth0"

Can I simply add "wlan0" at this point or is it more complicated than that?

Quote:

Originally Posted by cwizardone (Post 4854312)

Are you loading both rc.networkmanager and rc.wicd in /etc/rc.d/ ?

In Slackware 14.0 that is no longer an issue. rc.M has been updated so that it runs rc.wicd if that file is executable, otherwise it runs rc.networkmanager.

I think I solved it!

The help screen for the interface in Alien Bob's firewall generator states:

Quote:

If you are generating a script for a single system that sometimes uses a dail-up connection and other times uses a network connection, just specify + for the interface to match every interface.

A dated help screen for sure but it means that I only had to change the relevant section of rc.firewall as follows: (and it works)

Code:

# Internet Interface

INET_IFACE="+"

If nobody comes up within the next couple of days and says that I did something extremely stupid, I will mark this question "solved".

Quote:

Originally Posted by psionl0 (Post 4854405)

In Slackware 14.0 that is no longer an issue. rc.M has been updated so that it runs rc.wicd if that file is executable, otherwise it runs rc.networkmanager.

And if the are both installed and executable?

Quote:

Originally Posted by cwizardone (Post 4854578)

And if the are both installed and executable?

If rc.wicd is executable then it won't attempt to run rc.networkmanager. You can see it for yourself in /etc/rc.d/rc.M if you are running Slackware 14.0. The relevant section is as follows:

Code:

# Start wicd or networkmanager:

if [ -x /etc/rc.d/rc.wicd -a -x /usr/sbin/wicd ]; then

  sh /etc/rc.d/rc.wicd start

elif [ -x /etc/rc.d/rc.networkmanager ]; then

  sh /etc/rc.d/rc.networkmanager start

fi

Yes, I'm well aware of that as I use to edit it manually before it was included as the default configuration.

I am guessing that you think I might have messed up the rc.M file (or that I had included the startup commands in rc.local without realizing that it is now in rc.M).

Otherwise, it appears that you asked a question that you already knew the answer to.