Ubuntu

Firestarter init fails on system boot when NetworkManager is used

Reported by Antti Koskinen on 2006-05-03
320
This bug affects 4 people
Affects Status Importance Assigned to Milestone
firestarter (Debian)
Fix Released
Unknown
firestarter (Ubuntu)
High
Unassigned

Bug Description

Firestarter init script (/etc/init.d/firestarter) fails to load iptables setup on system boot when network interface is managed by NetworkManager.

The following error message is displayed:

Starting the Firestarter firewall: failed.

Manual startup fails with:

/etc/firestarter/firestarter.sh start
External network device eth0 is not ready. Aborting..

A resolution might be to adding a firestarter script in /usr/share/NetworkManager/dispatcher.d, which would load when NetworkManager enables the interface.

NOTE: This won't work with Edgy Eft in which the problem persists. If you wish to work around this problem in Edgy Eft, then make sure you place for example 50firestarter in /etc/NetworkManager/dispatcher.d and make this script executable.

Related branches

JoshuaPurcell (joshua-purcell) wrote :

I am running Firestarter 1.0.3 and the latest NetworkManager from the code repository (the NetworkManager applet says 0.6.0). I am able to start both applications at startup without any errors. What versions are you running?

As a side note, I get a similar error to "External network device eth0 is not ready" from the Firestarter GUI, but only when eth0 was not able to start due to the cable not being plugged in at startup. This occurs regardless of NetworkManager being installed or not. This makes me think that for some reason your install of NetworkManager isn't bringing up your eth0 device before Firestarter tries to begin, so Firestarter fails. This wouldn't be a problem with Firestarter, but possibly with the start time of NetworkManager on your system.

Antti Koskinen (elehvantti) wrote :

I'm running up-to-date Dapper AMD64 with Firestarter 1.0.3 and NetworkManager 0.6.2. NetworkManager and NetworkManagerDispatcher start fine on my system (started by /etc/rc2.d/S12dbus, way ahead of S20firestarter), but you're right - apparently NM doesn't bring the interface up properly for Firestarter.

My primary NIC (eth0) is a wireless Intel card (ipw2200) that connects to a WEP encrypted network. Could this be the reason Firestarter init fails? Both the /etc/init.d/firestarter script and GUI work fine after I log in and enter my Gnome keyring password for nm-applet.

Here's my /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

Here's eth0 ifconfig output right after system boot (note: I added the x's):

eth0
Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet6 addr: xxxx::xxx:xx:xxxx:xxxx/xx Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2747 errors:0 dropped:0 overruns:0 frame:0
TX packets:841 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:193 Base address:0x8000 Memory:febfb000-febfbfff

So NetworkManager does bring the interface up on system boot... strange this is not enough for Firestarter.

Chris Lasher (chris.lasher) wrote :

I'm experiencing this same problem on Dapper Drake. So are others. See http://ubuntuforums.org/showthread.php?p=1581628

Chris Lasher (chris.lasher) wrote :

