Linux-Networking Digest #688, Volume #11 Sun, 27 Jun 99 03:13:56 EDT
Contents:
Re: Connecting 2 computer's in a network (Mircea)
Trouble networking two linux machines (bill)
LinkSys NIC LNE100TX: Anybody have any problems with this card? (Lewis)
Re: Why not C++ (Bruce Hoult)
Re: 192.168/16 vs. 10/8 (Steve)
DSL filtering ports (Scott Sweeting)
Re: 2 modems routing problem ([EMAIL PROTECTED])
Is the 3com 905c supported? ("m")
Re: LinkSys NIC LNE100TX: Anybody have any problems with this card? ("m")
----------------------------------------------------------------------------
From: Mircea <[EMAIL PROTECTED]>
Subject: Re: Connecting 2 computer's in a network
Date: Sun, 27 Jun 1999 02:04:44 -0400
I suggest you read the Ethernet-HOWTO and the Net3-HOWTO. They answer
your question.
MST
Tycho Scholtens wrote:
>
> Hi Ya all,
>
> I now have linux running on 2 comp's. Both have a NE2000 compatible
> network-card. How can i set up the network under linux
>
> Someone new to networking under linux
------------------------------
From: bill <[EMAIL PROTECTED]>
Subject: Trouble networking two linux machines
Date: Sun, 27 Jun 1999 00:44:02 -0500
==============8BA038BDC33D4FEFB7F9FCC9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I'm having trouble networking two linux machines. My goal
is to setup up IP
Masq so that both computers can use the internet at the same
time (my bro and
I have have a tendency to fight for internet time).
However, I've haven't
been able to get the two computers to even talk to each
other yet. Maybe
someone could point out what I'm doing wrong or what I have
neglected to do.
The first of these is running Debian 2.0/2.0.34 with an ISA
3Com Etherlink
card (3c509) and it's configuration is as follows:
NIC card initialization--
eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24
03 b6 ea, IRQ 10.
3c509.c:1.16 2/3/98 [EMAIL PROTECTED]
eth0: Setting Rx mode to 1 addresses.
Setting up IP Address--
eth0 Link encap:Ethernet HWaddr 00:A0:24:03:B6:EA
inet addr:192.168.1.2 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:105 errors:0 dropped:0 overruns:0
carrier:105
Collisions:0
Interrupt:10 Base address:0x300
And the routing table--
Kernel IP routing table
Destination Gateway Genmask Flags Metric
Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0
0 16 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0
0 14 lo
And for the other computer (aka zeus) I'm running Debian 2.1
with a custom
built 2.2.10 kernel and a PCI 3Com Etherlink card (3c905b).
Everything looks
pretty much the same here, too.
eth0: 3Com 3c905B Cyclone 100baseTx at 0xfc00,
00:10:5a:0f:24:ca, IRQ 9
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate
interface.
MII transceiver found at address 24, status 7849.
MII transceiver found at address 0, status 7849.
Enabling bus-master transmits and whole-frame receives.
eth0 Link encap:Ethernet HWaddr 00:10:5A:0F:24:CA
inet addr:192.168.1.1 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:12 errors:0 dropped:0 overruns:0
carrier:12
Collisions:0
Interrupt:9 Base address:0xfc00
Kernel IP routing table
Destination Gateway Genmask Flags Metric
Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0
0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0
0 0 lo
When I try to ping each of the computers I don't recieve any
response. One
thing I did notice I thought was strange was that on each of
the computers
arp -a reported--
hermes (192.168.1.2) at <incomplete> on eth0 on the Deb 2.1
machine and
zeus (192.168.1.1) at <incomplete> on eth0 on the 2.0
machine.
>From what I understand the ip address on ethernets server as
aliases for
the hardware addresses on each of the cards and I thought
that maybe this
was my problem.
So, I manually constructed the table for both machines.
Then arp -a on
both machines returned completed tables--
hermes (192.168.1.2) at 00:A0:24:03:B6:EA [ether] PERM on
eth0
zeus (192.168.1.1) at 00:10:5A:0F:24:CA [ether] PERM on eth0
But, this didn't work either and pinging both computers
still failed.
Could I possible be lacking some support in either of my
kernels? I'm not
real sure what is supported in the installed kernel of the
Debian 2.0 system
but with the 2.2.10 kernel that I built I have the following
set --
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ROUTER=y
CONFIG_SYN_COOKIES=y
Or maybe all of this is correct and I'm making some mundane
mistake.
Thanks, Bill.
--
It was one of those perfect summer days -- the sun was shining, a breeze was blowing,
the birds were singing, and the lawn mower was broken ... --- James Dent
==============8BA038BDC33D4FEFB7F9FCC9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>I'm having trouble networking two linux machines. My goal is to
setup up IP
<br>Masq so that both computers can use the internet at the same time (my
bro and
<br>I have have a tendency to fight for internet time). However,
I've haven't
<br>been able to get the two computers to even talk to each other yet.
Maybe
<br>someone could point out what I'm doing wrong or what I have neglected
to do.
<br>The first of these is running Debian 2.0/2.0.34 with an ISA 3Com Etherlink
<br>card (3c509) and it's configuration is as follows:
<p>NIC card initialization--
<br>eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 03
b6 ea, IRQ 10.
<br>3c509.c:1.16 2/3/98 [EMAIL PROTECTED]
<br>eth0: Setting Rx mode to 1 addresses.
<p>Setting up IP Address--
<br>eth0 Link encap:Ethernet HWaddr
00:A0:24:03:B6:EA
<br> inet addr:192.168.1.2
Bcast:192.168.1.255 Mask:255.255.255.0
<br> UP BROADCAST
RUNNING MULTICAST MTU:1500 Metric:1
<br> RX packets:0
errors:0 dropped:0 overruns:0 frame:0
<br> TX packets:105
errors:0 dropped:0 overruns:0 carrier:105
<br> Collisions:0
<br> Interrupt:10
Base address:0x300
<p>And the routing table--
<br>Kernel IP routing table
<br>Destination
Gateway
Genmask Flags Metric
Ref
Use Iface
<br>192.168.1.0
0.0.0.0
255.255.255.0 U 0
0 16 eth0
<br>127.0.0.0
0.0.0.0
255.0.0.0 U
0 0 14
lo
<p>And for the other computer (aka zeus) I'm running Debian 2.1 with a
custom
<br>built 2.2.10 kernel and a PCI 3Com Etherlink card (3c905b). Everything
looks
<br>pretty much the same here, too.
<p>eth0: 3Com 3c905B Cyclone 100baseTx at 0xfc00, 00:10:5a:0f:24:ca,
IRQ 9
<br> 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
<br> MII transceiver found at address 24, status 7849.
<br> MII transceiver found at address 0, status 7849.
<br> Enabling bus-master transmits and whole-frame receives.
<p>eth0 Link encap:Ethernet HWaddr
00:10:5A:0F:24:CA
<br> inet addr:192.168.1.1
Bcast:192.168.1.255 Mask:255.255.255.0
<br> UP BROADCAST
RUNNING MULTICAST MTU:1500 Metric:1
<br> RX packets:0
errors:0 dropped:0 overruns:0 frame:0
<br> TX packets:12
errors:0 dropped:0 overruns:0 carrier:12
<br> Collisions:0
<br> Interrupt:9
Base address:0xfc00
<p>Kernel IP routing table
<br>Destination
Gateway
Genmask Flags Metric
Ref
Use Iface
<br>192.168.1.0
0.0.0.0
255.255.255.0 U 0
0 0 eth0
<br>127.0.0.0
0.0.0.0
255.0.0.0 U
0 0
0 lo
<br>
<p>When I try to ping each of the computers I don't recieve any response.
One
<br>thing I did notice I thought was strange was that on each of the computers
<br>arp -a reported--
<p>hermes (192.168.1.2) at <incomplete> on eth0 on the Deb 2.1 machine
and
<br>zeus (192.168.1.1) at <incomplete> on eth0 on the 2.0 machine.
<p>From what I understand the ip address on ethernets server as aliases
for
<br>the hardware addresses on each of the cards and I thought that maybe
this
<br>was my problem.
<p>So, I manually constructed the table for both machines. Then arp
-a on
<br>both machines returned completed tables--
<br>hermes (192.168.1.2) at 00:A0:24:03:B6:EA [ether] PERM on eth0
<br>zeus (192.168.1.1) at 00:10:5A:0F:24:CA [ether] PERM on eth0
<br>But, this didn't work either and pinging both computers still failed.
<p>Could I possible be lacking some support in either of my kernels?
I'm not
<br>real sure what is supported in the installed kernel of the Debian 2.0
system
<br>but with the 2.2.10 kernel that I built I have the following set --
<p>CONFIG_PACKET=y
<br>CONFIG_NETLINK=y
<br>CONFIG_RTNETLINK=y
<br>CONFIG_NETLINK_DEV=y
<br>CONFIG_UNIX=y
<br>CONFIG_INET=y
<br>CONFIG_IP_ROUTER=y
<br>CONFIG_SYN_COOKIES=y
<p>Or maybe all of this is correct and I'm making some mundane mistake.
<p>Thanks, Bill.
<pre>--
It was one of those perfect summer days -- the sun was shining, a breeze was blowing,
the birds were singing, and the lawn mower was broken ... --- James Dent</pre>
</html>
==============8BA038BDC33D4FEFB7F9FCC9==
------------------------------
From: [EMAIL PROTECTED] (Lewis)
Subject: LinkSys NIC LNE100TX: Anybody have any problems with this card?
Date: Sun, 27 Jun 1999 05:56:28 GMT
Folks,
I am building up a new computer, and converting my old Pentium 166/MMX
to a Linux box (my new computer will have Linux on it as well, but it
will primarily be a Windows98 box for my wife).
I plan to network the two computers, and am trying to determine which
NIC cards to use.
I am considering a Linksys Fast Ethernet Kit which contains two
Linksys LNE100TX cards and a hub. It seems like a good value.
I have been to RedHat's web site, and see that they do not support
this card, but I have been to LinkSys' web site, and see that they do
support it for Linux.
I sure that a few of you have used this kit. Any words of wisdom on
this kit?
1. Does it work for Linux? (I know that Linksys states it does, but I
want to hear it from somebody who is actually using it!)
2. Any "gotchas"?
3. Any suggestions for any other NIC's and hubs that support 100BaseT
(that don't cost an arm and a leg!)?
Any help/comments/etc. are appreciated.
Thanks in advance,
R.J.
===================================================
The Lewis's
Remove "NoSpam_" from email address if replying by email.
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 16:10:30 +1200
In article <7l3en8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Don Waugaman) wrote:
> Could you describe what you don't like about C++ templates, and how a
> statically-checked language that intends to minimize runtime cost could
> do better?
Well, here's what *I* don't like about C++'s templates...
Actually, C++ templates are just fine -- they're probably one of the best
parts of the language.
The *problem* is that C++ templates are an ad-hoc solution to just one
problem, and C++ has too *many* ad-hoc solutions. When you write a
function in C++ you've got to choose between template functions, inline
functions, overloaded functions, virtual functions ... it's a mess. (Yes,
I know those choices aren't orthogonal, and can be combined -- that just
makes it worse.)
Bjarne Stroustrup started with the simple "one name = one function"
principle in C and added on on virtual functions with runtime dispatch on
the first argument so that he could emulate Simula.
Then he thought "wouldn't it be nice if you could write new versions of
'+' and '<' and use the same name for several similar functions of your
own?". So he created overloaded functions, which are a completly
different and incompatable thing from virtual functions.
To try to close the gap between overloaded functions and virtual functions
a bit, he eventually added template functions, which basically let you
write a number of overloaded functions more economically.
It's a big untidy mess. And sometimes you actually can't do what you want
to do.
Don't get me wrong -- I greatly admire Bjarne Stroustrup and think he did
a great job, and C++ was a big improvement on the state-of-the-art in 1980
when he started to implement it (or 1990, when it started to spread
widely). But I think it's time to move on now.
> how a statically-checked language that intends to minimize runtime cost
> could do better?
Ok, let's look at what happens in Dylan.
Dylan has only *one* kind of function -- the generic method -- but
depending on the circumstances, the compiler will do any of:
- compile time selection of the right function
- inlining of the right function
- outlining of the right function (using it as a template)
- run time selection of the right function
Let's look at an example:
define inline method myAdd(a, b)
a + b;
end myAdd;
define method f(x, y)
myAdd(x, y);
end f;
define method g(x :: <integer>, y :: <integer>) => (z :: <integer>)
myAdd(x, y);
end g;
define method h(x :: <single-float>, y :: <single-float>)
=> (z :: <single-float>)
myAdd(x, y);
end h;
Look at "myAdd". Unlike g and h, it doesn't declare the paramter types,
or the return value type(s). What sort of function is it? You could
think of it either as a C++ template function with a and b declared to be
of some unspecified type...
template<class T> T myAdd(T a, T b){
return a + b;
}
... but it's bit more than that. C++ templates require that the actual
types of a and b be known at compile time. This C++ template requires
that a and b be of the *same* type, which is also the type of the result.
But with the Dylan function the arguments could be of different types,
more like this:
template<class T1, class T2> ???? myAdd(T1 a, T2 b){
return a + b;
}
But this is not easy in C++. What is the function return type? T1? Not
necessarily. T2? Not necessarily. Something else? But *what* else?
It's impossible to say. Dylan doesn't care.
You could also think of myAdd as being like a C++ virtual function that is
not actually part of a class, and that does runtime type dispatch based on
the types of *both* arguments, not just the first one.
Let's see what "d2c" (see <http://www.gwydiondylan.org>) does with this --
here is the C code output by d2c (with my comments after //):
// This is a reference to the "generic function" (i.e. runtime virtual
// function dispatch) for "+"
extern descriptor_t dylanZdylan_visceraZPLUS; /* + */
// This is the "virtual function" method for myAdd, used when the compiler
// doesn't know the types of the operands at compile time, and doesn't
// inline it either for some reason -- which doesn't happen in this example.
/* myAdd{<object>, <object>} */
descriptor_t * templateZtemplateZmyadd_METH(
descriptor_t *orig_sp, descriptor_t A0 /* a */, descriptor_t A1 /* b */
){
descriptor_t *cluster_0_top;
orig_sp[0] = A0;
orig_sp[1] = A1;
/* + */
cluster_0_top = GENERAL_ENTRY(dylanZdylan_visceraZPLUS.heapptr)(
orig_sp + 2, dylanZdylan_visceraZPLUS.heapptr, 2
);
return cluster_0_top;
}
// This is "f". The compiler has inlined the code for myAdd, so this looks
// just the same as the code for myAdd (above).
/* f{<object>, <object>} */
descriptor_t * templateZtemplateZf_METH(
descriptor_t *orig_sp, descriptor_t A0 /* x */, descriptor_t A1 /* y */
){
descriptor_t *cluster_0_top;
orig_sp[0] = A0;
orig_sp[1] = A1;
/* + */
cluster_0_top = GENERAL_ENTRY(dylanZdylan_visceraZPLUS.heapptr)(
orig_sp + 2, dylanZdylan_visceraZPLUS.heapptr, 2
);
return cluster_0_top;
}
// now we get to the interesting part! Not only was the code for myAdd
// inlined, the compiler also knew the types of the parameters, so it
// was able to replace the virtual dispatch of "+" in myAdd with direct
// use of an integer add instruction, just as you would get in C++
// inline template functions
/* g{<integer>, <integer>} */
long templateZtemplateZg_METH(
descriptor_t *orig_sp, long A0 /* x */, long A1 /* y */
){
return (A0 + A1);
}
// just the same as the above function, but this time it's inlined to a
// direct use of a floating-point add instruction. Which just happens to
// look the same in C, but that's not essential -- it could have been '+'
// for a user-defined class, in which case d2c would have use the appropriate
// C function call for that class.
/* h{<single-float>, <single-float>} */
float templateZtemplateZh_METH(
descriptor_t *orig_sp, float A0 /* x */, float A1 /* y */
){
return (A0 + A1);
}
Now, in this case, d2c has decided to inline all uses of myAdd(). But
this isn't essential. If myAdd() had been something a bit more
complicated then it might have choosen not to inline it, but to instead
use it as a template to create specialised versions of myAdd().
We can force the issue (and demonstrate the point) by adding the following
functions:
define method myAdd(a :: <integer>, b :: <integer>, #next super)
=> (c :: <integer>)
super();
end myAdd;
define method myAdd(a :: <single-float>, b :: <single-float>, #next super)
=> (c :: <single-float>)
super();
end myAdd;
This is essentially identical in purpose and effect to C++ explicit
instantiation of template functions.
"super()" is essentially the same idea as "super" in Java or SmallTalk or
"inherited" in Object Pascal (or the unsucessful C++ "inherited::"
proposal -- see section 13.6 in "The Design and Evolution of C++") --
except that in Dylan it applies to any overloaded function, not just
virtual functions. (btw, the name "super" is arbitrary, and in fact the
conventional name in Dylan code is "next-method"). The meaning, as usual,
is "call the function that would have been called in the first place, had
the current function not existed"
This change results in the C code output from d2c including the following
functions:
/* myAdd{<integer>, <integer>} */
long templateZtemplateZmyadd_METH_2(
descriptor_t *orig_sp, long A0 /* a */, long A1 /* b */, heapptr_t A2
){
return (A0 + A1);
}
/* myAdd{<single-float>, <single-float>} */
float templateZtemplateZmyadd_METH(
descriptor_t *orig_sp, float A0 /* a */, float A1 /* b */, heapptr_t A2
){
return (A0 + A1);
}
In this case we've forced the compiler to produce this. If the contents
of "myAdd" were a bit more complex then a smart compiler (d2c isn't smart
enough right now, but I'm hoping we'll make it smart enough soon) would
generate these functions automatically, for use when the types of a and b
were known but it wasn't worth inlining the whole function.
Unlike C++ template functions, these specialised functions are also useful
when the types of a and b are NOT known in advance, but fortuitously turn
out to be <integer> or <single-float> at run time. The specialised method
will automatically be called, rather than the general one, which will
result in not having to do virtual (generic) calls of arithmetic,
comparisons etc inside the function, and it may result in more efficient
calling (or even inlining) of any other functions called from within
myAdd().
I hope that I have demonstrated that a single simple mechanism in Dylan
can sucessfully replace *all* the different kinds of functions in C++,
with no loss of efficiency over C++.
I'll just point out at the end that the Dylan compiler I've used as the
example, d2c, is a free open source compiler that is still under active
development. Hopefully it will soon automatically inline and outline
(template expansion) functions automatically rather than needing the hints
I've used here.
d2c happens to generate C code, which is then compiled using gcc (or
other). This is convenient for the purposes of this note, because it
means we don't have to delve through Pentium or PowerPC or other machine
code to see what's going on under the covers. I have not altered the
genuine output of d2c except to clean up the formating and remove
extraneous comments and whitespace. Generating C code is of course not
essential for a Dylan compiler, and Harlequin Dylan (see
<http://www.harlequin.com/products/ads/dylan/> generates machine code
directly.
-- Bruce
------------------------------
From: Steve <[EMAIL PROTECTED]>
Subject: Re: 192.168/16 vs. 10/8
Date: Sun, 27 Jun 1999 06:23:08 GMT
Actually, it was intended that the 10/8 is used for 1st-tier backbone
networking within the corporate infrastructure. 176 for mid-tier and
192 for lower-tier.
[EMAIL PROTECTED] wrote:
>
> In article <7krr42$il$[EMAIL PROTECTED]>,
> "David Means" <[EMAIL PROTECTED]> wrote:
> > [...] use one of the RFC1597
> > (now RFC1918)-specified private address blocks. [ For home use, I
> > recommend 192.168.n.{1-254}. ]
>
> I have often wondered about this. Why is it that so many people suggest
> using 192.168/16 [actually, most recommendations are for 192.168.x/24]?
>
> I always suggest using 10/8 [10.0.0.0-10.255.255.255 for those
> unfamiliar with the "/" notation]. On a private network, there is no
> reason to conserve IP space, and I prefer the extra room the 10/8
> network provides for custom naming.
>
> One interesting scheme I saw worked something like this:
>
> 10.a/16 - Geographic location A
> 10.b/16 - Geographic location B
> 10.c/16 - Geographic location C
> etc...
> 10.a.1/24 - All devices of type "1" [routers] at location A.
> 10.a.2/24 - All devices of type "2" [eg, DNS] at location A.
> 10.a.3/24 - All devices of type "3" [eg, DHCP] at location A.
> etc..
> 10.a.x.1 - router for network X in location A
> 10.a.x.2 - DNS for network X in location A
> 10.a.x.3 - DHCP for network X in location A
> ...
> 10.a.x.100 - host on network X in location A
> etc...
>
> Then, you set up aliases such as
> 10.a.1.x [router for X at A] for 10.a.x.1
> So that you can do nifty things like:
> `ping 10.a.1.255`
> ..and see that all your routers are up at a specific location.
>
> Very cool stuff.
>
> For learning about networking, subnetting, and aliasing, it helps to
> have a lot of "space" to play in. Hence, why I always suggest using
> 10/8.
>
> --
> Bill Clark
> Systems Architect
> ISP Channel
> http://neighborhood.ispchannel.com/
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: Scott Sweeting <[EMAIL PROTECTED]>
Subject: DSL filtering ports
Date: Sat, 26 Jun 1999 18:30:49 -0700
I plan to set up a network of four workstation computers with a linux
box as a gateway to a DSL connection. Since I only get one IP #, I want
to use IP Masquerading so that all four workstations can get online.
But, according to my DSL provider's web page:
"Pacific Bell Internet Services filters out all non-IP protocols for DSL
customers, however, this does not guarantee the security of your
computer or LAN. If file and print sharing is not required on your
computer or network, we recommend that you turn it off as a minimum
security solution."
What bothers me is the filtering of non-IP protocols. Does that mean
that IP Masquerading won't work, or does it mean that things like SMB
and the like won't be accessable from outside the LAN? Does anyone know
about PacBell specifically?
TIA, and please cc to email.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 2 modems routing problem
Date: Sun, 27 Jun 1999 06:42:00 GMT
Thank You, I found the mistake.
I was using in the /etc/ppp/options file a defaultroute option and
that's why any ppp connection became defaultroute.
Now I created 2 separate files options.ttyS0 and options.ttyS1 and it
works (ttyS1 = defaultroute, ttyS0 - no).
Thanks again,
Ovidiu Dressler
In article <7l0hr0$qjp$[EMAIL PROTECTED]>,
Rob van der Putten <[EMAIL PROTECTED]> wrote:
> Hi there
>
> Clifford Kite <kite@NoSpam.% inetport.com> wrote:
>
> > I'd guess it is created by some script at the time of the call-in
since
> > pppd won't override an existing default route, even with the
defaultroute
> > option. I can't say which script - it could be in /etc/ppp/ip-up or
> > some script external to the pppd specific scripts.
>
> Put this in ip-up;
>
> #!/bin/bash
> case $2 in
> /dev/ttyS1)
> /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0
> ;;
> esac
>
> Rem_Ip is the remote addres of the ppp link, ttyS1 its tty.
> This way you can have different routes for diffent ppp links.
>
> > (The 255.255.255.255 mask for a PPP interface gateway route is also
odd
> > to me. It's 0.0.0.0 here, but this may have to do with the
particular
> > networking implementation.)
>
> 255.255.255.255 is OK; It's the route to a single host.
>
> Regards,
> Rob
> --
>
+------------------------------------------------------------------------+
> | Rob van der Putten,
[EMAIL PROTECTED] |
> |
http://www.sput.webster.nl/spam-policy.html |
>
+------------------------------------------------------------------------+
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "m" <[EMAIL PROTECTED]>
Subject: Is the 3com 905c supported?
Date: Sun, 27 Jun 1999 07:02:06 GMT
Has anyone read/know anything about the NIC 3com 905c being supported or
about to be supported?
The most I've seen is the 905b as being the most currently supported card
in this series.
------------------------------
From: "m" <[EMAIL PROTECTED]>
Subject: Re: LinkSys NIC LNE100TX: Anybody have any problems with this card?
Date: Sun, 27 Jun 1999 06:56:15 GMT
It works fine for me... The tulip driver is the one I use because it is the
chipset that my card comes with. There are 2 chipsets for this card.
If your are using Red Hat, you need to use 5.2 or newer, otherwise you will
have to either upgrade the kernel to 2.0.36 or to 2.2.x or patch the kernel
with the tulip driver patch.
One thing to note:
If you seem to be transmitting but no signal is coming back, and everything
seems to be correct with ifconfig and route, try shutting your machine down
completely (for a short bit) and restarting. I have had this happen twice
to me where the card freezes. Only shutting down completely worked each
time.
Linksys has a 100bT hub - works.
Lewis <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> Folks,
>
snip
> I am considering a Linksys Fast Ethernet Kit which contains two
> Linksys LNE100TX cards and a hub. It seems like a good value.
>
> I have been to RedHat's web site, and see that they do not support
> this card, but I have been to LinkSys' web site, and see that they do
> support it for Linux.
>
> I sure that a few of you have used this kit. Any words of wisdom on
> this kit?
>
> 1. Does it work for Linux? (I know that Linksys states it does, but I
> want to hear it from somebody who is actually using it!)
>
> 2. Any "gotchas"?
>
> 3. Any suggestions for any other NIC's and hubs that support 100BaseT
> (that don't cost an arm and a leg!)?
>
> Any help/comments/etc. are appreciated.
>
> Thanks in advance,
>
> R.J.
>
>
> ---------------------------------------------------
> The Lewis's
>
> Remove "NoSpam_" from email address if replying by email.
>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
