Linux-Networking Digest #612, Volume #12         Thu, 16 Sep 99 17:13:44 EDT

Contents:
  Re: ppp problem with uswest.net (ksvenbak)
  strange modem problem(s) HELP !!!! (Eric Trimmer)
  Re: ppp-2.3.7 problem (Clifford Kite)
  SAMBA and Netatalk on Slackware (Alexander Kozik)
  Re: Sub-C networks? (Clifford Kite)
  Re: Recommendation for 100Mbps Switched Ethernet hardware (Bryan)
  Re: routing: load balance with multiple defaults? (Raymonds Doetjes)
  Re: connect Win98 to Linux via serial ports ? (Eric Trimmer)

----------------------------------------------------------------------------

From: ksvenbak <[EMAIL PROTECTED]>
Subject: Re: ppp problem with uswest.net
Date: Thu, 16 Sep 1999 20:26:28 GMT


==============B3AC88D4ECDE78401A07DA0D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Bill Unruh for responding. I tried dialing out once again without the
kdebug option ( previously had kdebug 25 in the ppp script) and it connected fine.
The puzzling thing, however, is that the LCP ProtRej still was logged, but inspite
of that, the connection took place. What is the deal with the LCP ProtRej? Did the
removal of kdebug have anything to do with the correct operation of the script?

Here is the listing of /var/log/ppp:

Sep 16 13:07:04 zeus pppd[5531]: pppd 2.3.7 started by root, uid 0
Sep 16 13:07:06 zeus chat[5532]: timeout set to 3 seconds
Sep 16 13:07:06 zeus chat[5532]: abort on (\nBUSY\r)
Sep 16 13:07:06 zeus chat[5532]: abort on (\nNO ANSWER\r)
Sep 16 13:07:06 zeus chat[5532]: abort on (\nRINGING\r\n\r\nRINGING\r)
Sep 16 13:07:06 zeus chat[5532]: send (rAT^M)
Sep 16 13:07:06 zeus chat[5532]: expect (OK)
Sep 16 13:07:06 zeus chat[5532]: rAT^M^M
Sep 16 13:07:06 zeus chat[5532]: OK
Sep 16 13:07:06 zeus chat[5532]:  -- got it
Sep 16 13:07:06 zeus chat[5532]: send (ATH0^M)
Sep 16 13:07:06 zeus chat[5532]: timeout set to 30 seconds
Sep 16 13:07:06 zeus chat[5532]: expect (OK)
Sep 16 13:07:06 zeus chat[5532]: ^M
Sep 16 13:07:06 zeus chat[5532]: ATH0^M^M
Sep 16 13:07:06 zeus chat[5532]: OK
Sep 16 13:07:06 zeus chat[5532]:  -- got it
Sep 16 13:07:06 zeus chat[5532]: send (ATDT535-8580^M)
Sep 16 13:07:06 zeus chat[5532]: expect (CONNECT)
Sep 16 13:07:06 zeus chat[5532]: ^M
Sep 16 13:07:26 zeus chat[5532]: ATDT535-8580^M^M
Sep 16 13:07:26 zeus chat[5532]: CONNECT
Sep 16 13:07:26 zeus chat[5532]:  -- got it
Sep 16 13:07:26 zeus chat[5532]: send (^M)
Sep 16 13:07:26 zeus chat[5532]: expect (sername:)
Sep 16 13:07:26 zeus chat[5532]:  28800/ARQ/V34/LAPM/V42BIS^M
Sep 16 13:07:26 zeus chat[5532]: ^M
Sep 16 13:07:26 zeus chat[5532]: ^M
Sep 16 13:07:26 zeus chat[5532]: User Access Verification^M
Sep 16 13:07:26 zeus chat[5532]: ^M
Sep 16 13:07:26 zeus chat[5532]: Username:
Sep 16 13:07:26 zeus chat[5532]:  -- got it
Sep 16 13:07:26 zeus chat[5532]: send (ksvenbak^M)
Sep 16 13:07:27 zeus chat[5532]: expect (assword:)
Sep 16 13:07:27 zeus chat[5532]:  ^M
Sep 16 13:07:27 zeus chat[5532]: Username: ksvenbak^M
Sep 16 13:07:27 zeus chat[5532]: Password:
Sep 16 13:07:27 zeus chat[5532]:  -- got it
Sep 16 13:07:27 zeus chat[5532]: send (password^M)
Sep 16 13:07:27 zeus pppd[5531]: Serial connection established.
Sep 16 13:07:27 zeus pppd[5531]: Using interface ppp0
Sep 16 13:07:27 zeus pppd[5531]: Connect: ppp0 <--> /dev/ttyS1
Sep 16 13:07:28 zeus pppd[5531]: sent [LCP ConfReq id=0x1 <magic
0xf23eaf6f> <pcomp> <accomp>]
Sep 16 13:07:28 zeus pppd[5531]: rcvd [LCP ConfReq id=0x11 <asyncmap
0xa0000> <magic 0x12009460> <pcomp> <accomp>]
Sep 16 13:07:28 zeus pppd[5531]: sent [LCP ConfAck id=0x11 <asyncmap
0xa0000> <magic 0x12009460> <pcomp> <accomp>]
Sep 16 13:07:28 zeus pppd[5531]: rcvd [LCP ConfAck id=0x1 <magic
0xf23eaf6f> <pcomp> <accomp>]
Sep 16 13:07:28 zeus pppd[5531]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>
<compress VJ 0f 01>]
Sep 16 13:07:29 zeus kernel: PPP BSD Compression module registered
Sep 16 13:07:29 zeus kernel: PPP BSD Compression module registered
Sep 16 13:07:29 zeus kernel: PPP Deflate Compression module registered
Sep 16 13:07:29 zeus kernel: PPP Deflate Compression module registered
Sep 16 13:07:29 zeus pppd[5531]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Sep 16 13:07:29 zeus pppd[5531]: rcvd [IPCP ConfReq id=0x1 <addr 207.225.28.42>]
Sep 16 13:07:29 zeus pppd[5531]: sent [IPCP ConfAck id=0x1 <addr 207.225.28.42>]
Sep 16 13:07:29 zeus pppd[5531]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Sep 16 13:07:29 zeus pppd[5531]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
Sep 16 13:07:29 zeus pppd[5531]: rcvd [LCP ProtRej id=0x12 80 fd 01 01 00
0f 1a 04 78 00 18 04 78 00 15 03 2f]
Sep 16 13:07:29 zeus pppd[5531]: rcvd [IPCP ConfNak id=0x2 <addr
207.225.17.250>]
Sep 16 13:07:29 zeus pppd[5531]: sent [IPCP ConfReq id=0x3 <addr
207.225.17.250>]
Sep 16 13:07:30 zeus pppd[5531]: rcvd [IPCP ConfAck id=0x3 <addr
207.225.17.250>]
Sep 16 13:07:30 zeus pppd[5531]: local  IP address 207.225.17.250
Sep 16 13:07:30 zeus pppd[5531]: remote IP address 207.225.28.42
Sep 16 13:07:30 zeus pppd[5531]: Script /etc/ppp/ip-up started; pid = 5537
Sep 16 13:07:33 zeus pppd[5531]: Script /etc/ppp/ip-up finished (pid 5537),
status = 0x0

