Bug 50669

Than, can you extract these from other tools?

which tools do you mean?

at the moment i only have German and Norway in ISP database. It's no problem to
add more ISPs, if we have such configuration data from ISPs.

I'll mark this SHOULD-FIX, but it *requires* real data to use. :-)

This defect is considered SHOULD-FIX for Fairfax.

Hi Trond!

As we really don't have any information about US providers here in Germany it
would be great if you could collect some of them and either send the list to me
or than or if you could put it into providerdb yourself.

Thanks,

Read ya, Phil

I think we might have a cross-cultural communication error here.  The providerdb
as it stands doesn't make any sense for the providers here in the US.  I don't
think this is fixable in the time frame we have, but...  Some issues that came
up during my research:

1) We don't have a standard login and password - it is different for each user.
 It appears these can be left out of the providerdb entry, so that's okay.

2) We don't have one number for each provider.  Providers can have hundreds of
different dial-in numbers for various regions.  Can this be left out of the
providerdb entry?

3) DNS servers are not reliable on a per ISP basis, since most of the large ISPs
operate several different sets of DNS servers.  The server information is
delivered via DHCP to the clients.  Can this be left out of the providerdb entry?

4) The most common problem we have is that additional characters need to be
appended to the user name.  For example, on MSN, you must login with this:

MSN/username

Can we do that with the current structure?  Can we provide that information in
providerdb in the time frame we have?

5) Some providers offer both static and dynamic IPs, and the login does not
determine how things are set up (RoadRunner, for example).

6) Some providers (@home) require dhcpcd to be run with the -h flag or the -I
flag.  Is there any way to provide for this in providerdb and the structure we
have now?

In essence, the kind of things that are being set by providerdb need to be
user-editable over here, because things change across geographical areas for the
same provider (this would apply, I would think, for Germany as well, just so
that the user can see what is being set when he chooses a provider).  I'll build
you a generic entry for the US, and I'll try to get information from other
geographical regions about special dial-up, ISDN, or ADSL settings.

What are the allowable flag entries?  Do they follow some sort of specification
somewhere?

Than - any reflections on mdrew's comments?

2) use flag 'City' for every regions. I don't think that the ISP
   many dial-in numbers for a region ?
   of course you can let out flag 'Phone'
3) yes
4) yes
5) if providers supports both static/dynamic, we should use dynamic,
   it does not make sense for me to support both
6) at the moment not, but i can add it.

here are the allowable flag entries:
Country
Flag
City
Name
Type
User
Pass
Prefix
Phone
Domain
DNS
Netmask
Encaps
Layer2
Auth
Ipsetup

2) Unfortunately, that's the case.  Just for Earthlink alone, there are six
numbers in the RDU area (by city, true) and 41 access numbers for North Carolina
.  More to the point,there access numbers change on a fairly regular basis, and
there are many more which are undocumented (old numbers left over from mergers,
etc).  This also avoids a common trap here in the States of having a dial-up
number that seems local, but isn't, causing very large phone bills.  If we got
that wrong in a default configuration, we might run into legal trouble, and
those numbers are very hard to predict without quite a bit of research.  It is
safer and much simpler to have the user enter the number themselves.  This is
okay -- the "generic ISP" entry in the providerdb should cover that.

3) Okay
4) How do I do that?  For example, with MSN, I need the user to enter their
username, and have "MSN/" appended to the front of it.  Can you give me an
example on how to do that?

5) I would argue that if the provider supports static and dynamic, the user
should be able to set which one they are using.

6) Please do if you can, otherwise we are editing config files and scripts
directly to provide the needed functionality.

You misunderstood my question.  I wasn't talking about the allowable flags
(although a list is good, and I appreciate that).  I was talking about the
"Flag" flag -- what two letter abbreviations are allowed.  "us"? "tv"?  Is it
going by DNS country codes?  Are the graphics for the flags all there?  Where
are they being pulled from?  Locale data?

Okay, on RC1/roswell2 with 0.7.3-1:

I've got two entries for you, and a couple of bugs related to that:

[Begin]
[Country] USA
[Flag]    us
[City]    USA
[Type]    modem
[Name]    Generic
[Ipsetup] dynamic
[End]

[Begin]
[Country] USA
[Flag]    us
[City]    USA
[Type]    modem
[Name]    MSN
[User]    MSN/<username>
[End]

The problems:

For a [Name] entry, if you specify two words (e.g. "Microsoft Network") the
entry shows up in neat the first time, but disappears after accessing the Edit
menu, leaving a blank entry (both in the main neat window and in the Nickname
box).  Apparently, Internet Druid can handle names with spaces but neat cannot.

You cannot specify two City entries that are the same.  For example, given
Country=USA, you cannot set City=National, because that city is already taken
for German entries.  Inside one country, it's okay -- across countries, you
can't have the same entry.  However, Norway has City=National listed for some
ISDN connections along with Germany, so there is something deeper going on here
-- it might be modem specific, or linked to something else.  

I'll try to dredge up some more entries that make sense before the RC2 freeze.

1)
for "NAME" entry only the a-z|A-Z|_-  are allowed.

