text:
LPI Linux Certification/Advanced Network Configuration & Troubleshooting

Detailed Objective (205.2)
(LPIC-2 Version 4.5)

Weight: 4

Description: Candidates should be able to configure a network device to implement various network authentication schemes. This objective includes configuring a multi-homed network device and resolving communication problems.

Key Knowledge Areas:
 * Utilities to manipulate routing tables
 * Utilities to configure and manipulate ethernet network interfaces
 * Utilities to analyse the status of the network devices
 * Utilities to monitor and analyse the TCP/IP traffic

Terms and Utilities:

Overview
Description: ''The candidate should be able to configure a network device to implement various network authentication schemes. This objective includes configuring a multi-homed network device, configuring a virtual private network and resolving networking and communication problems.''

Key files, terms, and utilities include:

/sbin/route /sbin/ifconfig /bin/netstat /bin/ping /sbin/arp /usr/sbin/tcpdump /usr/sbin/lsof /usr/bin/nc

Network packet filtering
Network packet filtering is done in one of three ways under Linux : Their design and capabilities are quite different – note that ipfwadm is considered obsolete, iptables being the most advanced and current In iptables, the packet flow diagram looks like :
 * Ipfwadm : kernel 2.0.x and up (RedHat 5.x)
 * Ipchains : kernel 2.2.x and up (RedHat 6.x, 7.0)
 * Iptables : kernel 2.4.x and up (RedHat 7.1 – 9.0)

Iptables need some options configured in your kernel (or as modules) :

 * CONFIG_PACKET : This option allows applications and utilities that needs to work directly to various network devices. Examples of such utilities are tcpdump or snort.

 * CONFIG_NETFILTER : This option is required if you're going to use your computer as a firewall or gateway to the Internet.

 * CONFIG_IP_NF_CONNTRACK : This module is needed to make connection tracking. Connection tracking is used by, among other things, NAT and Masquerading. If you need to firewall machines on a LAN you most definitely should mark this option.

 * CONFIG_IP_NF_FTP : This module is required if you want to do connection tracking on FTP connections. Since FTP connections are quite hard to do connection tracking on in normal cases, conntrack needs a so called helper, this option compiles the helper. If you do not add this module you won't be able to FTP through a firewall or gateway properly.

 * CONFIG_IP_NF_IPTABLES : This option is required if you want do any kind of filtering, masquerading or NAT. It adds the whole iptables identification framework to the kernel. Without this you won't be able to do anything at all with iptables.

 * CONFIG_IP_NF_MATCH_LIMIT : This module isn't exactly required. This option provides the LIMIT match, that adds the possibility to control how many packets per minute that are to be matched, governed by an appropriate rule. For example, -m limit --limit 3/minute would match a maximum of 3 packets per minute. This module can also be used to avoid certain Denial of Service attacks.

 * CONFIG_IP_NF_MATCH_MAC : This allows us to match packets based on MAC addresses. Every Ethernet adapter has its own MAC address. We could for instance block packets based on what MAC address is used and block a certain computer pretty well since the MAC address very seldom change.

 * CONFIG_IP_NF_MATCH_MARK : This allows us to use a MARK match. For example, if we use the target MARK we could mark a packet and then depending on if this packet is marked further on in the table, we can match based on this mark. This option is the actual match MARK, and further down we will describe the actual target MARK.

 * CONFIG_IP_NF_MATCH_MULTIPORT : This module allows us to match packets with a whole range of destination ports or source ports. Normally this wouldn't be possible, but with this match it is.

 * CONFIG_IP_NF_MATCH_TOS : With this match we can match packets based on their TOS field. TOS stands for Type Of Service. TOS can also be set by certain rules in the mangle table and via the ip/tc commands.

 * CONFIG_IP_NF_MATCH_TCPMSS : This option adds the possibility for us to match TCP packets based on their MSS field.

 * CONFIG_IP_NF_MATCH_STATE : This is one of the biggest news in comparison to ipchains. With this module we can do stateful matching on packets. For example, if we have already seen traffic in two directions in a TCP connection, this packet will be counted as ESTABLISHED.

 * CONFIG_IP_NF_MATCH_UNCLEAN : This module will add the possibility for us to match IP, TCP, UDP and ICMP packets that don't conform to type or are invalid. We could for example drop these packets, but we never know if they are legitimate or not. Note that this match is still experimental and might not work perfectly in all cases.
 * CONFIG_IP_NF_MATCH_OWNER : This option will add the possibility for us to do matching based on the owner of a socket. For example, we can allow only the user root to have Internet access. This module was originally just written as an example on what could be done with the new iptables. Note that this match is still experimental and might not work for everyone.

 * CONFIG_IP_NF_FILTER : This module will add the basic filter table which will enable you to do IP filtering at all. In the filter table you'll find the INPUT, FORWARD and OUTPUT chains. This module is required if you plan to do any kind of filtering on packets that you receive and send.

 * CONFIG_IP_NF_TARGET_REJECT : This target allows us to specify that an ICMP error message should be sent in reply to incoming packets, instead of plainly dropping them dead to the floor. Keep in mind that TCP connections, as opposed to ICMP and UDP, are always reset or refused with a TCP RST packet.

 * CONFIG_IP_NF_TARGET_MIRROR : This allows packets to be bounced back to the sender of the packet. For example, if we set up a MIRROR target on destination port HTTP on our INPUT chain and someone tries to access this port, we would bounce his packets back to him and finally he would probably see his own homepage.

 * CONFIG_IP_NF_NAT : This module allows network address translation, or NAT, in its different forms. This option gives us access to the nat table in iptables. This option is required if we want to do port forwarding, masquerading, etc. Note that this option is not required for firewalling and masquerading of a LAN, but you should have it present unless you are able to provide unique IP addresses for all hosts.

 * CONFIG_IP_NF_TARGET_MASQUERADE : This module adds the MASQUERADE target. For instance if we don't know what IP we have to the Internet this would be the preferred way of getting the IP instead of using DNAT or SNAT. In other words, if we use DHCP, PPP, SLIP or some other connection that assigns us an IP, we need to use this target instead of SNAT. Masquerading gives a slightly higher load on the computer than NAT, but will work without us knowing the IP address in advance.

 * CONFIG_IP_NF_TARGET_REDIRECT : This target is useful together with application proxies, for example. Instead of letting a packet pass right through, we remap them to go to our local box instead. In other words, we have the possibility to make a transparent proxy this way.

 * CONFIG_IP_NF_TARGET_LOG : This adds the LOG target and its functionality to iptables. We can use this module to log certain packets to syslogd and hence see what is happening to the packet. This is invaluable for security audits, forensics or debugging a script you are writing.

 * CONFIG_IP_NF_TARGET_TCPMSS : This option can be used to counter Internet Service Providers and servers who block ICMP Fragmentation Needed packets. This can result in web-pages not getting through, small mails getting through while larger mails don't, ssh works but scp dies after handshake, etc. We can then use the TCPMSS target to overcome this by clamping our MSS (Maximum Segment Size) to the PMTU (Path Maximum Transmit Unit). This way, we'll be able to handle what the authors of Netfilter them selves call "criminally brain-dead ISPs or servers" in the kernel configuration help.

 * CONFIG_IP_NF_COMPAT_IPCHAINS : Adds a compatibility mode with the obsolescent ipchains. Do not look to this as any real long term solution for solving migration from Linux 2.2 kernels to 2.4 kernels, since it may well be gone with kernel 2.6.

 * CONFIG_IP_NF_COMPAT_IPFWADM : Compatibility mode with obsolescent ipfwadm. Definitely don't look to this as a real long term solution.

When a packet first enters the firewall, it hits the hardware and then gets passed on to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel, before it is either sent to the correct application (locally), or forwarded to another host - or whatever happens to it.

First, let us have a look at a packet that is destined for our own local host. It would pass through the following steps before actually being delivered to our application that receives it:

Note that this time the packet was passed through the INPUT chain instead of the FORWARD chain. Quite logical. Most probably the only thing that's really logical about the traversing of tables and chains in your eyes in the beginning, but if you continue to think about it, you'll find it will get clearer in time. Now we look at the outgoing packets from our own local host and what steps they go through.

In this example, we're assuming that the packet is destined for another host on another network. The packet goes through the different steps in the following fashion :

As you can see, there are quite a lot of steps to pass through. The packet can be stopped at any of the iptables chains, or anywhere else if it is malformed; however, we are mainly interested in the iptables aspect of this lot. Do note that there are no specific chains or tables for different interfaces or anything like that. FORWARD is always passed by all packets that are forwarded over this firewall/router.

Do not use the INPUT chain to filter on in the previous scenario! INPUT is meant solelyfor packets to our local host that do not get routed to any otherdestination.

We have now seen how the different chains are traversed in three separate scenarios. If we were to figure out a good map of all this, it would look something like this:

To clarify this image, consider this. If we get a packet into the first routing decision that is not destined for the local machine itself, it will be routed through the FORWARD chain. If the packet is, on the other hand, destined for an IP address that the local machine is listening to, we would send the packet through the INPUT chain and to the local machine.

Also worth a note, is the fact that packets may be destined for the local machine, but the destination address may be changed within the PREROUTING chain by doing NAT. Since this takes place before the first routing decision, the packet will be looked upon after this change. Because of this, the routing may be changed before the routing decision is done. Do note, that all packets will be going through one or the other path in this image. If you DNAT a packet back to the same network that it came from, it will still travel through the rest of the chains until it is back out on the network.

Mangle table
This table should as we've already noted mainly be used for mangling packets. In other words, you may freely use the mangle matches etc that could be used to change TOS (Type Of Service) fields and so on.

You are strongly advised not to use this table for any filtering; nor will any DNAT, SNAT or Masquerading work in this table.

Targets that are only valid in the mangle table:
 * TOS
 * TTL
 * MARK

The TOS target is used to set and/or change the Type of Service field in the packet. This could be used for setting up policies on the network regarding how a packet should be routed and so on. Note that this has not been perfected and is not really implemented on the Internet and most of the routers don't care about the value in this field, and sometimes, they act faulty on what they get. Don't set this in other words for packets going to the Internet unless you want to make routing decisions on it, with iproute2.

The TTL target is used to change the TTL (Time To Live) field of the packet. We could tell packets to only have a specific TTL and so on. One good reason for this could be that we don't want to give ourself away to nosy Internet Service Providers. Some Internet Service Providers do not like users running multiple computers on one single connection, and there are some Internet Service Providers known to look for a single host generating different TTL values, and take this as one of many signs of multiple computers connected to a single connection.

The MARK target is used to set special mark values to the packet. These marks could then be recognized by the iproute2 programs to do different routing on the packet depending on what mark they have, or if they don't have any. We could also do bandwidth limiting and Class Based Queuing based on these marks.

NAT table
This table should only be used for NAT (Network Address Translation) on different packets. In other words, it should only be used to translate the packet's source field or destination field. Note that, as we have said before, only the first packet in a stream will hit this chain. After this, the rest of the packets will automatically have the same action taken on them as the first packet. The actual targets that do these kind of things are:
 * DNAT
 * SNAT
 * MASQUERADE

The DNAT target is mainly used in cases where you have a public IP and want to redirect accesses to the firewall to some other host (on a DMZ for example). In other words, we change the destination address of the packet and reroute it to the host.

SNAT is mainly used for changing the source address of packets. For the most part you'll hide your local networks or DMZ, etc. A very good example would be that of a firewall of which we know outside IP address, but need to substitute our local network's IP numbers with that of our firewall. With this target the firewall will automatically SNAT and De-SNAT the packets, hence making it possible to make connections from the LAN to the Internet. If your network uses <IP_ADDRESS>/netmask for example, the packets would never get back from the Internet, because IANA has regulated these networks (among others) as private and only for use in isolated LANs.

The MASQUERADE target is used in exactly the same way as SNAT, but the MASQUERADE target takes a little bit more overhead to compute. The reason for this, is that each time that the MASQUERADE target gets hit by a packet, it automatically checks for the IP address to use, instead of doing as the SNAT target does - just using the single configured IP address. The MASQUERADE target makes it possible to work properly with Dynamic DHCP IP addresses that your ISP might provide for your PPP, PPPoE or SLIP connections to the Internet.

Filter table
The filter table is mainly used for filtering packets. We can match packets and filter them in whatever way we want. This is the place that we actually take action against packets and look at what they contain and DROP or /ACCEPT them, depending on their content. Of course we may also do prior filtering; however, this particular table, is the place for which filtering was designed. Almost all targets are usable in this chain. We will be more prolific about the filter table here; however you now know that this table is the right place to do your main filtering.

The state machine
The state machine is a special part within iptables that should really not be called the state machine at all, since it is really a connection tracking machine. However, most people recognize it under the first name. Throughout this chapter i will use this names more or less as if they were synonymous. This should not be overly confusing. Connection tracking is done to let the Netfilter framework know the state of a specific connection. Firewalls that implement this are generally called stateful firewalls. A stateful firewall is generally much more secure than non-stateful firewalls since it allows us to write much tighter rule-sets.

Within iptables, packets can be related to tracked connections in four different so called states. These are known as NEW, ESTABLISHED, RELATED and INVALID. We will discuss each of these in more depth later. With the --state match we can easily control who or what is allowed to initiate new sessions.

All of the connection tracking is done by special framework within the kernel called conntrack. conntrack may be loaded either as a module, or as an internal part of the kernel itself. Most of the time, we need and want more specific connection tracking than the default conntrack engine can maintain. Because of this, there are also more specific parts of conntrack that handles the TCP, UDP or ICMP protocols among others. These modules grabs specific, unique, information from the packets, so that they may keep track of each stream of data. The information that conntrack gathers is then used to tell conntrack in which state the stream is currently in. For example, UDP streams are, generally, uniquely identified by their destination IP address, source IP address, destination port and source port. In previous kernels, we had the possibility to turn on and off defragmentation. However, since iptables and Netfilter were introduced and connection tracking in particular, this option was gotten rid of. The reason for this is that connection tracking can not work properly without defragmenting packets, and hence defragmenting has been incorporated into conntrack and is carried out automatically. It can not be turned off, except by turning off connection tracking. Defragmentation is always carried out if connection tracking is turned on.

All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. What this means is that iptables will do all recalculation of states and so on within the PREROUTING chain. If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED, and so on. If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain of course. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table.

The conntrack entries
Let's take a brief look at a conntrack entry and how to read them in /proc/net/ip_conntrack. This gives a list of all the current entries in your conntrack database. If you have the ip_conntrack module loaded, a cat of /proc/net/ip_conntrack might look like:

tcp     6 117 SYN_SENT src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=32775 \ dport=22 [UNREPLIED] src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=22 \ dport=32775 use=2

This example contains all the information that the conntrack module maintains to know which state a specific connection is in. First of all, we have a protocol, which in this case is tcp. Next, the same value in normal decimal coding. After this, we see how long this conntrack entry has to live. This value is set to 117 seconds right now and is decremented regularly until we see more traffic. This value is then reset to the default value for the specific state that it is in at that relevant point of time. Next comes the actual state that this entry is in at the present point of time. In the above mentioned case we are looking at a packet that is in the SYN_SENT state. The internal value of a connection is slightly different from the ones used externally with iptables. The value SYN_SENT tells us that we are looking at a connection that has only seen a TCP SYN packet in one direction. Next, we see the source IP address, destination IP address, source port and destination port. At this point we see a specific keyword that tells us that we have seen no return traffic for this connection. Lastly, we see what we expect of return packets. The information details the source IP address and destination IP address (which are both inverted, since the packet is to be directed back to us). The same thing goes for the source port and destination port of the connection. These are the values that should be of any interest to us.

The connection tracking entries may take on a series of different values, all specified in the conntrack headers available in linux/include/netfilter-ipv4/ip_conntrack*.h files. These values are dependent on which sub-protocol of IP we use. TCP, UDP or ICMP protocols take specific default values as specified in linux/include/netfilter-ipv4/ip_conntrack.h. We will look closer at this when we look at each of the protocols; however, we will not use them extensively through this chapter, since they are not used outside of the conntrack internals. Also, depending on how this state changes, the default value of the time until the connection is destroyed will also change.

Recently there was a new patch made available in iptables patch-o-matic, called tcp-window-tracking. This patch adds, among other things, all of the above timeouts to special sysctl variables, which means that they can be changed on the fly, while the system is still running. Hence, this makes it unnecessary to recompile the kernel every time you want to change the timeouts. These can be altered via using specific system calls available in the /proc/sys/net/ipv4/netfilter directory. You should in particular look at the /proc/sys/net/ipv4/netfilter/ip_ct_* variables.

When a connection has seen traffic in both directions, the conntrack entry will erase the [UNREPLIED] flag, and then reset it. The entry tells us that the connection has not seen any traffic in both directions, will be replaced by the [ASSURED] flag, to be found close to the end of the entry. The [ASSURED] flag tells us that this connection is assured and that it will not be erased if we reach the maximum possible tracked connections. Thus, connections marked as [ASSURED] will not be erased, contrary to the non assured connections (those not marked as [ASSURED]). How many connections that the connection tracking table can hold depends upon a variable that can be set through the ip-sysctl functions in recent kernels. The default value held by this entry varies heavily depending on how much memory you have. On 128 MB of RAM, you will get 8192 possible entries, and at 256 MB of RAM, you will get 16376 entries. You can read and set your settings through the /proc/sys/net/ipv4/ip_conntrack_max setting.

User-land states
As you have seen, packets may take on several different states within the kernel itself, depending on what protocol we are talking about. However, outside the kernel, we only have the 4 states as described previously. These states can mainly be used in conjunction with the state match which will then be able to match packets based on their current connection tracking state. The valid states are NEW, ESTABLISHED, RELATED and INVALID states. The following table will briefly explain each possible state

These states can be used together with the --state match to match packets based on their connection tracking state. This is what makes the state machine so incredibly strong and efficient for our firewall. Previously, we often had to open up all ports above 1024 to let all traffic back into our local networks again. With the state machine in place this is not necessary any longer, since we can now just open up the firewall for return traffic and not for all kinds of other traffic.

TCP connections
In this section and the upcoming ones, we will take a closer look at the states and how they are handled for each of the three basic protocols TCP, UDP and ICMP. Also, we will take a closer look at how connections are handled per default, if they can not be classified as either of these three protocols. We have chosen to start out with the TCP protocol since it is a stateful protocol in itself, and has a lot of interesting details with regard to the state machine in iptables.

A TCP connection is always initiated with the 3-way handshake, which establishes and negotiates the actual connection over which data will be sent. The whole session is begun with a SYN packet, then a SYN/ACK packet and finally an ACK packet to acknowledge the whole session establishment. At this point the connection is established and able to start sending data. The big problem is, how does connection tracking hook up into this? Quite simply really.

As far as the user is concerned, connection tracking works basically the same for all connection types. Have a look at the picture below to see exactly what state the stream enters during the different stages of the connection. As you can see, the connection tracking code does not really follow the flow of the TCP connection, from the users viewpoint. Once it has seen one packet(the SYN), it considers the connection as NEW. Once it sees the return packet(SYN/ACK), it considers the connection as ESTABLISHED. If you think about this a second, you will understand why. With this particular implementation, you can allow NEW and ESTABLISHED packets to leave your local network, only allow ESTABLISHED connections back, and that will work perfectly. Conversely, if the connection tracking machine were to consider the whole connection establishment as NEW, we would never really be able to stop outside connections to our local network, since we would have to allow NEW packets back in again. To make things more complicated, there is a number of other internal states that are used for TCP connections inside the kernel, but which are not available for us in User-land. Roughly, they follow the state standards specified within RFC 793 - Transmission Control Protocol at page 21-23.

As you can see, it is really quite simple, seen from the user's point of view. However, looking at the whole construction from the kernel's point of view, it's a little more difficult. Let's look at an example. Consider exactly how the connection states change in the /proc/net/ip_conntrack table. The first state is reported upon receipt of the first SYN packet in a connection.

