Linux-Networking Digest #602, Volume #11 Sun, 20 Jun 99 20:13:44 EDT
Contents:
Re: DNS and routing problem ("Carl R. Friend")
proxy problem ("Cyberant")
How many virtual servers per machine? ("Adam Long")
Re: Here's My Networking Problems (Yuki Taga)
Netscape & localhost error (Max)
Re: Nagel algorithm?? (Joe Doupnik)
Re: VIA-RHINE.c &Redhat 5.2 (Thomas =?iso-8859-1?Q?S=F8rensen?=)
WEBSPACE ("Valle")
Disabling Promiscuous mode ("Phooey")
Re: Could Microsoft Cheat On The New Mindcraft Benchmark? (was: Mindcraft Retest
News ("Chad Mulligan")
Re: phoneline/wireless networking drivers ("Andrey Smirnov")
Re: Could Microsoft Cheat On The New Mindcraft Benchmark? (was: Mindcraft Retest
News ("Chad Mulligan")
----------------------------------------------------------------------------
From: "Carl R. Friend" <[EMAIL PROTECTED]>
Subject: Re: DNS and routing problem
Date: Sun, 20 Jun 1999 17:46:00 -0400
> Morten Ranheim <[EMAIL PROTECTED]> wrote in message
> news:7k8602$7ia$[EMAIL PROTECTED]...
>
> I've set up an imaginary nameserver for our intranet, Just as the DNS
> Howto describes. Everything works properly, but when I do a nslookup
> it returns:
>
> Default Server: dns.ramoe.no
> Address: 0.0.0.0
That's fine. On your DNS server you don't need any nameserver
entries in you /etc/resolv.conf file; it defaults to 0.0.0.0, the
"wildcard" address on the local machine, which will answer your
request. If you place your nameserver's IP address (or that of
localhost) in a "nameserver" line in resolv.conf, you'll see that
address instead of the wildcard.
--
+------------------------------------------------+---------------------+
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:[EMAIL PROTECTED] | |
| http://www.ultranet.com/~crfriend/museum | ICBM: N42:22 W71:47 |
+------------------------------------------------+---------------------+
------------------------------
From: "Cyberant" <[EMAIL PROTECTED]>
Subject: proxy problem
Date: Sat, 19 Jun 1999 23:24:23 +0200
I want to make a Linux machine available as a FTP server through my windows
dial-up session. I know it is a very backward way of doing things, but I
want to do it as a experiment.
I am running Red Hat Linux 6.0 and Windows 98 on two different PC's.
I have Wingate proxy software running on the Win98 machine. Any ideas?
Thanx
Cyberant
------------------------------
From: "Adam Long" <[EMAIL PROTECTED]>
Subject: How many virtual servers per machine?
Date: Sun, 20 Jun 1999 22:13:41 GMT
Hello everyone,
I am running virtuald and virtual services on my linux servers.
Each of my machines are running Red Hat linux 5.2 and they are
all Dual Pentium II 266MHZ systems with 128M Ram.
My qeustion is how many virtual servers would you recommend I should run on
each machine at a max.
Thank you for your help.
------------------------------
From: [EMAIL PROTECTED] (Yuki Taga)
Crossposted-To: alt.os.linux,alt.linux,comp.os.linux.questions
Subject: Re: Here's My Networking Problems
Reply-To: [EMAIL PROTECTED]
Date: Sun, 20 Jun 1999 22:31:58 GMT
On Sun, 20 Jun 1999 17:19:26 GMT, in article
<[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Sat, 19 Jun 1999 10:20:30 GMT, [EMAIL PROTECTED] (Yuki
>Taga) wrote:
>
>>On Sat, 19 Jun 1999 01:45:27 -0500, in article
>><[EMAIL PROTECTED]>, Bill Reynolds <[EMAIL PROTECTED]> wrote:
>>
>>>Have you selected the correct transport protocal. Linux uses TCP/IP and Windows
>>>98 uses IPX. Also you probably need to assign your linux box some kind of
>>>dns number.
>>
>>This is certainly amazing news about Windows98 to me. Do the folks at Novell
>>know about this? <vbg>
>>
>>Yuki ^_^
>
>As I recall, Win98 and Win95 both install IPX and NetBEUI by default.
>So unless they've changed the default config, Win98 *would* be using
>IPX.
NetBEUI I could believe. IPX, I don't. I have never seen any M$ product that
loaded IPX by default. None. Zero.
Yuki ^_^
------------------------------
From: [EMAIL PROTECTED] (Max)
Subject: Netscape & localhost error
Date: 20 Jun 1999 18:34:40 -0400
Greetings All!
I've been futzing along w/ my Redhat5.2 installation. When I installed
RH5.2 initially and started Netscape, I had no problem seeing local
contents from my own box using http://localhost/ or the alias which
I've given it -- http://deckard/.
Now, after some re-configurations I've tried again and my Linux RH5.2
machine can't "see" DocumentRoot, but the PCs on my LAN can.
Where do I need to poke around - my /etc/hosts, my resolv.conf files?
One of the things which seemd to muck things up was an upgrade installation
to linuxconf1.15.
I've deleted this install and reinstalled the one on the RH5.2 CD -
linuxconf-1.12r5-6.
Any help in this regard would be appreciated.
Thanks!
Max Pyziur
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Joe Doupnik)
Crossposted-To: comp.os.linux.development.system
Subject: Re: Nagel algorithm??
Date: 20 Jun 99 16:07:45 MDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mike
Jagdis) writes:
> In article <7kbfh8$esi$[EMAIL PROTECTED]>, bill davidsen wrote:
>>To repeat the original question, short of editing the config file by
>>hand, does this option appear in any of the "make *config" menus? I
>>said I was willing to do it by hand, but I thought it was originally in
>>a config menu. The "say N here" doesn't make much sense unless you get
>>the chance to say anything.
>>[...]
>>If I hadn't done enough network hacking to know there was such a thing
>>and why I wanted to use it, I probably would never have found it.
>
> The no nagle config option no long exists and probably the rogue
> ifdef check should no longer exist either. Nagle is automatically
> turned off on a per socket basis if you set the TCP_NODELAY
> socket option on the socket. Turning nagle off globally is a
> bit drastic in most cases.
>
> Mike
============
It turns out there is plenty of misunderstanding about Nagle mode,
its control, its proper use. It has a famous problem while trying to do
good deeds of grouping up data. The problem is it can hold back a small
segment (one less than a full MSS size) while it awaits ACKs for all
previous data. The ACKs may be delayed (delayed ACKs in use by the receiver).
In that case the deadlock of waiting on ACKs and the receiver waiting on
more data that won't come so as to piggyback the ACK is broken only by
either arrival of new application data to fill out the segment or the
delayed ACK timer in the receiver fires. Often it is latter and things
progress at the rate of that timer (frequently 200ms for five things/sec).
I have looked into the problem and have solved it. You may wish
to read about it in draft RFC
draft-doupnik-tcpimpl-nagle-mode-00.txt
whose title is "A new TCP transmission policy replacing Nagle mode."
It's easiest to grab this from
directory pub/misc on netlab1.usu.edu
Also present in parallel directory
pub/misc/newpolicy.sources
are source code changes for FreeBSD 3.2, Linux 2.2.5-15, and Solaris 7. The
code changes are tiny and all in one spot. The doc has much more insight
to Nagle modes (yes, there is more than one kind) than any networking book.
For a thumbnail sketch of the solution the story is like this.
Nagle mode can hold back a small segment until ACKs arrive, as noted
above. That's rather strange policy: it attempts predicting there will
be more app data, so waiting is worthwhile and avoids tinygrams. Meanwhile
the receiver is also holding back its ACKs, expecting more data and thus
reducing the count of tinygrams. They can deadlock waiting on each other.
Eventually the very slow delayed ACK timer fires and breaks the deadlock.
There is absolutely no way the TCP stack can predict that more
application data will follow immediately, nor can the receiver make a
prediction that no more data will follow immediately. The TCP transmitter
cannot know what the application will do next; that is fundamentally
impossible. Only the app knows what it will do next. Thus attempts at
predictions will fail and create the deadlock, no matter how clever are
the heuristics. This paragraph needs to be writ large.
The solution is hold back small segments until the application plus
o/s _tells_ the transmitter's TCP that there is no more data to follow.
The apps do this already in cooperation with the operating system. That's
how the PUSH (PSH) bit gets set properly. There is no extra programming
effort needed; it already happens naturally. The draft RFC above explains
this in detail. There is no fruitless predicting, there is no deadlock
possible, things go fast, full segments are made whenever the app gives
enough data, no app level controls are necessary nor wanted. The above
draft also contains some measurements on the matter.
To avoid sending small segments when the app writes small data
quantities then avoid sending small data quantities to the protocol stack
unless needed. Put simply, buffer app data into larger chunks. Below are
some hints on how.
Unix folks can use fwrite() and fflush() in cooperation with
setvbuf()/setbuffer(). This works very well indeed. It's just as fast as
immediate mode write() but it buffers as you wish. It's not whimpy. To use
f-functions on a socket use fdopen() to create a FILE pointer from a file
descriptor. Plain write() causes only its data to be sent to the TCP stack
as-is and right-now, and what's delivered is what the network will try
sending right now. fwrite() writes to large app buffer and that buffer is
flushed to the TCP stack when it fills and when fflush() is called. Very
simple buffering is the _fast_ way, avoiding many tinygrams and extra system
calls which are slow. It's faster than write().
I will say this in public. The teaching of network programming
has almost totally focused on using immediate-action i/o statments, like
write(), rather than using buffered-action i/o statements such as fwrite().
This is a serious blunder, a bit of blindness by those who should know
better. I was in this group until I figured out the deadlock situation.
My new TCP transmission policy causes the network to do what the
application requests, as quickly as it can, automatically, and that is a
welcome change from today's behavior. To ensure we don't overconsume
resources we output data in big chunks. This saves host cpu cycles at both
ends, it saves network resouces. It is faster with and without a network,
it is almost the same programming effort as write(). We need to educate
programmers to buffer and conserve and as a benefit things will go faster
than otherwise, even to a local disk drive. Stay away from write(). Yes I
know, old habits die hard; but now we have no excuse to behave as of old.
Turning off Nagle mode, the alternative to-date, leads to more
tinygrams. My "new policy" strongly groups when it can to send full segments.
The app can help that a lot at basically no cost by buffering well. We get
the benefits of full segments and no deadlock. No network programming is
required. Turning off Nagle mode, today, is via a socket option, TCP_NODELAY,
applied via setsockopt(), or option FIONBIO to ioctl(). My new policy needs
none of this sockets control code. We should keep in mind that not all TCP/IP
work uses sockets.
If you have comments on my new TCP transmission policy replacing
Nagle mode please feel free to contact me directly at [EMAIL PROTECTED]
Joe D.
------------------------------
From: Thomas =?iso-8859-1?Q?S=F8rensen?= <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: VIA-RHINE.c &Redhat 5.2
Date: Mon, 21 Jun 1999 00:49:18 +0200
John B wrote:
> Hello,
> I am trying to install the via-rhine driver into my RedHat 5.2.
> I am doing everything I am told and I am using the gcc compile-code
> at the end of via-rhine.c
> I keep getting the error
>
> "gcc: via-rhine.c : No such file or Directory"
>
> the compilecode is
> gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
> -Wstrict-prototypes -O6 -c via-rhine.c `[ -f
> /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`
>
> I did notice the -I parameter /usr/src/linux/net/inet is not on my file
> system.
> Does anyone know where this should point to for RH5.2?
>
> I am really stuck - its been weeks!
>
> Thank You
>
> John B
>
> _________________________________________
> Take the POOPY out of my e ma il to con tact me!
> Thanks
> ====================================
Hello John B
You must specify the exact path to via-rhine.c in the gcc-command.
Fx: If you have the source-code in "/usr/src/modules/via-rhine.c", you give
the command:
gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
-Wstrict-prototypes -O6 -c /usr/src/modules/via-rhine.c `[ -f
/usr/include/linux/modversions.h ] && echo -DMODVERSIONS`
- Thomas Sorensen
------------------------------
From: "Valle" <[EMAIL PROTECTED]>
Subject: WEBSPACE
Date: Sun, 20 Jun 1999 23:35:21 +0200
do you want CHEAP webspace ??
-> join us at our new server, starting in august
just reply to this mail, and tell us what you need - best
price guaranted
brauchen sie G�NSTIGEN webspace ?
-> dann kommen sie ab august auf unseren neuen server
mailen sie uns einfach ihre anfrage - sie werden �berrascht sein
------------------------------
From: "Phooey" <jbarak*NS*@ibm.net>
Subject: Disabling Promiscuous mode
Date: Sun, 20 Jun 1999 18:35:43 -0500
I've heard some comments in this newsgroup about eth0 going into promiscuous
mode. How do you disable an Ethernet card from entering promiscuous mode
at boot time? The [MAN] page for "ifconfig" tells you how to manually
turn this feature off, but does anyone know how to permanently disable this
feature?
I do not recall ever turning this feature on when configuring my card. Some
people in this newsgroup believe that this is a sign of being "Hacked".
I'm not sure if this is the case, or I enabled it accidentally when
configuring my network. Is anyone else having a problem with promiscuous
mode?
Jay
--
"I don't want to achieve immortality
through my work. I want to achieve
it through not dying."
- Woody Allen
------------------------------
From: "Chad Mulligan" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.advocacy,comp.infosystems.www.servers.unix,comp.os.linux.misc
Subject: Re: Could Microsoft Cheat On The New Mindcraft Benchmark? (was: Mindcraft
Retest News
Date: Sun, 20 Jun 1999 16:37:51 -0700
Stuart Fox wrote in message <7khtpg$2bu$[EMAIL PROTECTED]>...
>
>Chris Lee <[EMAIL PROTECTED]> wrote in message
>news:7kggrj$n4e$[EMAIL PROTECTED]...
>> In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED]
>> says...
>> >
>> >On Sat, 19 Jun 1999 13:22:10 +1200, "Stuart Fox"
>> ><[EMAIL PROTECTED]> wrote:
>> >
>> >:> This would be easy to program, but would never work, because
>> >:> Unix users just *don't* set up their software to
>> >:> automatically execute e-mail attachments.
>> >
>> >
>> >Wow, this was a beautiful piece of FUD I missed.
>>
>>
>> What FUD? How do you think BO got to be so popular with the Windows set?
>>
>FUD because Outlook doesn't open attachments automatically. It will by
>default show images inline....
>
Which anyone with any brains, turns off.
>
------------------------------
From: "Andrey Smirnov" <[EMAIL PROTECTED]>
Subject: Re: phoneline/wireless networking drivers
Date: Sun, 20 Jun 1999 16:10:23 -0700
Hello,
Proxim has a product that allows to create a wireless network and it's not a
internal card, but a external device. And you don't need any OS specific
drivers to make it work. The only draw back is the high price.
Good luck!
Ruth AnneF wrote in message
<[EMAIL PROTECTED]>...
>I was wondering if there are any drivers for any of the phoneline or
wireless
>home networking kits, as in Diamond HomeFree, Intel AnyPoint or Proxim
>Symphony. I know WebGear is making Linux drivers for Aviator2.4, but
they're
>not due out until July, and I would like to get my house networked before
then,
>and hopefully without the expense of wiring up my house, but I need for the
two
>Linux boxes that I have to be part of the network (one being a
masquerader).
>Thanks.
------------------------------
From: "Chad Mulligan" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.advocacy,comp.infosystems.www.servers.unix,comp.os.linux.misc
Subject: Re: Could Microsoft Cheat On The New Mindcraft Benchmark? (was: Mindcraft
Retest News
Date: Sun, 20 Jun 1999 16:40:23 -0700
Stuart Fox wrote in message <7khubm$3be$[EMAIL PROTECTED]>...
>
>Scott MacDonald <[EMAIL PROTECTED]> wrote in message
>news:6EGa3.299$[EMAIL PROTECTED]...
>>
>> Stuart Fox <[EMAIL PROTECTED]> wrote in message
>> news:7keqqo$7gk$[EMAIL PROTECTED]...
>> >
>> > Jason O'Rourke <[EMAIL PROTECTED]> wrote in message
>> > news:7kemol$sr0$[EMAIL PROTECTED]...
>> > > Stuart Fox <[EMAIL PROTECTED]> wrote:
>> >
>> > >
>> > > >It isn't MS's problem if someone exploits the tools provided in an
>> Office
>> > > >app. However it might be if a product didn't work as advertised -
>win
>> > 3.1
>> > > >on DR-DOS for instance.
>> > > >Does this mean that if I wrote a virus in VB that MS would be
>> > responsible?
>> > >
>> > > In my mind, yes. They created a 'feature' that has brought IS
>> departments
>> > > using Office to their knees. This started with the tame but annoying
>> word
>> > > macro virus and has now gotten quite dangerous.
>> > >
>> > > >>and the knowledge
>> > > >> that anyone could exploit IIS with a single line of code.
>> > > >Are you suggesting that *nix has no bugs? Or requires no patches to
>> get
>> > > >running securely? ALL operating systems have bugs that must be
>> patched,
>> > I
>> > > >don't care if it's linux, NT, Solaris etc. And why has no-one found
>> this
>> > > >bug until now - IIS 4.0 has been out for quite a while now...
>> > >
>> > > Unix certainly has had its troubles, especially with sendmail. But
at
>> > > this point, most of the issues have been resolved.
>> >
>> > Excluding of course every new app that is released, or every new
>update...
>> >
>> > Open source code and
>> > > 20 years of release time have been helpful. Meanwhile, Windows and
NT
>> > > have been used for networking for but a few years and it's pretty
>clear
>> > > that this is going to continue for quite some time. MS won't get
sued
>> > > over it, they'll make a killing selling fixes instead. Or perhaps
>> people
>> > > will start to realize the costs and move on.
>> >
>> > They don't sell fixes - they are free.
>> >
>> Win 98 was a fix for Win95 don't try to tell me they don't sell them.
Every component that was a fix for 95 was available for free via download.
>>
>>
>Your opinion only. Heard of service packs - they are fixes. And also
free.
>
>
------------------------------
** 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
******************************
