I really need your help to understand what the dl_type=0x0800 and the nw_proto=6 mean in this command of flowvisor:
$ fvctl -f /dev/null add-flowspace dpid1-port4-video-src 1 100 in_port=4,dl_type=0x0800,nw_proto=6,tp_src=9999 video=7
Thank you!
The conventions are the same as for the Open vSwitch ovs-ofctl tool, the manpage has all the information you are looking for.
The plaintext version of the manpage can be found here.
It mentions:
The following shorthand notations are also available:
(...)
tcp Same as dl_type=0x0800,nw_proto=6.
(...)
The full descriptions have more information:
dl_type=ethertype
Matches Ethernet protocol type ethertype, which is specified as
an integer between 0 and 65535, inclusive, either in decimal or
as a hexadecimal number prefixed by 0x (e.g. 0x0806 to match ARP
packets).
nw_proto=proto
ip_proto=proto
When ip or dl_type=0x0800 is specified, matches IP protocol type
proto, which is specified as a decimal number between 0 and 255,
inclusive (e.g. 1 to match ICMP packets or 6 to match TCP pack‐
ets).
When ipv6 or dl_type=0x86dd is specified, matches IPv6 header
type proto, which is specified as a decimal number between 0 and
255, inclusive (e.g. 58 to match ICMPv6 packets or 6 to match
TCP). The header type is the terminal header as described in
the DESIGN document.
When arp or dl_type=0x0806 is specified, matches the lower 8
bits of the ARP opcode. ARP opcodes greater than 255 are
treated as 0.
When rarp or dl_type=0x8035 is specified, matches the lower 8
bits of the ARP opcode. ARP opcodes greater than 255 are
treated as 0.
When dl_type is wildcarded or set to a value other than 0x0800,
0x0806, 0x8035 or 0x86dd, the value of nw_proto is ignored (see
Flow Syntax above).
Related
I am trying with the interactive version of pymodbus (pip install pymodbus[repl]) to access a modbus device (UPS).
I had accessed it by using mbpoll tool, so the communication and device are both working.
I guess I am having problems to figure out what are the "right" parameters that match the equivalent mbpoll.
From documentation, I am trying to access the values starting at 30405 (page 864 liebert-intellislot-modbus-rtu-reference-guide-SL-28170_0.pdf) what I understand as holding registers as the function is 30xxx:
pg 864 - Vertiv™ | Liebert® IntelliSlot Modbus/BACnet Reference Guide
Table 3.118 Liebert® GXT5—Input and Holding (continued)
Data Label Input Holding # of Reg Scale Notes/Units
System Input Frequency 30405 — 1 10 Uint16
System Input Power Factor L1 30406 — 1 100 Uint16
System Input Power Factor L2 30407 — 1 100 Uint16
System Input Power Factor L3 30408 — 1 100 Uint16
System Input Max Voltage L1-N 30409 — 1 10 Uint16
System Input Min Voltage L1-N 30410 — 1 10 Uint16
System Input Max Voltage L2-N 30411 — 1 10 Uint16
System Input Min Voltage L2-N 30412 — 1 10 Uint16
System Input Max Voltage L3-N 30413 — 1 10 Uint16
Using the mbpool it returns values as expected:
mbpoll -r 396 -t 3 -c 125 -1 -q 192.168.160.1 | \grep -v "65535 (-1)"
-- Polling slave 1...
[396]: 2162
[402]: 7
[405]: 599
[406]: 53
[409]: 2279
[410]: 2048
[415]: 230
[416]: 27
[417]: 60
[418]: 1
[419]: 0
[420]: 190
[431]: 2163
[434]: 599
[435]: 230
[446]: 2
[447]: 0
[448]: 1
[449]: 0
[450]: 1
[451]: 0
[452]: 14446
...
Then I fired /usr/local/bin/pymodbus.console tcp --host 192.168.160.1 --port 502 and at prompt I've tried several combinations of client.read_holding_registers only to get the "message": "IllegalAddress" for all trials below (and others, varying count, unit, addresses, etc):
client.read_holding_registers address=30396 count=10 unit=1
client.read_holding_registers address=396 count=10 unit=1
client.read_holding_registers address=30396 count=10 unit=0
client.read_holding_registers address=396 count=10 unit=0
The complete return of one of theses client.read is:
> client.read_holding_registers address=396 count=10 unit=0
{
"original_function_code": "3 (0x3)",
"error_function_code": "131 (0x83)",
"exception code": 2,
"message": "IllegalAddress"
}
Since it is returning valid values from mbpoll, I suspect I am doing something wrong with the parameters of client.read_holding_registers, but I can't figure out where is the problem.
Both access are from the same machine, at the same time, running opensuse tumbleweed.
Accessing as root or normal user does not make any difference.
I appreciate any hints to deal with the register address with pymodbus module.
As per the comments the mbpoll command line options can cause some confusion:
-t 3:int16 16-bit input register data type with signed int display
-t 4 16-bit output (holding) register data type (default)
This is confusing because the modbus command to read an input register is 4 and for holding registers its 3 (so the reverse of the mbpoll arguments). This is mentioned in an issue.
So the command you need will be client.read_input_registers address=395 count=10 (as per the comments there is also an issue with register numbering - the "Modbus: When 40001 Really Means 1, or 0 Really Means 1 " section in this article explains this well).
I am interested in the maximum length of the header name, header value.
And are there any restrictions on the maximum number of parameters?
None of the relevant specifications define a maximum length for a header name or value, but rfc5321 section 4.5.3.1.6 states that the maximum line length is 1000 octets (aka 1000 bytes) including the terminating <CR><LF> sequence.
How does that affect maximum header name/value lengths, you might ask?
It doesn't affect the maximum header value length at all because rfc5322 section 3.2.2 defines CFWS (Comment Folding WhiteSpace) which is further used in the BNF grammar definitions for headers, which basically allows header values to be infinite in length.
That said, while there is no explicit maximum length for a header field name, there is a practical one.
The maximum line length is 1000 octets (including the terminating <CR><LF> sequence).
The recommended maximum line length is 78 octets (see rfc5322 section 2.1.1).
The syntactical definition of a header looks like this:
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
(where optional-field is any header field that is not pre-defined in the specification such as "To", "From", "Date", "Subject", etc). This syntax definition can be found in rfc5322 section 3.6.8.
Header field names cannot be folded (as seen by the syntax definition).
Since it must be possible to represent a header field name and the colon (":") all within 998 bytes (1000 bytes minus the <CR><LF> sequence), we can safely conclude that the maximum length of a header field name is 997 bytes (or, since header field names are constrained to US-ASCII, 997 characters) and SHOULD be constrained to fit within a recommended maximum line length of 78 bytes, meaning the maximum header field name SHOULD be a maximum of 77 bytes/characters.
Why does the System.Net.IpAddress allow the following strings to be converted to valid IP addresses?
$b = [ipaddress]"10.10.10"
$b.IPAddressToString
#10.10.0.10
$c = [ipaddress]"10.10"
$c.IPAddressToString
#10.0.0.10
$d = [ipaddress]"10"
$d.IPAddressToString
#0.0.0.10
I can see that the pattern is that the last octet in the string is the last octet in the IPAddress object, and whatever the first octets are in the string, are used as the left most octets in the IPAddress, and zeros are used to fill the middle unspecified octets, if any.
But why does it do this? As a user I'd expect it to fail during conversion unless all octets are specified.
Because it allows these conversions, unexpected results like this are possible when checking if a string is a valid IP address:
[bool]("10" -as [ipaddress]) #Outputs True
According to https://msdn.microsoft.com/en-us/library/system.net.ipaddress.parse.aspx?f=255&MSPPError=-2147217396
The number of parts (each part is separated by a period) in ipString determines how the IP address is constructed. A one part address is stored directly in the network address. A two part address, convenient for specifying a class A address, puts the leading part in the first byte and the trailing part in the right-most three bytes of the network address. A three part address, convenient for specifying a class B address, puts the first part in the first byte, the second part in the second byte, and the final part in the right-most two bytes of the network address.
I have an ip field in a postgres database defined as an inet field.
At the moment, to determine ipv4 vs ipv6, it looks like I can use colon count and/or '.' count to some degree, but there must be a better way, right?
COLON_COUNT = (length(ip::text) - length(replace(ip::text, ':', '')));
DOT_COUNT = (length(ip::text) - length(replace(ip::text, '.', '')));
What is a clean/good way to determine if a address is ipv4 or ipv6?
Use the family() function. IPv4 will return 4, IPv6 will return 6.
I think if the trailing zeros are not ommitted you could just convert the field into a number and see if the number is less than 2 powers 32 IPv4 or not (IPV6).This means filtering out colons and dots before the number conversion.
I want to send two bytes which represent an unsigned short in big-endian to server via TCP. But net-send only supports string parameter.
Could anyone tell me how to do this with newLISP?
It works now.
CODE: SELECT ALL
(set 'socket (net-connect "localhost" 8889))
16
(set 'size (pack ">d" 19))
"\000\019"
(net-send socket size)
2
pack returns a string buffer that contains my two bytes, net-send sends the string to server.
My C++ server got two bytes, 0 and 19.
Thanks.