I suppose that wasn't the most helpful contribution to the bug above, sorry about that--let me give a little more info. This is with ipw3945 (Intel ProWireless 3945 ABG builtin module) seen as eth1. Happens on WEP, WPA, or non-secure networks. Problem occurs because wireless is not "up". Firstarter fails to activate the tables once NetworkManager has established a connection, though. I have to manually restart the firstarter daemon, or load firestarter. Note that if I put gksudo firestarter in my sessions for startup app, it fails because it can't find device eth1 (because NM hasn't gotten the chance to establish connection with the network). If, after establishing a connection with the network, I log back in, firestarter starts with the session, because the network connection has been established, and thus eth1 already "exists". Hope this helps more.
I love Firestarter and will continue to use it, even with this nuissance, but it would be great if it would "just work" with NM.

Mika Wahlroos (mpw) wrote :

The Firestarter init script also fails for me on Dapper, and I'm not using network manager. If I run the script later after the system has booted, it seems to work fine.

Rob Hasselbaum (rhasselbaum) wrote :

Same problem, but I was able to solve it using the script posted here:

http://www.debian-administration.org/users/emeitner/weblog/2

I suggest calling the script /usr/share/NetworkManager/dispatcher.d/50firestarter so it will launch after the 01ifupdown script. Otherwise, it doesn't work. Of course, you also need to make the script file executable.

Usiing this approach, you can disable the Firestarter system service. It fails to start at boot time anyway.

Alex van Niel (alexvanniel) wrote :

I can confirm this bug is still not fixed in Edgy Eft. I use firestarter version 1.0.3 and I have created a script in /etc/NetworkManager/dispatcher.d that will launch firestarter upon NM finding a network connection.

What disturbs me is that nobody seems to care about this problem, or at least I have not seen anyone getting upset by this but this could be a security problem. Moreover, you are not warned that the firestarter daemon is not running. SO the only way you will find this out is when you actually install the GUI and check the status there.

Someone PLEASE address this issue because the default operation of iptables is to close all ports instead of stealth them, that way hackers know a system is present at the other end.

Note to everyone reading this and thinks that Firestarter is just the GUI, Firestarter is NOT just the gui, it consists of a daemon that controls iptables dynamically AND of a gui. The gui is not installed by default, the daemon IS!

description: updated
description: updated
Alex van Niel (alexvanniel) wrote :

IMPORTANT NOTE
Manual running of the firestarter initscript works fine with Edgy Eft and Network Manager. The initscript does not fail like mentioned in the bug description, with Edgy Eft at least this doesn't happen. It just won't start at boot.

dr_d (bootstrap21) wrote :

>>IMPORTANT NOTE
>>Manual running of the firestarter initscript works fine >>with Edgy Eft and Network Manager. The initscript does >>not fail like mentioned in the bug description, with Edgy >>Eft at least this doesn't happen. It just won't start at >>boot.

Yes.. exactly what's happening to me.

Rob Hasselbaum (rhasselbaum) wrote :

Location of the dispatcher scripts changed in Edgy. They're now under:

/etc/NetworkManager/dispatcher.d

If you drop the script in there, it will run when (K)NetworkManager connects.

Alex van Niel (alexvanniel) wrote :

As you could have read per my comment but better twice then no mention at all ;-)
Still, this should be fixed! Even though you can drop the script in dispatcher.d this still should not happen, or at least a warning other then in dmesg should be given... only when you examine your system logs frequently will show you that firestarter is not running... if even then because it will not say that firestarter failed to run as far as I know. It will just not start at boot because it doesn't detect a network before the manager is running.

dr_d (bootstrap21) wrote :

Oh ok I see..

On an unrelated problem, I got into package dependency problems last night and decided to do a clean install..... Anyways I'm no longer using Firestarter so it's not an issue for me anymore.

Best of luck fixing it.

Mossroy (mossroy) wrote :

I faced the same problem on my Ubuntu Edgy.

It has been a very serious issue for me, because I thought I was protected by Firestarter. After installing Network Manager, it appears I wasn't at all.
I have several services (samba shares, ssh, vnc etc) that are supposed to be accessible only by my local network. Those services have been accessible by anyone for almost one month, until I found the problem.

I had to slightly modify the solution in the link above. The command-line "source" doesn't exist on my computer (seems like that depends on which shell is used), so I replaced it with the ". " command.

So I created a file 50firestarter with the following content, and gave it the execution rights (sudo chmod +x 50firestarter)

#!/bin/sh

. /etc/firestarter/configuration 2>&1

# Check to see if the interface that changed is the one currently
# protected by firestarter. If not, quit.
[ "$1" != "$IF" ] && exit

# Check the current status of Firestarter
[ -e /var/lock/subsys/firestarter -o -e /var/lock/firestarter ]
fs_status=$?

case "$2" in
        up)
                [ "$fs_status" -gt 0 ] && /etc/init.d/firestarter start
        ;;
        down)
                ## Uncomment the following line to allow this script to
                ## turn off the firewall when the interface goes down.
                #[ "$fs_status" -eq 0 ] && /etc/init.d/firestarter stop
        ;;
esac

guidol (monk-e) wrote :

This problem persists in Feisty!

I think I have the same problem in feisty. The init script fails on boot. Starting the GUI gives a "eth0 not ready, failed to start firestarter" error. Strangely enough, disabling and enabling eth0 makes firestarter start without problem.

sidenote: I use firestarter to share the internet connection

Linux flyingdutchman 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

firestarter 1.0.3-1.3ubuntu2
knetworkmanager 0.1-0ubuntu9
network-manager 0.6.4-6ubuntu3

Changed in firestarter:
status: Unconfirmed → Confirmed
SWedenfox (swedenfox) wrote :

same problem with feisty
:'(

Changed in firestarter:
assignee: nobody → mrpouit
status: Confirmed → In Progress
Lionel Le Folgoc (mrpouit) wrote :

