Update dreamworld.

Signed-off-by: Joachim Nilsson <troglobit@gmail.com>

TODO.md

@@ -63,11 +63,12 @@ to each inetd service.  When a client connects the finit will call the
 callback with a `struct in_pktinfo` argument which the callback then can
 allowed or deny.
 
-Alternatively, borrowing from TCP wrappers by Wietse Venema, a set of
-`allow` and `deny` directives can be added to `finit.conf` to control
-inetd services.  It could be what IP addreses, networks or interfaces
-are allowed to connect to the given inetd services.  To start with the
-easiest (and what we need for WeOS at Westermo) is allow/deny per iface.
+Alternatively, borrowing slightly from TCP wrappers by Wietse Venema, a
+set of `allow` and `deny` directives can be added to `finit.conf` to
+control inetd services.  It could be what IP addreses, networks or
+interfaces are allowed to connect to the given inetd services.  To start
+with the easiest (and what we need for WeOS at Westermo) is allow/deny
+per iface.
 
     # Disable access to SSH
     deny  ssh all
@@ -85,7 +86,8 @@ an SSH service on different ports on different interfaces:
     }
     
     # Run SSH on non-standard port 222 for upstream interface
-    tcp 222 {
+    tcp ssh {
+       port   = 222
        listen = wan0
        exec   = dropbear -i
        wait   = yes
@@ -98,7 +100,84 @@ an SSH service on different ports on different interfaces:
        user   = root
     }
 
-Syntax very similar to [xinetd](http://en.wikipedia.org/wiki/Xinetd)
+or, more concise
+
+    # System has four interfaces: wan0, eth0, eth1, eth2
+    # This runs SSH on only three, with various ports
+    tcp ssh {
+       listen = wan0:222 eth0:22 eth1:22
+       exec   = /usr/sbin/dropbear -i
+       wait   = yes
+    }
+
+this would be equivalent
+
+    tcp ssh {
+       listen = wan0:222 !eth2
+       exec   = /usr/sbin/dropbear -i
+       wait   = yes
+    }
+
+Syntax similar to [xinetd](http://en.wikipedia.org/wiki/Xinetd)
+
+### Custom Inet Port for Common Services
+
+- How to do this, without an obtrusive syntax?
+
+Maybe like this?  Then we can still refer to it as the time protocol,
+and have multiple entries.
+
+    inetd time:8037/udp wait [2345] @root:root internal
+    inetd time:3737/udp wait [2345] @root:root internal
+
+But what if we want to have different allow/deny rules per service?
+Here's a proposal, similar to user/pass encoding in URI's.  This variant
+could potentially be a lot easier to implement and also to maintain for
+users, compared to the above allow/deny/xinetd variants.
+
+    inetd ssh@eth0:222/tcp nowait [2345] /usr/sbin/sshd -i
+    inetd ssh@eth1:22/tcp  nowait [2345] /usr/sbin/sshd -i
+
+or
+
+    inetd ssh@eth0:222/tcp nowait [2345] /usr/sbin/sshd -i
+    inetd ssh@*:22/tcp     nowait [2345] /usr/sbin/sshd -i
+
+or
+
+    inetd ssh@eth0:222/tcp nowait [2345] /usr/sbin/sshd -i
+    inetd ssh/tcp          nowait [2345] /usr/sbin/sshd -i
+
+All three versions would be equivalent, except for the first one when
+there are more interfaces than just eth0 and eth1.  The latter two would
+however be equivalent.
+
+Multiple `inetd ssh` entries with the same port will not be unique, they
+will reuse all settings of the first listed entry.  However, an entry
+with a unique port and interface will be registered as a unique service.
+
+**Note:** Also, there is currently no verification that the same port is
+  used more than once.  So a standard http service will clash with an
+  ssh entry ssh@*:80/tcp ... why you would ever want that?
+
+Inetd callbacks are no different from other callbacks.  They match to an
+inetd line using the command.  So multiple `/usr/bin/sshd` inetd lines
+in `finit.conf` will all use the same callback.  However, the callback
+will be called with the Internet port and interface as arguments.  Like
+this:
+
+    svc_cmd_t sshd_callback(svc_t *svc, int port, char *ifname)
+    {
+        if (!cfg_is_ssh_enabled(ifname, port))
+            return SVC_STOP;
+    
+        return SVC_START;
+    }
+
+As usual, the callback is run in a separate process context and it is up
+to the implementer to return `SVC_STOP` or `SVC_START` (`SVC_RELOAD` is
+not applicable for inetd services).
+
 
 ### Internal inetd services