Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[monitoring] Allow to store IP addresses of interfaces in DeviceData.data #30

Closed
nemesifier opened this issue Apr 14, 2020 · 5 comments · Fixed by #64
Closed

[monitoring] Allow to store IP addresses of interfaces in DeviceData.data #30

nemesifier opened this issue Apr 14, 2020 · 5 comments · Fixed by #64

Comments

@nemesifier
Copy link
Member

nemesifier commented Apr 14, 2020

The device status information (accessible via DeviceData.data) stores information about the current status of the device (uptime, memory usage, load averages).

When the device has interfaces (eg LAN or WAN) set in DHCP client mode, there's no way to easily know which address the device got from the DHCP server.

This aims to fix that.

Incoming payoad example:

{
    'type': 'DeviceMonitoring',
    'interfaces': [
        {
            'name': 'br-lan',
            'addresses': [
                {
                    'proto': 'static',
                    'family': 'ipv4',
                    'address': '192.168.1.1',
                    'mask': 24
                },
                {
                    'proto': 'dhcp',
                    'family': 'ipv4',
                    'address': '10.0.0.4',
                    'mask': 24
                }
            ]
        }
    }
}

The schema in openwisp_monitoring.device.schema will have to be updated to include the addresses schema: http://netjson.org/rfc.html#addresses1
The gateway option can be ignored.

If we get a non-wireless interface without any address, we will not store it for now (wireless interfaces are stored anyway, they contain other useful info related to the wireless settings).

Once the data is saved and validated correctly (a few tests will need to ensure bogus addresses will be rejected) we will have to ensure the ip addresses of each interface are shown in the device status tab:
https://github.com/openwisp/openwisp-monitoring/blob/master/openwisp_monitoring/device/templates/admin/config/device/change_form.html#L66-L124

Will require openwisp/openwrt-openwisp-monitoring#1 to be complete.

@nepython
Copy link
Contributor

nepython commented May 1, 2020

I am working on it 😃

@nemesifier
Copy link
Member Author

@nepython do you already have an openwrt device or VM? Coordinate on the gitter channel with @NoumbissiValere and @PabloCastellano, they already have done similar things.

@nepython
Copy link
Contributor

nepython commented May 1, 2020

@nepython do you already have an openwrt device or VM?

No, I don't have an openwrt device currently but I have setup a VM (though I need to configure it correctly).
Is it essential for this PR, if so then I will proceed with configuring it.

Coordinate on the gitter channel with @NoumbissiValere and @PabloCastellano, they already have done similar things.

Sure 😄

nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 1, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 1, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 1, 2020
@nepython
Copy link
Contributor

nepython commented May 1, 2020

When the device has interfaces (eg LAN or WAN) set in DHCP client mode, there's no way to easily know which address the device got from the DHCP server.

@nemesisdesign, can you please give few details on how the addresses need to be refactored to easily retrieve them later. Should I do something similar to what has been done for uptime.

uptime = '{0.days} days, {0.hours} hours and {0.minutes} minutes'
data['general']['uptime'] = uptime.format(
relativedelta(seconds=data['general']['uptime'])

I have created a draft PR here. I am still working on it, created it for reference.

@nemesifier nemesifier added this to In progress in [GSOC20] Monitoring May 1, 2020
@nemesifier
Copy link
Member Author

nemesifier commented May 1, 2020

@nepython just loop over the addresses and show them in a table, eg:

address          |   mask      |   DHCP client?  
192.168.1.2    |  /{mask}   |   yes / no

The difficult part may be to get the correct mask, but we'll deal with that on the openwrt side.

nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 5, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 5, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 5, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 5, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 6, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 7, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 8, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 10, 2020
nepython added a commit to nepython/openwisp-monitoring that referenced this issue May 14, 2020
OpenWISP Contributor's Board automation moved this from To do (general) to Done May 14, 2020
[GSOC20] Monitoring automation moved this from In progress to Done May 14, 2020
pandafy pushed a commit to pandafy/openwisp-monitoring that referenced this issue May 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
2 participants