I've made a script based on the one from debian-administration.org. Could you test it? Copy it to /etc/NetworkManager/dispatcher.d and make it executable. I'll upload it (and forward to Debian) if it works.
Thanks

d selby (kbmaniac) wrote :

Exactly the same problem as ChrisLasher earlier. WIFI not up when firestarter script called - dangerous :(

My solution, edit /etc/firestarter ..

# *** Commented out by me otherwise firestarter wont start due to wifi not started ***
#if [ "$MASK" = "" -a "$1" != "stop" ]; then
# echo "External network device $IF is not ready. Aborting.."
# exit 2
#fi

And now firestarter works every time. OK this is a sincere question - I am no security expert - why does firestarter need to check to see if the eth? port is up before applying the iptable rules ? It appears that when firestarter starts all non defined ports are blocked so if firestarter IS mis configured network issues would alert the user. This has got to be better than silently failing and leaving the user vulnerable.

d selby (kbmaniac) wrote :

Opps - forgot to mention - fiesty fawn :)

Hi,

this script seems to work fine on my Ubuntu 6.10. I upgraded it to 7.04
yesterday and it still works fine.
Hope you will have enough feedback to upload this patch for everyone.

Thanks

Boris Maras

Lionel Le Folgoc a écrit :
> I've made a script based on the one from debian-administration.org. Could you test it? Copy it to /etc/NetworkManager/dispatcher.d and make it executable. I'll upload it (and forward to Debian) if it works.
> Thanks
>
> ** Attachment added: "50firestarter"
> http://librarian.launchpad.net/7464586/50firestarter
>
>

Alex van Niel (alexvanniel) wrote :

@dave s: you migth run into problems again when firestarter is updated ... the script you edited migth be replaced... isn't better to add a script like mentioned above to dispatcher of NetworkManager?

This problem indeed still persists in Feisty Fawn by the way... I urge SOMEONE to do something about it because this is real security issue!

I have to admit I had not thought of an update silently killing my
hack :) - In my books this is a VERY serious flaw and would have
thought it was #1 priority to be fixed. I only discovered I was
unprotected by accident & was not best pleased.

I am a very green bug fixer, just setting up a KDE4 dev environment. I
don't know about packaging or I would have a go myself.

Cheers

Dave

On 15/05/07, Azalin <email address hidden> wrote:
> @dave s: you migth run into problems again when firestarter is updated
> ... the script you edited migth be replaced... isn't better to add a
> script like mentioned above to dispatcher of NetworkManager?
>
> This problem indeed still persists in Feisty Fawn by the way... I urge
> SOMEONE to do something about it because this is real security issue!
>
> --
> Firestarter init fails on system boot when NetworkManager is used
> https://bugs.launchpad.net/bugs/42759
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare

Alex van Niel (alexvanniel) wrote :

Dear Dave,

so not to cloud the launchpad bug report with our conversation I
decided to mail you directly. I hope that is ok.

In any case, what I mean with SOMEONE fix the problem is that someone
from Canonical or at least someone involved in maintaining Firestarter
should fix this problem.

As far as your fix is concerned, why not try the supplied script in
the bugreport and place it as 50firestarter (make it executable) in
the dispatcher.d directory of NetworkManager. That script will not be
replaced by an update, at least I doubt it and if it will then it will
most defenitely be replaced by something that is also trying to fix
this issue so no harm can come from that. Whilst when firestarter is
updated, the firestarter script might be updated and thus your edited
version might be replaced. The problem most likely will reappear. With
the dispatcher script I assume it works for wireless connections as
well.

I would say, just give it a go.

Cheers,

Alex.

2007/5/16, dave s <email address hidden>:
> I have to admit I had not thought of an update silently killing my
> hack :) - In my books this is a VERY serious flaw and would have
> thought it was #1 priority to be fixed. I only discovered I was
> unprotected by accident & was not best pleased.
>
> I am a very green bug fixer, just setting up a KDE4 dev environment. I
> don't know about packaging or I would have a go myself.
>
> Cheers
>
> Dave
>
>
>
> On 15/05/07, Azalin <email address hidden> wrote:
> > @dave s: you migth run into problems again when firestarter is updated
> > ... the script you edited migth be replaced... isn't better to add a
> > script like mentioned above to dispatcher of NetworkManager?
> >
> > This problem indeed still persists in Feisty Fawn by the way... I urge
> > SOMEONE to do something about it because this is real security issue!
> >
> > --
> > Firestarter init fails on system boot when NetworkManager is used
> > https://bugs.launchpad.net/bugs/42759
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
>
> The unavoidable price of reliability is simplicity.
>
> -- C.A.R. Hoare
>
> --
> Firestarter init fails on system boot when NetworkManager is used
> https://bugs.launchpad.net/bugs/42759
> You received this bug notification because you are a direct subscriber
> of the bug.
>