tcp     6 117 SYN_SENT src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=1031 \ dport=23 [UNREPLIED] src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=23 \ dport=1031 use=1

As you can see from the above entry, we have a precise state in which a SYN packet has been sent, (the SYN_SENT flag is set), and to which as yet no reply has been sent (witness the [UNREPLIED] flag). The next internal state will be reached when we see another packet in the other direction.

tcp     6 57 SYN_RECV src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=1031 \ dport=23 src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=23 dport=1031 \ use=1

Now we have received a corresponding SYN/ACK in return. As soon as this packet has been received, the state changes once again, this time to SYN_RECV. SYN_RECV tells us that the original SYN was delivered correctly and that the SYN/ACK return packet also got through the firewall properly. Moreover, this connection tracking entry has now seen traffic in both directions and is hence considered as having been replied to. This is not explicit, but rather assumed, as was the [UNREPLIED] flag above. The final step will be reached once we have seen the final ACK in the 3-way handshake.

tcp     6 431999 ESTABLISHED src=<IP_ADDRESS> dst=<IP_ADDRESS> \ sport=1031 dport=23 src=<IP_ADDRESS> dst=<IP_ADDRESS> \ sport=23 dport=1031 use=1

In the last example, we have gotten the final ACK in the 3-way handshake and the connection has entered the ESTABLISHED state, as far as the internal mechanisms of iptables are aware. After a few more packets, the connection will also become [ASSURED], as shown in the introduction section of this chapter. When a TCP connection is closed down, it is done in the following way and takes the following states.

As you can see, the connection is never really closed until the last ACK is sent. Do note that this picture only describes how it is closed down under normal circumstances. A connection may also, for example, be closed by sending a RST(reset), if the connection were to be refused. In this case, the connection would be closed down after a predetermined time.

When the TCP connection has been closed down, the connection enters the TIME_WAIT state, which is per default set to 2 minutes. This is used so that all packets that have gotten out of order can still get through our rule-set, even after the connection has already closed. This is used as a kind of buffer time so that packets that have gotten stuck in one or another congested router can still get to the firewall, or to the other end of the connection.

If the connection is reset by a RST packet, the state is changed to CLOSE. This means that the connection per default have 10 seconds before the whole connection is definitely closed down. RST packets are not acknowledged in any sense, and will break the connection directly. There are also other states than the ones we have told you about so far.

Here is the complete list of possible states that a TCP stream may take, and their timeout values.

These values are most definitely not absolute. They may change with kernel revisions, and they may also be changed via the proc file-system in the /proc/sys/net/ipv4/netfilter/ip_ct_tcp_* variables. The default values should, however, be fairly well established in practice. These values are set in jiffies (or 1/100th parts of seconds), so 3000 means 30 seconds.

Also note that the User-land side of the state machine does not look at TCP flags set in the TCP packets. This is generally bad, since you may want to allow packets in the NEW state to get through the firewall, but when you specify the NEW flag, you will in most cases mean SYN packets.

UDP connections
UDP connections are in them selves not stateful connections, but rather stateless. There are several reasons why, mainly because they don't contain any connection establishment or connection closing; most of all they lack sequencing. Receiving two UDP datagrams in a specific order does not say anything about which order in which they were sent. It is, however, still possible to set states on the connections within the kernel. Let's have a look at how a connection can be tracked and how it might look in conntrack.

As you can see, the connection is brought up almost exactly in the same way as a TCP connection. That is, from the user-land point of view. Internally, conntrack information looks quite a bit different, but intrinsically the details are the same. First of all, let's have a look at the entry after the initial UDP packet has been sent.

udp     17 20 src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=137 dport=1025 \ [UNREPLIED] src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=1025 \ dport=137 use=1

As you can see from the first and second values, this is an UDP packet. The first is the protocol name, and the second is protocol number. This is just the same as for TCP connections. The third value marks how many seconds this state entry has to live. After this, we get the values of the packet that we have seen and the future expectations of packets over this connection reaching us from the initiating packet sender. These are the source, destination, source port and destination port. At this point, the [UNREPLIED] flag tells us that there's so far been no response to the packet. Finally, we get a brief list of the expectations for returning packets. Do note that the latter entries are in reverse order to the first values. The timeout at this point is set to 30 seconds, as per default.

udp     17 170 src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=137 \ dport=1025 src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=1025 \ dport=137 use=1

At this point the server has seen a reply to the first packet sent out and the connection is now considered as ESTABLISHED. This is not shown in the connection tracking, as you can see. The main difference is that the [UNREPLIED] flag has now gone. Moreover, the default timeout has changed to 180 seconds - but in this example that's by now been decremented to 170 seconds - in 10 seconds' time, it will be 160 seconds. There's one thing that's missing, though, and can change a bit, and that is the [ASSURED] flag described above. For the [ASSURED] flag to be set on a tracked connection, there must have been a small amount of traffic over that connection.

udp     17 175 src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=1025 \ dport=53 src=<IP_ADDRESS> dst=<IP_ADDRESS> sport=53 \ dport=1025 [ASSURED] use=1

At this point, the connection has become assured. The connection looks exactly the same as the previous example, except for the [ASSURED] flag. If this connection is not used for 180 seconds, it times out. 180 Seconds is a comparatively low value, but should be sufficient for most use. This value is reset to its full value for each packet that matches the same entry and passes through the firewall, just the same as for all of the internal states.

ICMP connections
ICMP packets are far from a stateful stream, since they are only used for controlling and should never establish any connections. There are four ICMP types that will generate return packets however, and these have 2 different states. These ICMP messages can take the NEW and ESTABLISHED states. The ICMP types we are talking about are Echo request and reply, Timestamp request and reply, Information request and reply and finally Address mask request and reply. Out of these, the timestamp request and information request are obsolete and could most probably just be dropped. However, the Echo messages are used in several setups such as pinging hosts. Address mask requests are not used often, but could be useful at times and worth allowing. To get an idea of how this could look, have a look at the following image.

As you can see in the above picture, the host sends an echo request to the target, which is considered as NEW by the firewall. The target then responds with a echo reply which the firewall considers as state ESTABLISHED. When the first echo request has been seen, the following state entry goes into the ip_conntrack.

icmp    1 25 src=<IP_ADDRESS> dst=<IP_ADDRESS> type=8 code=0 \ id=33029 [UNREPLIED] src=<IP_ADDRESS> dst=<IP_ADDRESS> \ type=0 code=0 id=33029 use=1

This entry looks a little bit different from the standard states for TCP and UDP as you can see. The protocol is there, and the timeout, as well as source and destination addresses. The problem comes after that however. We now have 3 new fields called type, code and id. They are not special in any way, the type field contains the ICMP type and the code field contains the ICMP code. These are all available in ICMP types appendix. The final id field, contains the ICMP ID. Each ICMP packet gets an ID set to it when it is sent, and when the receiver gets the ICMP message, it sets the same ID within the new ICMP message so that the sender will recognize the reply and will be able to connect it with the correct ICMP request.

The next field, we once again recognize as the [UNREPLIED] flag, which we have seen before. Just as before, this flag tells us that we are currently looking at a connection tracking entry that has seen only traffic in one direction. Finally, we see the reply expectation for the reply ICMP packet, which is the inversion of the original source and destination IP addresses. As for the type and code, these are changed to the correct values for the return packet, so an echo request is changed to echo reply and so on. The ICMP ID is preserved from the request packet.

The reply packet is considered as being ESTABLISHED, as we have already explained. However, we can know for sure that after the ICMP reply, there will be absolutely no more legal traffic in the same connection. For this reason, the connection tracking entry is destroyed once the reply has traveled all the way through the Netfilter structure.

In each of the above cases, the request is considered as NEW, while the reply is considered as ESTABLISHED. Let's consider this more closely. When the firewall sees a request packet, it considers it as NEW. When the host sends a reply packet to the request it is considered ESTABLISHED.

Note that this means that the reply packet must match the criterion given by the connection tracking entry to be considered as established, just as with all other traffic types.

ICMP requests has a default timeout of 30 seconds, which you can change in the /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout entry. This should in general be a good timeout value, since it will be able to catch most packets in transit.

Another hugely important part of ICMP is the fact that it is used to tell the hosts what happened to specific UDP and TCP connections or connection attempts. For this simple reason, ICMP replies will very often be recognized as RELATED to original connections or connection attempts. A simple example would be the ICMP Host unreachable or ICMP Network unreachable. These should always be spawned back to our host if it attempts an unsuccessful connection to some other host, but the network or host in question could be down, and hence the last router trying to reach the site in question will reply with an ICMP message telling us about it. In this case, the ICMP reply is considered as a RELATED packet. The following picture should explain how it would look.

In the above example, we send out a SYN packet to a specific address. This is considered as a NEW connection by the firewall. However, the network the packet is trying to reach is unreachable, so a router returns a network unreachable ICMP error to us. The connection tracking code can recognize this packet as RELATED. thanks to the already added tracking entry, so the ICMP reply is correctly sent to the client which will then hopefully abort. Meanwhile, the firewall has destroyed the connection tracking entry since it knows this was an error message.

The same behavior as above is experienced with UDP connections if they run into any problem like the above. All ICMP messages sent in reply to UDP connections are considered as RELATED. Consider the following image.

This time an UDP packet is sent to the host. This UDP connection is considered as NEW. However, the network is administratively prohibited by some firewall or router on the way over. Hence, our firewall receives a ICMP Network Prohibited in return. The firewall knows that this ICMP error message is related to the already opened UDP connection and sends it as an RELATED packet to the client. At this point, the firewall destroys the connection tracking entry, and the client receives the ICMP message and should hopefully abort.

Default connections
In certain cases, the conntrack machine does not know how to handle a specific protocol. This happens if it does not know about that protocol in particular, or doesn't know how it works. In these cases, it goes back to a default behavior. The default behavior is used on, for example, NETBLT, MUX and EGP. This behavior looks pretty much the same as the UDP connection tracking. The first packet is considered NEW, and reply traffic and so forth is considered ESTABLISHED.

