Collect all IP addresses on eth0

[JarryShaw]

Motivation

• Please give a brief description for the background of this change.
• Issue number: Add cli/json parsing to fleet provisioning collect system info flag #456

As discovered internally by our team, on certain devices, there might be multiple IP addresses associated on interface eth0.

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet xx.xx.xx.xx/16 scope link eth0
       valid_lft forever preferred_lft forever
    inet xx.xx.xx.xx/23 brd xx.xx.xx.xx scope global eth0
       valid_lft forever preferred_lft forever

This change will collect all of these IP addresses on the eth0 interface and send them altogether to the pre-provisioning Lambda instance for further processing.

NOTE: I was unable to figure out a programming approach to distinguish the two IP addresses as listed above. The address with scope global is the one we're looking for. However, it seems that the stdlib doesn't provide any info and/or API to check that. Should anyone have a better idea, do please let us know.

Modifications

Change summary

Please describe what changes are included in this pull request.

Collect all IP addresses on eth0 interface and format them as a comma separated string. Also updating the parameter key name from DeviceIPAddress to DeviceIPAddresses for backward compatibility.

Revision diff summary

If there is more than one revision, please explain what has been changed since the last revision.

Testing

Is your change tested? If not, please justify the reason.
Please list your testing steps and test results.

• CI test run result:

Tested on the above described camera and the provisioning was successful.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[HarshGandhi-AWS]

Hey @JarryShaw , How was this change tested and what about other IP addresses stored in eth1 or eth2? Hard-coding the logic to only fetch eth0 IP addresses as per your requirements would not be the best way of coding over here since other Device Client users might not need eth0 IP addresses or might require some other IP addresses. We should have a generalized way of fetching system details which can be used by different users for their different use cases.

[JarryShaw]

Hi @HarshGandhi-AWS , thanks for the comments. We've just pushed another commit to address the hardcoded network interface issue. We're proposing to add a network-interface configuration (JSON & CLI) to allow users to specify which network interface they're expecting to collect this information, while for backward compatibility, this configuration value will be default to eth0.