【代码保留】How to match the IP Address

Kconfig如下 开启哪些可以配置tcp_delack_min # # IP configuration # config IP_MULTICAST bool "IP: multicasting" help This is code for addressing several networked computers at once, enlarging your kernel by about 2 KB. You need multicasting if you intend to participate in the MBONE, a high bandwidth network on top of the Internet which carries audio and video broadcasts. More information about the MBONE is on the WWW at <http://www.savetz.com/mbone/>. For most people, it's safe to say N. config IP_ADVANCED_ROUTER bool "IP: advanced router" ---help--- If you intend to run your Linux box mostly as a router, i.e. as a computer that forwards and redistributes network packets, say Y; you will then be presented with several options that allow more precise control about the routing process. The answer to this question won't directly affect the kernel: answering N will just cause the configurator to skip all the questions about advanced routing. Note that your box can only act as a router if you enable IP forwarding in your kernel; you can do that by saying Y to "/proc file system support" and "Sysctl support" below and executing the line echo "1" > /proc/sys/net/ipv4/ip_forward at boot time after the /proc file system has been mounted. If you turn on IP forwarding, you should consider the rp_filter, which automatically rejects incoming packets if the routing table entry for their source address doesn't match the network interface they're arriving on. This has security advantages because it prevents the so-called IP spoofing, however it can pose problems if you use asymmetric routing (packets from you to a host take a different path than packets from that host to you) or if you operate a non-routing host which has several IP addresses on different interfaces. To turn rp_filter on use: echo 1 > /proc/sys/net/ipv4/conf/<device>/rp_filter or echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter Note that some distributions enable it in startup scripts. For details about rp_filter strict and loose mode read <file:Documentation/networking/ip-sysctl.txt>. If unsure, say N here. config IP_FIB_TRIE_STATS bool "FIB TRIE statistics" depends on IP_ADVANCED_ROUTER ---help--- Keep track of statistics on structure of FIB TRIE table. Useful for testing and measuring TRIE performance. config IP_MULTIPLE_TABLES bool "IP: policy routing" depends on IP_ADVANCED_ROUTER select FIB_RULES ---help--- Normally, a router decides what to do with a received packet based solely on the packet's final destination address. If you say Y here, the Linux router will also be able to take the packet's source address into account. Furthermore, the TOS (Type-Of-Service) field of the packet can be used for routing decisions as well. If you need more information, see the Linux Advanced Routing and Traffic Control documentation at <http://lartc.org/howto/lartc.rpdb.html> If unsure, say N. config IP_ROUTE_MULTIPATH bool "IP: equal cost multipath" depends on IP_ADVANCED_ROUTER help Normally, the routing tables specify a single action to be taken in a deterministic manner for a given packet. If you say Y here however, it becomes possible to attach several actions to a packet pattern, in effect specifying several alternative paths to travel for those packets. The router considers all these paths to be of equal "cost" and chooses one of them in a non-deterministic fashion if a matching packet arrives. config IP_ROUTE_VERBOSE bool "IP: verbose route monitoring" depends on IP_ADVANCED_ROUTER help If you say Y here, which is recommended, then the kernel will print verbose messages regarding the routing, for example warnings about received packets which look strange and could be evidence of an attack or a misconfigured system somewhere. The information is handled by the klogd daemon which is responsible for kernel messages ("man klogd"). config IP_ROUTE_CLASSID bool config IP_PNP bool "IP: kernel level autoconfiguration" help This enables automatic configuration of IP addresses of devices and of the routing table during kernel boot, based on either information supplied on the kernel command line or by BOOTP or RARP protocols. You need to say Y only for diskless machines requiring network access to boot (in which case you want to say Y to "Root file system on NFS" as well), because all other machines configure the network in their startup scripts. config IP_PNP_DHCP bool "IP: DHCP support" depends on IP_PNP ---help--- If you want your Linux box to mount its whole root file system (the one containing the directory /) from some other computer over the net via NFS and you want the IP address of your computer to be discovered automatically at boot time using the DHCP protocol (a special protocol designed for doing this job), say Y here. In case the boot ROM of your network card was designed for booting Linux and does DHCP itself, providing all necessary information on the kernel command line, you can say N here. If unsure, say Y. Note that if you want to use DHCP, a DHCP server must be operating on your network. Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details. config IP_PNP_BOOTP bool "IP: BOOTP support" depends on IP_PNP ---help--- If you want your Linux box to mount its whole root file system (the one containing the directory /) from some other computer over the net via NFS and you want the IP address of your computer to be discovered automatically at boot time using the BOOTP protocol (a special protocol designed for doing this job), say Y here. In case the boot ROM of your network card was designed for booting Linux and does BOOTP itself, providing all necessary information on the kernel command line, you can say N here. If unsure, say Y. Note that if you want to use BOOTP, a BOOTP server must be operating on your network. Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details. config IP_PNP_RARP bool "IP: RARP support" depends on IP_PNP help If you want your Linux box to mount its whole root file system (the one containing the directory /) from some other computer over the net via NFS and you want the IP address of your computer to be discovered automatically at boot time using the RARP protocol (an older protocol which is being obsoleted by BOOTP and DHCP), say Y here. Note that if you want to use RARP, a RARP server must be operating on your network. Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details. config NET_IPIP tristate "IP: tunneling" select INET_TUNNEL select NET_IP_TUNNEL ---help--- Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the encapsulating protocol. This particular tunneling driver implements encapsulation of IP within IP, which sounds kind of pointless, but can be useful if you want to make your (or some other) machine appear on a different network than it physically is, or to use mobile-IP facilities (allowing laptops to seamlessly move between networks without changing their IP addresses). Saying Y to this option will produce two modules ( = code which can be inserted in and removed from the running kernel whenever you want). Most people won't need this and can say N. config NET_IPGRE_DEMUX tristate "IP: GRE demultiplexer" help This is helper module to demultiplex GRE packets on GRE version field criteria. Required by ip_gre and pptp modules. config NET_IP_TUNNEL tristate select DST_CACHE select GRO_CELLS default n config NET_IPGRE tristate "IP: GRE tunnels over IP" depends on (IPV6 || IPV6=n) && NET_IPGRE_DEMUX select NET_IP_TUNNEL help Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the encapsulating protocol. This particular tunneling driver implements GRE (Generic Routing Encapsulation) and at this time allows encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure. This driver is useful if the other endpoint is a Cisco router: Cisco likes GRE much better than the other Linux tunneling driver ("IP tunneling" above). In addition, GRE allows multicast redistribution through the tunnel. config NET_IPGRE_BROADCAST bool "IP: broadcast GRE over IP" depends on IP_MULTICAST && NET_IPGRE help One application of GRE/IP is to construct a broadcast WAN (Wide Area Network), which looks like a normal Ethernet LAN (Local Area Network), but can be distributed all over the Internet. If you want to do that, say Y here and to "IP multicast routing" below. config IP_MROUTE_COMMON bool depends on IP_MROUTE || IPV6_MROUTE config IP_MROUTE bool "IP: multicast routing" depends on IP_MULTICAST select IP_MROUTE_COMMON help This is used if you want your machine to act as a router for IP packets that have several destination addresses. It is needed on the MBONE, a high bandwidth network on top of the Internet which carries audio and video broadcasts. In order to do that, you would most likely run the program mrouted. If you haven't heard about it, you don't need it. config IP_MROUTE_MULTIPLE_TABLES bool "IP: multicast policy routing" depends on IP_MROUTE && IP_ADVANCED_ROUTER select FIB_RULES help Normally, a multicast router runs a userspace daemon and decides what to do with a multicast packet based on the source and destination addresses. If you say Y here, the multicast router will also be able to take interfaces and packet marks into account and run multiple instances of userspace daemons simultaneously, each one handling a single table. If unsure, say N. config IP_PIMSM_V1 bool "IP: PIM-SM version 1 support" depends on IP_MROUTE help Kernel side support for Sparse Mode PIM (Protocol Independent Multicast) version 1. This multicast routing protocol is used widely because Cisco supports it. You need special software to use it (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more information about PIM. Say Y if you want to use PIM-SM v1. Note that you can say N here if you just want to use Dense Mode PIM. config IP_PIMSM_V2 bool "IP: PIM-SM version 2 support" depends on IP_MROUTE help Kernel side support for Sparse Mode PIM version 2. In order to use this, you need an experimental routing daemon supporting it (pimd or gated-5). This routing protocol is not used widely, so say N unless you want to play with it. config SYN_COOKIES bool "IP: TCP syncookie support" ---help--- Normal TCP/IP networking is open to an attack known as "SYN flooding". This denial-of-service attack prevents legitimate remote users from being able to connect to your computer during an ongoing attack and requires very little work from the attacker, who can operate from anywhere on the Internet. SYN cookies provide protection against this type of attack. If you say Y here, the TCP/IP stack will use a cryptographic challenge protocol known as "SYN cookies" to enable legitimate users to continue to connect, even when your machine is under attack. There is no need for the legitimate users to change their TCP/IP software; SYN cookies work transparently to them. For technical information about SYN cookies, check out <http://cr.yp.to/syncookies.html>. If you are SYN flooded, the source address reported by the kernel is likely to have been forged by the attacker; it is only reported as an aid in tracing the packets to their actual source and should not be taken as absolute truth. SYN cookies may prevent correct error reporting on clients when the server is really overloaded. If this happens frequently better turn them off. If you say Y here, you can disable SYN cookies at run time by saying Y to "/proc file system support" and "Sysctl support" below and executing the command echo 0 > /proc/sys/net/ipv4/tcp_syncookies after the /proc file system has been mounted. If unsure, say N. config NET_IPVTI tristate "Virtual (secure) IP: tunneling" depends on IPV6 || IPV6=n select INET_TUNNEL select NET_IP_TUNNEL depends on INET_XFRM_MODE_TUNNEL ---help--- Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the encapsulating protocol. This can be used with xfrm mode tunnel to give the notion of a secure tunnel for IPSEC and then use routing protocol on top. config NET_UDP_TUNNEL tristate select NET_IP_TUNNEL default n config NET_FOU tristate "IP: Foo (IP protocols) over UDP" select XFRM select NET_UDP_TUNNEL ---help--- Foo over UDP allows any IP protocol to be directly encapsulated over UDP include tunnels (IPIP, GRE, SIT). By encapsulating in UDP network mechanisms and optimizations for UDP (such as ECMP and RSS) can be leveraged to provide better service. config NET_FOU_IP_TUNNELS bool "IP: FOU encapsulation of IP tunnels" depends on NET_IPIP || NET_IPGRE || IPV6_SIT select NET_FOU ---help--- Allow configuration of FOU or GUE encapsulation for IP tunnels. When this option is enabled IP tunnels can be configured to use FOU or GUE encapsulation. config INET_AH tristate "IP: AH transformation" select XFRM_ALGO select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 select CRYPTO_SHA1 ---help--- Support for IPsec AH. If unsure, say Y. config INET_ESP tristate "IP: ESP transformation" select XFRM_ALGO select CRYPTO select CRYPTO_AUTHENC select CRYPTO_HMAC select CRYPTO_MD5 select CRYPTO_CBC select CRYPTO_SHA1 select CRYPTO_DES select CRYPTO_ECHAINIV ---help--- Support for IPsec ESP. If unsure, say Y. config INET_ESP_OFFLOAD tristate "IP: ESP transformation offload" depends on INET_ESP select XFRM_OFFLOAD default n ---help--- Support for ESP transformation offload. This makes sense only if this system really does IPsec and want to do it with high throughput. A typical desktop system does not need it, even if it does IPsec. If unsure, say N. config INET_IPCOMP tristate "IP: IPComp transformation" select INET_XFRM_TUNNEL select XFRM_IPCOMP ---help--- Support for IP Payload Compression Protocol (IPComp) (RFC3173), typically needed for IPsec. If unsure, say Y. config INET_TABLE_PERTURB_ORDER int "INET: Source port perturbation table size (as power of 2)" if EXPERT default 16 help Source port perturbation table size (as power of 2) for RFC 6056 3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm. The default is almost always what you want. Only change this if you know what you are doing. config INET_XFRM_TUNNEL tristate select INET_TUNNEL default n config INET_TUNNEL tristate default n config INET_XFRM_MODE_TRANSPORT tristate "IP: IPsec transport mode" default y select XFRM ---help--- Support for IPsec transport mode. If unsure, say Y. config INET_XFRM_MODE_TUNNEL tristate "IP: IPsec tunnel mode" default y select XFRM ---help--- Support for IPsec tunnel mode. If unsure, say Y. config INET_XFRM_MODE_BEET tristate "IP: IPsec BEET mode" default y select XFRM ---help--- Support for IPsec BEET mode. If unsure, say Y. config INET_DIAG tristate "INET: socket monitoring interface" default y ---help--- Support for INET (TCP, DCCP, etc) socket monitoring interface used by native Linux tools such as ss. ss is included in iproute2, currently downloadable at: http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2 If unsure, say Y. config INET_TCP_DIAG depends on INET_DIAG def_tristate INET_DIAG config INET_UDP_DIAG tristate "UDP: socket monitoring interface" depends on INET_DIAG && (IPV6 || IPV6=n) default n ---help--- Support for UDP socket monitoring interface used by the ss tool. If unsure, say Y. config INET_RAW_DIAG tristate "RAW: socket monitoring interface" depends on INET_DIAG && (IPV6 || IPV6=n) default n ---help--- Support for RAW socket monitoring interface used by the ss tool. If unsure, say Y. config INET_DIAG_DESTROY bool "INET: allow privileged process to administratively close sockets" depends on INET_DIAG default n ---help--- Provides a SOCK_DESTROY operation that allows privileged processes (e.g., a connection manager or a network administration tool such as ss) to close sockets opened by other processes. Closing a socket in this way interrupts any blocking read/write/connect operations on the socket and causes future socket calls to behave as if the socket had been disconnected. If unsure, say N. menuconfig TCP_CONG_ADVANCED bool "TCP: advanced congestion control" ---help--- Support for selection of various TCP congestion control modules. Nearly all users can safely say no here, and a safe default selection will be made (CUBIC with new Reno as a fallback). If unsure, say N. if TCP_CONG_ADVANCED config TCP_CONG_BIC tristate "Binary Increase Congestion (BIC) control" default m ---help--- BIC-TCP is a sender-side only change that ensures a linear RTT fairness under large windows while offering both scalability and bounded TCP-friendliness. The protocol combines two schemes called additive increase and binary search increase. When the congestion window is large, additive increase with a large increment ensures linear RTT fairness as well as good scalability. Under small congestion windows, binary search increase provides TCP friendliness. See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ config TCP_CONG_CUBIC tristate "CUBIC TCP" default y ---help--- This is version 2.0 of BIC-TCP which uses a cubic growth function among other techniques. See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf config TCP_CONG_WESTWOOD tristate "TCP Westwood+" default m ---help--- TCP Westwood+ is a sender-side only modification of the TCP Reno protocol stack that optimizes the performance of TCP congestion control. It is based on end-to-end bandwidth estimation to set congestion window and slow start threshold after a congestion episode. Using this estimation, TCP Westwood+ adaptively sets a slow start threshold and a congestion window which takes into account the bandwidth used at the time congestion is experienced. TCP Westwood+ significantly increases fairness wrt TCP Reno in wired networks and throughput over wireless links. config TCP_CONG_HTCP tristate "H-TCP" default m ---help--- H-TCP is a send-side only modifications of the TCP Reno protocol stack that optimizes the performance of TCP congestion control for high speed network links. It uses a modeswitch to change the alpha and beta parameters of TCP Reno based on network conditions and in a way so as to be fair with other Reno and H-TCP flows. config TCP_CONG_HSTCP tristate "High Speed TCP" default n ---help--- Sally Floyd's High Speed TCP (RFC 3649) congestion control. A modification to TCP's congestion control mechanism for use with large congestion windows. A table indicates how much to increase the congestion window by when an ACK is received. For more detail see http://www.icir.org/floyd/hstcp.html config TCP_CONG_HYBLA tristate "TCP-Hybla congestion control algorithm" default n ---help--- TCP-Hybla is a sender-side only change that eliminates penalization of long-RTT, large-bandwidth connections, like when satellite legs are involved, especially when sharing a common bottleneck with normal terrestrial connections. config TCP_CONG_VEGAS tristate "TCP Vegas" default n ---help--- TCP Vegas is a sender-side only change to TCP that anticipates the onset of congestion by estimating the bandwidth. TCP Vegas adjusts the sending rate by modifying the congestion window. TCP Vegas should provide less packet loss, but it is not as aggressive as TCP Reno. config TCP_CONG_NV tristate "TCP NV" default n ---help--- TCP NV is a follow up to TCP Vegas. It has been modified to deal with 10G networks, measurement noise introduced by LRO, GRO and interrupt coalescence. In addition, it will decrease its cwnd multiplicatively instead of linearly. Note that in general congestion avoidance (cwnd decreased when # packets queued grows) cannot coexist with congestion control (cwnd decreased only when there is packet loss) due to fairness issues. One scenario when they can coexist safely is when the CA flows have RTTs << CC flows RTTs. For further details see http://www.brakmo.org/networking/tcp-nv/ config TCP_CONG_SCALABLE tristate "Scalable TCP" default n ---help--- Scalable TCP is a sender-side only change to TCP which uses a MIMD congestion control algorithm which has some nice scaling properties, though is known to have fairness issues. See http://www.deneholme.net/tom/scalable/ config TCP_CONG_LP tristate "TCP Low Priority" default n ---help--- TCP Low Priority (TCP-LP), a distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the ``fair share`` of bandwidth as targeted by TCP. See http://www-ece.rice.edu/networks/TCP-LP/ config TCP_CONG_VENO tristate "TCP Veno" default n ---help--- TCP Veno is a sender-side only enhancement of TCP to obtain better throughput over wireless networks. TCP Veno makes use of state distinguishing to circumvent the difficult judgment of the packet loss type. TCP Veno cuts down less congestion window in response to random loss packets. See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186> config TCP_CONG_YEAH tristate "YeAH TCP" select TCP_CONG_VEGAS default n ---help--- YeAH-TCP is a sender-side high-speed enabled TCP congestion control algorithm, which uses a mixed loss/delay approach to compute the congestion window. It's design goals target high efficiency, internal, RTT and Reno fairness, resilience to link loss while keeping network elements load as low as possible. For further details look here: http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf config TCP_CONG_ILLINOIS tristate "TCP Illinois" default n ---help--- TCP-Illinois is a sender-side modification of TCP Reno for high speed long delay links. It uses round-trip-time to adjust the alpha and beta parameters to achieve a higher average throughput and maintain fairness. For further details see: http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html config TCP_CONG_DCTCP tristate "DataCenter TCP (DCTCP)" default n ---help--- DCTCP leverages Explicit Congestion Notification (ECN) in the network to provide multi-bit feedback to the end hosts. It is designed to provide: - High burst tolerance (incast due to partition/aggregate), - Low latency (short flows, queries), - High throughput (continuous data updates, large file transfers) with commodity, shallow-buffered switches. All switches in the data center network running DCTCP must support ECN marking and be configured for marking when reaching defined switch buffer thresholds. The default ECN marking threshold heuristic for DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets (~100KB) at 10Gbps, but might need further careful tweaking. For further details see: http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf config TCP_CONG_CDG tristate "CAIA Delay-Gradient (CDG)" default n ---help--- CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies the TCP sender in order to: o Use the delay gradient as a congestion signal. o Back off with an average probability that is independent of the RTT. o Coexist with flows that use loss-based congestion control. o Tolerate packet loss unrelated to congestion. For further details see: D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg config TCP_CONG_BBR tristate "BBR TCP" default n ---help--- BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to maximize network utilization and minimize queues. It builds an explicit model of the the bottleneck delivery rate and path round-trip propagation delay. It tolerates packet loss and delay unrelated to congestion. It can operate over LAN, WAN, cellular, wifi, or cable modem links. It can coexist with flows that use loss-based congestion control, and can operate with shallow buffers, deep buffers, bufferbloat, policers, or AQM schemes that do not provide a delay signal. It requires the fq ("Fair Queue") pacing packet scheduler. #if defined(CONFIG_BCM_KF_MPTCP) && defined(CONFIG_BCM_MPTCP) config TCP_CONG_LIA tristate "MPTCP Linked Increase" depends on MPTCP default n ---help--- MultiPath TCP Linked Increase Congestion Control To enable it, just put 'lia' in tcp_congestion_control config TCP_CONG_OLIA tristate "MPTCP Opportunistic Linked Increase" depends on MPTCP default n ---help--- MultiPath TCP Opportunistic Linked Increase Congestion Control To enable it, just put 'olia' in tcp_congestion_control config TCP_CONG_WVEGAS tristate "MPTCP WVEGAS CONGESTION CONTROL" depends on MPTCP default n ---help--- wVegas congestion control for MPTCP To enable it, just put 'wvegas' in tcp_congestion_control config TCP_CONG_BALIA tristate "MPTCP BALIA CONGESTION CONTROL" depends on MPTCP default n ---help--- Multipath TCP Balanced Linked Adaptation Congestion Control To enable it, just put 'balia' in tcp_congestion_control config TCP_CONG_MCTCPDESYNC tristate "DESYNCHRONIZED MCTCP CONGESTION CONTROL (EXPERIMENTAL)" depends on MPTCP default n ---help--- Desynchronized MultiChannel TCP Congestion Control. This is experimental code that only supports single path and must have set mptcp_ndiffports larger than one. To enable it, just put 'mctcpdesync' in tcp_congestion_control For further details see: http://ieeexplore.ieee.org/abstract/document/6911722/ https://doi.org/10.1016/j.comcom.2015.07.010 #endif choice prompt "Default TCP congestion control" default DEFAULT_CUBIC help Select the TCP congestion control that will be used by default for all connections. config DEFAULT_BIC bool "Bic" if TCP_CONG_BIC=y config DEFAULT_CUBIC bool "Cubic" if TCP_CONG_CUBIC=y config DEFAULT_HTCP bool "Htcp" if TCP_CONG_HTCP=y config DEFAULT_HYBLA bool "Hybla" if TCP_CONG_HYBLA=y config DEFAULT_VEGAS bool "Vegas" if TCP_CONG_VEGAS=y config DEFAULT_VENO bool "Veno" if TCP_CONG_VENO=y config DEFAULT_WESTWOOD bool "Westwood" if TCP_CONG_WESTWOOD=y config DEFAULT_DCTCP bool "DCTCP" if TCP_CONG_DCTCP=y config DEFAULT_CDG bool "CDG" if TCP_CONG_CDG=y config DEFAULT_BBR bool "BBR" if TCP_CONG_BBR=y #if defined(CONFIG_BCM_KF_MPTCP) && defined(CONFIG_BCM_MPTCP) config DEFAULT_LIA bool "Lia" if TCP_CONG_LIA=y config DEFAULT_OLIA bool "Olia" if TCP_CONG_OLIA=y config DEFAULT_WVEGAS bool "Wvegas" if TCP_CONG_WVEGAS=y config DEFAULT_BALIA bool "Balia" if TCP_CONG_BALIA=y config DEFAULT_MCTCPDESYNC bool "Mctcpdesync (EXPERIMENTAL)" if TCP_CONG_MCTCPDESYNC=y #endif config DEFAULT_RENO bool "Reno" endchoice endif config TCP_CONG_CUBIC tristate depends on !TCP_CONG_ADVANCED default y config DEFAULT_TCP_CONG string default "bic" if DEFAULT_BIC default "cubic" if DEFAULT_CUBIC default "htcp" if DEFAULT_HTCP default "hybla" if DEFAULT_HYBLA default "vegas" if DEFAULT_VEGAS default "westwood" if DEFAULT_WESTWOOD default "veno" if DEFAULT_VENO #if defined(CONFIG_BCM_KF_MPTCP) && defined(CONFIG_BCM_MPTCP) default "lia" if DEFAULT_LIA default "olia" if DEFAULT_OLIA default "wvegas" if DEFAULT_WVEGAS default "balia" if DEFAULT_BALIA #endif default "reno" if DEFAULT_RENO default "dctcp" if DEFAULT_DCTCP default "cdg" if DEFAULT_CDG default "bbr" if DEFAULT_BBR default "cubic" config TCP_MD5SIG bool "TCP: MD5 Signature Option support (RFC2385)" select CRYPTO select CRYPTO_MD5 ---help--- RFC2385 specifies a method of giving MD5 protection to TCP sessions. Its main (only?) use is to protect BGP sessions between core routers on the Internet. If unsure, say N.
10-29
Example Packet Analyzer Commands This section is applicable for the following families of devices: a Aldrin a Aldrin2 a Gen6 devices Packet Analyzer commands require switching to Packet Analyzer context (within Debug context) using the packet-analyzer command. Use the exit command to exit any of the Packet Analyzer sub-contexts. To use the Packet Analyzer commands, the debugged device iDebug XML file must be located in the appropriate location. XML files are under cpss/tools/admin/iDebug. Copy them to either of the following locations, depending on the desired platform: For Linux target devices (black mode), to /usr/bin For Linux simulation, to ~/embeddedFs/CHIP_SIMULATION_03_394/ For Windows simulation, to C:\Users\<user-name>\AppData\Local\Temp\embeddedFs\CHIP_SIMULATION_03_394\ Packet Analyzer configuration and operation is preserved even when outside the Packet Analyzer context, enabling re-entrance for sampled data viewing. See Lua CLI Support section in CPSS User Guide for more details. clear Use the clear command to reset the sampling counter which counts the number of samplings in each Stage. Using this command ensures accurate count results between separate samplings. Syntax clear Parameters None Command Context Packet-Analyzer context Example Console(debug.0-pa-1)# clear configure pipeline Use the configure pipeline command to configure a Packet Analyzer to operate in pipeline mode. Using this command transitions to a sub-context for configuring pipeline mode parameters. Syntax configure pipeline Parameters None Command Context Packet-Analyzer context Example To configure Pipeline mode: Console(debug)# packet-analyzer manager 1 device 0 Console(debug.pa-1)# configure pipeline Console(debug.0-pa-1-pipeline)# configure pipeline packet-trace Use the configure pipeline packet-trace command to configure a Packet Analyzer to operate in pipeline mode and enable packet-trace option. Using this command transitions to a sub-context for configuring pipeline mode parameters. See explanation on packet trace usage in Packet Analyzer section CPSS User Guide. This command is not available for Aldrin and Aldrin2. Syntax configure pipeline packet-trace Parameters None Command Context Packet-Analyzer context Example To configure Pipeline mode: Console(debug)# packet-analyzer manager 1 device 0 Console(debug.pa-1)# configure pipeline packet-trace Console(debug.0-pa-1-pipeline-packet-trace)# configure stage Use the configure stage command to set the Stage to use in stage mode. Using this command transitions to a sub-context for configuring stage mode parameters of the specified stage, as demonstrated by the prompt containing the stage name. When trying to configure an inactive stage muxed with a currently active one, an error message is issued naming the currently active stage. Following deactivation of the latter, reuse this command to activate the desired stage. Use the no form of the configure stage command to stop sampling the specified stage, as well as deactivating a stage prior to activating any of its muxed stages. Syntax configure stage <stageName> no configure stage <stageName> Parameters stageName - Stage name; replacing stageName with a ‘?’ yields a list of stage names available for configuration. Stage name may be either a pre-defined or a user-defined Stage Command Context Packet-Analyzer context Example To obtain a list of Stage names to configure: Console(debug.0-pa-1)# configure stage ? Packet-Analyzer stage bridge Pre Bridge ingress stage e-filter Pre Filter egress stage e-oam Pre OAM egress stage e-pcl Pre PCL egress stage e-policer Pre Policer egress stage equeue Pre e-Queue ingress stage header-alt Pre Header Alteration egress stage i-oam Pre OAM ingress stage i-pcl Pre PCL0,1,2 ingress tages i-policer Pre Policer ingress stage mac Pre MAC egress stage mll Pre MLL ingress stage pha Pre programmable Header Alteration egress stage (falcon only) replication Pre replication egress stage (falcon only) router Pre Router ingress stage timestamp Pre Timestamp egress stage tti Pre TTI0,1 ingress stages tx-queue Pre tx-Queue egress stage <CR> Select stage Console(debug.0-pa-1)# To configure the Stage named i-pcl: Console(debug.pa-1)# configure stage i-pcl Console(debug.0-pa-1-i-pcl)# disable Use the disable command to cease sampling before viewing the sampling results. Syntax disable Parameters None Command Context Packet Analyzer context Example Sample the Pipeline for descriptors that came for port 5: Console(debug.0-pa-1)# configure pipeleine Console(debug-pa-1-pipeline)# match local_dev_src_port 5 Console(debug-pa-1-pipeline)# exit Console(debug-pa-1)# enable pipeline Run traffic, and then: Console(debug-pa-1)# disable enable pipeline Use the enable pipeline command to apply the configuration set by the configure pipeline command to the device hardware, and begin sampling in pipeline mode. Syntax enable pipeline Parameters None Command Context Packet Analyzer context Example Sample the Pipeline for descriptors Ingressing through port 5: Console(debug.0-pa-1)# configure pipeleine Console(debug-pa-1-pipeline)# match local_dev_src_port 5 Console(debug-pa-1-pipeline)# exit Console(debug-pa-1)# enable pipeline enable stage Use the enable stage command to apply the configuration set by the configure stage command(s) to the device hardware, and begin sampling in stage mode. Syntax enable stage Parameters None Command Context Packet Analyzer context Example Sample Stage i-pcl for descriptors with source port 5 and e-pcl for descriptors with egress port 6: Console(debug.0-pa-1)# configure stage i-pcl Console(debug-pa-1-i-pcl)# match local_dev_src_port 5 Console(debug-pa-1-i-pcl)# exit Console(debug.0-pa-1)# configure stage e-pcl Console(debug-pa-1-i-pcl)# match trg_phy_port 6 Console(debug-pa-1-i-pcl)# exit Console(debug-pa-1)# enable stage Stages must be configured in order to be enabled in Stage mode inverse Use the inverse command to sample descriptors not matching all configured filters in Pipeline or Stage mode. Due to this command requiring none of the filters is matched (AND between all NOTs), use it sparingly and carefully. This command affects sampling at all Stages when in Pipeline mode, and at the currently configured Stage when in Stage mode. Syntax inverse Parameters None Command Context Pipeline Configuration and Stage Configuration contexts Example To match in Pipeline mode on ingress port number other than 5: Console(debug.0-pa-1)# configure pipeleine Console(debug-pa-1-pipeline)# match local_dev_src_port 5 Console(debug-pa-1-pipeline)# inverse Console(debug-pa-1-pipeline)# match Use the match command to filter descriptors with a specific field value when configuring Pipeline or a Stage for sampling. This allows limiting sampling to descriptors with specific values in specific fields. A mask can be used in conjunction with the value, when only a field segment is of interest, such as domain within and IP address. In Pipeline configuration context, the field must exist in at least one of the stages within the Pipeline. In Stage configuration context, the field must exist in the configured Stage. The filtered fields are marked for display in the show pipeline or show stage commands Syntax match <fieldName> <fieldValue> [mask <maskValue>] Parameters fieldName - Name of field within one of the Pipeline stages or in the configured Stage fieldValue - Value of field to match maskValue - Mask limiting matching to a field value segment; for example, in an IPV4 field, a 255.255.255.0 mask limits matching to the domain; 0 disable filtering according to field value, meaning this field is of interest regardless of its value User Guidelines Field and mask values are specified in terms of the field type: Numeric values - A decimal number Hex values - Hex number preceded by a 0x prefix IP address - IP address formatted as xxx.xxx.xxx.xxx or xxx:xxx:xxx:xxx:xxx MAC Address - MAC address formatted as xx:xx:xx:xx:xx:xx Replacing field value with ?, yields a list of possible field values. Setting a 0 (0x0) mask merely marks the field for display in the show command. Command Context Pipeline configuration and Stage configuration contexts Examples To sample ingress port number 5 in Pipeline mode: Console(debug.0-pa-1)# configure pipeleine Console(debug-pa-1-pipeline)# match local_dev_src_port 5 Console(debug-pa-1-pipeline)# To sample a domain value of 192.168.1 in an IPv4 destination address while in the ‘router’ Stage: Console(debug.0-pa-1)# configure stage router Console(debug-pa-1-router)# match ipv4_dip 192.168.1.1 mask 255.255.255.0 Console(debug-pa-1-router)# To mark local_dev_src_port field for the show command only; no match: Console(debug.0-pa-1)# configure pipeleine Console(debug-pa-1-pipeline)# match local_dev_src_port 0 mask 0 Console(debug-pa-1-pipeline)# packet-analyzer Use the packet-analyzer Debug context command to create a Packet Analyzer Manager for the specified device, and enter Packet Analyzer context. If the specified Manager ID is already in use, switches to this existing manager. It is possible to create several concurrent managers with varying configurations, and use them at separate times. Syntax packet-analyzer [manager <managerId>] device <devId> Parameters managerId - Packet Analyzer manager ID; when omitted, a manager with ID = 1 is created, or if already exists, switches to its working context devId – Device ID Command Context Debug context Example Console(debug)# packet-analyzer manager 1 device 0 Console(debug.pa-1)# sampling-mode Use the sampling-mode command to configure Packet Analyzer to sample the first or last of the descriptors matching the sampling criteria. Regardless of the sampling mode, the hit counter continues counting until sampling is disabled. If this command is not used, last-match sampling mode is used Syntax sampling-mode {first-match | last-match} Parameters first-match - Sample first descriptor matching sampling criteria last-match - Continue sampling and matching descriptor for sampling criteria Command Context Pipeline Configuration and Stage Configuration contexts Example To sample the first descriptor in all Pipeline Stages: Console(debug.0-pa-1)# configure pipeleine Console(debug-pa-1-pipeline)# sampling-mode first-match Console(debug-pa-1-pipeline)# To sample the first descriptor in i-pcl Stage, and the last descriptor in the router Stage: Console(debug.0-pa-1)# configure stage i-pcl Console(debug-pa-1-i-pcl)# sampling-mode first-match Console(debug-pa-1-i-pcl)# exit Console(debug.0-pa-1)# configure stage router Console(debug-pa-1-router)# sampling-mode last-match Console(debug-pa-1-router)# exit Console(debug-pa-1)# show pipeline Use the show pipeline command to display the sampled pipeline-mode data. The displayed data includes, in this order: List of Pipeline Stages, and number of matches found in each List of fields used in filters (configured using the match command) Sampling mode – First/last, or inverse List of all stages and sampled values, if any (no value signifies no found match) Note: Field list depends on command parameter Syntax show pipeline [field {<fieldName> | all | dump}] Parameters fieldName - Field to display all - Display values of all defined fields (both pre and user-defined) dump - Display values of all fields - predefined, user-defined, and unnamed - in all Stages Command Context Packet Analyzer context Example Console(debug.pa-1)# configure pipeline Console(debug.0-pa-1-pipeline)# match local_dev_src_port 1 Console(debug.0-pa-1-pipeline)# exit Console(debug.pa-1)# enable pipeline Console(debug.pa-1)# disable Console(debug.pa-1)# show pipeline Hits: tti : 165719975 i-pcl : 182160528 bridge : 181962972 router : 179923992 i-oam : 179307633 i-policer : 178133064 equeue : 174874642 e-filter : 173543688 header-alt : 0 e-pcl : 0 e-policer : 0 replication : 0 mac : 666079946 Match : local_dev_src_port = 1 mask = 0x3FF Sampled data (first-match): Stage: tti local_dev_src_port = 1 Stage: i-pcl local_dev_src_port = 1 Stage: bridge local_dev_src_port = 1 Stage: router local_dev_src_port = 1 Stage: i-oam local_dev_src_port = 1 Stage: i-policer local_dev_src_port = 1 Stage: equeue local_dev_src_port = 1 Stage: e-filter local_dev_src_port = 1 Stage: header-alt NONE Stage: e-pcl NONE Stage: e-policer NONE Stage: replication NONE Stage: mac Console(debug.pa-1)# show stage Use the show stage command to display the sampled stage-mode data. The displayed data per stage includes, in this order: Stage name, and number of matches found in it List of fields used in Stage filters (configured using the match command) Sampling mode – first/last, inverse List of fields and sampled values, if any (no value signifies no found match) Syntax show stage <stageName> [field {<fieldName> | all | dump}] Parameters stageName - Name of Stage to display field - Field to display. When omitted, all matched fields are displayed fieldName - Field to display all - Display values of all defined fields (both pre and user-defined) dump - Display values of all fields - predefined, user-defined, and unnamed - in the specified Stage Command Context Packet Analyzer context Example Console(debug.pa-1)# configure stage bridge Console(debug.0-pa-1-bridge)# Console(debug.0-pa-1-bridge)# match mac_da 00:00:00:00:00:00 Console(debug.0-pa-1-bridge)# exit Console(debug.pa-1)# enable stage Console(debug.pa-1)# disable Console(debug.pa-1)# show stage bridge field mac_da Stage: bridge Hits: 0 Match : mac_da = 00:00:00:00:00:00 mask = 0xFF:FF:FF:FF:FF:FF Sampled data (last-match): NONE Console(debug.pa-1)# show user-defined stage Use the show user-defined stage Exec context command to display the list of user defined Stages. Syntax show user-defined stage [all] Parameters all - Display information, including Stage index, on all Stages, including pre-defined ones. When omitted, display only user-defined Stages Command Context Packet Analyzer context Example Console(debug.pa-1)# show user-defined stage Stage Name | Interface | Instance | Leg | Status | Index ---------------- --------------- ------------- ------- -------- -------- stage1 i22 s32 1 invalid 0 stage2 i10 s123 2 valid 1 Status may be one of: invalid – Stage is inactive valid – Stage is active To activate a Stage, use the configure stage command. user-defined field Use the user-defined field Packet Analyzer context command to add a field to the list of defined fields. Use the no form of this command to delete the user-defined field definition. Number of UDFs is limited to 64 Syntax user-defined field <udfName> field-id <udfId> no user-defined field <udfName> Parameters udfName - Name to assign to new user-defined field udfId - Field ID in system, as supplied by a Marvell engineer Command Context Packet Analyzer context Example Console(debug-pa-1-router)#user-defied field myField field-id f50 Console(debug.0-pa-1)# no user-defined field myField user-defined stage Use the user-defined stage command to add a Stage to the list of defined Stages. Use the no form of this command to delete the user-defined Stage definition. Number of UDSes is limited to 20 New stages require activation before their usage, and when muxed with another stage, require that the currently muxed stage is deactivated, and only then can they be activated: Utilize the configure pipeline command to activate a new stage, or if muxed, to obtain the name of the currently active muxed stage Use the no form of the configure pipeline command to deactivate the muxed stage, and then re-use configure pipeline to activate the new stage Syntax user-defined stage <udsName> interface <interfaceId> instance <instanceId> leg <instanceLeg> no user-defined stage <udsName> Parameters udsName - Name to assign to new user-defined Stage interfaceId - i-Debug interface ID, as supplied by a Marvell engineer instanceId - ID of i-Debug instance connected the Interface, as supplied by a Marvell engineer instanceLeg - Leg of Interface in Instance, as supplied by a Marvell engineer Command Context Packet Analyzer context Example Console(debug-pa-1-router)#user-defined stage MyStage interface i22 instance s32 leg 0 Console(debug.0-pa-1)# no user-defined stage <udsName> PHY Commands phy 10G register read Use the phy 10G register read Debug context commands to read the specified SMI register and 10G PHY device. Syntax phy 10g register read device {all | <devNum>} port <PortNum> register <reg> phyDev <phyDev_Num> phyID <phyID_Num> Parameters all |devNum – All devices or a specific device PortNum – Port number reg – Register to read, specified as an 16-bit unsigned integer phyDev_Num – PHY device number; range: 0-31 phyID_Num – PHY ID 翻译并解释
10-18
3.5 Edit the Script 1. Launch a text or code editor to create a new JavaScript file. 2. Review the script one function at a time. There are four functions that must be implemented in the script to support solicited ethernet communications. • onProfileLoad: Retrieves driver metadata • onValidateTag: Verifies the address and data type created in the configuration or any dynamic tags created in an OPC client are valid for the end device connected • onTagsRequest: Builds a packet of bytes to transmit to the device across the wire. • onData: Interprets the response from the device and updates tag values or indicates if the read or write operation was successful based on the data in the response. Note: onTagsRequest and onData can do much more then described in this example. These functions can be used to communicate with many kinds of protocols. For more information view the Profile Library Plugin Help documentation. 3. Build out the script one function at a time, use the following information to edit the script. Required function: onProfileLoad The onProfileLoad function is the first of these functions called by the driver. It retrieves driver metadata, identifying the interface between the script and the driver by specifying the version of Universal Device Driver with which it was created as well as the mode. For more information on the mode please view the Profile Library plug-in help. Note: The only supported version is 2.0. Any other value is rejected, leading to failure of all subsequent functions. Any exception thrown out of any of the “framework” functions is caught and results in failure of the current operation. An exception thrown out of: • onProfileLoad causes all subsequent operations to fail until corrected • onValidateTag causes the tag address to be treated as “invalid” • onTagsRequest causes the read or write operation on the current tag to fail • onData causes the read or write operation on the current tag to fail Below is the entire onProfileLoad function: function onProfileLoad() { return { version: “2.0”, mode: “Client” }; } Required function: onValidateTag The onValidateTag script function is to validate the address syntax of a tag and the data type, which is central to communicating with a device. In the case of a Modbus device, this function ensures that an address is a holding register in the supported range. If desired, add logic to this function to modify various tag fields, such as providing a valid default data type,r modifying an address format to enforce consistency among tag addresses, or assigning a bulkId to group specific tags together. For the onValidateTag function in this Modbus example, review the sections: www.ptc.com 6 ©2021-2023 PTC, Inc. All Rights Reserved. // Validate the address is a holding register in the supported range let tagAddress = info.tag.address; try { let numericAddress = parseInt(tagAddress, 10); if (numericAddress < MINREGISTERADDRESS || numericAddress > MAXREGISTERADDRESS || isNaN(numericAddress)) { info.tag.valid = false; return info.tag; } // If grouping tags into bulks, assign bulkId now. // Otherwise, the next bulkId is assigned by default. let bulkId = Math.floor((numericAddress - MINREGISTERADDRESS)/BULKREGISTERCOUNT); info.tag.bulkId = bulkId; log(`Modbus Ethernet onValidateTag: Bulk register count ${BULKREGISTERCOUNT}, address ${tagAddress}, bulkId ${info.tag.bulkId}`, VERBOSE_LOGGING); info.tag.valid = true; return info.tag; } catch (e) { // Use log to provide helpful information that can assist with error resolution log(`Unexpected error (onValidateTag): ${e.message}`, VERBOSE_LOGGING); info.tag.valid = false; return info.tag; } The code above offers a look at the JavaScript object info that the driver provides to the script writer. This object is meant to hold data to be exchanged between the script and the driver. It checks the address received from the driver (info.tag.address) and verifies it is in the expected range for a Modbus holding register as defined by constants MINREGISTERADDRESS, MAXREGISTERADDRESS. If it’s not in that range, fail the tag being added by setting the valid field of the tag to false: info.tag.valid = false. The script also defines the bulkId field for each tag. The register in the address along with the BULKREGISTERCOUNT constant facilitates assigning the bulkId that allows blocking together consecutive registers. Once the tags are blocked together, the Universal Device driver will then provide them in the tags object passed to the onTagsRequest and onData functions. // Provide a valid default data type based on register // Note: "Default" is an invalid data type let validDataTypes = {"3": "Word", "4": "Word"} if (info.tag.dataType === "Default") { let registerChar = info.tag.address.charAt(0); info.tag.dataType = validDataTypes[registerChar]; } /* www.ptc.com 7 ©2021-2023 PTC, Inc. All Rights Reserved. * The regular expression to compare address to. * ^4 starts with '4' * 0* find zero or more occurrences of '0' * 1$ ends with '1' */ let addressRegex = /^40*1$/; // Correct a "semi-correct" tag address (e.g. 401 or 400001 --> 40001) with regex if (addressRegex.test(info.tag.address)) { info.tag.address = "40001"; } The above code provides examples of logic to modify various tag fields. The first code block resets the data type if Default is initially selected. While Default is a Kepware server data type, it is an invalid return value for a tag data type (i.e., info.tag.dataType). As such, provide an appropriate and valid data type based on the register if the data type is set as Default. The second code block uses a regex to recognize semi-correct addresses and modify them accordingly. In the above implementation, this logic adjusts tag addresses with too few or too many zeros; for example, ‘401’ or ‘400001` is changed to ‘40001’. Below is the entire onValidateTag function: function onValidateTag(info) { // Provide a valid default data type based on register // Note: "Default" is an invalid data type let validDataTypes = {"3": "Long", "4": "DWord"} if (info.tag.dataType === "Default") { let registerChar = info.tag.address.charAt(0); info.tag.dataType = validDataTypes[registerChar]; } /* * The regular expression to compare address to. * ^4 starts with '4' * 0* find zero or more occurrences of '0' * 1$ ends with '1' */ let addressRegex = /^40*1$/; // Correct a "semi-correct" tag address (e.g. 401 or 400001 --> 40001) with regex if (addressRegex.test(info.tag.address)) { info.tag.address = "40001"; } // Validate the address is a holding register in the supported range let tagAddress = info.tag.address; try { www.ptc.com 8 ©2021-2023 PTC, Inc. All Rights Reserved. let numericAddress = parseInt(tagAddress, 10); if (numericAddress < MINREGISTERADDRESS || numericAddress > MAXREGISTERADDRESS || isNaN(numericAddress)) { info.tag.valid = false; return info.tag; } // If grouping tags into bulks, assign bulkId now. // Otherwise, the next bulkId is assigned by default. let bulkId = Math.floor((numericAddress - MINREGISTERADDRESS)/BULKREGISTERCOUNT); info.tag.bulkId = bulkId; log(`Modbus Ethernet onValidateTag: Bulk register count ${BULKREGISTERCOUNT}, address ${tagAddress}, bulkId ${info.tag.bulkId}`, VERBOSE_LOGGING); info.tag.valid = true; return info.tag; } catch (e) { // Use log to provide helpful information that can assist with error resolution log(`Unexpected error (onValidateTag): ${e.message}`, VERBOSE_LOGGING); info.tag.valid = false; return info.tag; } } Required function: onTagsRequest The onTagsRequest script function builds a packet of bytes that is sent to the target Modbus device. In the example implementation, the onTagsRequest function makes use of two helper functions to build action-specific packet: BuildReadMessage and BuildWriteMessage: function onTagsRequest(info) { let action = "Fail"; if (info.type === "Read") { let readData = BuildReadMessage(info.tags); // Evaluate if the data was successfully built if (readData.length === 12) { action = "Receive"; } return { action: action, data: readData }; } else if (info.type === "Write") { SENTWRITEDATA = BuildWriteMessage(info.tags); // Evaluate if the data was successfully built www.ptc.com 9 ©2021-2023 PTC, Inc. All Rights Reserved. if (SENTWRITEDATA.length === 12) { action = "Receive"; } return { action: action, data: SENTWRITEDATA }; } } Unlike the onTagsRequest function, these helper functions are not required; they help make the script more manageable. Let’s dive into these helper functions now. Helper Function: BuildReadMessage This function builds into the packet the function code for a Modbus read to ensure that the read is on the appropriate address(es). Most of the Modbus-specific pieces of this snippet are documented in code comments with the important parts called out. The Modbus protocol supports blocking / bulk read and write functionality. The Universal Device Driver supports blocking tags for reads but does not support blocking tags for writes. The tags parameter is an array containing at least one tag element. If, in onValidateTag, the script assigned the same bulkId to more than one tag, then those tags sharing a bulkId are included in the array when the request type is Read. function BuildReadMessage (tags) { // This should never happen, but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } // Sort the Modbus registers low to high let registers = []; for(let i=0; i<tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } registers.sort (sortNumber); // Find the lowest register, and the number of registers required to read the whole block let first = registers[0]; let count = registers[registers.length - 1] - first + 1; // Get the zero-based register index to make the request first -= 40001; The code above checks the tags component of the JavaScript object info (i.e. info.tags). This component holds an array of tags. Each tag has an address used to build a request packet for a read. The beginning of this section of code ensures that the driver has given a tag to build a request packet. If the length of the tags array is zero, it exits the function because there's no reason for the driver to build a request packet if no tag – and in turn, no address – is provided. www.ptc.com 10 ©2021-2023 PTC, Inc. All Rights Reserved. // Update the transaction ID in the stateful transaction object if (TXID === undefined) { TXID = 0; } else { TXID++; } JavaScript is not a strongly typed language, making it possible to modify a variable's type or composition at runtime. This is something to take advantage of within the BuildReadMessage function. The above code snippet updates the value of a global variable TXID, which represents a transaction ID exchanged between the script and the driver. Use this global variable to keep track of the number of times it is building packets to transmit to the device. It's important to keep track of this because the transaction ID is a necessary part of the Modbus protocol, as seen in the next step. TXID is stateful between transactions because it is shared between the script and driver and maintains state across transactions. Every time this function is called, the transaction ID value maintains the state it was the last time it was changed at runtime. // Build the Modbus Ethernet data let data = // ----Transaction ID------|-Protocol--|---Length--|Server|-Fxn-| [hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x03, ------Starting Address-------|-------Register count--------| hiByte(first), loByte(first), hiByte(count), loByte(count)] The above shows the packet being constructed. It is an array of bytes to be sent to the Modbus device. The code comments the different parts of the packet that are defined in the Modbus protocol; for instance, the TXID described earlier is used in the protocol as the top two bytes. Note: Only bytes are currently supported for the data array. Below is the entire BuildReadMessage function: function BuildReadMessage (tags) { // This should never happen, but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } // Sort the Modbus registers low to high let registers = []; for(let i=0; i<tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } registers.sort (sortNumber); // Find the lowest register, and the number of registers required to read the whole block let first = registers[0]; let count = registers[registers.length - 1] - first + 1; // Get the zero-based register index to make the request first -= 40001; www.ptc.com 11 ©2021-2023 PTC, Inc. All Rights Reserved. // Initialize or update the transaction ID in the stateful transaction object if (TXID === undefined) { TXID = 0; } else { TXID++; } // Build the Modbus Ethernet data let data = // ----Transaction ID------|-Protocol--|---Length--|Server|-Fxn-|------Starting Address--- - [hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x03, hiByte(first), ---|-------Register count--------| loByte(first), hiByte(count), loByte(count)] return data; } Helper Function: BuildWriteMessage The BuildWriteMessage function is similar to the BuildReadMessage function in that it assists with building an array of bytes to send the device. However, this function facilitates writing a value to, rather than reading a value from, a Modbus device. Note: Not all devices support writes. If the target device does support writes, the BuildWriteMessage function – in conjunction with the ParseWriteMessage function – provides an example of how to implement this functionality. // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for write request."; } // Sort the Modbus registers low to high let register = parseInt(tags[0].address, 10); register -= 40001; // Get the value to write which is located in the first // element in the tags[n].value object let value = parseInt(tags[0].value); The code above assigns the integer value of the tag address to the variable register. Additionally, is assigns the value of the first tag value to the variable value since KEPServerEX only allows single writes. // Build the Modbus Ethernet data let data = // ----Transaction ID-----|-Protocol--|---Length--|Server|-Fxn-| www.ptc.com 12 ©2021-2023 PTC, Inc. All Rights Reserved. [ hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x06, --------Starting Address----------|-------value to write--------| hiByte(register), loByte(register), hiByte(value), loByte(value) ]; return data; The above shows how to build up a write packet, which is very similar to building a read packet within the BuildReadMessage function. Required function: onData The onData script function parses the array of bytes received from a Modbus device. In the example implementation, as was the case with the onTagsRequest function, the onData function uses two helper functions to parse responses from a Modbus device: ParseReadMessage and ParseWriteMessage: function onData(info) { let action = ACTIONFAILURE; if (info.type === "Read") { let tags = ParseReadMessage(info.tags, info.data); // Evaluate if the data was successfully parsed from the packet if (tags[0].value != null || tags[0].quality != null) { action = ACTIONCOMPLETE; } return { action: action, tags: tags }; } else if (info.type === "Write") { action = ParseWriteMessage(info.data); return { action: action, tags: info.tags }; } } Helper Function: ParseReadMessage This function's purpose is to parse an incoming packet into a tag value to update the respective tag in the server. The incoming packet is passed to the script via the JavaScript object information as the returned byte array is contained in its data component (i.e. info.data). The function determines what information is important based on the protocol specification and extracts the value for the tag/address. This value is assigned to the value field of the tag (e.g. info.tags[0].value) and then returned from the function, which is how the tag is updated in the server. www.ptc.com 13 ©2021-2023 PTC, Inc. All Rights Reserved. function ParseReadMessage(tags, data) { // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } log(`Modbus Ethernet ParseReadMessage: data ${JSON.stringify(data)}`, VERBOSE_LOGGING); // Convert the string addresses to integers (eg 40001) let registers = []; for(let i=0; i < tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } // Find the lowest numbered register - this is the starting address let startingAddress = Array.min (registers); // MBE Response values start here: let offset = 9; // Enough bytes? if (data.length < offset + 2 * registers.length) { // Iterate the registers and set the quality of each tag to bad for (let i = 0; i < registers.length; ++i) { // Log message only once for this response if (i === 0) { if (data.length === offset){ log(`Modbus Ethernet ParseReadMessage: Device returned an error code ${data[7]}, ${data[8]}`); } else { log(`Modbus Ethernet ParseReadMessage: Invalid response from device`); } } tags[i].quality = "Bad"; } } The code above performs error checking and gathering some information about the transaction. If the number of bytes in the response is not the number of bytes expected, then the script sets the quality of each tag to Bad. If the response appears to include an error code from the device, then the script provides that information in the message passed to the log function. Otherwise, the script logs a message indicating an invalid response from the device. The result is an updated tags component of the JavaScript object info to be shared with the driver and ultimately used to update the tag qualities in the server. // Iterate the registers and lookup the response value for each for (let i = 0; i < registers.length; ++i) { // Calculate the index of this register's value in the response buffer let index = registers[i] - startingAddress; // Extract it from the response buffer www.ptc.com 14 ©2021-2023 PTC, Inc. All Rights Reserved. let hi = data[2*index + offset]; let lo = data[2*index + offset + 1]; tags[i].value = (wordFromBytes (hi, lo)); } return tags; The code above extracts the value returned from the device and assigns it to the appropriate tag to be used to update the tag value in the server. The result is an updated tags component of the JavaScript object info to be shared with the driver and ultimately used to update the tag values in the server. Below is the entire ParseReadMessage function. function ParseReadMessage(tags, data) { // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } log(`Modbus Ethernet ParseReadMessage: data ${JSON.stringify(data)}`, VERBOSE_LOGGING); // Convert the string addresses to integers (eg 40001) let registers = []; for(let i=0; i < tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } // Find the lowest numbered register - this is the starting address let startingAddress = Array.min (registers); // MBE Response values start here: let offset = 9; // Enough bytes? if (data.length < offset + 2 * registers.length) { // Iterate the registers and set the quality of each tag to bad for (let i = 0; i < registers.length; ++i) { // Log message only once for this response if (i === 0) { if (data.length === offset){ log(`Modbus Ethernet ParseReadMessage: Device returned an error code ${data[7]}, ${data[8]}`); } else { log(`Modbus Ethernet ParseReadMessage: Invalid response from device`); } } tags[i].quality = "Bad"; } www.ptc.com 15 ©2021-2023 PTC, Inc. All Rights Reserved. } else { // Iterate the registers and lookup the response value for each. // Assigning the quality of the tag is optional. If undefined, Good is assumed. for (let i = 0; i < registers.length; ++i) { // Calc the index of this register's value in the response buffer let index = registers[i] - startingAddress; // Extract the value from the response buffer let hi = data[2*index + offset]; let lo = data[2*index + offset + 1]; tags[i].value = (wordFromBytes (hi, lo)); } } return tags; } Helper Function: ParseWriteMessage The purpose of the ParseWriteMessage function is to determine if the write was successful. Most devices respond that the request was received and executed. In the case of Modbus, the response echoes the request, which makes it possible to compare the returned message with the sent message that was saved in the global variable SENTWRITEDATA. Below is the entire ParseWriteMessage function: function ParseWriteMessage(data) { // Modbus echoes a write request so if the data sent // does not match the data received, then the write fails SENTWRITEDATA.forEach((e1) => data.forEach((e2) => { if (e1 !== e2) { return "Fail"; } })); return "Complete"; } 以上分析总结出重点
09-30
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值