d selby (kbmaniac) wrote :

On 16/05/07, Azalin <email address hidden> wrote:
> Dear Dave,
>
> so not to cloud the launchpad bug report with our conversation I
> decided to mail you directly. I hope that is ok.
>

Yep no problem

> In any case, what I mean with SOMEONE fix the problem is that someone
> from Canonical or at least someone involved in maintaining Firestarter
> should fix this problem.
>

Its worrying that this has been left out in the cold especially with a
fix sitting there.

> As far as your fix is concerned, why not try the supplied script in
> the bugreport and place it as 50firestarter (make it executable) in
> the dispatcher.d directory of NetworkManager. That script will not be
> replaced by an update, at least I doubt it and if it will then it will
> most defenitely be replaced by something that is also trying to fix
> this issue so no harm can come from that. Whilst when firestarter is
> updated, the firestarter script might be updated and thus your edited
> version might be replaced. The problem most likely will reappear. With
> the dispatcher script I assume it works for wireless connections as
> well.

Just tested it - works a treat with my wifi.

>
> I would say, just give it a go.
>
> Cheers,
>
> Alex.
>

--

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare

Hi Dave,

dave s schreef:
>
>> In any case, what I mean with SOMEONE fix the problem is that someone
>> from Canonical or at least someone involved in maintaining Firestarter
>> should fix this problem.
>>
>>
>
> Its worrying that this has been left out in the cold especially with a
> fix sitting there.
>
>
It indeed IS worrying... but there are some more worrying things at the
moment. like the tty / sata problem nobody seems to care about... there
is a work around, just like with firestarter, but there doesn't seem to
be anyone interested in fixing it in the distribution... strange.
>
>> As far as your fix is concerned, why not try the supplied script in
>> the bugreport and place it as 50firestarter (make it executable) in
>> the dispatcher.d directory of NetworkManager. That script will not be
>> replaced by an update, at least I doubt it and if it will then it will
>> most defenitely be replaced by something that is also trying to fix
>> this issue so no harm can come from that. Whilst when firestarter is
>> updated, the firestarter script might be updated and thus your edited
>> version might be replaced. The problem most likely will reappear. With
>> the dispatcher script I assume it works for wireless connections as
>> well.
>>
>
> Just tested it - works a treat with my wifi.
>
>
>
Excellent. That way you at least know that your connection will be
protected even when firestarter is updated and the firestarter.sh is
replaced with another one :)

Cheers,

Alex.

Lionel Le Folgoc (mrpouit) wrote :

Uploaded in gutsy, thanks for feedback. ;)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 20 May 2007 12:01:00 +0200
Source: firestarter
Binary: firestarter
Architecture: source
Version: 1.0.3-2ubuntu2
Distribution: gutsy
Urgency: low
Maintainer: Ubuntu MOTU Developers <email address hidden>
Changed-By: Lionel Le Folgoc <email address hidden>
Description:
 firestarter - gtk program for managing and observing your firewall
Launchpad-Bugs-Fixed: 42759
Changes:
 firestarter (1.0.3-2ubuntu2) gutsy; urgency=low
 .
   * LP: #42759
     - debian/firestarter.NetworkManagerDispatcher: script to let NetworkManager
       start/stop the firewall when the interface goes up/down
     - debian/control: suggests network-manager
     - debian/rules: installs firestarter.NetworkManagerDispatcher to
       /etc/NetworkManager/dispatcher.d/50firestarter
Files:
 a3e3c873af2cbd49663c231efe214a44 813 admin optional firestarter_1.0.3-2ubuntu2.dsc
 2d63f7f61379b5bfdbb568ac5815a281 56038 admin optional firestarter_1.0.3-2ubuntu2.diff.gz
Original-Maintainer: Yann Verley <email address hidden>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGUByCRaA1e1F5WRARAjJ/AJ43Mk5mUGypYWvF7z7mFr55IH1OnACgvGLM
E5M6EKxQxAKUXPAiAMCJr+s=
=DHPb
-----END PGP SIGNATURE-----

