Thread View: comp.os.linux.help
9 messages
9 total messages
Started by Richard Lindner
Sun, 10 Jul 1994 13:27
SLIP/Ethernet Conflict
Author: Richard Lindner
Date: Sun, 10 Jul 1994 13:27
Date: Sun, 10 Jul 1994 13:27
21 lines
1454 bytes
1454 bytes
hmm - i trust that this isn't a FAQ - some help would be appreciated: The Problem: Linux Box with dial-up SLIP connection as well as ethernet connection to local linux boxes. Without the SLIP link active, there is no difficulty in NFSmounting disks to/from the other linux machines. But once SLIP is up, I'm unable to access the local machines - in fact a reboot is necessary to restore access. Would someone help steer me in the right direction here? Thanks in advance. rl -- Richard Lindner - System Manager Upper Murray Public Access Unix rjl@spectre.apana.org.au PO Box 1555, Wodonga, Vic. 3689, Oz Data: 060 208773 Fax: 060 562105 Voice: 060 562072 (bh) 060 208813 (ah)
Re: SLIP/Ethernet Conflict
Author: Stephen White
Date: Tue, 12 Jul 1994 05:55
Date: Tue, 12 Jul 1994 05:55
11 lines
1339 bytes
1339 bytes
Richard Lindner (rjl@spectre.apana.org.au) wrote: : Without the SLIP link active, there is no difficulty in NFSmounting disks : to/from the other linux machines. But once SLIP is up, I'm unable to access : the local machines - in fact a reboot is necessary to restore access. When you put the SLIP link up, you're hosing the routing tables. Make sure that the routes for the local boxes are still via ethernet. Use "route" to list the kernel routing table. -- steve@adam.com.au
Re: SLIP/Ethernet Conflict
Author: news
Date: Tue, 12 Jul 1994 21:59
Date: Tue, 12 Jul 1994 21:59
25 lines
1914 bytes
1914 bytes
Richard Lindner (rjl@spectre.apana.org.au) wrote: : Linux Box with dial-up SLIP connection as well as ethernet connection to : local linux boxes. : Without the SLIP link active, there is no difficulty in NFSmounting disks : to/from the other linux machines. But once SLIP is up, I'm unable to access : the local machines - in fact a reboot is necessary to restore access. What I have done which seems OK (not perfect) is : Machine A (Linux) ---- Machine B (Linux) ---- Machine C (DOS) These three are ethernet connected. Each with a single ethernet address on the same net as the SLIP gateway. On A and B I have 3 static routes for A,B and C, i.e. no -net entries for /sbin/route commands in your rc.inet1. The only thing that still doesn't work is that B and C can't access the world when A slips to the gateway. All local connectivity remains and A has full world connectivity while SLIP connected to the gateway. C.L.Burke
Re: SLIP/Ethernet Conflict
Author: Matthew Geier
Date: Tue, 12 Jul 1994 22:41
Date: Tue, 12 Jul 1994 22:41
21 lines
1920 bytes
1920 bytes
steve@adam.com.au (Stephen White) writes: >Richard Lindner (rjl@spectre.apana.org.au) wrote: >: Without the SLIP link active, there is no difficulty in NFSmounting disks >: to/from the other linux machines. But once SLIP is up, I'm unable to access >: the local machines - in fact a reboot is necessary to restore access. >When you put the SLIP link up, you're hosing the routing tables. Make sure >that the routes for the local boxes are still via ethernet. Use "route" to >list the kernel routing table. Ive had that happen with PPP. When the link started, it added a route to 0.0.0.0 out the PPP link, which effectivly overroad all the other routes. My linux machine depends on NFS - it boots of a 40 meg disk. Several reboots later I realized what was happening, and managed to delete the rogue route before the machine hung waiting for a response from NFS. (Basic system and net utils are on the local disk..) I havent had time to play with Linux SLIP/PPP recently, but I would hope that one was fixed.
Re: SLIP/Ethernet Conflict
Author: Uri Blumenthal
Date: Thu, 14 Jul 1994 03:28
Date: Thu, 14 Jul 1994 03:28
19 lines
1623 bytes
1623 bytes
In article <2vtb8k$ijv@eve.adam.com.au>, steve@adam.com.au (Stephen White) writes: > : Without the SLIP link active, there is no difficulty in NFSmounting disks > : to/from the other linux machines. But once SLIP is up, I'm unable to access > : the local machines - in fact a reboot is necessary to restore access. > When you put the SLIP link up, you're hosing the routing tables. That's why I patched the DIP to allow for - local IP/hostname - remote IP/hostname - netmask And anybody who cares about Ethernet or such, can take advantage of it, and make sure his/her SLIP addresses don't mess the LAN. "sunsite:dip337c-uri.tgz" -- Regards, Uri. uri@watson.ibm.com N2RIU ------------ <Disclaimer>
Re: SLIP/Ethernet Conflict
Author: Uri Blumenthal
Date: Thu, 14 Jul 1994 03:32
Date: Thu, 14 Jul 1994 03:32
12 lines
1274 bytes
1274 bytes
On the second thought - it also helps to know, whether your SLIP link should become your default route (in which case add the default statement to your DIP script, or NOT - in which case make darn sure there's NO "default" statement in there... -- Regards, Uri. uri@watson.ibm.com N2RIU ------------ <Disclaimer>
Re: SLIP/Ethernet Conflict
Author: Maurie Daly
Date: Thu, 14 Jul 1994 23:49
Date: Thu, 14 Jul 1994 23:49
48 lines
2708 bytes
2708 bytes
In article <2vv3n6$e11@prism.mindware.brisnet.org.au> news@prism.mindware.brisnet.org.au (news) writes: >From: news@prism.mindware.brisnet.org.au (news) >Subject: Re: SLIP/Ethernet Conflict >Date: 13 Jul 1994 07:59:02 +1000 >Richard Lindner (rjl@spectre.apana.org.au) wrote: >: Linux Box with dial-up SLIP connection as well as ethernet connection to >: local linux boxes. >: Without the SLIP link active, there is no difficulty in NFSmounting disks >: to/from the other linux machines. But once SLIP is up, I'm unable to access >: the local machines - in fact a reboot is necessary to restore access. >What I have done which seems OK (not perfect) is : >Machine A (Linux) ---- Machine B (Linux) ---- Machine C (DOS) >These three are ethernet connected. Each with a single ethernet address on >the same net as the SLIP gateway. >On A and B I have 3 static routes for A,B and C, i.e. no -net entries >for /sbin/route commands in your rc.inet1. >The only thing that still doesn't work is that B and C can't access the world >when A slips to the gateway. All local connectivity remains and A has full >world connectivity while SLIP connected to the gateway. > C.L.Burke I had a problem like this and fixed it by using a dedicated PC running KA9Q nos as the machine which has the slip link and the internal ethernet. You dont need an expensive machine for the NOs box , Im using an old 286,you could even use an XT if you still had one although you may need a 16550 uart on the slip port. This way all the machines on the home network can see the world and each other. cheers Maurie Daly Sen Tech Officer DOC Comms Lab Canberra Australia 06 2748431 ph 06 2748449 fax mauried@happy.dotc.gov.au
Re: SLIP/Ethernet Conflict
Author: Terry Dawson
Date: Fri, 15 Jul 1994 09:00
Date: Fri, 15 Jul 1994 09:00
17 lines
1563 bytes
1563 bytes
matthew@cs.su.oz.au (Matthew Geier) writes: > Ive had that happen with PPP. When the link started, it added a route >to 0.0.0.0 out the PPP link, which effectivly overroad all the other >routes. Matthew, if the default route (0.0.0.0/0) is overriding your other routes then chances are your other routes aren't correct, or are going missing. I suggest you also follow the previous advice, and check that your local network route still exists after you close the ppp connection. If not, then you'll need to manually reinstate it after you drop your ppp connection. Terry -- --- Terry Dawson, terryd@extro.ucc.su.oz.au
Re: SLIP/Ethernet Conflict
Author: Al Longyear
Date: Fri, 15 Jul 1994 19:29
Date: Fri, 15 Jul 1994 19:29
15 lines
1508 bytes
1508 bytes
matthew@cs.su.oz.au (Matthew Geier) writes: > Ive had that happen with PPP. When the link started, it added a route >to 0.0.0.0 out the PPP link, which effectivly overroad all the other >routes. Don't use the defaultroute parameter to pppd unless you want pppd to add the default route so that it points to the ppp device. If you wish to leave the default route alone, then don't include the parameter. There was an error in one of the early versions which would allow this to happen as the device route. The current code will not accept a remote IP address of 0.0.0.0 so you should not have a problem. -- Al Longyear longyear@netcom.com
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads