Bug 10007

Summary:	Static routes will not apply at boot.
Product:	IPFire	Reporter:	Arne.F <arne.fitzenreiter>
Component:	network	Assignee:	Michael Tremer <michael.tremer>
Status:	CLOSED FIXED	QA Contact:
Severity:	- Unknown -
Priority:	- Unknown -	CC:	mathias
Version:	2
Hardware:	unspecified
OS:	Unspecified
Attachments:	Fix for static routing

Description Arne.F 2012-01-23 18:11:30 UTC

Many user has reported this.
I think the initskript was running to erly so it could not set the routes because the interfaces are not up or have no matching ip.

Mabee we have als to call the script after every dialup connect.

Comment 1 Michael Tremer 2012-01-23 22:39:50 UTC

I added two additional connection hooks that reload all rules when the RED connection goes either up or down:

http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=b4c77ffb891f956f2b3c017bd55090a57e3b9862

Comment 2 Michael Tremer 2012-01-24 18:48:19 UTC

Arne, who could test the changes?

Comment 3 Mathias Schneuwly 2012-02-02 22:39:54 UTC

Core: 56

I can't confirm this fix!

After restart of IPFire, static routes are not applied. The checkbox in the webgui is enabled but not static routes are enabled. After unchecking (just one is enough, if more than one are configured) and checking it again, then they are applied.

I'm using static routes on the green interface.

I added a new symlink in rc3.d called "S97staticroutes", which points to "/etc/rc.d/init.d/static-routes" to solve this issue.

Can you please add something similar to IPFire?

Comment 4 Michael Tremer 2012-02-03 18:55:52 UTC

I just changed back the status to MODIFIED because I could not understand the old state.

Please help me to understand you proposed solution. Why would that help if the routes would be applied at nearly the end of the boot process? I can think of some services that already may need them at this place.

Comment 5 Mathias Schneuwly 2012-02-03 23:41:53 UTC

Sorry about the strange status, but I was not allowed to reopen this issue... I could only choose between resolved and verified.

Well I found out, that applying static routes will fail if no interface is present.

If I invoked "/etc/rc.d/init.d/static-routes start" after bringing up the green interface, then it worked. A possible solution could be to add static routes at the end of the start section in S20network?

Comment 6 Michael Tremer 2012-02-04 11:09:29 UTC

(In reply to comment #5)
> Sorry about the strange status, but I was not allowed to reopen this issue... I
> could only choose between resolved and verified.

Yes, that was right. It was a misconfiguration of Bugzilla and I fixed that already.

> Well I found out, that applying static routes will fail if no interface is
> present.

Yes, that is right and so we are adding them after the red network comes up. That should be fairly the end of the network startup process.

> If I invoked "/etc/rc.d/init.d/static-routes start" after bringing up the green
> interface, then it worked. A possible solution could be to add static routes at
> the end of the start section in S20network?

That is where it now should be. Could you submit a patch?

Comment 7 Mathias Schneuwly 2012-02-04 13:48:12 UTC

Created attachment 14 [details]
Fix for static routing

Patch file added to this bug report.

Regards

Comment 8 Michael Tremer 2012-02-05 22:00:41 UTC

Arne pointed me to that the files I added were not properly included in the update. New installations will have the fix, but so updated don't.

Original commit: http://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=b4c77ffb891f956f2b3c017bd55090a57e3b9862

He has already fixed that: http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=184bee29d09351f9b47876c785027dc5b4c264ab

Could you check if you have those files in your system?

Comment 9 Mathias Schneuwly 2012-02-05 22:37:56 UTC

No, I don't have these files in my core 56 installation!

I copied them to my IPFire and it seems to work too.

Comment 10 Mathias Schneuwly 2012-02-20 21:07:37 UTC

Core: 57-testing

I restarted my Fire several times and I always got my static routes. For me, the problem is solved with the new core update and the bug report can be closed.