# TCP/IP Daemon Configuration

TCP/IP Daemon configuration dialogue is invoked with Config / TCP/IP Daemon menu command.

General

TCP/IP connection parameters are configured here.

The Incoming Ports string grid allows you to set-up TCP/IP ports which should be checked by TCP/IP Daemon to receive incoming connections. Each of three currently available protocols could be set for a number of TCP/IP ports - use space characters to divide port numbers in the string grid entry. If there are no ports set for a protocol, the protocol is not used by Argus for receiving incoming connections.

Argus can also use SOCKSv4 proxy server.

Station

This is the information about the system which will be transferred in the handshake packet. This information is almost the same as EMSI data, but if you are planning to connect with systems which are using BinkD by Dima Maloff, you should configure addresses in the Address List as 5-D FTN addresses (5-D FTN address is the 4-D FTN address plus '@' character and network name after it; e.g.: 2:469/38.77@fidonet.org) - if an address is not transferred in 5-D format, BinkD may refuse the connection.

Restrictions

These are the restrictions for outgoing connections. The principles of these restrictions are similar to those of Dialling Restrictions schemes

Required - conditions necessary for a poll to be valid. All the conditions stated must be satisfied to make a poll valid. If there are no conditions stated, a poll is valid.

Forbidden - conditions making a poll invalid. If at least one of the conditions stated is satisfied the poll is invalid. If there are no conditions stated, a poll is valid.

Two condition types are implemented in the current version of Argus: address mask (possibly with Regular Expressions) and Nodelist flags.

Nodes

This string grid has the same purpose as Node overrides table , the only difference is that instead of telephone numbers IP addresses are used (it is possible to use symbolic addresses as well as digital ones) and it is possible to define IP port numbers which are available on a particular node.

Symbolic IP address should be enclosed in quotation marks, e.g.: `193.219.215.11` or `"fido.ritlabs.com"`. If a non-standard IP port is used, its number should be put after the IP address followed by underline, e.g.: `193.219.215.11_60177` or `"fido.ritlabs.com"_60177`.

Flags specific for a particular node could be obtained from an IP Nodelist (the basic difference between conventional and IP nodelists is the use of IP addresses instead of 'phone numbers) or defined directly in the overrides.

You may specify an auxiliary nodes file, which defines additional overrides besides of listed in the string grid. The format of the file follows, one override per line:

    Address | Override

Example:

    2:469/38 | "fido.ritlabs.com",CM,BND
    3:383/514 | "fido.host.com",CM,IFC "fido.host.com",CM,TELNET

Auxiliary TCP/IP node overrides file is loading into memory on Argus Start-up and by detection of `IPOVR.OK` file-flag in Argus Home Directory. Results of parsing of the file are logged in polls log.

## DNS

Argus also supports DNS distributed nodelists.

IP addresses of FTN nodes can be from DNS by rendering their FTN addresses to host domain name and resolving this name. The rendering is performing by the following scheme:

    [p<Point>.]f<Node>.n<Net>.z<Zone>.<RootDomain>

The default root domain for Fidonet-reserved FTN-zones (1,2,3,4,5,6) is fidonet.net. E.g., the IP address of node 1:2/3.4, according to this scheme, is to be the same as of host p4.f2.n3.z1.fidonet.net.

Root domains for each address mask are configured in DNS tab of TCP/IP Daemon Configuration dialogue. Address mask may also contain Regular Expressions.

Here are parts of a FAQ on fidonet.net domain. The most recent list is available at:

`http://www.doe.carleton.ca/~nsoveiko/fido/fido-over-ip.FAQ.english.html#fidonet.net`

Q? | What is `fidonet.net`?
A: | fidonet.net is an Internet domain registered to facilitatedevelopment and deployment of fido-over-internet technology of all kinds and flavours.
Q? | How fidonet.net sub-domain and host names are assigned?
A: | Sub-domain and host names are formed in the same way as for the `fidonet.org` domain. For example, if your 4D Fidonet address is `A:BBB/CCC[.DDD]`, then your domain address would be `[pDDD.]fCCC.nBBB.zA.fidonet.net`. Such unique address mapping allows one to obtain a node's IP address knowing only it's FTN address.
Q? | What is the difference between `fidonet.net` and `fidonet.org` than?
A: | Fidonet.org domain was registered with the purpose of exchanging mail between Internet RFC822-style and Fidonet mail systems. In other words, hosts in the fidonet.org domains are Fidonet-Internet gateways that are supposed to accept mail by both SMTP and FTS-0001 (or, better EMSI) protocols. There is no such restriction on hosts in fidonet.net domains (see below). Technology developed and tested in fidonet.net domain in the future might migrate to the fidonet.org domain subject to approval of the latter's administration.
Q? | What do I do to get a fidonet.net host name?
A: | Your system should have binkp capability. This protocol is currently supported by binkd and Argus mailers. You should contact a person who is responsible for DNS in your Fidonet network. You can use nslookup to figure out if your network already has a DNS server. If there is none, please contact Fyodor Ustinov, 2:5020/79, ufm@prospect.com.ru to arrange a DNS record for you.
Q? | I am using Vmodem. Why should I install something else in order to be listed in fidonet.net?
A: | Common sense is that Fidonet systems should be able to exchange mail directly. In order to make this possible, they should support some protocol which will be the least common denominator for a given transport. FTS-0001 is such a protocol for conventional dial-up transport. Vmodem-based technologies do not make a good candidate for the least common denominator protocol because for many platforms these technologies are not free they merely adapt dial-up technology for TCP/IP transport retaining many drawbacks of the former and without taking full advantage of the latter. On the contrary, binkp is an open specification protocol designed to operate over reliable connections with unpredictable delays (such as TCP connections) has a portable implementation that is distributed in sources under terms of GNU public license. So, it seems to be a natural choice for the least common denominator protocol.