I'm subscribing the "Single Service" provided by Tokyo Metallic Communications. The provider claims that the ADSL connection service consists of:
The point to be noted here is the use of the word "a PC" or "Use of a dedicated program." The provider's FAQ implies that, for the case of Tokyo Metallic Communications' Single Service, they are not the rule, but a limitation of the support. That is, the provider guarantees and supports the use of its service only if the user connects a PC using the dedicated program. Any other configuration is not disallowed but the provider is irresponsible in that case.
Hence, I concluded that there is no problem to connect multiple PC's through FreeBSD based router, under my own responsibility.
The following lists my goals. I think most of them are done.
Tokyo Metallic Communications provides another service called "Family Service" for those who want to connect two or more PC's with single ADSL connection. If I selected the Family Service, ADSL router would be supplied instead of ADSL modem for Single Service. However, I totally ignored it, because:
Later, I learned that the Family Service is even less flexible than I expected, and there were a lot of complaints from users. Some of the typical issues seen on WWW pages included:
And, if you are a geek, the most frustrating feature of the router is that, if you telnet to the router IP address, it connects to an administration port and ask you a password. If you ask user support for the password, he/she just says "you have no right to know it."
When I knew them, I was certain that I made a good choice.
Later, Tokyo Metallic Communications stopped enrollment to Single Service; for personal use, they only provide Family Service, today. Recently, they also changed their policy, and the users of Family Service are allowed to change the ADSL router settings.
I can't connect DOS/Win32 (i.e., Windows 95/98/Me) machines to the Internet directly. It's too risky. (Although Microsoft may have other opinion.)
Windows NT/2000 were candidates, but didn't win because:
On the other hand, FreeBSD is cheaper, doesn't require anything like a client licenses, and is more familiar to me than Linux. Moreover, entire source code of the FreeBSD is available, so, if I met any software trouble, I can (try to) fix it by myself. Hence, I chose FreeBSD.
(I chose FreeBSD because I had some experience of using FreeBSD for several years. If I were new to free OSs, I would have chosen Linux, since it is the trend in early 21st century.)
Actually I didn't get stuck in the network media issue, since I knew it's a catch. I write it here just as a hint for other people.
Ethernet interface on ADSL (or cable) modems are generally famous in their stupidity. There are so many reports that say link speed detection doesn't work on them.
If you cannot send to and/or receive from the modem at all, or you can but the link seems unstable, you should try fixing the network media of the Ethernet interface on the FreeBSD box. The safest setting is: fixed 10Mbps and half-duplex. In FreeBSD, you can control the media details of a network interface through media option (and optional mediaopt) of ifconfig command. You can do it in /etc/rc.conf as:
ifconfig_sis1="up media 10baseT/UTP"
where sis1 must be replaced with the name of your interface.
For whatever reason, I had to make the interface up manually before starting ppp. Otherwise, the ppp reported an error. I have never seen such a description, so it may be an sis driver specific problem. Anyway, my setting for ifconfig_sis1 contains UP keyword to solve the problem.
PPPoE uses an MTU value that is smaller than the PPP's mandatory minimum 1500. This often causes a trouble. I wrote about this issue on another page.
The provider's DNS server addresses are not documented in Tokyo Metallic Communications' Installation and Setup Guide. The document just says that DNS server addresses are automatically set by PPP (PPPoE.) By monitoring PPPoE packets, I can see those addresses are actually passed. However, the addresses are not guaranteed to be fixed, and eventually be changed by some circumstances.
My PPPoE router box runs named on it, and other machines on the in-house LAN queries to it. So, the best setting is that PPPoE passes the received DNS server addresses to the named and that named forwards queries to those addresses. Although ppp can be configured to rewrite /etc/resolv.conf based on the PPP-notified info., it can't be configured to rewrite /etc/named/named.conf. I estimated the idea to modify the ppp command, but the syntax of named.conf is far more complex than that of resolv.conf (remember that recent FreeBSD uses bind 8,) so it will be tough to modify the named.conf reliably.
This should not be a PPPoE specific problem, since, even with dial up PPP connection, the situation is same; the reason I had no problem on the issue before is only because my dial up Internet provider published a fixed set of DNS server addresses explicitly. I asked for several people how they solve the case, but there were no good answer.
My current configuration contains fixed DNS server addresses manually taken from the PPPoE conversation log, that is, named.conf contains a fixed forwarders clause. This is the most reasonable solution for the case, suggested by several experts. These addresses are not guaranteed to be fixed, so they may eventually be changed. My named.conf lacks forward only, so that my named can look up the required RR, starting from the root servers when forwarders don't answer.
I'm still looking for a better solution. If you have any idea, please let me know.