In another thread I asked about my Thinkpad T400 occasionally dropping the wireless connection. Yesterday I discovered I can imitate an observed symptom with the wired connection.

That symptom is I can't ping anything beyond my local WRT54GL router.

In short, I can ping my WRT54GL router but I can't ping the VOIP router. I have my main office machine on at the same time --- wired only, no wireless, using rc.inet1.conf --- and that system pings the VOIP router with no problems. The basic connection looks like this:

All Computers -> WRT54GL Router -> VOIP router -> ISP CPE -> Internet

All computers and the WRT54GL are on subnet 192.168.1.X. All computers connect to the WRT54GL statically. The VOIP router is on subnet 192.168.2.X. The WRT54GL connects to the VOIP router using DHCP.

The laptop conflict seems to be between NetworkManager (NM) and my firewall script. When I disable iptables and restart NM I then can ping beyond the WRT54GL.

Rebooting each time, I compared the output of iptables -S with both eth0 and wlan0. The output is the same except for the obvious eth0/wlan0 interface references. When I tested eth0 I physically disabled the wireless switch and rebooted. When I tested wlan0 I pulled the cable and rebooted.

As an additional test, I disabled rc.networkmanager, populated rc.inet1.conf in the traditional manner, and made no changes to my firewall script. Everything just worked and I could ping beyond the WRT54GL.

Seems to me that NM is the culprit.

I'm aware of other on-the-fly networking applets, but I'd like to stay focused on what NM might be doing that conflicts with my firewall. Hopefully I'm missing something obvious in the way NM functions.

I have read references that NM gets cranky when the physical wireless switch is disabled. I don't know what that fully means yet but I'm still trying to learn more. Then again, I'm not toggling the switch after booting, I'm disabling the switch before booting. So I'm thinking NM should not see the wireless at all.

Note: ipv6 is disabled.

At this point I won't speculate whether this wired behavior is the cause of the wireless drops.

Thanks again.

By any chance does your router have DNSmasque enabled?

Disabled. That said, I am running dnsmasq on the laptop but only as a DNS cache and not as a DHCP server. I use static IP addresses in my home LAN.

I'm not really sure I solved the problem, but I wrote a script that restarts NM as necessary after I start the iptables rc.firewall script. This is very much a sledge hammer solution and although "working" right now, I'll need several days to be sure.

To me, the whole wired vs. wireless strategy is flawed in Linux systems. In a normal Slackware wired boot sequence, rc.inet1.conf is populated, rc.inet1 runs, then rc.firewall. Straightforward. Simple.

Throw NM into the loop and everybody starts playing Twister.

The new boot sequence then runs like this: rc.inet1.conf is not populated; rc.inet1 runs but does nothing; then rc.inet2 runs, which runs rc.firewall runs; then rc.networkmanager runs. rc.networkmanager needs to run after dbus is running.

rc.firewall can't be run until NM is running because the firewall script does not know which interface NM will use. Running NM after starting iptables seems to break NM. At least on my laptop. So I have to restart NM.

Running rc.networkmanager after rc.firewall is where I see the problems, but as I mentioned, that is necessary to run rc.firewall. Basically, anybody running NM in Slackware must rewrite the boot sequence of the affected scripts within rc.local.

So in my sledge hammer script I now test ping the VOIP router and when that fails I restart NM because the firewall is already started. My script then loops through this ping/sleep until NM stabilizes, which seems to be several seconds.

Not to mention that NM insists upon rewriting my resolv.conf, which I have to chattr to stop. What cretin from Redhat wrote that POS?

Perhaps wicd avoids the Keystone Kops routine. I don't know. Perhaps I ought to learn to use the old rc.wireless script.

This is my first laptop and despite years of using Linux systems and Slackware, I find the whole wireless experience to be similar to inserting a size 9 foot into a size 7 shoe. Like banging my head against the wall and expecting different results. Wireless is not a great selling point with Linux systems, which is one reason I have avoided laptops all these years.

That said, as this is my first laptop, I'm sure there are some PEBKAC problems. As I'm a lappie newbie, I'm not going to recognize them as would veteran road warriors. I suspect many laptop users have pretty much jumped through similar hoops but have done so for so long that they no longer realize how messed up wireless really is.

Good question but when you set up the original Networking on Slackware, did you by chance choose NetworkManager first as the primary configuration, or choose DHCPCD first then edit in NetworkManager later?

I have no memory. What do you have in mind?

I use static IP addresses in my LAN. No DHCP.

NetworkManager usually works with dhcp assigned dynamic-ip by default and not a static-ip. I would also double check the configuration within NetworkManager to see if it's set exclusively for static-ip rather than dynamic-ip?

Also, if by chance you did enable dhcpcd in the original setup, you may want to disable the daemon at start up so it stops a conflict between dhcpcd and NetworkManager. I made that mistake myself.

As I use static IP addresses I dont' start dhcpcd on any system here.

As far as I can tell I'm okay, but to be sure, how do I determine that?