Re: [aclug-L] PC-Card Linux Problems

[JOHNSTONE JEREMY S <jsjohnst@xxxxxxxxxxx>]

On 25 Aug 1998, John Goerzen wrote:

> Hmm, that is a dilly of a pickle.
> 
> It is suggestive that the same problem occurs under Windows.
> 
> OK, so the basic situation is:
> 
> * You have a laptop hooked up to an Ethernet without Internet
> connectivity.  Your Ethernet has its own internal-only name service
> and is the default route for your computer.
> 

correct.

> * You occasionally want to dial out to the Internet using a PCMCIA
> modem card.
> 

correct.

> * The modem card works, but only if the Ethernet card is not present
> as well.
> 

partially correct. I can dial out with minicom just not pppd

> Please correct me if my assumptions are incorrect.
> 
> Assuming I understand the situation correctly:
> 
> Jeremy Johnstone <jsjohnst@xxxxxxxxxxx> writes:
> 
> > their lack of any understanding or knowledge of Unix/Linux. (Secret is
> > you have to figure out that they use CHAP authentication although their
> 
> Valuable tip!
> 
> > problems with my desktop machines. The problem I am running into is,
> > with the new 100Base-T PC Card I use on my laptop. I own a Linksys
> > 10/100 PCCARD and the card itself runs fine, but when I try to use PPP
> > it locks up, doesn't load chat, and won't return to the prompt without
> > me using control-c. I am currently using RedHat 5.0. I have checked and
> 
> This locks up the entire system, or just that particular console?

just that console. and I can break the program and regain access to that
console.

> 
> If possible, you may want to check /var/log/ppp.log or
> /var/log/messages to see if anything "interesting" appears there.
> 

I personally have all messages/warnings/notices forwarded to vt9.
I check that and I get a weird message stating, Device ppp0 not
registered. or something similar, yet I have ppp compiled statically in
the kernel. (Also when the net card is not inserted I do not have this
problem.)

> > there is no IRQ conflict with the modem, and Minicom works fine.
> 
> In this case, I would suspect that there may be an IRQ conflict
> between the some device and the PCMCIA controller, or (more likely)
> that there is some sort of networking confusion going on when you
> bring up PPP.
> 
> There are several issues at play:
> 
> 1. Routing
> 
> When your system needs to communicate with others, it must know which
> interface (Ethernet or PPP) to use to get it there.  On Ethernet, you
> generally tell it to "put a packet on the wire" if it is going to a
> machine on the same local physical Ethernet, or you tell it to send
> the packet through a router if it is going somewhere else.  Generally, 
> you set a default route such that everything that is not local goes to 
> a router that knows where to send it.
> 
> The trick is that you generally set a default route for PPP as well,
> since everything that is not local comes from some Internet site that
> should be sent through your ISP.
> 
> If you have two interfaces with a default route set, problems can
> arise.
> 

I have tryed deleting the default route before I call pppd and that
doesn't change / fix anything.

> 2. IP addresses
> 
> If your internal Ethernet happens to use IP addresses that are also in 
> use outside, bad things can happen to confuse your machine.
> 

I use the IP's in the range or 10.10.10.1 - 10.10.10.8 so that is not a
problem.

> 3. Name service
> 
> The name service is the way for your computer to lookup the numeric
> identification (or IP address) of the machine it's trying to talk to.
> Usually, your name service is provided by an ISP's server for PPP
> connections.  If you have an internal-only Ethernet with no Internet
> connection, you'd probably have internal-only nameservice.  But --
> this name service may interfere with other requests if not done
> properly.
> 


I run named on both my laptop and main server. And my laptop's resolv.conf
lists itself before the main server so I doubt that is a problem.

> Fortunately, these issues can be resolved in Linux.  I am not so sure
> if Windows is powerful enough to properly deal with them.
> 
> We can get into resolution later.  I don't want to do any more typing
> if my assumptions above turn out to be wrong :-)
> 



Any further help is appreciated,
Jeremy Johnstone

---
This is the Air Capitol Linux Users Group discussion list.  If you
want to unsubscribe, send the word "unsubscribe" to
aclug-L-request@xxxxxxxxxxxx.  If you want to post to the list, send your
message to aclug-L@xxxxxxxxxxxx.