# [solved ... moving on] nftables: and, or, not for match?

## dpaddy

Using gotos, I can cruft together performing action(s) only if conditions are true, and alternatively only if condition(s) are false  (which gives me a Schaefer set so that nftables becomes useful).

Although there is surely a way without using gotos, my tired old eyes have not recognized it in tfm.  :Embarassed: Last edited by dpaddy on Sat Apr 15, 2017 5:48 pm; edited 3 times in total

----------

## dpaddy

I'm calling it a day... will proceed with goto's, although it is nearly beyond belief that a matching language has left out "and", "or", and "not"  :Surprised: 

----------

## dpaddy

I can appreciate that execution speed, ease of implementation, and ease of maintenance (of nftables) could be reasons for leaving out a logic parser.  Anyhow,  expressing the logic expression in disjunctive normal form makes it particularly well suited for using "continue" statements, so a well-structured set of rules implements any compound logic   :Very Happy: 

----------

## dpaddy

Don't know what I was thinking regarding "continue" statements... 

The more I think about nftables and the more I read the "documentation", the more I realize I have no clue about what "continue" is good for.

ON A RELATED SUBJECT:

I have no idea of what the match semantics is of syntax commonly found in example rules (that is not for lack of effort; I have read tfm -- though my tired eyes could have overlooked key points).

The example *Quote:*   

> You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:
> 
> % nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter

  suggests an implied "and" between "ip saddr 192.168.1.100" and  "ip daddr 192.168.1.1", whereas the example *Quote:*   

> ip saddr 1.1.1.1 ip daddr 2.2.2.2 tcp dport 111 tcp dport 222 goto other-chain

 suggests an implied "or" between "tcp dport 111" and "tcp dport 222" -- or can a packet simultaneously have two destination ports (beats me)?

I have been unable to find explanation for implied "ands" (if any), "ors" (if any), "nots" (if any), grouping-and-precedence (if any) in rules, neither have I been able to locate clear unambiguous specification of semantics w.r.t. control flow within a rule.  I'ld like to believe it is all "ands" (so grouping is a non-issue), but it would be nice to see that in documentation.  

Anyone know of good documentation which explicitly addresses such things   :Question:   Such things are, after all, important   :Exclamation: 

----------

## dpaddy

I'm going to assume nftables is essentially a wrapper providing syntactic sugar for iptables... that (assumption) has the advantage of enlarging the collection of available documentation.  

While realizing that nftables -- even if conforming to my assumption -- may mess with the rule semantics of iptables, at this point I'm desparate and eager to get on with things... 

Accordingly, http://homes.di.unimi.it/sisop/qemu/iptables-tutorial.pdf seems (so far) a good read.   :Wink: 

----------

## Hu

 *dpaddy wrote:*   

> can a packet simultaneously have two destination ports (beats me)?

 No, but you might want to write a single rule that can match multiple logically related types of traffic.  For example, if you run an http/https web server and you want to use a firewall to limit the addresses which can talk to it, it might make sense to have one stage be (tcp.port == 80 || tcp.port == 443), so that later stages run only for incoming http/https, but not incoming smtp.  The latter stage would then implement the IP-based whitelist (or logging, or rate-limiting, etc.).

----------

## Ant P.

This is "or" syntax:

```
tcp dport { 80, 443 }
```

----------

