Project

General

Profile

Bug #919

dynamic gateway handling is broken

Added by Marcus Brown over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Gateways
Target version:
Start date:
09/23/2010
Due date:
% Done:

100%

Estimated time:
Affected Version:
Affected Architecture:

Description

2.0 BETA4, built Sept22, on an ALIX board with a 3G PPP WAN connection defined.

1. I've been reading of the code that handles gateways and specifically monitor IP address. There is one place in the code (only in system_gateways_edit.php) where monitorip is saved to $config['interfaces'][$iface]['monitorip']. When I enter a monitor IP for the WAN gateway entry it doesn't end up in <monitorip> field in wan config in config.xml.

I see one place in the code of gwlib.inc that reads this value (in the return_gateways_array function):

/* retrieve a proper monitor IP? */
$ifcfg =& $config['interfaces'][$ifname];
if (is_ipaddr($ifcfg['monitorip']))
    $gateway['monitor'] = $ifcfg['monitorip'];
else
    $gateway['monitor'] = $gateway['gateway'];

In the functions returned array, I think this code will always write the gateway ip address over whatever is stored in $config['gateways']['gateway_item']['monitor']. I think it's making problems. (Apinger conf relies on this functions returned array, so it may be why when a monitor IP is defined, apinger is still pinging the gateway IP.) Here's my /tmp/apinger.status file:

10.64.64.0|XXX.232.27.100|WAN|2813|0|0|0.000ms|100.0%|down

2. I also saw that when dynamic ppp interface variants are defined from interfaces_ppps_edit.php there is no code anywhere I can see that automatically populates gateway info into the $config['gateways']['gateway_item'] part of the config. This may be okay by design, but I thought I would point it out here.

3. Finally, I'm also seeing very strange monitor ip handling behavior, and inconsistent reporting by pfSense of the monitor ip when I enter an alternate monitor IP for my 3G ppp connection. 

Steps:
Start from a default config and define a PPP, PPPoE, or PPtP interface on interfaces_ppps_edit.php and assign to WAN on interfaces_assign.php

Go to system_gateways_edit.php and open the WAN gateway entry and press save. This causes $config['gateways']['gateway_item'] to be populated like this:

<gateways>
    <gateway_item>
        <interface>wan</interface>
        <gateway></gateway>
        <name>WAN</name>
        <weight>1</weight>
        <descr><![CDATA[Interface WAN Dynamic Gateway]]></descr>
        <defaultgw/>
    </gateway_item>
</gateways>

Then, I add a monitor IP (because the gateway according to PPP is 10.64.64.0 and its not a real IP. After saving the config changes to this. Notice that before and after the monitor IP save the <gateway></gateway> field does not say "dynamic" so that throws off the handling of the monitor ip in the gwlib.inc code.
<gateways>
    <gateway_item>
        <interface>wan</interface>
        <gateway></gateway>
        <name>WAN</name>
        <weight>1</weight>
        <descr><![CDATA[Interface WAN Dynamic Gateway]]></descr>
        <monitor>XX.XX.206.184</monitor>
        <defaultgw/>
    </gateway_item>
</gateways>

Now if I go to the pfSense homepage, the gateway shows as being "Online." Then I go to Status-> Gateways and see this. . . (This info is being pulled from /tmp/apinger.status file.)

Name Gateway Monitor Status Description
WAN 10.64.64.0 10.64.64.0 Offline Interface WAN Dynamic Gateway

Now I go back to system_gateways_edit.php for WAN interface and the Monitor IP field is blank, but the IP address is still in conf.xml!
And on the pfSense dashboard, the gateway is shown as "Offline".

I think this needs a small overhaul. :) Right now the different pages of pfSense that report on gateway status pull info from different places, and the system_gateways_edit.php page pulls a combination of info directly from $config['gateways']['gateway_item'] and the return_gateways_array function. :)

apinger.conf.txt (2.21 KB) apinger.conf.txt Marcus Brown, 09/23/2010 04:19 AM

Associated revisions

Revision 58611e3a (diff)
Added by Marcus Brown over 8 years ago

Fixes #919 by properly saving <gateway> field as "dynamic"

`

Revision e0df9716 (diff)
Added by Marcus Brown over 8 years ago

cbuechler says monitorip should not be stored in <interfaces><$if>. See ticket #919

Revision 80a5b5f7 (diff)
Added by Marcus Brown over 8 years ago

We don't store monitor ip in the <interfaces> config any more.

Requested by cbuechler in ticket #919.

History

#1 Updated by Marcus Brown over 8 years ago

I just tested saving a monitor ip on the OPT3 interface on the monitorip field did end up in the [interfaces][opt] section of config.xml, but it's not working with WAN still.

#2 Updated by Marcus Brown over 8 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#3 Updated by Marcus Brown over 8 years ago

This is still partially broken. After my commit, it saves properly, but you can't unset(delete) the monitor ip because of code in system_gateways_edit.php that is trying to handle monitor ip as a special case for dynamic gateways.

Also, scratch the comment above (in the original report) that reads "I think this code will always write the gateway ip address over whatever is stored in $config['gateways']['gateway_item']['monitor']. I think it's making problems."
It's not the problem at all. I missed something in reading that function code so that comment is invalid.

Basically, this monitorip stuff seems overly complicated. It seems unnecessary to bother with storing monitorip in the $config[interfaces][iface] section of config.xml. It's seems simpler to just store gateway info in one place if user wants to edit gateway info, or add gateway info to a dynamic system gateway.

#4 Updated by Chris Buechler over 8 years ago

The monitor IP should never be associated with an interface, sounds like there are still bits of that issue around (it's largely fixed from where it started).

#5 Updated by Marcus Brown over 8 years ago

I'm working on this issue.

#6 Updated by Ermal Luçi over 8 years ago

  • Status changed from Feedback to Resolved

It has been working correctly for several snapshots now.

Also available in: Atom PDF