Device Pinging in 1.2.0beta

In the new beta, there is a useful device ping output on the device page,

  • type: “‘ping’”

Our devices have two external interfaces, one public, and one private over which all our ACS communication occurs.

In certain situations, we see the ping output to either one of these interfaces, both which are accessible via routing from the Genieacs server.

Is there a way to further control the output, in terms of which interface is used for pinging so we can have consistent use of this feature.

I mispoke; In our case, the ACS server can only reach devices via their private management network; Sometimes Genieacs pings the management IP address, which shows a result; Othertimes it tries to ping the public address, which it would normally not receive a response from.

It pings the host or IP extracted from ConnectionRequestURL parameter which is typically reported by the device on every Inform. So it should always be using the correct IP unless the device is offline and the IP has been recycled.

This makes sense.

I can see the public interface of the ACS server in ConnectionRequestURL parameter, so it looks like a config issue in this environment on my part. Should be a quick fix.

How does the server influence the ConnectionRequestURL, as we want to limit ACS communications to our private ACS network. Is it only using the CWMP_INTERFACE?

In our case, both the ACS server and the CPE have public interfaces, but we want to limit communications to the private ACS network.

Informs from the CPE are travelling the righ path, but the ConnectionRequests seem to find a path on the public interface all on their own even thought the CPE is provisioned with the correct ACS URL.

Ideally, we want to be able to have some devices on a private ACS network and still have a few other off-net devices doing https via specific public internet subnets.

Another observation is that all the Connection Request, ACS Request and other Inform logs in genieacs-cwmp are logged with the private network IP, even though the initial CONNECTION REQUEST traffic from the Summon is travelling via the public interfaces and then followed by ACS Request data travelling over the ACS network.

This sounds like a network and/or device configuration issue.

The network part is pretty straightforwads, here is the scenario we are testing:

ACS Server:
eth0: public interface (firewall restricted, https proxy, allows informs from specific remote networks where we manage only the CPE, also NBI/Admin)
eth1: private cpe management (not routed, restricted for only ACS FS/CWMP)

CPE:
wan0: public interface (firewall restricted, outbound only, currently allows ACS for testing)
wan1: private cpe management (not routed, restricted for only ACS/FS/CWMP)

The idea with the private subnet for ACS is just to simplify security mangement the ACS communications. Elimination of public cwmp/stund listeners across a variety of acs clients is the goal, with the objective of resolving lots of potential resource exhaustion / DoS scenarios on the public listeners for cwmp/stund, particularily with odm-managed bcm/busybox stacks.

In the case where CPEs with a private ACS interface choose to use their routed public interface for the ConnectionRequestURL, they have no knowledge of the ACS server public IP, so the assumption is that they tell the ACS server their CRA URL based on their own interface configuration.

In our case, we would assume the buggy/misconfigured client advertises the ConnectionRequestURL based on enumeration of the interfaces the tr69 client listens on, and in this case, the public interface is the first one, even though they inform from their second, private network interface.

If this is the case, we might try changing the order, to work around this, while we prod upstream to correct.

Some manufactures, even based on the same stack, seem to do this properly, sticking to the private network for Informs and ConnectionRequestURL, even though they have the same basic network configuration. So we have working and non-working scenarios - which is why we originally asked what causes the Ping to show correctly in some cases not realizing the CONNECTION REQUEST were actually using the public network.

Our goals in this thread are to

  1. rule out any part of the ACS Server setting up the ConnectionRequestURL, which I think we have

  2. secondly to point out that the CWMP logging does not take into account the actual IP being used for communication. Normally in a syslog format, is is assumed the ip would match the message header. With GenieACS, it appears that it is coming from something else in the device model or the message body that confuses interpretation of the log.

In our case (substituing public IP for Google) the ConnectionRequestURL is http://8.8.8.8:30005/, but the genieacs-cwmp is logging 10.5.1.203, which is the private listener and inform originator for the CPE.

If support of a multi-homed ACS server or CPE in within scope of GenieACS, tweaking the logs to match the actual IP where the client message originates might be a good improvment for consideration.

If a private network for ACS communication is considered an out of scope model for GenieACS, we should probably give up on trying to take ACS communication out of the public band and find a better way to mitigate risks associated with public interface listeners for acs.