When the default behavior is used, all of these packets will attain the same default timeout value. This can be set via the /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout variable. The default value here is 600 seconds, or 10 minutes. Depending on what traffic you are trying to send over a link that uses the default connection tracking behavior, this might need changing. Especially if you are bouncing traffic through satellites and such, which can take a long time.

Complex protocols and connection tracking
Certain protocols are more complex than others. What this means when it comes to connection tracking, is that such protocols may be harder to track correctly. Good examples of these are the ICQ, IRC and FTP protocols. Each and every one of these protocols carries information within the actual data payload of the packets, and hence requires special connection tracking helpers to enable it to function correctly.

Let's take the FTP protocol as the first example. The FTP protocol first opens up a single connection that is called the FTP control session. When we issue commands through this session, other ports are opened to carry the rest of the data related to that specific command. These connections can be done in two ways, either actively or passively. When a connection is done actively, the FTP client sends the server a port and IP address to connect to. After this, the FTP client opens up the port and the server connects to that specified port from its own port 20 (known as FTP-Data) and sends the data over it.

The problem here is that the firewall will not know about these extra connections, since they were negotiated within the actual payload of the protocol data. Because of this, the firewall will be unable to know that it should let the server connect to the client over these specific ports.

The solution to this problem is to add a special helper to the connection tracking module which will scan through the data in the control connection for specific syntaxes and information. When it runs into the correct information, it will add that specific information as RELATED and the server will be able to track the connection, thanks to that RELATED entry. Consider the following picture to understand the states when the FTP server has made the connection back to the client.

Passive FTP works the opposite way. The FTP client tells the server that it wants some specific data, upon which the server replies with an IP address to connect to and at what port. The client will, upon receipt of this data, connect to that specific port, from its own port 20(the FTP-data port), and get the data in question. If you have an FTP server behind your firewall, you will in other words require this module in addition to your standard iptables modules to let clients on the Internet connect to the FTP server properly. The same goes if you are extremely restrictive to your users, and only want to let them reach HTTP and FTP servers on the Internet and block all other ports. Consider the following image and its bearing on Passive FTP.

Some conntrack helpers are already available within the kernel itself. More specifically, the FTP and IRC protocols have conntrack helpers as of writing this. If you can not find the conntrack helpers that you need within the kernel itself, you should have a look at the patch-o-matic tree within user-land iptables. The patch-o-matic tree may contain more conntrack helpers, such as for the ntalk or H.323 protocols.

Conntrack helpers may either be statically compiled into the kernel, or as modules. If they are compiled as modules, you can load them with the following command :

modprobe ip_conntrack_*

Do note that connection tracking has nothing to do with NAT, and hence you may require more modules if you are NAT'ing connections as well. For example, if you were to want to NAT and track FTP connections, you would need the NAT module as well. All NAT helpers starts with ip_nat_ and follow that naming convention; so for example the FTP NAT helper would be named ip_nat_ftp and the IRC module would be named ip_nat_irc. The conntrack helpers follow the same naming convention, and hence the IRC conntrack helper would be named ip_conntrack_irc, while the FTP conntrack helper would be named ip_conntrack_ftp.

How a rule is built
As we have already explained, each rule is a line that the kernel looks at to find out what to do with a packet. If all the criteria - or matches - are met, we perform the target - or jump - instruction. Normally we would write our rules in a syntax that looks something like this:

iptables [-t table] command [match] [target/jump]

There is nothing that says that the target instruction has to be last function in the line. However, you would usually adhere to this syntax to get the best readability. Anyway, most of the rules you'll see are written in this way. Hence, if you read someone else's script, you'll most likely recognize the syntax and easily understand the rule.

If you want to use another table than the standard table, you could insert the table specification at the point at which [table] is specified. However, it is not necessary to state explicitly what table to use, since by default iptables uses the filter table on which to implement all commands. Neither do you have to specify the table at just this point in the rule. It could be set pretty much anywhere along the line. However, it is more or less standard to put the table specification at the beginning.

One thing to think about though: The command should always come first, or alternatively directly after the table specification. We use 'command' to tell the program what to do, for example to insert a rule or to add a rule to the end of the chain, or to delete a rule. We shall take a further look at this below. The match is the part of the rule that we send to the kernel that details the specific character of the packet, what makes it different from all other packets. Here we could specify what IP address the packet comes from, from which network interface, the intended IP address, port, protocol or whatever. There is a heap of different matches that we can use that we will look closer at further down.

Finally we have the target of the packet. If all the matches are met for a packet, we tell the kernel what to do with it. We could, for example, tell the kernel to send the packet to another chain that we've created ourselves, and which is part of this particular table. We could tell the kernel to drop the packet dead and do no further processing, or we could tell the kernel to send a specified reply to the sender. As with the rest of the content in this section, we'll look closer at it further down.

Tables
The -t option specifies which table to use. Per default, the filter table is used. We may specify one of the following tables with the -t option. Do note that this is an extremely brief summary

Commands
In this section we will cover all the different commands and what can be done with them. The command tells iptables what to do with the rest of the rule that we send to the parser. Normally we would want either to add or delete something in some table or another. The following commands are available to iptables:

You should always enter a complete command line, unless you just want to list the built-in help for iptables or get the version of the command. To get the version, use the -v option and to get the help message, use the -h option. As usual, in other words. Next comes a few options that can be used with various different commands. Note that we tell you with which commands the options can be used and what effect they will have. Also note that we do not include any options here that affect rules or matches. Instead, we'll take a look at matches and targets in a later section of this chapter.

Options :

Matches
First of all we have the generic matches, which can be used in all rules. Then we have the TCP matches which can only be applied to TCP packets. We have UDP matches which can only be applied to UDP packets, and ICMP matches which can only be used on ICMP packets. Finally we have special matches, such as the state, owner and limit matches and so on. These final matches have in turn been narrowed down to even more subcategories, even though they might not necessarily be different matches at all.

Generic matches
This section will deal with Generic matches. A generic match is a kind of match that is always available, whatever kind of protocol we are working on, or whatever match extensions we have loaded. No special parameters at all are needed to use these matches; in other words. I have also included the --protocol match here, even though it is more specific to protocol matches. For example, if we want to use a TCP match, we need to use the --protocol match and send TCP as an option to the match. However, --protocol is also a match in itself, since it can be used to match specific protocols. The following matches are always available.

Generic matches

Implicit matches
Those are matches that are loaded implicitly. Implicit matches are implied, taken for granted, automatic. For example when we match on --protocol tcp without any further criteria. There are currently three types of implicit matches for three different protocols. These are TCP matches, UDP matches and ICMP matches. The TCP based matches contain a set of unique criteria that are available only for TCP packets. UDP based matches contain another set of criteria that are available only for UDP packets. And the same thing for ICMP packets. On the other hand, there can be explicit matches that are loaded explicitly. Explicit matches are not implied or automatic, you have to specify them specifically. For these you use the -m or --match option, which we will discuss in the next section.

TCP matches
These matches are protocol specific and are only available when working with TCP packets and streams. To use these matches, you need to specify --protocol tcp on the command line before trying to use them. Note that the --protocol tcp match must be to the left of the protocol specific matches. These matches are loaded implicitly in a sense, just as the UDP and ICMP matches are loaded implicitly. The other matches will be looked over in the continuation of this section, after the TCP match section.

UDP matches
will only work together with UDP packets. These matches are implicitly loaded when you specify the --protocol UDP match and will be available after this specification. Note that UDP packets are not connection oriented, and hence there is no such thing as different flags to set in the packet to give data on what the datagram is supposed to do, such as open or closing a connection, or if they are just simply supposed to send data. UDP packets do not require any kind of acknowledgment either. If they are lost, they are simply lost (Not taking ICMP error messaging etc into account). This means that there are quite a lot less matches to work with on a UDP packet than there is on TCP packets. Note that the state machine will work on all kinds of packets even though UDP or ICMP packets are counted as connectionless protocols. The state machine works pretty much the same on UDP packets as on TCP packets.

ICMP matches
These are the ICMP matches. These packets are even more ephemeral, that is to say short lived, than UDP packets, in the sense that they are connectionless. The ICMP protocol is mainly used for error reporting and for connection controlling and suchlike. ICMP is not a protocol subordinated to the IP protocol, but more of a protocol that augments the IP protocol and helps in handling errors. The headers of ICMP packets are very similar to those of the IP headers, but differ in a number of ways. The main feature of this protocol is the type header, that tells us what the packet is for. One example is, if we try to access an unaccessible IP address, we would normally get an ICMP host unreachable in return. For a complete listing of ICMP types, see the ICMP types appendix. There is only one ICMP specific match available for ICMP packets, and hopefully this should suffice. This match is implicitly loaded when we use the --protocol ICMP match and we get access to it automatically. Note that all the generic matches can also be used, so that among other things we can match on the source and destination addresses.

Explicit matches
Explicit matches are those that have to be specifically loaded with the -m or --match option. State matches, for example, demand the directive -m state prior to entering the actual match that you want to use. Some of these matches may be protocol specific. Some may be unconnected with any specific protocol - for example connection states. These might be NEW (the first packet of an as yet unestablished connection), ESTABLISHED (a connection that is already registered in the kernel), RELATED (a new connection that was created by an older, established one) etc. A few may just have been evolved for testing or experimental purposes, or just to illustrate what iptables is capable of. This in turn means that not all of these matches may at first sight be of any use. Nevertheless, it may well be that you personally will find a use for specific explicit matches. And there are new ones coming along all the time, with each new iptables release. Whether you find a use for them or not depends on your imagination and your needs. The difference between implicitly loaded matches and explicitly loaded ones, is that the implicitly loaded matches will automatically be loaded when, for example, you match on the properties of TCP packets, while explicitly loaded matches will never be loaded automatically - it is up to you to discover and activate explicit matches.

