WO2021163825A1

WO2021163825A1 - Method and system for obtaining listening ports of a device under test

Info

Publication number: WO2021163825A1
Application number: PCT/CN2020/075487
Authority: WO
Inventors: Dongting ZHANG; Linzhou CAI; Ruilu ZENG; Shenxia TAN
Original assignee: Arris Enterprises Llc
Priority date: 2020-02-17
Filing date: 2020-02-17
Publication date: 2021-08-26

Abstract

A method and system are disclosed for identify listening ports on a device under test (DUT). The method includes sending a Get Request to the device under test; triggering a netstat command on the device under test upon receipt of the Get Request; executing the netstat command on the device under test and obtaining netstat output; and storing a list of listening ports from the netstat output on the device under test.

Description

METHOD AND SYSTEM FOR OBTAINING LISTENING PORTS OF A DEVICE UNDER TEST

TECHNICAL FIELD

The present disclosure generally relates generally to a method and system for obtaining listening ports of a device under test (DUT) , for example, for multiple system operators (MSO) .

BACKGROUND

Cable service providers, which are also referred to as Multiple System Operators ( “MSO” ) , or any communication or content distribution business that operates through a cable network, renders its services to its subscribers. The services can include, but are not limited to, different subscription plans for broadband Internet access and telephony. In order to consume these services, subscribers connect to a private network owned (or co-owned or rented) by the broadband cable operator which is implemented according to the Data Over Cable Service Interface Specification (DOCSIS) standard.

Subscribers connect their computers, routers, voice-over-IP telephones and other devices to this network through the network terminals, for example, cable modems (CM) or network gateways. The network terminals, for example, cable modems (CM) or network gateways include hardware which runs software that provides the low-level control for the device's specific hardware, which is known as firmware, which can be updated by pushing a new firmware version (or image) from time to time to the network gateway, for example, the cable modem (CM) or gateway.

A port scan is an important security test, however, full range port scans (for example, scanning Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports 0-65535 on each DUT interface) can be very time-consuming (for example, the full range ports scan be as long as 20 hours for some interfaces) . The port scan is generally an application designed to probe a server or host, for example, a device under test (DUT) for open ports (e.g., listening ports) configured to accept packets. Generally, a port scan application can be used to verify security policies on networks and/or devices to identify networks services running on a host and exploit vulnerabilities.

The port concept specifically relates to data transferred across networks by the TCP/IP protocol suite (Transmission Control Protocol/Internet Protocol) . A series of standards explain how data should be packaged and addressed to reach their destination, which involves dividing up the data into segments and then placing each data segment in a structure called a packet. The packet has a header where the network protocols store information for their receiving counterpart. The last header to go onto the packet is the IP header, which contains the address of the destination computer. The IP header goes in front of the transport header, which is where the port number of the receiving application is written.

Knowing a DUT's listening ports can be a desirable requirement for multiple system operators (MSOs) , and more particularly, software quality assurance (SQA) for multiple system operators (MSOs) . For example, if a software quality analyst for a MSO or a SQA system knows the DUT's listening ports of the device under test (DUT) , only those specific ports need to be scanned, which can save time.

Generally, software quality assurance (SQA) is a process that helps ensure that developed software meets and complies with defined or standardized quality specifications. For example, SQA is an ongoing process within the software development life cycle (SDLC) that routinely checks the developed software to ensure it meets desired quality measures.

The only way to currently know a DUT's listening port is, for example, by running a "netstat" command from the DUT's shell. netstat (network statistics) is a command line tool for monitoring network connections both incoming and outgoing as well as viewing routing tables, interface statistics, etc. netstat can be available on all Unix-like Operating Systems and is also available on Windows OS.

SUMMARY

