Welcome to PacHell

alternatives - links - testing - speed - tweaking - FAQs - usenet - newstools - misc - pacbell - media - heypacbell

Nov 27, 2001 - PacHell.com content is now hosted on a non-SBC server.

Oct 11, 2001 - PacBell management has threatened to cut off service to this site unless all content at this site is removed. In discussing their concerns, they specifically object to "advertising proprietary information" and the links to sites that are "defamatory" or use domain names that are a "mockery". This demand comes at a time when PacBell Internet's customer self-support groups are unavailable, their tech support has no details on the how to get access, and their status page still says "normal". This "PacHell" page may be the only web source of accurate Usenet access details for communicating with other customers about the outages. The DNS delay info is certainly NOT proprietary, and it concerns perceived server performance all over the net. This site has a clear explanation of a problem that is affecting all customers but is largely unrecognized. (For the price of one 30 second TV spot smearing a bankrupt cable competitor for having congestion problems at peak hours, PacBell's DNS congestion problem could be quickly fixed.) Please solve the problem rather than shoot the messenger.

Now for the supposedly objectionable content, while expecting a response from my appeal...

PacBell becomes PacHell when something critical is broken. SBC's PBI (PacBell Internet) division is agressively marketing their ADSL product, when the service is already suffering from overload. I get my email and Usenet news elsewhere, so those continuing outages don't bother me. I'm simply looking for a solid DSL Internet connection. No glitz or hype, please. Those deceptive PacBell smear campaign ads are really irritating.
-- Ed Anderson

PacBell "PARK" - Got looooong delays when first connecting to a server?

It's probably the overloaded PacBell Internet nameservers. All PBI customers are being affected, there is no escape by using an alternate domain name server, and the problem is getting worse. SBC has been plastering the airwaves with more claims about high speed networking, and PR about high speed fiber being tested. This is all moot if remote hosts are stalled when trying to resolve the addresses of SBC customers using their services. All the reverse lookups for PBI go through only two DNS servers, and they're swamped. Daytime PBI reverse lookup failures are currently at around 75% on average, with frequent periods where both PBI servers are 100% unresponsive. Other ISP's reliably return a reverse lookup in a fraction of a second. Please read the full explanation and spread the word to other customers.

The reverse-lookup problem has gotten severe enough that PBI's Usenet servers (and possibly the email servers) are often refusing to authenticate users because they can't be identified as PBI customers. If the dialup.pacbell.net account config site ever redirects your browser to public.pacbell.net, that's probably because it can't see you're a customer from your IP aaddress.

DNS lookup failure rate and Delay (ms) history for PacBell's primary nameserver
Click on the graph for DNS details and Packet loss charts through PBI.

This graph is an indication of DNS name lookup failures and delay for PacBell's main server. Because the primary servers are used by remote sites for reverse lookup of all addresses in the PBI netblock, all connectivity through PacBell Internet can suffer delays. A third party DNS or cache can be used to minimize the common forward DNS lookup delays, but not the reverse lookups from remote hosts. These PBI DNS failures result in remote server retries, usually halting all response until the lookup is resolved or the remote server hits a failure timeout limit.

Recent samples are at the right end of the graph. Green represents the average lookup delay in thousandths of a second. Blue shows the percentage of failed requests. Samples are taken every five minutes. Shift-reload this page if the graph is showing old data. Click the graph for historical graphs, and charts of router response through the PBI network.

DSL Alternatives

The only way to escape the slow reverse DNS problem and iffy PBI mail/news is to use an alternate ISP. Pacbell ADSL as a last-mile connection can be acceptable once it's installed, and other service providers may deliver over the same hardware what PBI cannot. They have difficulty matching PBI's privileged pricing, but the improved service may be worth the extra cost. Here are some links to reviews and info about various service providers:

Other PacBell user efforts

Software for testing and monitoring your connection:

Online tools for status and speed testing

Tweaking your connection:

General DSL Help

Help with Usenet News
Having trouble with PacBell Internet's Usenet service? The internal server problems have persisted for years, but there is now another reason for missing articles and poor propagation. Because they have neglected to maintain server security and enforce their Acceptable Use Policies, SBC/PacBell/SWBell has become a top haven for email and Usenet spammers. Other ISPs are responding to the the flood of net-abuse by blacklisting Pacbell.net servers and invoking a UDP - Usenet Death Penalty.
As of October 2001, SBC has responded to the UDP by taking its existing servers offline and attempting to migrate all users to servers maintained by Prodigy. This is hinted at in a notice that was emailed to some users, but it never gave accurate details about the names of the new NNTP servers. There's a lame web page that isn't linked from the support pages.

Unfortunately for PacBell customers, the news.sf.sbcglobal.net and news.la.sbcglobal.net servers are thoroughly broken, depsite the status page claiming that all systems are normal, and support techs telling users that the problem must be in their newsreader settings. It is possible to get access through the new SWBell servers, although that's probably by accident.

Tip # 1:
Stop trying to use the servers that are pooled by cityname. They often behave differently depending on which server gets resolved by the DNS. Choose them instead specifically by their actual name or IP address:
SWBell (for starters):
  newssvr11.news.prodigy.com (151.164.60.156)
  newssvr30.news.prodigy.com (151.164.61.156)
PacBell (in case these start working when managed by Prodigy):
  newssvr13.news.prodigy.com (64.164.98.6) (sf/la) Broken
  newssvr14.news.prodigy.com (64.164.98.7) (sf/la) Broken
  newssvr21.news.prodigy.com (64.164.98.29) Broken