Limit match
The limit match extension must be loaded explicitly with the -m limit option. This match can, for example, be used to advantage to give limited logging of specific rules etc. For example, you could use this to match all packets that does not exceed a given value, and after this value has been exceeded, limit logging of the event in question. Think of a time limit : You could limit how many times a certain rule may be matched in a certain time frame, for example to lessen the effects of DoS syn flood attacks. This is its main usage, but there are more usages, of course. The limit match may also be inverted by adding a ! flag in front of the limit match. It would then be expressed as -m limit ! --limit 5/s.This means that all packets will be matched after they have broken thelimit.

To further explain the limit match, it is basically a token bucket filter. Consider having a leaky bucket where the bucket leaks X packets per time-unit. X is defined depending on how many matching packets we get, so if we get 3 packets, the bucket leaks 3 packets per that time-unit. The --limit option tells us how many packets to refill the bucket with per time-unit, while the --limit-burst option tells us how big the bucket is in the first place. So, setting --limit 3/minute --limit-burst 5, and then receiving 5 matches will empty the bucket. After 20 seconds, the bucket is refilled with another token, and so on until the --limit-burst is reached again or until they get used.

Consider the example below for further explanation of how this may look.
 * 1) We set a rule with -m limit --limit 5/second --limit-burst 10. The limit-burst token bucket is set to 10 initially. Each packet that matches the rule uses a token.
 * 2) We get packet that matches, 1-2-3-4-5-6-7-8-9-10, all within a 1/1000 of a second.
 * 3) The token bucket is now empty. Once the token bucket is empty, the packets that qualify for the rule otherwise no longer match the rule and proceed to the next rule if any, or hit the chain policy.
 * 4) For each 1/5 s without a matching packet, the token count goes up by 1, upto a maximum of 10. 2 seconds after receiving the 10 packets, we will once again have 10 tokens left.
 * 5) And of course, the bucket will be emptied by 1 token for each packet it receives.

MAC match
The MAC (Ethernet Media Access Control) match can be used to match packets based on their MAC source address. As of writing this documentation, this match is a little bit limited, however, in the future this may be more evolved and may be more useful. This match can be used to match packets on the source MAC address only as previously said.

Do note that to use this module we explicitly load it with the -m mac option. The reason that I am saying this is that a lot of people wonder if it should not be -m mac-source, which it should not.

Mark match
The mark match extension is used to match packets based on the marks they have set. A mark is a special field, only maintained within the kernel, that is associated with the packets as they travel through the computer. Marks may be used by different kernel routines for such tasks as traffic shaping and filtering. As of today, there is only one way of setting a mark in Linux, namely the MARK target in iptables. This was previously done with the FWMARK target in ipchains, and this is why people still refer to FWMARK in advanced routing areas. The mark field is currently set to an unsigned integer, or<PHONE_NUMBER> possible values on a 32 bit system. In other words, you are probably not going to run into this limit for quite some time.

Multiport match
The multiport match extension can be used to specify multiple destination ports and port ranges. Without the possibility this match gives, you would have to use multiple rules of the same type, just to match different ports.

You can not use both standard port matching and multiport matching at the same time, for example you can't write: --sport 1024:63353 -m multiport --dport 21,23,80. This will simply not work. What in fact happens, if you do, is that iptables honors the first element in the rule, and ignores the multiport instruction.

Owner match
The owner match extension is used to match packets based on the identity of the process that created them. The owner can be specified as the process ID either of the user who issued the command in question, that of the group, the process, the session, or that of the command itself. This extension was originally written as an example of what iptables could be used for. The owner match only works within the OUTPUT chain, for obvious reasons: It is pretty much impossible to find out any information about the identity of the instance that sent a packet from the other end, or where there is an intermediate hop to the real destination. Even within the OUTPUT chain it is not very reliable, since certain packets may not have an owner. Notorious packets of that sort are (among other things) the different ICMP responses. ICMP responses will never match.

State match
The state match extension is used in conjunction with the connection tracking code in the kernel. The state match accesses the connection tracking state of the packets from the conntracking machine. This allows us to know in what state the connection is, and works for pretty much all protocols, including stateless protocols such as ICMP and UDP. In all cases, there will be a default timeout for the connection and it will then be dropped from the connection tracking database. This match needs to be loaded explicitly by adding a -m state statement to the rule. You will then have access to one new match called state.

