Linux-Networking Digest #97, Volume #10 Wed, 3 Feb 99 09:13:59 EST
Contents:
Strange prob w/telnet ("James D. McIninch")
RedHat/Kingston KNE110TX NIC ("zz")
Re: can not ftp certain file types (Ted Potter)
Re: SurfBoard 1000 Cable Modem ("Jim Orfanakos")
OOB problem ([EMAIL PROTECTED])
NFS and dynamic IP address ([EMAIL PROTECTED])
OOB problem (Nikos Kolomvos)
Re: Problem with connecting in batch mode to ISP (Solved). ([EMAIL PROTECTED])
weird routing/firewall/internet situation. Help? ([EMAIL PROTECTED])
Slackware Install over TCP/IP ("Jason Rigsbee")
3c900B (Haaino Beljaars)
Re: Free X-Window Server & File System viewer for NT (David Stutes)
----------------------------------------------------------------------------
Date: Tue, 02 Feb 1999 17:36:12 -0500
From: "James D. McIninch" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Strange prob w/telnet
We have several machines w/various kinds of Linux on our net and
one have the following bizarre problem: it does not permit incoming
telnet connections. Before you jump all over this one:
I'm not trying to login as root (I don't even get as far as a
login prompt, attempts to connect simply stall).
/etc/hosts.allow and /etc/hosts.deny are empty so any
connection should be allowed.
/usr/sbin/in.telnetd is exactly where and what it should be.
The inetd.conf entry for telnet is:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
And, /var/log/secure reports that it is turning away connection
requests from host "unknown" (despite the fact that the DNS is
working for the entire network, including, apparently, the
machine refusing the requests).
Other incidental information about the troublesome machine:
RedHat Linux 5.1 w/ kernel 2.0.34 (not 2.0.34-1), using 3com
PCMCIA ethernet (3c574).
Any ideas?
------------------------------
From: "zz" <[EMAIL PROTECTED]>
Subject: RedHat/Kingston KNE110TX NIC
Date: Tue, 2 Feb 1999 22:19:40 -0800
Hello,
I am attempting to get networking installed under RH 5.2, but it seems
that the NIC provided to me by Ma Bell for my DSL connection (Kingston
KNE110TX), is not supported. Does anyone have experience to the contrary?
I can, as an alternative, install a 3Com 3C905 TX (not 3C905b) card, but
it doesn't seem to be RH Tier 1.
Any help in this matter would be sincerely appreciated.
------------------------------
From: [EMAIL PROTECTED] (Ted Potter)
Subject: Re: can not ftp certain file types
Date: Wed, 03 Feb 1999 12:28:11 GMT
Thanks I will give that a shot. Any chance you are able to do what I
can not ?
Robert wrote to Ted:
This is surely wierd. About the only thing I can think is that
the *.exe file contains a modem escape sequence (usually `+++`
by default) at 36kB that causes the modem to drop back into
command mode. When you gzip the file, the escape sequence
is compressed & distroyed.
Try changing or disabling the modem escape sequence by
one of the AT commands.
-- Robert
On Tue, 02 Feb 1999 13:23:45 GMT, [EMAIL PROTECTED] (Ted Potter)
wrote:
>Following up here is some more infomration:
>
>from my win95 box I go to
>www.brownbearsw.com/icalv23.exe
>
>the file starts to download and gets to about 36K and then stops,
>stuck forever.
>
>OK fine. telnet to my linux box and start up lynx
>
>$ lynx www.brownbearsw.com/icalv23.exe
>
>same thing. Starts to download gets to about 36K and then stops.
>
>
>OK fine. telnet to my isp (whom thank goodness runs *nix) use lynx
>and no problem, get the file.
>
>OK fine. ftp to my isp, down the file. Same thing gets to about 36K
>and then stops.
>
>OK fine. telnet to my isp. gzip the file. logout. start ftp, download
>file. Bingo no problem the file comes over.
>
>Thinking it over the separate ftp program offered by Alan is not a
>solution, the above mention site does not run an ftp server.
>
>*sigh* I do hope some kind soul will find my post and offer some
>ideas. I am stuck and of course this week every file I needed was
>compressed with the .exe extension.
>Thanks again!
>
>
>
>
>On Mon, 01 Feb 1999 19:14:54 GMT, [EMAIL PROTECTED] (Ted Potter)
>wrote:
>
>>
>>Thanks for the post, yes it does work! and for my purpose the
>>solution will suffice.
>>
>>However my clients would not likely to be able to cope wit using
>>yet another application to get files off the net.
>>
>>Is it the passive option that makes this program able to transfer
>>files ?
>>
>>Surely people are using my type of setup and able to use just netscape
>>to download files.
>>
>>Anyone else out there have some comments ? - can someone tell me
>>how they do what I am trying to do ? or can anyone else duplicate the
>>problem I am having ?
>>
>>Thanks
>>
>>
>>
>>
>>On Mon, 01 Feb 1999 12:03:53 -0500, Alan Cohen
>><[EMAIL PROTECTED]> wrote:
>>
>>>Had the same problem
>>>Using Terrapin FTP on Windows machine and ended the problem
>>>Did not set up the firewall option in the FTP client and did set the
>>>client to be passive
>>>got the client at www.download.com
>>>
>>>Ted Potter wrote:
>>>
>>>> I have a redhat 5.0 system setup with ipfwadm running. From my windows
>>>> machine I can run netscape and agent just fine. Real Audio works as
>>>> well.
>>>>
>>>> However whenever I attempt to download a file that ends with an .exe
>>>> extentsion the download gets stuck after about 36K
>>>>
>>>> This happens at anysite anytime. So I thought something was wrong with
>>>> my ipfwadm setup.
>>>>
>>>> Using lynx from the redhat machine produces the same problem.
>>>>
>>>> I can download .zip .gz .tar files all day and night.
>>>>
>>>> This problem occures with both http and ftp.
>>>>
>>>> Help!
>>>>
>>>> Can someone tell me what more information I can get in order to
>>>> troubleshoot this problem ?
>>>>
>>>> Thanks
>>>>
>>>> Ted Potter
>>>> [EMAIL PROTECTED]
>>>
>>
>
>
>On Mon, 01 Feb 1999 19:14:54 GMT, [EMAIL PROTECTED] (Ted Potter)
>wrote:
>
>>
>>Thanks for the post, yes it does work! and for my purpose the
>>solution will suffice.
>>
>>However my clients would not likely to be able to cope wit using
>>yet another application to get files off the net.
>>
>>Is it the passive option that makes this program able to transfer
>>files ?
>>
>>Surely people are using my type of setup and able to use just netscape
>>to download files.
>>
>>Anyone else out there have some comments ? - can someone tell me
>>how they do what I am trying to do ? or can anyone else duplicate the
>>problem I am having ?
>>
>>Thanks
>>
>>
>>
>>
>>On Mon, 01 Feb 1999 12:03:53 -0500, Alan Cohen
>><[EMAIL PROTECTED]> wrote:
>>
>>>Had the same problem
>>>Using Terrapin FTP on Windows machine and ended the problem
>>>Did not set up the firewall option in the FTP client and did set the
>>>client to be passive
>>>got the client at www.download.com
>>>
>>>Ted Potter wrote:
>>>
>>>> I have a redhat 5.0 system setup with ipfwadm running. From my windows
>>>> machine I can run netscape and agent just fine. Real Audio works as
>>>> well.
>>>>
>>>> However whenever I attempt to download a file that ends with an .exe
>>>> extentsion the download gets stuck after about 36K
>>>>
>>>> This happens at anysite anytime. So I thought something was wrong with
>>>> my ipfwadm setup.
>>>>
>>>> Using lynx from the redhat machine produces the same problem.
>>>>
>>>> I can download .zip .gz .tar files all day and night.
>>>>
>>>> This problem occures with both http and ftp.
>>>>
>>>> Help!
>>>>
>>>> Can someone tell me what more information I can get in order to
>>>> troubleshoot this problem ?
>>>>
>>>> Thanks
>>>>
>>>> Ted Potter
>>>> [EMAIL PROTECTED]
>>>
>>
>
------------------------------
From: "Jim Orfanakos" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: SurfBoard 1000 Cable Modem
Date: Wed, 3 Feb 1999 07:34:52 -0500
Thanks. I have tried giving the name, as well as tried just to view the
contents of the file with the 't' option...no luck.
danno (nospam_noway) (Dan) <@itn.net> wrote in message
<[EMAIL PROTECTED]>...
>Jim,
>
>try: tar xvf sb1000-1_1_2.tar
>
>The filename must be on the argument line.
>
>Dan
>
>
>On Tue, 2 Feb 1999 18:00:26 -0500, "Jim Orfanakos" <[EMAIL PROTECTED]>
>wrote:
>
>>I have a Surfboard 1000 Cable modem. This is a hybrid system where I use
my
>>modem for the uplink and the cable modem for the downlink.
>>
>>1) Has anyone got this working in Linux?
>>
>>2) I downloaded from my ISP's web site the Linux drivers. The file
>>"sb1000-1_1_2.tar.gz" will uncompress with gzunzip...but I cannot un-tar
the
>>file. When I "tar -xvt" or any one of those options...the tar process
>>hangs.
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: OOB problem
Date: Wed, 03 Feb 1999 12:36:01 GMT
Hello
I have two applications communicating with one another, one running on Linux
(Slakware, kernel v. 2.0.34) and one on Solaris. I have used OOB messages to
implement a signalling protocol that regulates data flow between the two.
A SIGURG signal handler triggers the appropriate actions in each application,
upon reception of an OOB byte.
When the two communicate over a local network, everything works fine.
When I try to get them to talk over PPP and a telephone line (either leased
or dialup), which is what they are meant to do, a strange thing happens:
Right after receiving an OOB on the Linux side, the SIGURG handler is invoked
again (for no apparent reason) and since there is no other OOB byte waiting
to be received, recv() fails with an EAGAIN. If another OOB arrives after
this has happened, it is simply ignored, the signal handler not being invoked
at all. It takes yet another OOB to be sent to the Linux side (normal
in-band data sometimes does the trick too) to get things working again. Note
that the two OOB bytes may be sent with a considerable amount of time in
between, so this is not the case of two OOBs arriving in the same TCP frame,
causing the first one to go unnoticed by the receiver!
A probable explanation of why this happens may have to do with the fact that
the sending TCP will send more than one frame with the urg flag set, in order
to make sure that the receiver is notified of the existence of urgent data.
The receiving side, in this case Linux, is supposed to check the OOB byte
pointer in the frame, so that only a frame that references a new OOB byte
causes the interested parties to be informed of its arrival. It seems that
the buffers involved in the communication over PPP get in the way and the
urg flag / OOB pointer get mixed up in some way, so that the receiving process
is notified twice for some arriving OOB and not at all for the following one.
Using tcpdump, I found that when the double invocation of the SIGURG handler
occurs, two successive packets are delivered with the 'urg' flag. The first
one (obviously the correct one) contains 1 byte -the OOB, no other data is
sent- and has the PUSH flag set (what on earth is the PUSH flag for anyway?).
The second does not have the P flag set and does not contain any data!
Furthermore, tcpdump reports urg 1 for the first packet and urg 0
for the second - I am not sure if 0 and 1 refer to the length of the OOB, its
position, or something else.
Could this be a bug in the Linux TCP stack? (nothing of the kind was ever
observed on my Solaris client)
Does anyone know a solution to my problem?
If anyone does, please post an answer to this message, or mail me directly
at [EMAIL PROTECTED]
Thanks!
Nikos Kolomvos
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: NFS and dynamic IP address
Date: Sun, 31 Jan 1999 07:33:48 -0800
all you need is a steady hostname on the server (or if
the server has a static ip, who cares what your own ip
address is.)
mount srv0:/usr /mnt/usr
if its on a lan, you will probably have a set hostname
too. cool-ness.
*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***
------------------------------
From: Nikos Kolomvos <[EMAIL PROTECTED]>
Subject: OOB problem
Date: Wed, 03 Feb 1999 12:46:47 GMT
Hello
I have two applications communicating with one another, one running on Linux
(Slakware, kernel v. 2.0.34) and one on Solaris. I have used OOB messages to
implement a signalling protocol that regulates data flow between the two.
A SIGURG signal handler triggers the appropriate actions in each application,
upon reception of an OOB byte.
When the two communicate over a local network, everything works fine.
When I try to get them to talk over PPP and a telephone line (either leased
or dialup), which is what they are meant to do, a strange thing happens:
Right after receiving an OOB on the Linux side, the SIGURG handler is invoked
again (for no apparent reason) and since there is no other OOB byte waiting
to be received, recv() fails with an EAGAIN. If another OOB arrives after
this has happened, it is simply ignored, the signal handler not being invoked
at all. It takes yet another OOB to be sent to the Linux side (normal
in-band data sometimes does the trick too) to get things working again. Note
that the two OOB bytes may be sent with a considerable amount of time in
between, so this is not the case of two OOBs arriving in the same TCP frame,
causing the first one to go unnoticed by the receiver!
A probable explanation of why this happens may have to do with the fact that
the sending TCP will send more than one frame with the urg flag set, in order
to make sure that the receiver is notified of the existence of urgent data.
The receiving side, in this case Linux, is supposed to check the OOB byte
pointer in the frame, so that only a frame that references a new OOB byte
causes the interested parties to be informed of its arrival. It seems that
the buffers involved in the communication over PPP get in the way and the
urg flag / OOB pointer get mixed up in some way, so that the receiving process
is notified twice for some arriving OOB and not at all for the following one.
Using tcpdump, I found that when the double invocation of the SIGURG handler
occurs, two successive packets are delivered with the 'urg' flag. The first
one (obviously the correct one) contains 1 byte -the OOB, no other data is
sent- and has the PUSH flag set (what on earth is the PUSH flag for anyway?).
The second does not have the P flag set and does not contain any data!
Furthermore, tcpdump reports urg 1 for the first packet and urg 0
for the second - I am not sure if 0 and 1 refer to the length of the OOB, its
position, or something else.
Could this be a bug in the Linux TCP stack? (nothing of the kind was ever
observed on my Solaris client)
Does anyone know a solution to my problem?
If anyone does, please post an answer to this message, or mail me directly
at [EMAIL PROTECTED]
Thanks!
Nikos Kolomvos
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Problem with connecting in batch mode to ISP (Solved).
Date: Wed, 03 Feb 1999 08:23:19 GMT
In article <794jec$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Clifford Kite) wrote:
> The "escape FF" is seldom good for anything except causing trouble.
> And "asyncmap 0" has the least overhead and most ISP will accept it.
>
> I would check on whether /dev/ttyS0 is the correct device node, and,
> since minicom works, "ls -l /dev/modem" will show the device node to
> which modem points (/dev/modem is usually a link to the real one that
> is used by minicom). If this is OK then I would check to see if the
> IRQ configured for /dev/ttyS0 is the same as the modem actually uses.
> Executing the command "setserial /dev/ttyS0" at the command line will
> show the configured IRQ. Determining the IRQ the modem actually uses
> is up to you.
>
> Another thing you might do is to replace the \rAT with ATZ or ATF or
> ATF1 to reset the modem at the beginning of each ISP call. The \r
> is not sent correctly, you will need to quote it: '\rAT' for the
> carriage return to be sent - although the carraige return is not
> really needed. This hasn't anything to do with the present problem.
Thanks to many helpful suggestions, I was able to fix this.
The two changes I had to make were:
(a) /dev/modem was pointing to /dev/cua0 instead of the tty.
(b) Change the script to the following:
**** Start
exec chat -v \
TIMEOUT 3 \
ABORT BUSY \
ABORT 'NO CARRIER' \
ABORT 'NO ANSWER' \
'' ATZ \
TIMEOUT 40 \
OK ATDP$TELEPHONE \
CONNECT '' \
sername:--sername: $ACCOUNT \
sword:--sword: $PASSWORD \
'\>--\>' ppp
**** End
-Krishnan.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: weird routing/firewall/internet situation. Help?
Date: Tue, 02 Feb 1999 23:32:46 GMT
Hello, world:
My network at home is connected to the Internet via a cablemodem connected to
machine "ns", which is multi-homed and runs a nameserver, a web server, and a
mail server. It uses ipfwadm to proxy this connection to the inside network
172.19.1.X on eth0 and 172.20.1.X on eth1 (eth2 is the cablemodem).
Similarly, another multi-homed machine "workproxy" with inside IP 172.19.1.201
on eth0 is connected via ISDN router on eth1 to my network at work. As I am
only assigned one IP, this connection is also proxied to the other inside
networks.
Everything works except for one thing: the services that run on machines at
work which are outside of or allowed through the firewall - http, snmp, and
telnet. When, for example, I (or anyone at work) tries to access my web
server, the connection is made through the office's web proxy over the
internet and is received at my end. However, the connection isn't completed:
(me) (work)
tcp 0 1 xxx.xxx.67.123:80 xxx.43.254.220:2602 SYN_RECV
For the return trip, it's following my routing instructions that send traffic
to that network through the ISDN proxying machine. Since the machines that
handle the web, mail, and telnet connections aren't accessible from the
inside network, it never gets there. I've tried setting a route to those
specific hosts through the internet-proxying machine, both through its IP
address, its interface name, and both, and with a lower metric, but no luck.
Anyone have any suggestion or experience with something like this?
Thanks
Kevin
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Jason Rigsbee" <[EMAIL PROTECTED]>
Subject: Slackware Install over TCP/IP
Date: Wed, 3 Feb 1999 08:34:30 -0500
Which HowTo will tell me how to install Slackware over TCP/IP? I have a pc
that has NT installed with a NTFS and FAT16 partitions. I want to install
linux FROM the FAT16 partition to another pc that is connected to the NT box
via Ethernet. The Linux Installation HowTo states that this can be done,
but does not provide a solution.
Any help in this matter would be greatly appreciated.
Thank you.
Jason
------------------------------
From: Haaino Beljaars <[EMAIL PROTECTED]>
Subject: 3c900B
Date: Wed, 03 Feb 1999 14:40:01 +0100
Reply-To: [EMAIL PROTECTED]
Hi,
can anybody tell me if the 3c900B is supported by the 3c59x module?
ps. don't post answer in the newsgroup but reply it directly to me.
Thanx
Greetings,
Haaino Beljaars
------------------------------
From: [EMAIL PROTECTED] (David Stutes)
Subject: Re: Free X-Window Server & File System viewer for NT
Date: Wed, 03 Feb 99 12:49:54 GMT
In article <7994a6$vjk$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Hi! Can anybody help me in finding: a) a free X-Window Graphic Server for
>Windows NT (not XWin32, it's shareware) b)
I have used a free X-server from http://www.microimages.com
It is simple, but works well.
Dave Stutes
Ohio State University
David Stutes 2-3850
Ohio State University [EMAIL PROTECTED]
Colege of Biological Sciences
------------------------------
** 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
******************************