Changed in firestarter:
importance: Medium → High
status: In Progress → Fix Committed
Changed in firestarter:
status: Unknown → Unconfirmed
Changed in firestarter:
assignee: mrpouit → nobody
status: Fix Committed → Fix Released
kilou (qiloooo) wrote :

I have the same problem (Starting the Firestarter firewall....[failed]). I have created the script in /etc/NetworkManager/dispatcher.d, made it executable as Boris Maras proposed. However I still get the same message when booting (well I have to do Ctrl+Alt+Backspace to see the message). How do I know this sript is working on my system?? Is there anything else to do in order to allow Firestarter to start during boot?

guidol (monk-e) wrote :

kilou:
You can run "sudo /etc/init.d/firestarter status" and it will tell you if it's running or not.

rai4shu2 (rai4shu2) wrote :

How much longer will we have to wait for the fix? This is still a serious bug for us Feisty users.

Soul-Sing (soulzing) wrote :

is this bug not fixed in gutsy? i heard that this bug was over and done wth.
what is this firestarter/debian bug? a duplicate? why isn't it confirmed?

Changed in firestarter:
status: New → Fix Released
Lex Berger (lexberger) wrote :

Not fixed in Gutsy yet

logari81 (logari81) wrote :

Bug still present in Gutsy upgraded from Feisty. Somebody should care.

Jean-Luc Thirion (jlinho) wrote :

I can confirm that the bug is still there in Gutsy.
Starting Firestarter firewall ... fail run-parts: /etc/network/if_up.d 50firestarter exited with return code 2

Jean-Luc Thirion (jlinho) wrote :

I just add that manual startup works for me. Firestarter just fails at startup

Igor Gomes (igorgomes) wrote :

I'm second and confirming the bug on Ubuntu 8.10.

Firestarted still failing during the startup due the init order. It starts before the wlan0 interface be created and, so, and error is displayed. To add, it doesn't add itself to the "Services" as others startup daemons.

Thanks!

Igor Gomes

Igor Gomes (igorgomes) wrote :

Forget it... Wrong place.

Reopened for Jaunty. The problem is still here on Ubuntu 9.04 RC. The current package version (1.0.3-7ubuntu4) no longers contains the /etc/NetworkManager/dispatcher.d/50firestarter file that was included into the 1.0.3-2ubuntu2 version.

Looking at the changelog.Debian.gz file, I can see:

firestarter (1.0.3-4ubuntu1) gutsy; urgency=low
  [...]
  * Drop ubuntu changes from 1.0.3-2ubuntu2 and use debian solution instead.
  [...]

I don't know what's the "debian solution" the changelog says, but it obviously don't work.

Changed in firestarter (Ubuntu):
status: Fix Released → Confirmed
BrokenDreamz (nono-yopmail) wrote :

I had the same problem...
For people who are looking for an other firewall, just notice that you can install Gufw, using synaptic

In console

#Uninstall Firestarter
$ sudo apt-get autoremove firestarter

#install Gufw
$ sudo apt-get install gufw

eris23 (jdkatz23) wrote :

Problem still in karmic with firestarter 1.0.3-7ubuntu5.

Dinesh (linux-future) wrote :

I can confirm that the problem still persists with Karmic

LeeDaugherty (granfury83) wrote :

Firestarter has been dormant for a couple years (yes, there has been a couple patches...). First off, the "service" portion of Firestarter is loading on boot. You can verify on boot-up with a "sudo iptables -L -n"...if you see anything special, Firestarter ran its scripts. So you are "protected". You don't have the GUI on X startup, but that can be fixed by creating a startup entry (and modifying /etc/sudoers if wanted). As a side note, several years ago (might still be in the docs somewhere), the work-around to not have the "failure" was to comment out a couple lines in firestarter.sh). While getting Firestarter up-to-date wouldn't take much, from what I've seen in its scripts (window scaling disabling and such) it can lead to some network stalls in recent distros (not to mention some weird headaches if you like tossing bittorrents around). While I haven't seen a fun real-time GUI interface that would compare with this, users are better off finding another way to build their iptables.

Jamie Strandboge (jdstrand) wrote :

The Debian bug is marked as Fix Released and based on the changelog in the Debian bug, this should be fixed in Hardy and later, so I am marking the bug as such. If people are having problems with later releases, I suggest filing a new bug.

Changed in firestarter (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.