Joe wrote:
>As far as DNS requirements are concerned, two things I have seen:
>1. The Linux documentation on this (a few months ago) said that
> automatic DNS detection was not implemented and "probably
> never would be implemented". No reason was given for this.
>2. DR-Webspyder 2.1b2 *did* implement this feature (or try to),
> but, for me at least, it did not work properly. However, this
> does indicate that Caldera thought it was possible ...
Well IMHO I think we could ignore this since this "feature" is said to work
in Windows 95 but have never worked for me on any ISP that have said that
this was the correct procedure (and not in Windows 98 or NT either).
Anyway I've looked into RFC 1877 ("PPP Internet Protocol Control Protocol
Extensions for Name Server Addresses" from Microsoft) a bit and it seems
quite straightforward. Send a dummy request to some server, wait for an
answer from the peer with the correct data that contains the DNS (or the
second DNS or waiting for a "Config-Nak" packet containing the data).
>I too would be interested in the next epppd - so perhaps you
>could e-mail me a copy when it's ready. As you know, my
>interest is in FIFO RX-interrupt trigger level control ... :-)
Ah yes, good that you reminded me.
And w0rm (I still don't know if you are on arachne-development), I hope
this answers your questions as well although I would still like to get in
contact with David Lindauer (the week has almost passed now hasn't it?).
In reality I only have 7 days to finish off work on epppd since it will be
more expensive dialing in for me latter (in September).
And of course most importantly of all: There is IMHO not any point in
adding this to EPPPD since the nameserver is read from arachne.cfg by
core.exe like this (atcpip.c for those that have the sopurce):
value=configvariable(&ARACHNEcfg,"NameServer",NULL);
if(value) _add_server( &_last_nameserver, MAX_NAMESERVERS,
def_nameservers, resolve(value));
value=configvariable(&ARACHNEcfg,"AltNameServer",NULL);
if(value) _add_server( &_last_nameserver, MAX_NAMESERVERS,
def_nameservers, resolve(value));
So I think it's up to core.exe to find the DNS and send them to WatTCP.
DNS for epppd is meant for BOOTP replys not for normal use (so adding that
extra nameserver option to pppdrc.cfg is IMHO prety useless - and I've said
so earlier). They will be returned to the application that wants BOOTP so I
can perhaps see some use for it but not much (it would be better if Arachne
created the wattcp.cfg file IMHO as Michael has suggested and support for
this would be removed (unknown ammount of memory saved - if nothing else I
will make a version that doesn't have this in it and use it myself).
Let me quote from the docs to epppd (as of 0.6 - it's in the dospppd.txt in
the Arachne directory):
>BOOTP PROTOCOL EMULATION
>
> Some DOS Internet applications support a method for automatic TCP/IP
> configuration, called the BOOTP protocol. The Ethernet emulation
> versions of the DOS PPPD driver support this form of configuration,
> acting as fake BOOTP servers that generate a reply when they see a
> BOOTP request.
>
> In order to fully support the BOOTP protocol, I added an option that
> doesn't exist in the original DOS PPPD code. The option is 'namsrv' and
> is intended for specifiying up to two nameservers' IP addresses that
> will be sent to the application doing a BOOTP request. The rest of
> BOOTP information is generated from the local/remote IPs negotiated by
> DOS PPPD during the link establishment phase.
>
> The remote IP will be used for the gateway address and server address;
> the local IP will be used for 'your_ip' address. The netmask is
> calculated by the following method:
>
> First, a value is obtained based just on the class (i.e. class A, B or
> C) of the local IP, specifically:
>
> class A ==> 255.0.0.0
> class B ==> 255.255.0.0
> class C ==> 255.255.255.0
>
> If this value is consistent with the gateway's IP number, that is, if:
>
> ( <netmask> & <gateway> ) = ( <netmask> & <localIP> )
>
> [where & represents logical AND], then this value is used as the
> netmask. (See RFC 950.) Otherwise, a different netmask value is
> chosen: it is the largest number which (a) is consistent in the above
> sense, and (b) has a binary form of 1's followed by 0's.
>
> This method is the same used by Frank Molzahn's PPPPKT06 driver. This
> calculated value is then binary ORed with any user supplied value
> through the 'netmask' option.
>
> This netmask calculation method applies to both the class 6 and class 1
> versions of the drivers, regardless of the BOOTP support.
I think this settles it (all opposed can send their mails to nul (or
/dev/nul if you are running on a UN*X clone) <g>). And IMHO it would be
better to have an external program that would tell us the DNS (since they
are most likely static anyway), and not only Arachne but all DOS programs
would benefit from it, I'll see what I can do to make one. I'm assuming
this is why Linux don't support this either - there's no use in supporting it.
Now to get back to the RX trigger level that Joe asked about, this is from
epppd (in n8250.h for those who have the source)
#define FIFO_SIZE_1 0x00 /* RX fifo trigger levels */
#define FIFO_SIZE_4 0x40
#define FIFO_SIZE_8 0x80
#define FIFO_SIZE_14 0xC0
So this was easy (when I found it (perhaps I should have added "-i" to grep
a little earlier now it took me 5-10 minutes to figure that out) to add
support for in pppdrc.cfg but we still need a way to configure it in
Arachne (and make Arachne write the information to pppdrc.cfg). Now the
question is which values should be allowed (this should be checked in
Arachne IMHO to not increase the size of epppd). Should they be 1, 4, 8 and
14 or the hexadecimal numbers (and are others actually allowed? I now
absolutely nothing about what the results may be of my changes in this area).
In any event the information that pppdrc.cfg should contain is in decimal
form (or actually the number would be even better but I doubt much is
gained by that).
I'll see if I can put together a beta this weekend. Without the trigger
choice of course and not with the best reduction I can make (for that I
must know the exact order for how Arachne writes pppdrc.cfg - thereby
making it work only with a specific version (1.70?)
Michael perhaps we should take this either off this list now or onto the
"Arachne Developer Network" - what do you say Glenn and Clarence,
interested or not? Or should I just finish epppd 0.7 and send the changes
required in Arachne to you?
BTW: I actually noticed right now that I don't have the rights to make any
changes to the code made by Toni Lopez and redistribute it. Ah heck, since
he seems to have drop all interest in it (AFAIK) I guess he doesn't care if
I change things...
BTW2: I also realized that I'll need to put some sort of documentation
together :(
I guess it will take a while before I'll release the stand-alone version
then with complete docs...