In accordance with exemplary embodiments, since access to shell of a device under test (e.g., DUT's shell) access is unavailable on production units, for example, of customer-premise equipment or customer-provided equipment (CPE) broadband devices, it would be desirable to have a method and system for software quality analyst, for example, of a MSO, or a SQA system can obtain a DUT's listening ports and netstat information without depending on DUT's shell access, and wherein the method will not impact the performance of the computer processing unit (CPU) of the DUT.

In accordance with an aspect, a method for identify listening ports on a device under test (DUT) , the method comprising: sending a Get Request to the device under test; triggering a netstat command on the device under test upon receipt of the Get Request; executing the netstat command on the device under test and obtaining netstat output; and storing a list of the listening ports from the netstat output on the device under test.

In accordance with an another aspect, a system for identifying listening ports on devices under test, the system comprising: a device under test; a multiple system operator (MSO) or a software quality assurance (SQA) system configured to send a Get Request to the device under test, and upon receipt of the Get Request on the device under test, the device under test is configured to execute a netstat command on the device under test and obtain netstat output, and wherein a list of listening ports from the netstat output is stored on the device under test.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of an exemplary network environment for a system and method for obtaining listening ports of a device under test (DUT) , for example, for a multiple system operator (MSO) .

FIG. 2 is a flowchart illustrating an exemplary method for obtaining listening ports of a device under test (DUT) and netstat information.

FIG. 3 is a flowchart illustrating another exemplary method for obtaining listening ports of a device under test (DUT) and netstat information.

FIG. 4 is an exemplary hardware architecture for an embodiment of a communication device.

DETAILED DESCRIPTION

System for obtaining listening ports of a device under test (DUT) and netstat information

FIG. 1 is a block diagram illustrating an example network environment 10 for obtaining listening ports of a device under test (DUT) and netstat information. In embodiments, a device under test (DUT) is used in engineering or the design phase that describes a product that is still undergoing testing. For example, as shown in FIG. 1, a multiple server provider (MSO) 110 can deploy a plural of field devices or customer-premise equipment or customer-provided equipment (CPE) broadband devices 120 in the field that can include, for example, a network gateway 120 or a set-top box 130c. In accordance with an exemplary embodiment, a set-top box 130c can be, for example, a cable box that generally contains a TV-tuner input and displays output to a television set and an external source of signal, tuning the source signal into content in a form that can then be displayed on the television screen, for example, 130e’ or

other display device

130a, 130b, 130d.

In accordance with an exemplary embodiment, the network gateway 120 or set-top box 130c can provide, for example, video and/or data services to a plurality of

devices

130a, 130b, 130d, 130e, 130e’ . The network gateway 120 may communicate with the plurality of

devices

130a, 130b, 130c, 130d, 130e, 130e’ over a local network 132 (for example, a local area network (LAN) , a wireless local area network (WLAN) , a personal area network (PAN) , etc. ) and/or wired, for example, a television 130e connected to a modem (for example, a set-top box) 120, and may communicate with an upstream wide area network (WAN) 160 through a connection 150 to a cable provider 110. The cable provider 110 can provide high-bandwidth data transfer, for example, cable television and broadband internet access via, for example, coaxial cables 140. The cable provider 110 can include one or more servers 112 configured to deliver services, for example, cable television and/or broadband internet and infrastructure supporting such services including management of image software and/or firmware.

In accordance with an exemplary embodiment, the network gateway 120 and the plurality of

devices

130a, 130b, 130c, 130d, 130e, 130e’ are field devices, or customer-premise equipment or customer-provided equipment (CPE) broadband devices. The plurality of

devices

130a, 130b, 130c, 130d, 130e, 130e’ may be any type of computing device configured to connect via a wireless network, for example, wireless network utilizing an IEEE 802.11 specification, including a set-top box (STB) , a smart phone, a smart TV, a computer, a mobile device, a tablet, a router, a home security system, or any other device operable to communicate wirelessly with the network gateway 120. The network gateway 120 may provide access to an external network, such as the Internet, for any devices connected thereto via the area network 132. The area network 132 may be, for instance a local area. In accordance with an exemplary embodiment, the network gateway 120 may be a gateway device, an access point, a modem, a wireless router including an embedded modem, a wireless network extender or any other device operable to deliver, for example, data and/or video services from the provider 110 and/or a wide area network (WAN) 160 to one or more of the plurality of

devices

130a, 130b, 130c, 130d, 130e, 130e’.

In accordance with an exemplary embodiment, the network gateway 120 may communicate with the provider 110 over a wired or a wireless connection. A wireless connection between the provider 110 and the network gateway 120 may be established through a protected setup sequence (for example, Wi-Fi protected setup (WPS)) . The protected setup sequence may include the steps of scanning multiple wireless channels for an available access point, exchanging one or more messages between a station and access point, exchanging key messages (for example, pre-shared key (PSK) ) between the station and access point, and installing a key (for example, PSK) at the station.

Process for obtaining listening ports and netstat information

FIG. 2 is a flowchart 200 illustrating an exemplary method for obtaining listening ports of a device under test (DUT) and netstat information for multiple system operators (MSO) , which includes adding a new management information base (MIB) and/or a TR181 parameter can be added to show DUT's listening ports in real time. For example, full range port scanning can be extremely time-consuming. In addition, a production device under test (DUT) generally does not support shell access which can prevents, for example, a MSO or SQA from using netstat in shell to obtain the listening ports.

In accordance with an exemplary embodiment, the listening ports and other netstat information can be shown via MIB/TR181, which can be used to save time, for example, in a port scan test, for both MSO and SQA. In accordance with an exemplary embodiment, Simple Network Management Protocol (SNMP) and TR069/USP are MSO management interfaces which are relatively safe to store the netstat output. In addition, excessive CPU usage can be avoided, by running netstat in the background (and without user intervention) , and which is triggered only when, for example, a user sends a Get Request to the device under test (DUT) .

In accordance with an exemplary embodiment, the management information base (MIB) is a database used for managing the entities in a communication network. MIB is most often associated with the Simple Network Management Protocol (SNMP) , and, for example, in contexts such as in an OSI/ISO Network management model. While intended to refer to the complete collection of management information available on an entity, MIB is often used to refer to a particular subset, more correctly referred to as MIB-module.

In accordance with an exemplary embodiment, for example, a full TCP range port scan can be about 4 hours for some DUT interfaces and a full UDP range port scan can be about 20 hours for some DUT interfaces. In accordance with an exemplary embodiment, the method as disclosed in which the DUT's listening ports are known, the TCP/UDP port scan on the DUT interface can take only several minutes.

In accordance with an exemplary embodiment, the device under test (DUT) 120, 130c, includes a netstat command (i.e., netstat) , for example, in the operating system (OS) of the device under test (DUT) . In accordance with an exemplary embodiment, the netstat command is only triggered, for example, when the device under test receives a Get Request from the user, for example, a MSO and/or SQA system. As shown in FIG. 2, in step 210, a Get Request, for example, a snmpget request or aTR069/USP GetParameterValues request is sent to the device under test (DUT) 120, 130c. In step 220, the Get Request, for example, the snmpget request or TR069/USP GetParameterValues request triggers the netstat command for execution on the device under test. In step 230, the netstat output is stored in the management information base (MIB) or the TR181 parameter, accordingly. In step 240, when the MSO and/or SQA system wishes to run, for example, a port scan test to determine the status of an Internet facing service or firewall, the netstat output from step 230 can be retrieved. In accordance with an exemplary embodiment, for example, the netstat output from step 230 can provide the user access to the listening ports, for example, via SNMP access or TR069/USP access. The netstat output can also be used to identify the listening ports on the device under test and other netstat information when shell access is not allowed on the device under test. In addition, the listening ports and netstat information can be used for port scan tests and other security audits on the device under test.

In accordance with an exemplary embodiment, for example, the impact of sending a snmpget request or TR069/USP GetParameterValues request on CPU usage can be almost ignored since netstat command is only triggered when DUT receives the Get Request (e.g., snmpget request or TR069/USP GetParameterValues request) .

In accordance with an exemplary embodiment, an exemplary of the standard netstat output on the device under test (DUT) 120, 130c, which can be organized in table format as follows:

#netstat–antu

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 0.0.0.0: 139 0.0.0.0: * LISTEN

tcp 0 0 192.168.254.254: 111 0.0.0.0: * LISTEN

tcp 0 0 127.0.0.1: 111 0.0.0.0: * LISTEN

tcp 0 0 192.168.254.254: 38262 0.0.0.0: * LISTEN

tcp 0 0 0.0.0.0: 445 0.0.0.0: * LISTEN

tcp 0 0 0.0.0.0: 5150 0.0.0.0: * LISTEN

tcp 0 0 192.168.254.254: 836 192.168.254.253: 59757

ESTABLISHED

tcp 0 0 : : : 23 : : : * LISTEN

udp 0 0 0.0.0.0: 56835 0.0.0.0: *

udp 0 0 192.168.254.254: 57895 0.0.0.0: *

(more to display)

In accordance with an exemplary embodiment, as shown, for example, as shown in FIG. 3, for DOCSIS products, two (2) new MIB tables can be added to store the TCP/UDP listening ports shown in the netstat output. For example, MIB_1 can be used to store all the listening TCP ports on the

DUT

120, 130c. In accordance with an exemplary embodiment, the type is string, for example, 22, 23, 80, 443. MIB_2 can be used to store all the listening UDP ports on the

DUT

120, 130c. The type is string, for example, 161, 56835.

In accordance with an exemplary embodiment, for example, for non-DOCSIS products (for example, a standalone router) , two (2) new TR181 parameters can be added to store the TCP/UDP listening ports shown in netstat output, similar to the MIB_1 and MIB_2.

In accordance with an exemplary embodiment, when the DUT 120, 130 receives a snmpget request on the new MIB, or TR-069/USP GetParameterValues request on the new TR181 parameter, the

DUT

120, 130c, runs command “netstat -ant” (displaying listening TCP ports) or “netstat -anu” (displaying listening UDP ports) in the background. If the

DUT

120, 130c has both ARM and ATOM as in Intel-based modems, or CM and RG for Broadcom-based (BRCM-based) modems, the netstat command can be run on both ARM/ATOM sides in an Intel-based modem, or alternatively, the netstat command can be run on both CM/RG sides in a BRCM-based modem.

In accordance with an exemplary embodiment, the real-time TCP and UDP listening ports from netstat output are stored in the new MIBs or TR181 parameters, respectively. Accordingly, for example, the impact of the exemplary method on computer processor unit (CPU) usage can be almost ignored since the netstat command is only triggered when the

DUT

120, 130c receives the Get Request.

FIG. 3 is a flowchart 300 illustrating another exemplary method for obtaining listening ports of a device under test (DUT) 120, 130c and netstat information. As shown in FIG. 3, in step 310, the MIB or TR181 on the device under test (DUT) 120, 130c is queried to get the listening ports. In step 320, a determination is made between TCP ports or UDP ports, for example, MIB_1 or TR181 parameter 1 for TCP ports or MIB_2 or TR181 parameter 2 for UDP ports. If the determination in step 320 is made that the queried listening ports are MIB_1 or TR181 parameter 1 for TCP ports, the process continues to step 330 where the run “netstat-ant’ from the shell (for example, ARM/ATOM) of the

DUT

120, 130c is triggered. In step 332, the listening TCP ports are extracted and stored in MIB_1 or TR181.

In accordance with an exemplary embodiment, if the determination in step 320 is made that the queried listening ports are MIB_2 or TR181 parameter 2 for UDP ports, the process continues to step 340 where the run “netstat-anu’ from the shell (for example, ARM/ATOM) of the

DUT

120, 130c is triggered. In step 332, the listening UDP ports are extracted and stored in MIB_2 or TR181.

In accordance with an exemplary embodiment, after

steps

332, 342, the process continues to step 350 where the Multiple System Operators (MSO) can use the port list to execute a TCP and/or UDP port scan.

Experimental Results and Benefits

In accordance with an exemplary embodiment, an example is illustrated, which shows the difference between full range port scan and specific range port scan (i.e., only scan the listening ports from netstat) , in terms of time and the number of ports.

Example 1: Hardware: TG1672G/TW Firmware: TS9.1.103J8C

Table 1. Scanned ports number for TCP port scan: full range port scan vs. specific range port scan.

	Full range	Specific range
Scanned TCP ports #	65535 ports	17 ports

Table 2. Time for TCP port scan: full range port scan vs. specific range port scan.

Example 2: Hardware: TG862G/CT Firmware: TS9.1.103M2AQ

Table 3. Scanned ports number for UDP port scan: full range port scan vs. specific range port scan

	Full range	Specific range
Scanned UDP ports #	65535 ports	12 ports

Table 4. Time for UDP port scan: full range port scan vs. specific range port scan

For non-DOCSIS products (for example, a standalone router) , the two (2) TR181 tables can contain, for example, different parameters for each column of the netstat output table, similar to the MIB implementation.

For example, in accordance with an exemplary embodiment, UDP versus TCP for Voice over IP (VoIP) . In VoIP, audio samples are placed into data packets for transmission over the IP network. In accordance with an exemplary embodiment, a single packet can contain anywhere from 10 milliseconds to 30 milliseconds of audio. TCP and UDP are two of the most commonly used connection protocols used for data traversal across the Internet.

Computer System Architecture

FIG. 4 illustrates a representative computer system 400 in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, the one or more servers 112, the network gateway 120, and the plurality of

devices

130a, 130b, 130c, 130d, 130e, 130e’ of FIG. 1 may be implemented in whole or in part by a computer system 300 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may embody modules and components used to implement the methods and steps of the present invention.

If programmable logic is used, such logic may execute on a commercially available processing platform configured by executable software code to become a specific purpose computer or a special purpose device (for example, programmable logic array, application-specific integrated circuit, etc. ) . A person having ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device. For instance, at least one processor device and a memory may be used to implement the above described embodiments.

A processor unit or device as discussed herein may be a single processor, a plurality of processors, or combinations thereof. Processor devices may have one or more processor “cores. ” The terms “computer program medium, ” “non-transitory computer readable medium, ” and “computer usable medium” as discussed herein are used to generally refer to tangible media such as a removable storage unit 418, a removable storage unit 422, and a hard disk installed in hard disk drive 412.

Various embodiments of the present disclosure are described in terms of this representative computer system 400. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the present disclosure using other computer systems and/or computer architectures. Although operations may be described as a sequential process, some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

Processor device 404 may be a special purpose or a general purpose processor device specifically configured to perform the functions discussed herein. The processor device 404 may be connected to a communications infrastructure 406, such as a bus, message queue, network, multi-core message-passing scheme, etc. The network may be any network suitable for performing the functions as disclosed herein and may include a local area network ( “LAN” ) , a wide area network ( “WAN” ) , a wireless network (e.g., “Wi-Fi” ) , a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency ( “RF” ) , or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. The computer system 400 may also include a main memory 408 (e.g., random access memory, read-only memory, etc. ) , and may also include a secondary memory 410. The secondary memory 410 may include the hard disk drive 412 and a removable storage drive 414, such as a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.

The removable storage drive 414 may read from and/or write to the removable storage unit 418 in a well-known manner. The removable storage unit 418 may include a removable storage media that may be read by and written to by the removable storage drive 414. For example, if the removable storage drive 414 is a floppy disk drive or universal serial bus port, the removable storage unit 418 may be a floppy disk or portable flash drive, respectively. In one embodiment, the removable storage unit 418 may be non-transitory computer readable recording media.

In some embodiments, the secondary memory 410 may include alternative means for allowing computer programs or other instructions to be loaded into the computer system 400, for example, the removable storage unit 422 and an interface 420. Examples of such means may include a program cartridge and cartridge interface (e.g., as found in video game systems) , a removable memory chip (e.g., EEPROM, PROM, etc. ) and associated socket, and other removable storage units 422 and interfaces 420 as will be apparent to persons having skill in the relevant art.

Data stored in the computer system 400 (e.g., in the main memory 408 and/or the secondary memory 410) may be stored on any type of suitable computer readable media, such as optical storage (e.g., a compact disc, digital versatile disc, Blu-ray disc, etc. ) or magnetic tape storage (e.g., a hard disk drive) . The data may be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and storage types will be apparent to persons having skill in the relevant art.

The computer system 400 may also include a communications interface 424. The communications interface 424 may be configured to allow software and data to be transferred between the computer system 400 and external devices. Exemplary communications interfaces 424 may include a modem, a network interface (e.g., an Ethernet card) , a communications port, a PCMCIA slot and card, etc. Software and data transferred via the communications interface 424 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals as will be apparent to persons having skill in the relevant art. The signals may travel via a communications path 426, which may be configured to carry the signals and may be implemented using wire, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, etc.

The computer system 400 may further include a display interface 402. The display interface 402 may be configured to allow data to be transferred between the computer system 400 and external display 430. Exemplary display interfaces 402 may include high-definition multimedia interface (HDMI) , digital visual interface (DVI) , video graphics array (VGA) , etc. The display 430 may be any suitable type of display for displaying data transmitted via the display interface 402 of the computer system 400, including a cathode ray tube (CRT) display, liquid crystal display (LCD) , light-emitting diode (LED) display, capacitive touch display, thin-film transistor (TFT) display, etc.

Computer program medium and computer usable medium may refer to memories, such as the main memory 408 and secondary memory 410, which may be memory semiconductors (e.g., DRAMs, etc. ) . These computer program products may be means for providing software to the computer system 400. Computer programs (e.g., computer control logic) may be stored in the main memory 408 and/or the secondary memory 410. Computer programs may also be received via the communications interface 424. Such computer programs, when executed, may enable computer system 400 to implement the present methods as discussed herein. In particular, the computer programs, when executed, may enable processor device 404 to implement the methods illustrated by FIGS. 1-3, as discussed herein. Accordingly, such computer programs may represent controllers of the computer system 400. Where the present disclosure is implemented using software executed on hardware, the software may be stored in a computer program product and loaded into the computer system 400 using the removable storage drive 414, interface 420, and hard disk drive 412, or communications interface 424.

The processor device 404 may comprise one or more modules or engines configured to perform the functions of the computer system 400. Each of the modules or engines may be implemented using hardware and, in some instances, may also utilize software executed on hardware, such as corresponding to program code and/or programs stored in the main memory 408 or secondary memory 410. In such instances, program code may be compiled by the processor device 404 (e.g., by a compiling module or engine) prior to execution by the hardware of the computer system 400. For example, the program code may be source code written in a programming language that is translated into a lower level language, such as assembly language or machine code, for execution by the processor device 404 and/or any additional hardware components of the computer system 400. The process of compiling may include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed translation, code generation, code optimization, and any other techniques that may be suitable for translation of program code into a lower level language suitable for controlling the computer system 400 to perform the functions disclosed herein. It will be apparent to persons having skill in the relevant art that such processes result in the computer system 400 being a specially configured computer system 400 uniquely programmed to perform the functions discussed above.

Techniques consistent with the present disclosure provide, among other features, systems and methods for reducing service impact to users during image and/or firmware changes. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the disclosure, without departing from the breadth or scope.

Claims

A method for identify listening ports on a device under test (DUT) , the method comprising:

sending a Get Request to the device under test;

triggering a netstat command on the device under test upon receipt of the Get Request;

executing the netstat command on the device under test and obtaining netstat output; and

storing a list of the listening ports from the netstat output on the device under test.
The method according to claim 1, further comprising

retrieving the netstat output from the device under test for a port scan or a security audit of the device under test.
The method according to claim 1, further comprising:

triggering the netstat command on the device under test only upon receipt of the Get Request.
The method according to claim 1, wherein the Get Request is a snmpget request or a TR069/USP GetParameterValues request.
The method according to claim 4, further comprising:

storing the list of listening ports in a management information base (MIB) on the device under test.
The method according to claim 4, further comprising;

storing the list of listening ports in a TR181 parameter on the device under test.
The method according to claim 1, further comprising:

receiving the Get Request from a multiple system operator (MSO) or a software quality assurance (SQA) system;

sending a port scan request from the MSO or the SQA system to the device under test; and

executing the port scan on the device under test using the netstat output.
The method according to claim 7, wherein the port scan is a Transmission Control Protocol (TCP) port scan and/or a User Datagram Protocol (UDP) port scan.
The method according to claim 1, wherein the device under test is a Data Over Cable Service Interface Specification (DOCSIS) product, the method further comprising:

adding two management information bases (MIBs) to the device under test to store the netstat output, the two management information bases (MIBs) configured to store a list of Transmission Control Protocol (TCP) listening ports and a list of User Datagram Protocol (UDP) listening ports.
The method according to claim 1, wherein the device under test is a not a Data Over Cable Service Interface Specification (DOCSIS) product, the method further comprising:

adding two TR181 parameters to the device under test to store the netstat output, and the two TR181 parameters configured to store a list of Transmission Control Protocol (TCP) listening ports and a list of User Datagram Protocol (UDP) listening ports.
The method according to claim 1, when the device under test receives the Get Request, the method comprising:

running a command “netstat-ant” or “netstat-anu” in the background of the device under test.
The method according to claim 1, wherein the device under test is a customer-premise equipment or customer-provided equipment (CPE) broadband devices, the method further comprising:

providing the customer-premise equipment or customer-provided equipment broadband devices with Simple Network Management Protocol (SNMP) access or TR069/USP access.
The method according to claim 1, wherein shell access to the device under test is not allowed.
A system for identifying listening ports on devices under test, the system comprising:

a device under test;

a multiple system operator (MSO) or a software quality assurance (SQA) system configured to send a Get Request to the device under test, and

upon receipt of the Get Request on the device under test, the device under test is configured to execute a netstat command on the device under test and obtain netstat output, and wherein a list of listening ports from the netstat output is stored on the device under test.
The system according to claim 14, wherein the multiple system operator (MSO) or the software quality assurance (SQA) system is configured to retrieve the netstat output from the device under test for a port scan or a security audit of the device under test.
The system according to claim 14, wherein the netstat command is triggered on the device under test only upon receipt of the Get Request.
The system according to claim 14, wherein the Get Request is a snmpget request or a TR069/USP GetParameterValues request, and the netstat output is stored in a management information base (MIB) or a TR181 parameter on the device under test.
The system according to claim 14, wherein the device under test is a Data Over Cable Service Interface Specification (DOCSIS) product, and the netstat output is stored on two management information bases (MIBs) on the device under test, the two management information bases (MIBs) configured to store a list of Transmission Control Protocol (TCP) listening ports and a list of User Datagram Protocol (UDP) listening ports.
The system according to claim 14, wherein the device under test is a not a Data Over Cable Service Interface Specification (DOCSIS) product, and the netstat output is stored on two TR181 parameters on the device under test, the two TR181 parameters configured to store a list of Transmission Control Protocol (TCP) listening ports and a list of User Datagram Protocol (UDP) listening ports.
The system according to claim 14, wherein the device under test is a customer-premise equipment or customer-provided equipment (CPE) broadband devices, and the customer-premise equipment or customer-provided equipment broadband devices has Simple Network Management Protocol (SNMP) access or TR069/USP access.