MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Ruleset_debug/tracing",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "41": {
                "pageid": 41,
                "ns": 0,
                "title": "Rejecting traffic",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "'''Note''': Full reject support is available since Linux kernel 3.18.\n\nThe following rule shows how to reject any traffic from the network:\n\n<source lang=\"bash\">\n% nft add rule filter input reject\n</source>\n\nIf you don't specify any reason, an ICMP/ICMPv6 port unreachable packet is sent to the origin.\n\nYou can narrow down this through the [[matching connection tracking stateful metainformation|ct]] selector, so this only rejects traffic coming to the local machine which was '''not''' originated from us.\n\n<source lang=\"bash\">\n% nft add rule filter input ct state new reject\n</source>\n\nYou can also specify the reject reason. For example:\n\n<source lang=\"bash\">\n% nft add rule filter input reject with icmp type host-unreachable\n</source>\n\nFor ICMP, you can use the following reject reasons:\n\n* '''net-unreachable''': Destination network unreachable\n* '''host-unreachable''': Destination host unreachable\n* '''prot-unreachable''': Destination protocol unreachable\n* '''port-unreachable''': Destination port unreachable (this is the default)\n* '''net-prohibited''': Network administratively prohibited\n* '''host-prohibited''': Host administratively prohibited\n* '''admin-prohibited''': Communication administratively prohibited\n\nYou can also reject IPv6 traffic indicating the reject reason, for example:\n\n<source lang=\"bash\">\n% nft add rule ip6 filter input reject with icmpv6 type no-route\n</source>\n\nFor ICMPv6, you can use the following reasons:\n\n* '''no-route''': No route to destination.\n* '''admin-prohibited''': Communication with destination administratively prohibited\n* '''addr-unreachable''': Address unreachable\n* '''port-unreachable''': Port unreachable\n\nFrom the inet family, you can use an abstraction, the so-called ''icmpx'', to reject the IPv4 and IPv6 traffic\nusing one single rule. For example:\n\n<source lang=\"bash\">\n% nft add rule inet filter input reject with icmpx type no-route\n</source>\n\nThis rule rejects IPv4 traffic with the reason \"net unreachable\" and the IPv6 traffic with the reason \"no route\". The mapping is shown in the following table:\n\n{| border=\"1\"\n|'''ICMPX REASON'''\n|'''ICMPv6'''\n|'''ICMPv4'''\n|-\n|admin-prohibited\n|admin-prohibited\n|admin-prohibited\n|-\n|port-unreachable\n|port-unreachable\n|port-unreachable\n|-\n|no-route\n|no-route\n|net-unreachable\n|-\n|host-unreachable\n|addr-unreachable\n|host-unreachable\n|}"
                    }
                ]
            },
            "114": {
                "pageid": 114,
                "ns": 0,
                "title": "Ruleset debug/VM code analysis",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "In the kernel, nf_tables is implemented as a virtual machine with its own\ninstruction set. The kernel's '''expressions''' implement such instructions. In\nuser space, the mapping is not (necessarily) as direct as this.\n\n= Statements and expressions in user space =\n\nIn user space nomenclature, a distinction is made between '''statements''' and\n'''expressions'''; the relevant difference is that the former are valid parts\nof a rule on their own while the latter usually appear as parameter or input to\na statement. For instance, take the following '''payload statement''':\n\n ip dscp set 42\n\nHere, '''ip dscp''' is an expression identifying what part of the packet\npayload to mangle, '''42''' is a constant expression holding the value to\nassign. There are certain limits as to what may appear after the '''set'''\nkeyword, nft does some type checking to make sure it is compatible. But to\nillustrate the power this concept has, take the following example:\n\n tcp dport set tcp sport\n\nThis will mangle a TCP packet's destination port to match whatever its source\nport value may be. Albeit a bit constructed, this is an example of a statement\naccepting data from two expressions.\n\n= Expressions in kernel space =\n\nThe kernel does not have the concept of a statement. There are merely\nexpressions (instructions) loading data from or writing to registers, thereby\ninteracting with each other. Aside from twenty general purpose data registers\n(each sized four bytes), there is a single '''verdict''' register used to\nterminate rule or even chain traversal available to expressions.\n\n= VM bytecode in action =\n\nWhen '''nft''' translates user input into VM code for the kernel, it translates\nfrom statements and expressions as user space knows them into VM code calling\nkernel's expressions. Passing the '''--debug=netlink''' option makes this visual:\n\n nft --debug=netlink add rule inet t c ip daddr 10.1.2.3 counter accept\n inet t c\n   [ meta load nfproto => reg 1 ]\n   [ cmp eq reg 1 0x00000002 ]\n   [ payload load 4b @ network header + 16 => reg 1 ]\n   [ cmp eq reg 1 0x0302010a ]\n   [ counter pkts 0 bytes 0 ]\n   [ immediate reg 0 accept ]\n\nThe rule added by the command above matches the packet's\n'''IPv4 Destination Address''' field against the value '''10.1.2.3''', counts\nmatching packets and finally accepts them (thereby ending chain traversal for\nthis packet.\n\nThe printed VM bytecode reveals a few more interesting details:\n\n# The rule actually starts with a match on '''meta nfproto''' value: Because the chain resides in inet family, it may see packets other than IPv4 ones as well. This filtering is necessary because:\n# User space's '''ip daddr''' expression is actually very generic: The '''payload''' expression it translates into merely loads 4B from the network header at offset 16B into register 1. With an IPv6 packet, this would happily load parts of the Source Address field, which might even match the value 0x0302010a by accident. To avoid such unexpected (and unforseeable) behaviour, the implicit '''meta nfproto''' match is required.\n# Packet matching is often implicit: The second expression, comparing '''meta nfproto''' value against '''0x02''' (= NFPROTO_IPV4) for equality ('''eq'''). If not successful, it will write the value '''NFT_BREAK''' into the verdict register and chain traversal continues with the next rule.\n# Contrary to the above, the last expression is an explicit access to the verdict register ('''reg 0'''), writing NF_ACCEPT.\n\n= Statements in VM bytecode =\n\nPicking up one of the examples above:\n\n nft --debug=netlink add rule t c tcp dport set tcp sport\n ip t c\n   [ meta load l4proto => reg 1 ]\n   [ cmp eq reg 1 0x00000006 ]\n   [ payload load 2b @ transport header + 0 => reg 1 ]\n   [ payload write reg 1 => 2b @ transport header + 2 csum_type 1 csum_off 16 csum_flags 0x0 ]\n\nThis reveals how '''payload statement''' is actually just a variant of the\nkernel's '''payload expression'' which writes instead of reads. Some further\nobservations:\n\n# There is again an implicit match present, this time to assert '''meta l4proto''' matches the value 0x6 (= IPPROTO_TCP). Again to make sure the following payload expressions don't read garbage or write to odd parts of the packet.\n# The second '''payload expression'' also holds extra information for a partial checksum update which is necessary after mangling an IPv4 packet."
                    }
                ]
            }
        }
    }
}