Ameritech (all cities currently point to this server:)
  newssvr26.news.prodigy.com (206.141.193.32)

A full email address and password are required for authentication with the new servers. The [email protected] accounts are only allowed on the PacBell servers, and [email protected] only on SWbell servers. (Hint: Using that rule, it is possible for Pacbell users to login to Swbell servers, perhaps under a nonsense username.)

Once access is gained, don't expect activity in any pbinet.* groups, since few PacBell customers have achieved Usenet access. Look for semi-official explanations and answers in this Prodigy support group: prodigynet.help.tech.newsgroups

NNTP Servers:
open-news.pacbell.net
  Disabled but back 7/27/01
news.sbcglobal.net
  same server, new name
  BROKEN Oct 7, 2001 		A server that doesn't carry binary groups
(may allow outside access to pbinet.*)
web interface available for remote access
Disabled mid-July 2001. Apparently PBI can't tell who its legitimate users are because so many passwords have been compromised by other security lapses. After the server was repeatedly used to flood the net-abuse discussion forums, the only solution PBI could come up with is to shut off the server. Even legitimate customers are now denied access with this greeting:
"502 Permission Denied - This system is no longer availible for service. Please abuse another server. (Typhoon v1.2.3)"
news.flash.net
  Closed Feb 18, 2001		 Former best choice, no password required for SBC users.
(SBC merged w/ Prodigy, which bought Flashnet)
no pbinet.* or swbell.* groups (except what leaks out)
news.nvbell.net
  OFFLINE Oct 7, 2001 		Uses same servers as news.pacbell.net but excludes lame SoCal server
password required
news.swbell.net
  PBI users blocked 		(was the popular choice, misses fewer aticles)
all PBI users now blocked.
Password required for swbell users.
news.pacbell.net
  OFFLINE Oct 7, 2001 		slow and spotty, posts go into the ether (better 5/99)
6/2000 - even slower, now capped at 12 KB/sec, still spotty.
Extra login and password now required (yet another obstacle).
Random choice of four servers in the "farm".
Experiments with accessing by raw IP addr may avoid a dead server:
206.13.28.33   206.13.28.143   206.13.28.144 or 206.13.28.183
dnews.pbi.net
  Gone 		Now aliased to news.pacbell.net
(Was) similar in coverage to swbell, reportedly slower, password required
news.prodigy.net
  PBI users can't post
  PBI users blocked Oct 7, 2001 		Currently read-only, no posting (yet?)
no password required for SBC users, no pbinet.* or swbell.* groups
7/24/2001 - still read-only, but a password is now required
(PBI customers - try using "[email protected]" and "anypass")
Actually one of two randomly assigned servers that have different characteristics.
Try picking the better of 207.115.63.150 or 207.115.63.157
news.dallas.sbcglobal.net
  SWBell only? 7/2001 		Two servers. Try logging in with real [email protected] and password
news.sf.sbcglobal.net
news.la.sbcglobal.net
  PacBell only? 8/2001
  BROKEN Oct 7, 2001 		Try logging in with [email protected] and password
Actually two servers: 64.164.98.6 and 64.164.98.7
Both names randomly access either server, but they may someday split

 
Newsgroups:
search the Pacbell user site map for a full list
prodigynet.help.tech.newsgroups Only available from Prodigy or new SBCglobal servers
The group is monitored by helpful employees.
See the Prodigy help pages for more newsgroups.
pbinet.adsl local PBI ADSL group
pbinet.discussion local PBI discusison group
alt.online-service.pacbell global PBI discussion group (gaining momentum)
Crosspost to this group so complaints will be seen!
comp.dcom.xdsl global discussions of DSL datacom technology
ba.internet discussions about SF Bay Area ISP's (including DSL options)

Usenet via GoogleGroups (Deja)

Misc related links

News Media SavvySearch
SF Chronicle/Examiner
the SJ Mercury News only last seven days w/o fee
the dialup.pacbell.net site [not in service since 8/99]
News.com / C|Net
SBC news releases (old PB news)
Google!
Epionions.com
area code prefix TheDirectory.org city finder
Area Code Prefix AgroMan's NANPA Central Office Database
area code prefix DSLreports Central Office finder
DSL Distance Qualifier at ConnectNet

Pacbell links

Other reports

Are you an SBC customer with a Cayman DSL router? You may have a serious security hole. The routers are delivered without password protection, and come configured to reveal themselves to any web browser in the world. Check your own router to see if it is vulnerable. The security alert dates from May 2000, but SBC has done little to inform or protect their customers. Thousands of customers are currently vulnerable.

Security Incidents originating from PacBell.net reported daily by MyNetWatchman agents.

Utility Consumer Action Network lawsuit against PacBell - filed July 11, 2000
Send in detailed complaints by email to support this ongoing effort.

Hey PacBell!

Please use this MRTG software to display your network status. It is designed to peek at the router stats using an SNMP call every few minutes. Here's an example at Abovenet of how to display PacBell router stats. If you can't spare an engineer for the job, I volunteer to install it on one of your servers for you.

An alias shortcut to this page is http://welcome.to/pachell

Please submit any comments or useful links to the pbinet.adsl ba.internet or comp.dcom.xdsl public newsgroups. That way, more people might benefit from your input.

This page carries (as if it needed to be stated) Copyright © 1999 by Ed Anderson

This Welcome to PacHell page has been online since February 7, 1999