2)
City=National means that the provider must have the same configuration
(Prefix, Areacode, Phone,User,Name ...) inside country (USA).
This configuration is alway valid independent from location inside country     
(USA). 
City=Country is wrong. Here is the name of your location inside country.
for Example, your provider XY is in Durham has same configuration inside USA,
you should use City=National in this case otherwise City=Durham.

*)
[User]    MSN/<username>
is not supported. 



Could you please give me a list of your provider with all following infos
[Flag]
[City]
[Name]
[Type]
[Prefix]
[Phone]
[Domain]
[DNS]
[Encaps]
[Layer2]
[Auth]
[Ipsetup]

i will try to add them into provider database.

>1)
>for "NAME" entry only the a-z|A-Z|_-  are allowed.

Okay, that makes sense -- I'll keep that in mind.

>2)
>City=National means that the provider must have the same configuration
>(Prefix, Areacode, Phone,User,Name ...) inside country (USA).
>This configuration is alway valid independent from location inside country     
>(USA).

I'm trying to create a generic national ISP *without* that information being
specified, since very few of our ISPs are static nationwide.  Explanation below.
 
>City=Country is wrong. Here is the name of your location inside country.
>for Example, your provider XY is in Durham has same configuration inside USA,
>you should use City=National in this case otherwise City=Durham.

This was an attempt at creating a generic national ISP without specific
information.  Would City=Nationwide with no specific information work?

>*)
>[User]    MSN/<username>
>is not supported. 

This is what I was asking before.  This sort of setup is pretty common in the
US, because the ISP's do not necessarily own the POPs -- it allows the POP
owners to bill the correct company when one of their customer's dials up.  It
does actually show up in neat -- neat needs to accept (and dial with, but wvdial
can already do this) usernames with the formats:

BigISP/mdrew

or

BigISP/user

or

user

otherwise we are locking out a large percentage of our customers.  Earthlink and
AT&T Worldnet are two huge ISPs that I know of that use this sort of configuration.

>Could you please give me a list of your provider with all following infos
>[Flag]
>[City]
>[Name]
>[Type]
>[Prefix]
>[Phone]
>[Domain]
>[DNS]
>[Encaps]
>[Layer2]
>[Auth]
>[Ipsetup]

You are missing the scope of the problem here.  I've seen estimates of anywhere
from 4,000 to 10,000 ISPs in the US, probably half of which actually provide
dial-up service.  Assuming 10% of those 2,000 are nationwide, that leaves us
with 200 ISPs.  Now, each national ISP generally does have a toll-free 1-800
number that is available, *but* it usually costs money above and beyond your ISP
fee to use it (1-800 numbers are expensive to run for a company).  So, each ISP
contracts out or builds a POP in each area where they provide service. 
Earthlink, from my earlier example, provides six dial-in numbers in the RDU
area.  Someone in a particular area can use one or several of these numbers,
usually depending on whether or not they are long distance for that user and
what kind of connection the user has (K56flex, x2, V.90, ISDN, etc).  In North
Carolina alone, Earthlink provides a total of 41 numbers, and we'll assume each
number is for a different city, and that 41 is an average number per state. 
That means, just for national ISPs, I have 200 ISPs x 41 cities per state x 50
states ~ 410,000 entries.  Even If I took only the top 20 ISPs (minus AOL), that
is still 41,000 entries.

Now comes the fun part.  Most of the national ISPs were assembled by purchasing
different local ISPs, merging with other regional ISPs, or leasing POP access
from various providers.  What this means is that access number configurations
can (and often do) vary *inside* the same calling area.  Mostly it varies by
authentication method (PPP handled or normal, PAP, CHAP), but it can also vary
by speed settings (V.90, K56flex, x2, etc -- yes, they are still out there),
connection type (analog or ISDN), by hardware (TotalControl vs. Ascend Max or
TNT).  DNS server addresses are delivered by DHCP in about 75% of normal
dial-ups, with the rest being manually configured -- and whether or not this
occurs generally goes by access number (newer vs. older hardware at the numbers,
for example).  It is possible to assume a configuration by number (that usually
works) but not possible solely by city or dialing area.

And that's just analog dial-up services. :)

In short, a major ISP like Earthlink can barely keep track of their own
configurations, let alone everyone elses.  What you are asking me to do is not
possible in the time frame that we have.  The best I can offer is generic
configurations that guide our users past a few known major trouble spots
(MSN/username, for example -- most people don't know this, as the Microsoft
software appends the "MSN/" for them).  This keeps us from getting inundated
with calls from people trying to dial up on various problematic services. 
Otherwise, they have to know their own information, and enter it in.  Does this
make sense?  Should I just boot and bring this up for 8.0?

OK, i think we have to shift this to 8.0. I was just talking with Than about it
and he agrees. 41 000 entires would really be insane, and i'm not sure we can
easily handle the generic information for the provider database yet.

If you stay in contact with Than what would be reasonable i'd really appreciate it!

Thanks,

Read ya, Phil
PS: I'm DEFERING this bug now (so that we can still keep track of it). This
doesn't mean it is really closed, mind you ;)