Thanks,
Krishna.


Bill Unruh wrote:

> I would suggest tutning off kdebug in the pppd options. It makes it hard
> to read and (at least I) cannot make any use of the kdebug output.
>
> In <[EMAIL PROTECTED]> ksvenbak <[EMAIL PROTECTED]> writes:
> A
>
> >I have tried using all sorts of options while dialing out such as novj,
> >novjccomp, lcp-max-configure 40, noip, default asyncmap(later replaced
> >it with asyncmap 0x200a0000, but was not of any help), noauth, noccomp.
>
> >Will someone please help? USWest will not help dialers using linux.
>
> >Below are kernel and pppd messages recorded in /var/log/ppp:
>
> >Sep 14 21:09:44 zeus pppd[8916]: rcvd [LCP ProtRej id=0x80 80 21 01 01
> >00 0a 03 06 00 00 00 00]
>
> This appears to be the crucial line. I do not know where they got this
> from?
>
> Anyway, I would suggest trying NOT to do login authentication, but
> rather trying pap/chap. Ie, terminate the chat string with
> CONNECT '\d\c'
> and see what happpens.

==============B3AC88D4ECDE78401A07DA0D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks Bill Unruh for responding. I tried dialing out once again without
the kdebug option ( previously had kdebug 25 in the ppp script) and it
connected fine. The puzzling thing, however, is that the LCP ProtRej still
was logged, but inspite of that, the connection took place. What is the
deal with the LCP ProtRej? Did the removal of kdebug have anything to do
with the correct operation of the script?
<p><tt>Here is the listing of /var/log/ppp:</tt><tt></tt>
<p><tt>Sep 16 13:07:04 zeus pppd[5531]: pppd 2.3.7 started by root, uid
0</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: timeout set to 3 seconds</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: abort on (\nBUSY\r)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: abort on (\nNO ANSWER\r)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: abort on (\nRINGING\r\n\r\nRINGING\r)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: send (rAT^M)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: expect (OK)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: rAT^M^M</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: OK</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]:&nbsp; -- got it</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: send (ATH0^M)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: timeout set to 30 seconds</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: expect (OK)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: ^M</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: ATH0^M^M</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: OK</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]:&nbsp; -- got it</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: send (ATDT535-8580^M)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: expect (CONNECT)</tt>
<br><tt>Sep 16 13:07:06 zeus chat[5532]: ^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: ATDT535-8580^M^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: CONNECT</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]:&nbsp; -- got it</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: send (^M)</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: expect (sername:)</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]:&nbsp; 28800/ARQ/V34/LAPM/V42BIS^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: ^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: ^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: User Access Verification^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: ^M</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: Username:</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]:&nbsp; -- got it</tt>
<br><tt>Sep 16 13:07:26 zeus chat[5532]: send (ksvenbak^M)</tt>
<br><tt>Sep 16 13:07:27 zeus chat[5532]: expect (assword:)</tt>
<br><tt>Sep 16 13:07:27 zeus chat[5532]:&nbsp; ^M</tt>
<br><tt>Sep 16 13:07:27 zeus chat[5532]: Username: ksvenbak^M</tt>
<br><tt>Sep 16 13:07:27 zeus chat[5532]: Password:</tt>
<br><tt>Sep 16 13:07:27 zeus chat[5532]:&nbsp; -- got it</tt>
<br><tt>Sep 16 13:07:27 zeus chat[5532]: send (password^M)</tt>
<br><tt>Sep 16 13:07:27 zeus pppd[5531]: Serial connection established.</tt>
<br><tt>Sep 16 13:07:27 zeus pppd[5531]: Using interface ppp0</tt>
<br><tt>Sep 16 13:07:27 zeus pppd[5531]: Connect: ppp0 &lt;--> /dev/ttyS1</tt>
<br><tt>Sep 16 13:07:28 zeus pppd[5531]: sent [LCP ConfReq id=0x1 &lt;magic</tt>
<br><tt>0xf23eaf6f> &lt;pcomp> &lt;accomp>]</tt>
<br><tt>Sep 16 13:07:28 zeus pppd[5531]: rcvd [LCP ConfReq id=0x11 &lt;asyncmap</tt>
<br><tt>0xa0000> &lt;magic 0x12009460> &lt;pcomp> &lt;accomp>]</tt>
<br><tt>Sep 16 13:07:28 zeus pppd[5531]: sent [LCP ConfAck id=0x11 &lt;asyncmap</tt>
<br><tt>0xa0000> &lt;magic 0x12009460> &lt;pcomp> &lt;accomp>]</tt>
<br><tt>Sep 16 13:07:28 zeus pppd[5531]: rcvd [LCP ConfAck id=0x1 &lt;magic</tt>
<br><tt>0xf23eaf6f> &lt;pcomp> &lt;accomp>]</tt>
<br><tt>Sep 16 13:07:28 zeus pppd[5531]: sent [IPCP ConfReq id=0x1 &lt;addr
0.0.0.0></tt>
<br><tt>&lt;compress VJ 0f 01>]</tt>
<br><tt>Sep 16 13:07:29 zeus kernel: PPP BSD Compression module registered</tt>
<br><tt>Sep 16 13:07:29 zeus kernel: PPP BSD Compression module registered</tt>
<br><tt>Sep 16 13:07:29 zeus kernel: PPP Deflate Compression module registered</tt>
<br><tt>Sep 16 13:07:29 zeus kernel: PPP Deflate Compression module registered</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: sent [CCP ConfReq id=0x1 &lt;deflate
15></tt>
<br><tt>&lt;deflate(old#) 15> &lt;bsd v1 15>]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: rcvd [IPCP ConfReq id=0x1 &lt;addr
207.225.28.42>]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: sent [IPCP ConfAck id=0x1 &lt;addr
207.225.28.42>]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: rcvd [IPCP ConfRej id=0x1 &lt;compress
VJ 0f 01>]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: sent [IPCP ConfReq id=0x2 &lt;addr
0.0.0.0>]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: rcvd [LCP ProtRej id=0x12 80 fd
01 01 00</tt>
<br><tt>0f 1a 04 78 00 18 04 78 00 15 03 2f]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: rcvd [IPCP ConfNak id=0x2 &lt;addr</tt>
<br><tt>207.225.17.250>]</tt>
<br><tt>Sep 16 13:07:29 zeus pppd[5531]: sent [IPCP ConfReq id=0x3 &lt;addr</tt>
<br><tt>207.225.17.250>]</tt>
<br><tt>Sep 16 13:07:30 zeus pppd[5531]: rcvd [IPCP ConfAck id=0x3 &lt;addr</tt>
<br><tt>207.225.17.250>]</tt>
<br><tt>Sep 16 13:07:30 zeus pppd[5531]: local&nbsp; IP address 207.225.17.250</tt>
<br><tt>Sep 16 13:07:30 zeus pppd[5531]: remote IP address 207.225.28.42</tt>
<br><tt>Sep 16 13:07:30 zeus pppd[5531]: Script /etc/ppp/ip-up started;
pid = 5537</tt>
<br><tt>Sep 16 13:07:33 zeus pppd[5531]: Script /etc/ppp/ip-up finished
(pid 5537),</tt>
<br><tt>status = 0x0</tt><tt></tt>
<p>Thanks,
<br>Krishna.
<br>&nbsp;
<p>Bill Unruh wrote:
<blockquote TYPE=CITE>I would suggest tutning off kdebug in the pppd options.
It makes it hard
<br>to read and (at least I) cannot make any use of the kdebug output.
<p>In &lt;[EMAIL PROTECTED]> ksvenbak &lt;[EMAIL PROTECTED]>
writes:
<br>A
<p>>I have tried using all sorts of options while dialing out such as novj,
<br>>novjccomp, lcp-max-configure 40, noip, default asyncmap(later replaced
<br>>it with asyncmap 0x200a0000, but was not of any help), noauth, noccomp.
<p>>Will someone please help? USWest will not help dialers using linux.
<p>>Below are kernel and pppd messages recorded in /var/log/ppp:
<p>>Sep 14 21:09:44 zeus pppd[8916]: rcvd [LCP ProtRej id=0x80 80 21 01
01
<br>>00 0a 03 06 00 00 00 00]
<p>This appears to be the crucial line. I do not know where they got this
<br>from?
<p>Anyway, I would suggest trying NOT to do login authentication, but
<br>rather trying pap/chap. Ie, terminate the chat string with
<br>CONNECT '\d\c'
<br>and see what happpens.</blockquote>
</html>

==============B3AC88D4ECDE78401A07DA0D==


------------------------------

Date: Thu, 16 Sep 1999 13:17:27 -0400
From: Eric Trimmer <[EMAIL PROTECTED]>
Subject: strange modem problem(s) HELP !!!!

Ever since someone (phone company ?) "played" with my phone lines on the
side of my house I've been having a problem with my Internet connection.

What happens is that randomly (sometimes daily and sometimes only once a
month) my modem will hangup but still keep carrier ! Meaning that the 
connection (phone call) will cease to exist but Linux still thinks it does.
ie. The "route","ifconfig",..... still show a connection; but there really
isn't ! And once this happens it is impossible to communicate with the 
modem. The only cure is to manually turn the modem off and back on.
(it's an external modem).

Many people suggested that perhaps my serial port had gone bad. But I've
tried changing all related hardware; modem, modem-cable, serial ports (both
using another and installing a whole new card). I've also tried re-compiling
a new kernel and ppp. I've also tried various init commands for the modem.
But the problem still happens.

Has anyone else experienced this ? And/or can anyone think of a specific
modem init string to solve this problem ?

Thanks,

This next problem might/might not be related.

My most recent "fix" was to buy yet another new serial port card. But this one 
allows ANY address and/or IRQ to assigned to each port on the card. So I
installed the card with ports cua2(com3) and cua3(com4) with the standard
address's but IRQ's 11 and 12. (Those IRQ's were available and I also set
the BIOS settings for those IRQ's to ISA/LEGACY instead of the default of
PCI/AUTO). Everything worked fine for about 10 hours. But then then modem
started acting up again. It keep disconnecting and reconnecting repeatedly.
It would connect, then disconnect after about 20 secs. This went on for about
an hour. Then the original problem occured; again ! And once again the only 
cure for the original problem was to turn the modem off and back on.
And the only cure for the newer problem was to reboot my machine.

Thanks,
=============================================================
Eric Trimmer                       email: [EMAIL PROTECTED]
                           Web Address: http://et.trimmer.org

Remember: If vegetarians eat vegetables;
          beware of humanitarians !! 
=============================================================


------------------------------

From: kite@NoSpam.%inetport.com (Clifford Kite)
Subject: Re: ppp-2.3.7 problem
Date: 16 Sep 1999 14:50:00 -0500

Gene Heskett ([EMAIL PROTECTED]) wrote:

> We can start a ping to some site from this problem site, and get 5-15
> second ping times for minutes at a time, and then it will catch up,
> and do 300 milliseconds for maybe 30 seconds, then it will die for
> 10-30 or more.  And when it starts back up, 10-30 packets in the
> sequence will be on the missing list.

> Something unique to this install (or site) seems to be at work.  We
> are using the same ppp configuration settings, and the same ppp-2.3.7
> at 3 locations, all to this same ISP, and 2 work quite nicely while
> the busiest one (or would be if it worked) lags along for minutes at a
> time, telling us there is no DNS available and such.

The first thing I'd check is the IRQ configured for the /dev/ttySx that
the modem uses and make sure it is the IRQ that the modem actually uses.
An incorrectly configured IRQ *might* result in the symptoms you describe.

If that's not the problem then I'd swap the two USR boxes to verify whether
the problem was indeed on the box or somewhere along the Telco lines.

I'd suspect it's either the IRQ or the Telco lines but I suppose that
faulty hardware on the box might also be causing it.  I can't see any
other possiblilities, but hasten to add that doesn't mean that another
possiblity doesn't exit.

--
Clifford Kite <kite@inet%port.com>                    Not a guru. (tm)
/* Those who can't write, write manuals. */

------------------------------

From: Alexander Kozik <[EMAIL PROTECTED]>
Subject: SAMBA and Netatalk on Slackware
Date: Thu, 16 Sep 1999 09:26:30 -0700


I am going to install file and printer servers on Linux box for LAN with
Windows NT and Macintosh computers. I know from my friends that Netatalk
does work "out of the box" on RedHat Mandrake but something is wrong with
SAMBA. At the same time SAMBA is "OK" on SuSE but Netatalk needs
attention.  I need both SAMBA and Netatalk and I would be happy to use
Slackware. What distribution is better for this purpose?
Any suggestions, please.
Do I need to recompile the Slackware 3.9 or 4.0 kernel to get support for
Appletalk?

Thanks a lot in advance.

Alexander.

=================================================
Alexander Kozik, Medical School, Bio-Chem Dpt,
               University of California at Davis.
                      Davis, 95616 CA.
                  email: [EMAIL PROTECTED]
                    tel: (530)-752 3314
=================================================


------------------------------

From: kite@NoSpam.%inetport.com (Clifford Kite)
Subject: Re: Sub-C networks?
Date: 16 Sep 1999 12:02:31 -0500

David C. ([EMAIL PROTECTED]) wrote:

> When I run netatat -rn, I see:

> >>>>>>>>>>
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 10.1.1.0        0.0.0.0         255.255.255.0   U      1500 0          0 eth0
> 127.0.0.0       0.0.0.0         255.0.0.0       U      3584 0          0 lo
> 0.0.0.0         10.1.1.1        0.0.0.0         UG     1500 0          0 eth0
> <<<<<<<<<<

> So what am I missing here?  Looks like all the default routes are
> automatically created at boot time from the network configuration files.

> I never wrote a single "route add" line.

No, but RH configuration scripts set up routes in one of the boot-up
files, usually in /etc/rc.d/ .  There's a difference between configuring
the routes with boot-up resource configuration scripts and the kernel
automatically configuring routes based on existing interfaces at boot-up.

--
Clifford Kite <kite@inet%port.com>                    Not a guru. (tm)
/* To extract lines:  View file with "vi -R".  Move cursor to first line.
   Press "v".  Move cursor to mark lines (Esc unmarks).  Write lines to
   fubar with ":w fubar <Enter>".  Exit with ":q <Enter>". */

------------------------------

From: Bryan <Bryan@[EMAIL PROTECTED]>
Subject: Re: Recommendation for 100Mbps Switched Ethernet hardware
Crossposted-To: comp.sys.ibm.pc.hardware.networking
Date: Thu, 16 Sep 1999 20:42:28 GMT

In comp.os.linux.networking David C. <[EMAIL PROTECTED]> wrote:

: - Hub - An incredibly generic term.  Any device that connects multiple
:   network devices together.  Usually, when people refer to "hubs" they
:   are referring to dumb repeaters.

depends on the context; for an office 'port expander' the size of
which you can hold in your palm, it won't be managable (dumb).  but
alost any comms room hub will have snmp on it for management.  maybe
even an embedded webserver and telnet.


:   A repeater takes every packet that comes in and transmits it out every
:   port.  Repeaters have no intelligence. 

they do know about when a port is 'bad' and will cut off the bad
station from the rest of the network.  too many collisions (sometimes)
and definitely when a tolerance is horribly wrong.  certainly when no
link is at the far end, the port will partition ('shut off') that
port.


: Layer-2 switches are often referred to as "bridges".  They forward
: packets between two network segments based on layer-2 information, which
: is the 6-byte source and destination MAC addresses on Ethernet networks.
: They are called bridges because the "bridge" between two layer-2
: segments, combining them into a single layer-3 network.

also part of bridging is running a distributed algorithm called
'spanning tree'. which essentially exists to remove loops (cycles)
from extended lans.  if a lan has a loop, frames will travel thru and
thru and never really expire.  IP doesn't need this since the protocol
has a 'time to live' field and if some lost packet circles thru too
many times, it will auto-expire.


: layer-3 switches are often referred to as "routers".  They forward
: packets between two layer-2 network segments based on information in
: each packet's layer-3 header.  They will rewrite a packet's layer-2
: information in doing so, because layer-2 information from one segment is
: usually uselsss on another segment.

slight problem with this.  'useless on the other segment'?  ethernet
addr's are (should be) globally unique so there's no problem in merely
repeating the frame as-is on the other segment.  but the destination
address of the next-hop router has to be modified if that router is
supposed to relay that packet.


: Layer-3 switches can only work with the layer-3 protocols they're
: designed for.  This is usually IP, but many networks will use other
: protocols as well (like NetBEUI, IPX and AppleTalk).  If the router
: doesn't have software to deal with those (and other) protocols, it not
: be able to forward those kinds of packets to other networks.

usually these days, routers can fallback to bridging mode and bridge
what they can't natively route.


: A routing protocol is a program running on a layer-3 switch.

actually, ALL switches in a participating routing domain.


-- 
Bryan, http://www.Grateful.Net - Linux/Web-based Network Management
->->-> to email me, you must hunt the WUMPUS and kill it.

------------------------------

From: Raymonds Doetjes <[EMAIL PROTECTED]>
Subject: Re: routing: load balance with multiple defaults?
Date: Thu, 16 Sep 1999 20:30:07 +0200

Is not yet implemented work is being done to do this!
The only problem you still ahve with load-balanced networks, is the order
of your packets isn't known wich has no problems to TCP packets but a long
dependable stream of UDP packets need to arrive in the good order or the
application layer needs to take care of this. (Small background).

Raymond

Raymond

Leslie Mikesell wrote:

> If I supply multiple default routes through different gateways at equal
> costs, will Linux load balance across them like a Cisco router would?
>
>   Les Mikesell
>    [EMAIL PROTECTED]


------------------------------

Date: Thu, 16 Sep 1999 15:59:10 -0400
From: Eric Trimmer <[EMAIL PROTECTED]>
Subject: Re: connect Win98 to Linux via serial ports ?

On Thu, 16 Sep 1999, Raymonds Doetjes wrote:

> Date: Thu, 16 Sep 1999 19:38:34 +0200
> From: Raymonds Doetjes <[EMAIL PROTECTED]>
> To: Eric Trimmer <[EMAIL PROTECTED]>
> Newgroups: comp.os.linux.networking
> Subject: Re: connect Win98 to Linux via serial ports ?
> 
> You can create a null-modem ppp session from your Windows box to your
> linux.
> It's a bit tricky but dowable. There is some info on this in the mgetty and
> the pppd howto's (if I'm correct).
> 
> Raymond
> 

Thanks, I'll look into those doc's
=============================================================
Eric Trimmer                       email: [EMAIL PROTECTED]
                           Web Address: http://et.trimmer.org

Remember: If vegetarians eat vegetables;
          beware of humanitarians !! 
=============================================================


------------------------------


** 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
******************************

Reply via email to