TOS match
The TOS match can be used to match packets based on their TOS field. TOS stands for Type Of Service, consists of 8 bits, and is located in the IP header. This match is loaded explicitly by adding -m tos to the rule. TOS is normally used to inform intermediate hosts of the precedence of the stream and its content (it doesn't really, but it informs of any specific requirements for the stream, such as it having to be sent as fast as possible, or it needing to be able to send as much payload as possible). How different routers and administrators deal with these values depends. Most do not care at all, while others try their best to do something good with the packets in question and the data they provide.

TTL match
The TTL match is used to match packets based on their TTL (Time To Live) field residing in the IP headers. The TTL field contains 8 bits of data and is decremented once every time it is processed by an intermediate host between the client and recipient host. If the TTL reaches 0, an ICMP type 11 code 0 (TTL equals 0 during transit) or code 1 (TTL equals 0 during reassembly) is transmitted to the party sending the packet and informing it of the problem. This match is only used to match packets based on their TTL, and not to change anything. The latter, incidentally, applies to all kinds of matches. To load this match, you need to add an -m ttl to the rule.

Targets/Jumps
The target/jumps tells the rule what to do with a packet that is a perfect match with the match section of the rule. There are a couple of basic targets, the ACCEPT and DROP targets, which we will deal with first. However, before we do that, let us have a brief look at how a jump is done.

The jump specification is done in exactly the same way as in the target definition, except that it requires a chain within the same table to jump to. To jump to a specific chain, it is of course a prerequisite that that chain exists. As we have already explained, a user-defined chain is created with the -N command. For example, let's say we create a chain in the filter table called tcp_packets, like this: iptables -N tcp_packets

We could then add a jump target to it like this:

iptables -A INPUT -p tcp -j tcp_packets

We would then jump from the INPUT chain to the tcp_packets chain and start traversing that chain. When/If we reach the end of that chain, we get dropped back to the INPUT chain and the packet starts traversing from the rule one step below where it jumped to the other chain (tcp_packets in this case). If a packet is ACCEPTed within one of the sub chains, it will be ACCEPT'ed in the superset chain also and it will not traverse any of the superset chains any further. However, do note that the packet will traverse all other chains in the other tables in a normal fashion.

Targets on the other hand specify an action to take on the packet in question. We could for example, DROP or ACCEPT the packet depending on what we want to do. There are also a number of other actions we may want to take, which we will describe further on in this section. Jumping to targets may incur different results, as it were. Some targets will cause the packet to stop traversing that specific chain and superior chains as described above. Good examples of such rules are DROP and ACCEPT. Rules that are stopped, will not pass through any of the rules further on in the chain or in superior chains. Other targets, may take an action on the packet, after which the packet will continue passing through the rest of the rules. A good example of this would be the LOG, ULOG and TOS targets. These targets can log the packets, mangle them and then pass them on to the other rules in the same set of chains. We might, for example,


text:
Queen of Hearts (2019 film)

Queen of Hearts (Dronningen, The Queen) is a 2019 Danish drama film directed by May el-Toukhy, and starring Trine Dyrholm and Gustav Lindh. The Danish and English film titles obliquely refer to the Queen of Hearts character in the children's book Alice's Adventures in Wonderland which is mentioned repeatedly in the film. The film was selected as the Danish entry for the Best International Feature Film at the 92nd Academy Awards, though it was not nominated. The film won the 2019 Nordic Council Film Prize.

Plot
Anne is a lawyer working on three cases of rape and violent abuse of young women. She is married to a physician, Peter, and they have two young, twin daughters, Frida and Fanny. Peter's teenage son from his past marriage is Gustav, who lives in Sweden with his mother Rebecca. The family plans for Gustav to move in with Anne and Peter. Gustav arrives and Anne flirts with him. Gustav begins to have conflicts with Peter, pushing to move out on his own despite being a minor. One day, Anne returns home to find there has been a burglary. The incident is reported to the police, but afterwards Anne finds an item in Gustav's laundry that was in her bag, stolen during the break-in. She realizes that Gustav was responsible for the robbery and confronts him with the evidence. Anne promises to keep the matter a secret if Gustav does his part in the household. From then on, Gustav joins in the social life of the family, for instance reading the Danish version of Alice's Adventures in Wonderland for the twin girls, which Anne herself also does.

One night, Gustav brings his girlfriend Amanda home. Anne hears the couple having sex and is aroused.

Peter and Anne entertain guests on their balcony, but Anne leaves the group to take Gustav to a bar. There, she kisses him. Later at night, she enters his bedroom and seduces him. The two begin a sexual relationship. Gustav interviews Anne with a tape recorder, asking her various questions, such as about her first sexual relationship. Anne says it was with someone she should not have had sex with. The family celebrates Frida and Fanny's birthday. When Anne and Gustav step away, Gustav kisses her. A guest, Anne's sister Lina, witnesses the encounter and, upset, leaves the party. Anne fears Lina will tell Peter, and breaks off her relationship with Gustav.

Gustav and Peter leave to spend time at their cabin in the woods. After their return, Peter tells Anne that Gustav wants to go to a boarding school, and told his father what had happened between him and Anne and. Anne denies the accusation, claiming Gustav hates her for ending Peter and Rebecca's marriage. She also tells Peter that Gustav was responsible for the burglary. Anne, Peter, and Gustav then sit down together, where Anne continues to deny the affair. Gustav departs for a boarding school. Much later, Gustav visits the office of Anne and threatens to report her for the illegal relationship, but she replies he is not a credible witness and never will be believed. He calls on her house at night asking for his father but is rejected by Anne who leaves him weeping on the ground. At a party for Anne, Peter is called with the message that Gustav has gone missing from his school. Peter is called to Stockholm by the police. It turns out a hunter has discovered Gustav's body near the cabin, where he froze to death. When Anne tells Peter that Gustav's death is not his fault, Peter violently silences her. In the end, Peter, Anne and the two young girls, dressed in black, drive in silence in their car, presumably to Gustav's funeral.

Cast

 * Trine Dyrholm as Anne
 * Gustav Lindh as Gustav
 * Magnus Krepper as Peter
 * Preben Kristensen as Erik
 * Mads Wille as Karsten
 * Peter Khouri as Janus
 * Diem Camille Gbogou as Louise

Production
In reference to the sex scenes, protagonist Trine Dyrholm said: "We had the first meeting about the nude scenes very early on with both the producer and the director. They told us what they had in mind. And we agreed that you could go to the producer along the way if there was something someone didn't want to go along with. We were even sent storyboard illustrations of the scene frame by frame, and the prosthetics that would resemble the male genitalia were made. I would almost compare working on nude scenes here to working on a stunt scene. When you have to do that kind of scene, it's always a bit awkward, but because it was such a safe working space and everything was agreed in advance, it worked."

Reception
Guy Lodge of Variety magazine called it "[A] sleek, engrossing melodrama." Dyrholm's performance was especially praised. The Los Angeles Times review referred to the "tricky brilliance" of the film.

On Rotten Tomatoes the film has an approval rating of based on  reviews. The site's critical consensus reads, "Led by an exceptional performance from Trine Dyrholm, Queen of Hearts is a bold and uncompromising look at the darkness that can lie within family, directed with formidable skill by May El-Toukhy."

The film won nine Robert Awards, including Best Danish Film. It also won four Bodil Awards, including Best Danish Film. At the 2019 Sundance Film Festival, the film won the Audience Award in the World Cinema Dramatic category.

Remake
A French remake was directed by Catherine Breillat, from a screenplay written by Breillat in collaboration with Pascal Bonitzer. Starring Léa Drucker and Samuel Kircher, the film premiered in competition at the 76th Cannes Film Festival.

source: wikimedia

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Queen of Hearts (2019 film)


text:
Paraul, Republic of Dagestan

Paraul (Параул; Пари-авул, Pari-avul) is a rural locality (a selo) in Karabudakhkentsky District, Republic of Dagestan, Russia. The population was 4,949 as of 2010. There are 66 streets.

Geography
Paraul is located 90 km northwest of Novokayakent (the district's administrative centre) by road. Karabudakhkent and Buynaksk are the nearest rural localities.

title: Paraul, Republic of Dagestan


text:
Talk:American International School of Johannesburg

Note about specific locations and directions
The schools website states that: "For security reasons the American International School of Johannesburg does not have directions / or a map available on the website. Should you need directions to either the Johannesburg / Pretoria Campus please request it from the individual or department you will be visiting."

I do not know how to handle photo requests for this place. I will ask South African Wikipedians for guidance. WhisperToMe (talk) 07:16, 10 February 2015 (UTC)


text:
Talk:Bernard Gosselin

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on Bernard Gosselin. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20110625075726/http://www.northernstars.ca:80/directorsal/gosselin_bernard.html to http://www.northernstars.ca/directorsal/gosselin_bernard.html

Cheers.— InternetArchiveBot  (Report bug) 13:13, 31 October 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 external links on Bernard Gosselin. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20120515214729/http://tiff.net/CANADIANFILMENCYCLOPEDIA/content/bios/bernard-gosselin to http://www.tiff.net/CANADIANFILMENCYCLOPEDIA/content/bios/bernard-gosselin
 * Added tag to http://www.onf-nfb.gc.ca/eng/portraits/bernard_gosselin/
 * Corrected formatting/usage for http://www.northernstars.ca/directorsal/gosselin_bernard.html

Cheers.— InternetArchiveBot  (Report bug) 15:23, 18 July 2017 (UTC)

title: Talk:Bernard Gosselin


text:
Life (gamer)

Lee Seung-Hyun (이승현, born January 11, 1997), better known as Life, is a South Korean former professional StarCraft II player. He began his professional career in 2011 with Team Zenex, which later merged with StarTale. He subsequently represented teams such as KT Rolster and briefly, Afreeca Freecs. Throughout his career, Life distinguished himself as one of the most accomplished StarCraft II players in the history of the game. He secured numerous premier tournament victories, including a World Championship Series title in 2014, two Global StarCraft II League (GSL) titles, a GSL Blizzard Cup title, two Major League Gaming events, two DreamHack tournaments, and one Intel Extreme Masters competition.

Life's career ended with controversy in 2016 when he was embroiled in a match fixing scandal that resulted in his arrest. Subsequently, he was convicted and handed an 18-month suspended prison sentence, along with a fine of (approximately US$58,000). Additionally, Life received a lifetime ban from participating in Korean esports events.

Early success (2011–2012)
At the age of 14, Life began his professional StarCraft career by joining Team Zenex in March 2011. He primarily participated in the iCCup Korean Weekly, later renamed the ESV TV Korean Weekly. Within one month of competitive play, he achieved his first tournament victory by defeating Jung "jjakji" Ji-hoon in the finals of ESV TV Korean Weekly Season 1 #6. Over his initial seven months as a competitor, Life secured top-eight finishes or higher nine times. Among these, he reached the finals on four occasions, claiming victory in two. During this period, Life engaged in a rivalry with fellow player Yun "TaeJa" Young-seo. Throughout their encounters in the Korean Weekly tournaments, TaeJa defeated Life on five occasions, while Life had yet to secure a win against him.

Subsequently, Life participated in the Global StarCraft II Team League (GSTL). During one of the GSTL events, he achieved an "All-Kill" when he defeated all five players from Team Liquid. In July 2012, Team Zenex merged with StarTale. Life then participated in the Team Liquid StarLeague, where his performance over a span of five months led him to a second-place finish. The only match he lost throughout the tournament was to Jang "Creator" Hyun Woo in the finals.

Following his participation in the Team Liquid StarLeague, Life made his debut in the Global StarCraft II League (GSL) Code S, the highest division of GSL, during GSL Season 4 in 2012. This season, Life achieved a feat known as "walking the Royal Road," a term used when a player secures a premier Korean title during their first qualification for competition. Throughout the season, Life displayed defeated players such as Lim "NesTea" Jae Duk, Ahn "Seed" Sang-wong, Lee "MarineKing" Jung-hoon, and TaeJa. In the grand finals of GSL Season 4, he faced off against Jung "Mvp" Jong-hun, a player who had won the third most premier StarCraft II tournaments at that time. Life won the series, four games to three, ultimately becoming the GSL champion. At 15 years old, he became the youngest player ever to secure a GSL championship and the first player to achieve the "Royal Roader" status in GSL history.

In the subsequent week following his GSL victory, Life won 2012 MLG Fall Championship in Dallas, Texas. He defeated Lee "Leenock" Dong-nyoung in the finals, despite initially trailing the match 1–3. This achievement made him the youngest player ever to secure an MLG championship. After returning to Korea to compete in the next GSL, Life faced a swift elimination within two weeks. One of the next tournaments he competed in was season five of the IGN Pro League (IPL5), held in Las Vegas, Nevada, in November 2012. He ultimately lost against Leenock and Jens "Snute" Aasgaard in the upper and lower brackets, respectively. While the IPL5 event was ongoing, the GSL World Championship exhibition series, a showmatch pitting Team Korea against Team World, took place, with Life competing as a member of Team Korea. In the first round, he won in his first match against Johan "Naniwa" Lucches, as Team Korea went on to win the round. In the second round, the winner was determined by the first team to secure five victories, with each match winner proceeding to face another player from the opposing team. Life, as the first representative of Team Korea, secured four consecutive victories. Although he lost his fifth match against Ilyes "Stephano" Satouri, Team Korea won the event.

Life's participation in the 2012 tournament circuit concluded with the GSL Blizzard Cup, an event featuring the top Korean players of that year. After advancing through the group stage, he defeated Park "DongRaeGu" Soo-ho and Leenock in the bracket stage, securing a place in the finals. In the championship match, he faced Won "Parting" Lee-sak. Parting took an early lead in the series by claiming victory in the first two games. However, Life won the following four matches to claim the tournament title.

Struggles and rebound (2013)
Early in 2013, Life secured a tournament victory at Iron Squid 2, after rallying back from a 0–3 deficit against Park "DRG" Soo-ho in the finals. During this period, the competitive landscape of StarCraft II was undergoing a transition from StarCraft II: Wings of Liberty to the new expansion, StarCraft II: Heart of the Swarm. Life's final tournament in the Wings of Liberty era was 2013 GSL Season 1, where he was eliminated during the group stage. He won his first Heart of the Swarm tournament at the 2013 MLG Winter after defeating Lee "Flash" Young-ho. This victory made him the first StarCraft player to win consecutive MLG Championship events. In April 2013, Life participated in the preliminary qualifiers for the 2013 Asian Indoor and Martial Arts Games, securing a spot at the event by defeating Flash in the qualifiers. However, due to a scheduling conflict with an upcoming MLG event, he was unable to attend the Asian Indoor and Martial Arts Games.

In the first of the three 2013 StarCraft II World Championship Series (WCS) seasons held in Korea, which was hosted by GSL, Life was eliminated during the group stage. This marked the third consecutive season in which he failed to progress beyond the round of 16. His performance in this event resulted in his relegation to the WCS Challenger League. However, he was qualified for the subsequent WCS season after defeating MarineKing in the Challenger League. Life continued to encounter difficulties throughout the rest of the year. In between WCS seasons, he participated in DreamHack Summer 2013, where he faced Jeffrey "Sjow" Brusi in a match where he was heavily favored to win but ultimately lost. Following the loss, Life's motivation appeared to wane, leading to a reduction in his practice regimen. Upon his return to Korea for the second WCS season of the year, this time hosted by the OnGameNet StarLeague (OSL), Life was eliminated after just two games, experiencing defeats by both Jung "Fantasy" Myung-hoon and Hwang "KangHo" Kang-ho. This once again relegated him to the Challenger League, where he was defeated in the round of 24 by Shin "hyvaa" Dae-kun. This early exit meant that Life would need to compete in the Up & Down matches, a qualifier tournament, in order to secure a spot in the following season's WCS Code S. In the Up & Down matches, Life lost his first two matches and ultimately failed to qualify for the next season's Code S tournament.

By the end of 2013, Life's competitive drive appeared to be rekindled, as he achieved success at several foreign events, reaching the semifinals or finals in four of them. In September, he traveled to Bucharest, Romania, to participate in his second DreamHack event. There, he reached the semifinals but was defeated by the eventual champion, Yun "TaeJa" Young-seo. Less than a month later, Life attended the Intel Extreme Masters New York 2013. After advancing past the group stage, he swept his opponents in both the quarterfinals and semifinals, securing a spot in the finals. In the championship match, he faced off against Naniwa and emerged victorious, claiming the IEM title with a 4–2 victory. In late December, Life travelled to Sweden for DreamHack Winter 2013. He reached the upper bracket finals, where he lost to TaeJa. However, after defeating Jo "Patience" Ji-hyun in the lower bracket finals, he earned a place in the grand finals. Ultimately, Life finished the event in second place, with TaeJa winning in the grand finals. At his final event in 2013, Life reached the semifinals at ASUS ROG NorthCon.

World champion (2014–2016)
In the early months of 2014, Life qualified for Code S of GSL Season 1. During the tournament, he advanced to the semifinals where he lost to Eo "soO" Yoon-su. In April 2014, Life traveled to compete in DreamHack Bucharest 2014. Throughout the event, he lost only once during the group stage. Life won the event after defeating Kim "Impact" Joon-hyuk in the finals.

By the end of 2014, Life had accrued sufficient World Championship Points to secure a spot in the 2014 StarCraft II World Championship Series (WCS) at BlizzCon 2014, held in November. During the WCS tournament, he won his initial two matches, advancing him to the semifinals. In the semifinals, Life defeated TaeJa, who widely regarded as the strongest player remaining in the tournament. The championship match saw Life face Mun "MMA" Seong-won. In a 4–1 victory, he defeated MMA and clinched the 2014 championship title. Reflecting on his journey to the WCS title, Life said in a press conference, "[Last year] I had a lot of confidence in my skills, but since things didn't work out well this year, I have gotten more humble. Personally, being without that higher confidence level has been good for me. Because I can strive forward, work harder." At his final event in 2014, Life participated in DreamHack Winter 2014. He defeated TaeJa once again in the semifinals and finished the tournament in second place after losing to Park "ForGG" Ji-soo in the finals.

In January 2015, Life won IEM Taipei 2015. In this tournament, he achieved victory over Cho "Maru" Seong Ju in the finals, who was widely recognized as one of the top players at the time. The following month, he departed from StarTale and signed with KT Rolster. Life then participated in the 2015 GSL Season 1: Code S, where he ultimately defeated Parting and claimed the first-place title. Throughout the year, he maintained his competitive standing with top-four finishes in both the StarCraft II StarLeague (SSL) Season 1 and the KeSPA Cup, as well as a top-eight finish in SSL Season 2. However, it became apparent that Life's passion for the game began to wane once again by the end of 2015. Despite this, he had accumulated enough World Championship Points to secure a spot in the 2015 StarCraft II World Championship Series. In the event, Life reached the finals, facing off against Kim "sOs" Yoo Jin. He ultimately finished in second place, with a 3–4 loss in the finals.

In January 2016, Life signed with Afreeca Freecs. His professional StarCraft II career came to an end in 2016 when he received a lifetime ban from all Korean esports events due to his involvement in match-fixing activities. At the end of his career, Life had secured the second-highest number of premier StarCraft II tournament victories among all players and had accumulated the second largest prize money earnings in the competitive scene, amounting to around US$475,000.

Match fixing
On January 29, 2016, the Korean e-Sports Association (KeSPA) released a statement announcing that Life was under investigation by the Changwon district prosecutors' office for his alleged involvement in match-fixing activities in professional StarCraft II matches. Three months later, on April 21, the Changwon Regional Prosecution Service special investigations division released a report confirming that Life, along with Jung "Bbyong" Woo-yong and 11 financial backers and brokers, had been convicted of match-fixing in two matches during the KeSPA Cup. As a result of this conviction, Life was sentenced to 18 months of imprisonment with a suspended sentence for three years. Additionally, he was fined (approximately $58,000) as part of the legal consequences of his involvement. Furthermore, Life received a lifetime ban from participating in Korean esports events. The match-fixing scandal involving Life was regarded the most disappointing events in esports in 2016 by ESPN.

Accomplishments

 * World Championship Series
 * One-time WCS Global Finals champion – 2014

 * Global StarCraft II League
 * Two-time GSL champion – 2012 Season Four, 2015 Season One
 * One-time GSL Blizzard Cup champion – 2012

 * Other
 * Two-time DreamHack champion – Bucharest 2014, Taipei 2015
 * Two-time MLG champion – Fall 2012, Winter 2013
 * One-time Iron Squid champion – 2013
 * One-time IEM champion – New York 2013
 * One-time IGN Pro Team League champion – 2012

title: Life (gamer)


text:
Hemidactylus sankariensis

Hemidactylus sankariensis, the Sankari brookiish gecko is a species of gecko. It is endemic to India.

title: Hemidactylus sankariensis


text:
Government Arts College for Men, Nandanam

Government Arts College for Men (Autonomous), Nandanam, is a general degree college located at Nandanam, Chennai, Tamil Nadu. It was established in the year 1901. The college is affiliated with University of Madras. This college offers different courses in arts, commerce and science.

Department
Source:
 * DEPARTMENT OF TAMIL
 * DEPARTMENT OF ENGLISH
 * DEPARTMENT OF HISTORICAL STUDIES
 * DEPARTMENT OF ECONOMICS
 * DEPARTMENT OF COMMERCE
 * DEPARTMENT OF COMMERCE (Corporate secretaryship)
 * DEPARTMENT OF B.B.A BUSINESS ADMINISTRATION
 * DEPARTMENT OF MATHEMATICS
 * DEPARTMENT OF PHYSICS
 * DEPARTMENT OF CHEMISTRY
 * DEPARTMENT OF BOTANY
 * DEPARTMENT OF ZOOLOGY
 * DEPARTMENT OF COMPUTER SCIENCE
 * DEPARTMENT OF PUBLIC ADMINISTRATION
 * DEPARTMENT OF STATISTICS
 * LIBRARY

Courses Offered
Source:

Accreditation
The college is recognized by the University Grants Commission (UGC).


text:
Sphaerocoris annulus

Sphaerocoris annulus, common names Picasso bug or Zulu hud bug (Zulu: "iCikwa"), is a species of shield-backed bugs of the family Scutelleridae.

Description
Sphaerocoris annulus can reach a length of about 15 mm. The basic color is green, with eleven ring-shaped spots on the scutellum. The colors and the design of these bugs represent a warning to predators. They also emit a noxious odour when disturbed. Main host plants are Gossypium species (Malvaceae), Coffea arabica (Rubiaceae), Citrus species (Rutaceae) and Vernonia amygdalina (Asteraceae). This species reproduces at the beginning of the dry season (November–December). Eggs are laid on the underside of leaves, and nymphs will spend a majority of their time in flowers feeding. Once they molt into adults, however, their feeding becomes more generalized. The full development lasts 56 days. Sphaerocoris annulus nymphs are a creamy-white color with black stripes and dots, and gain their colorful spots when they reach maturity.

Distribution
This species is present in tropical and subtropical Africa (Benin, Cameroon, Côte d'Ivoire, Ethiopia, Ghana, Kenya, Malawi, Mozambique, Namibia, Nigeria, Sierra Leone, South Africa, Tanzania, Togo, Zambia and Zimbabwe).

title: Sphaerocoris annulus


text:
User:Arysardar42069/sandbox

Aryan Sardar... Who is Aryan Sardar? He is an enigma. A gambler. A muslim. A professional gamer. A lil pump fan. Ray's left nippy. A man with 2000 IQ. But who is he really?

That story is yet to be written...

title: User:Arysardar42069/sandbox


text:
Talk:Free Spirit (band)

Small Edits
As a part of an assignment for this course, I corrected a few grammatical errors on the page. I reworded the first two sentences on the history section and changed a semicolon to a colon.And also added a few minor sentences. Mpastr1 (talk) 00:19, 8 February 2015 (UTC)

title: Talk:Free Spirit (band)


text:
Micaela Martins Jacintho

Micaela Martins Jacintho (born 12 June 1979) is a Brazilian basketball player who competed in the 2008 Summer Olympics.

title: Micaela Martins Jacintho


text:
Portal:Learning Projects/Categories

 * Learning projects
 * Astronomy Project
 * Biology learning projects
 * Business learning projects
 * Advanced Placement and Pre-AP Chemistry projects

title: Portal:Learning Projects/Categories


text:
User:Dmckelvey/more markup

italic text

Subsection
external link

bulleted list:

 * item 1
 * item 2
 * sub-item

numbered list:

 * 1) first item
 * 2) sub-item 1
 * 3) sub-item 2
 * 4) second item

template

signature: Dmckelvey (talk)

title: User:Dmckelvey/more markup


text:
Talk:Discrete Mathematics/Modular arithmetic

under Chinese remainder theorem it says

N=m1m2...mk, then write n1=N/m1, ..., nk=N/mk.

leading to

nk=N/mk and nkmk=N (sounds right)

and

Our solution will be x ≡ a1m1n1+...+akmknk (mod N)

leading to

Our solution will be x ≡ (a1+...+ak)N (mod N) ≡ 0 (mod N)

which sounds wrong. Hopefully someone can fix this, or explain better why it is right.

also, N can be lcm(m1,...,mk) when gcd(m1,...,mk)!=1

 * I've always disliked the CRT, so there might be an error lurking there somewhere. I've got to review and expand that section, but I have little time nowadays... Dysprosia 08:29, 16 Mar 2004 (UTC)

More explanations for the answers would be awesome
For question 6 I have a hard time grasping why the answer would be 3. A more in depth explanation of the answers provided would be helpful. --Emilhem (discuss • contribs) 18:48, 25 August 2016 (UTC)


text:
Alfredson

Alfredson is a surname meaning "son of Alfred". Notable people with the surname include:

 * Daniel Alfredson (born 1959), Swedish film director
 * Hans Alfredson (1931–2017), Swedish actor, film director, writer and comedian
 * Hawk Alfredson (born 1960), Swedish artist
 * Tomas Alfredson (born 1965), Swedish film director

title: Alfredson


text:
Talk:Infinity Divine

Fair use rationale for Image:PM-ID-album.jpg
Image:PM-ID-album.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

BetacommandBot (talk) 15:17, 8 March 2008 (UTC)

title: Talk:Infinity Divine


text:
Body language/Essay questions

Relative Position
When studying body language, we learn that our position and its relativity to others around you can indicate a number social preferences.

For instance, when talking ‘one on one’ with someone, the position of your legs and their direction in relation to the person you're speaking to can suggest whether you wish to continue conversation.

When in a group situation, the very same set of observations (position of the legs), can suggest which person you most desire to interact with.

What else is there to learn or observe, which other parts of the body can we collect this type of information from?

title: Body language/Essay questions


text:
Template:Did you know nominations/Masanobu Takayanagi

The result was: promoted by Miyagawa (talk) 12:12, 14 February 2015 (UTC)

Masanobu Takayanagi

 * ... that Masanobu Takayanagi was inspired to move to the U.S. and become a cinematographer after seeing a book about the subject in a Japanese bookstore?
 * Reviewed: Philharmonic Hall, London

Created by 97198 (talk). Self nominated at 06:25, 10 February 2015 (UTC).

 * Symbol confirmed.svg New enough, long enough. Hook cited. No signs of close paraphrasing. QPQ done. Good to go. Freikorp (talk) 22:27, 10 February 2015 (UTC)


text:
Anthropomorphic Robotics Project/Brainstorming/Artificial intelligence and cognitive systems

Suppose you wanted to design a robot to farm. Suppose you wanted to have an organic farm, so you build yourself a robot with the millions of dollars and hours of time you have to do such a thing.

You build this robots mechanical systems and now you need to program it.

You tell the robot, "Dig a circular hole four feet deep and 10 feet in diameter on the north east corner of our property no closer than 10 feet to property boundary. Put the dirt in trucks that we will bring in as needed." (you want to make a pond to house coy but you are too busy building more robots to actually dig the hole yourself)

So we contract with a group to monitor the robot and bring big trucks in as need to haul away the dirt.

The robot will then have to decode and execute the instructions. This presumes that the robot can walk and knows how to use its body and has somewhat complex motor control.

The robot tells itself:
 * Okay. Act...
 * Act when? I only act during the day when there is light to act.
 * Could I act now in the dark? What would I need to act now in the dark?
 * I would need light. Do I have a way of providing light? Yes. I have infrared vision. I can see in the dark.
 * "Dig a circular hole four feet deep and 10 feet in diameter on the north east corner of our property no closer than 10 feet to property boundary. Put the dirt in trucks that we will bring in as needed."
 * Dig. What is to dig? I will look in my knowledge database....
 * So the robot checks its Wiktionary database first. It either does this through a wireless connection it has to a computer in the barn (or house) (or where ever), or checks its local copy of the data base and finds after parsing the page:

Verb

 * 1) To move hard-packed earth out of the way, especially downward to make a hole with a shovel.  Or to drill etc. through rocks, roads, etc.
 * They dug an eight foot deep ditch along the side of the road.
 * In the wintertime, heavy truck tires dig into the road, forming potholes.
 * If the plane can't pull out of the dive it is in, it'll dig a hole in the ground.
 * 1) "dig into" - To research a particular subject.
 * She is going to dig into Egyptian basket-weaving this semester.
 * 1) as slang - To appreciate, or like.
 * Baby, I dig you.
 * 1) as slang - To understand or show interest in.
 * You dig?

So using modeling it asks itself: Is what my owner meant by "dig" most likely that he wants me "to like a hole"? Looks up like... "like" is positivly correlated with "positive emotional valance" but positive emotional valance is very weakly associated with "farm" and "dig"... this is a farm... I do not see "positive emotional valance" correlated with "farm" and "dig".. I do see that "farm" is correlated more heavily with "hole", "pond" and with "plant" which is correlated with "dig" No... he wants me to move hard packed earth.

What do I need? My database tells me that shovels, and heavy equipment are useful for digging. What do I have access to? I have access to a shovel in the barn. What does a shovel look like? According to the database a shovel has the following features associated with it. 4-5 feet long, wood, handle, metal piece on end .5-.15 feet squared in flat area attached to handle. I must walk to the barn and find such an object....

The robot walks to the barn... goes to where tools are known to be kept... looks for shovel... finds object most likely to be a shovel.

The robot looks up word handle - grab handle hold... handle. The robot grabs the handle half way down the handle and is careful to avoid object collision as it walks out the the north east corner of the property. Usings its GPS model it creates a top down map of the property in its on board computer...

It orients itself on the map.

It creates the environment in 3D including itself. It knows where its hands are. It places the shovel on the ground.

"Dig a circular hole four feet deep and 10 feet in diameter on the north east corner of our property no closer than 10 feet to property boundary. Put the dirt in trucks that we will bring in as needed."

Am I ready to start digg? The robot surveys the map of the area and checks it against his vision. The land is "flat", "barren" "covered" - "with grass" - the condition of the soil is "probably soft". Metal can penetrate. There is a truck placed near by. There is also a wheel barrow. The robot decides it is time to dig after assessing no threats to safety of humans or self.

Robot sees "shovel" - knows is highly correlated with "dig".

Examines shovel and earth and runs through simulatory analysis engine to see how to to best utilize the highly correlated "shovel" with "dig".

The physics engine simulates what the final hole will look like.

It works backwards to see the slope of the whole created in such a way to not trap the robot in the whole.

The shape of the metal part of the shovel is correlated with "sharp", and "peirce", and "dig" and "carry", "soil", bang, hit.

The robot examines "dig" and "property" together they are correlated with "soft" "soil" "earth" "soil" "ground" "rights" "ownership" "excavate" "soft"...

The robot runs more analysis...

The robot simulates the movements it would take for it to pick up the shovel. It sees the shovel on the ground next to itself. It keeps this model of it next to the shovel. It see itself bending its knees and lowering its body to a point it can reach the shovel....

To be continued...

Initial thoughts from this brain storming session are that for a robot to have "intelligent" cognitive systems it would need a rather large database of precorrelated terms to other terms. So every term would have all possible correlates arranged by probability, so when "reasoning" a robot would have to be able to effeciently grab terms correlated to objects it its environment and auditory/cognitive/memory systems.

At least for inputs... have one device to listen... one to transcribe... one ...

Reading

 * Natural language processing at Wikipedia


text:
The Voynich Manuscript/F9v

Transcription, comments, theories, links to do with VMs page f9v to be added here... :-)

Description:
One plant, flush against the right and bottom edges, reaching almost to the top.

 * Root: a bundle of thin wires. Dark overpaint?

 * Stem: one straight. Light color.

 * Branches: two symmetrical pairs, oblique.

 * Leaves: the four lower ones are medium width, lance-shaped, with smooth edges; the others have the same outline but are deeply cut into five narrow points. Dark color.

 * Stalk: short, mostly missing.

 * Flowers: five, at the tips of stem and branches.

 * Stalk: medium length, thin

 * Chalyx: flat or everted, with short triangular sepals, partly hidden by corolla.

 * Petals: five rounded petals, a large one on top, the others like "arms and legs".

 * Core: very small. Medium and dark colors.

Two paragraphs (with 3.7 and 7.7 lines) at the top, left-justified. The first one is right-justified; the second one follows the plant's profile on the right. Both are interrupted in several places by the flowers and leaves.

Comments:
Petersen identifies this plant, with high confidence, as "Viola trinitalis". I coudn't find such species, but "herba trinitatis" is the herbalists' name for Viola tricolor (heartsease,wild pansy) [1,2,3].

Indeed, comparing f9v with a drawing by Carl Lindman [1], we see an almost perfect match --- including the roots, and the two types of leaves.

Dennis Mardle [10 Oct 1998] observes that the details match also Viola arvensis (field pansy), which hybridises with V. tricolor and is very similar in shape, including especially the dimorphic leaves [1,4].

The colors may help resolve this issue. The flowers of Viola tricolor are usually purple and white with yellow core; Lindman's drawing shows V. arvensis as white (or light blue?) with yellow core. Jim Reeds color list [03 Mar 1998] reports some blue on this page, to be confirmed.

In either case, there is one odd detail: the flowers in f9v are upside-down. Also the two bottom flowers are somewhat different.

Viola tricolor was used internally to treat epilepsy, asthma and bronchitis (whole plant), as an emetic and purgative (seeds) and as a heart tonic (flowers). Externally it was used to treat skin diseases [2]. The flowers are reported to be edible.

References:
[1] Carl Axel Magnus Lindman
 * Bilder ur Nordens Flora
 * 227. A. Styvmorsviol, Viola tricolor L.; B. Åkerviol, Viola arvensis Murr.
 * http://www.runeberg.org/nordflor/
 * http://www.runeberg.org/nordflor/227.html

[2] Mrs. M. Grieve, F.R.H.S.
 * A Modern Herbal
 * Viola tricolor - Heartsease
 * http://www.botanical.com/botanical/mgmh/mgmh.html
 * http://www.botanical.com/botanical/mgmh/h/hearts10.html

[3] ECNC DATABASE: SAXIFRAGA European Flora Slides
 * Viola tricolor ssp. tricolor
 * http://www.ecnc.nl/doc/ecnc/saxifrag/euroflor.html
 * http://www.ecnc.nl/gif/viotritr.gif

[4] ECNC DATABASE: SAXIFRAGA European Flora Slides
 * Viola Arvensis Murr.
 * http://www.ecnc.nl/doc/ecnc/saxifrag/euroflor.html
 * http://www.ecnc.nl/gif/vioarv.gif

title: The Voynich Manuscript/F9v