HDTenEightyP/NetNews huggingface dataset:
From: burch@seas.smu.edu (Chris Burchett)
Subject: Help! (75 seconds to connect() after reboot)
Organization: SMU - School of Engineering & Applied Science - Dallas
Distribution: usa
Date: Wed, 6 Jan 1993 19:14:11 GMT

Help!  I've found a situation in which I'm unsure of the best 
solution.  The problem has to do with a 75 second timeout in the 
connect() system call.  This occurs after one of two previously
connected machines is rebooted and an attempt is subsequently
made to reestablish communication.

I am using TCP/IP via Berkeley sockets to communicate between a Sun
workstation and an embedded system running VxWorks.  After communi-
cation is established, the embedded system is rebooted.  Once the
reboot is finished an attempt is made to reestablish the connection,
at which point, the connect() system call on the embedded system is
unable to reconnect and times out after 75 seconds.  

I believe this may happen because the embedded system is using the 
same port number that was used for a connection before the reboot 
occured (while the remote machine still maintains an established 
connection on that port).  It appears that (after a reboot) if the 
embedded system attempts to connect() using a port number which was
not previously connected, the connection is immediately established; 
this is the desired behavior.  However, if the embedded system uses 
a port which was previously connected, the connect() system call 
times out after 75 seconds.

Unfortunately, in my application 75 seconds is somewhat too long 
to wait.  I have a potential work around, but it seems to be
sort of a kludge and I felt certain that this problem must be a 
known one with known solutions.  (I'm relatively new to NEWS and if
this is a topic which has already been discussed in depth or I have
improperly used this service in any way, I appologize.)  But if 
someone with insight into this problem would enlighten me on the 
issues involved, or documentation to be studied, or potential 
solutions, I would greatly appreciate the help.


Chris Burchett
email: burch@seas.smu.edu
voice: (214) 205-8065
Newsgroups: comp.os.vxworks
From: hjb@netcom.com (H. J. Bae)
Subject: Re: Forwarding of MAC broadcasts
Organization: Peaceful Star, Inc.
Date: Sun, 10 Jan 1993 14:04:15 GMT

In article <C0MBsq.EBL@waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:
>I just read Hwa Jin's response to this and I think I have a glimmering of
>an explaination.
>
>Note that the _MAC_ address is a broadcast and the _IP_ address is not.
>Now, one of the (many) failings of BSD 4.3 network code is the fact that
>the "broadcastness" of the incoming frame is lost once you get into IP
>protocol code. If the IP address is not broadcast, whether legitimately so
>or as a result of a misunderstood subnet broadcast (due to incorrect or no
>subnet mask), IP will forward if so configured. Of course, it REALLY should
>NOT be forwarded because the MAC address was broadcast - information that
>BSD 4.3 Tahoe quietly throws away.
>
>BSD Networking Release 2 code nicely fixes this (I'm not sure whether Reno
>code does or not, but it may).


as always, ted is quite correct about this.  [ah... so that's what
that datalink bcast flags/stuff was all about in net2 code, silly me]
of course, if things are done "correctly" (correct subnet masks,
correct ip broadcast addr derived from subnet mask, etc.) the problem 
should not occur.  thanks.


hwajin

-- 
Peaceful Star Project	hjb@netcom.com
2899 Ford Street	Available for peaceful, responsible work only.
Oakland, CA 94601	(510) 536-7607
From: dog@xdev.sunspot.noao.edu (Fritz Stauffer)
Newsgroups: comp.os.vxworks
Subject: vxWorks Sockets and Pipes
Date: 12 Jan 93 20:19:21 GMT
Organization: Computer, Hardware and Observatory Support

I am porting pdtar to vxWorks.  It works on local disk
systems just fine.  Now, I am writing the remote transfer
stuff.  I spawn a task which creates a pipe to
replace the tar file descriptor.  The spawned task
runs rcmd to 'dd' on a unix host for the remote I/O.
There are two problems.  

1) writing to a vxWorks pipe returns an ERROR if the pipe is full.
Is there a way to block I/O when the pipe is full, or do I need to use
message queues?  

2) writing large files on the vxWorks target to the socket to output 
on the unix host uses all of the memory up and crashes.  This is 
because the socket write buffers data in memory.  This is okay for 
small tar files, but fails on large tar files.  Is there a way to 
wait for the socket buffers to flush, or to get a socket status as 
to how much buffer is left, or any other feedback?

Thanks for any ideas.

Fritz Stauffer, Sac Peak Observatory
From: Roeber <fjr@ssd.ray.com>
Newsgroups: comp.os.vxworks
Subject: re:  text editor for VxWorks ?
Date: Fri, 8 Jan 1993 08:14:32 -0500
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Jeff Price writes:

>  Rumor has it that there are some text editors out there in the ether
>  somewhere that run under VxWorks.  I have even heard that a copy the
>  beloved "vi" editor exists for VxWorks. 
>  
>  Can anyone confirm or deny these rumors, and if they are true 
>  where might one get one of these ?

The VxWorks archive has a copy of stevie in it (a vi clone).  Sorry but I
haven't used it under VxWorks but it is probably what you want.   Fred

----------

Subject: Monthly VxWorks archive posting

Submitted-by thor@thor.atd.ucar.edu  Tue Dec 31 22:59:28 1992
Submitted-by: thor@thor.atd.ucar.edu (Richard Neitzel)

This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:


-rw-r--r--  1 thor        41196 Oct 16 09:43 stevie01
-rw-r--r--  1 thor        35279 Oct 16 09:43 stevie02
-rw-r--r--  1 thor        35278 Oct 16 09:43 stevie03
-rw-r--r--  1 thor        35012 Oct 16 09:43 stevie04
-rw-r--r--  1 thor        34502 Oct 16 09:43 stevie05
-rw-r--r--  1 thor        37476 Oct 16 09:43 stevie06
-rw-r--r--  1 thor        30073 Oct 16 09:43 stevie07
-rw-r--r--  1 thor        31562 Oct 16 09:43 stevie08
-rw-r--r--  1 thor        37360 Oct 16 09:43 stevie09
-rw-r--r--  1 thor        20662 Oct 16 09:43 stevie10
-rw-r--r--  1 thor        25717 Oct 16 09:43 stevie11
-rw-r--r--  1 thor        28075 Oct 16 09:43 stevie12
-rw-r--r--  1 thor        31852 Oct 16 09:43 stevie13
From: thoff@netxwest.com (Todd Hoff)
Newsgroups: comp.os.vxworks
Subject: Problem with broadcasts
Date: Thu, 7 Jan 93 14:46:44 PST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

I'm having problems sending broadcasts over our network and
would like some help. 

The code that works on just a Sun network doesn't work under VxWorks,
and neither does the VxWorks demo code-- just to show I'm not totally
stupid :-)

The test involves 2 machines X and Y. Some vitals are specified below.
When I send directly from X to Y then Y receives the message, no problem.
When I send to a broadcast address of 144.10.5.255 the message doesn't
arrive. The reciever is setup to recieve for any address. I set the
socket option for BROADCAST to on.

Any ideas?
Any good debugging tips?

Thanx for any help.

There is a Sun router on the network with an IP address of 144.10.2.6.

The interface definition for machine X is:
ln (unit number 0):
     Flags: (0x63) UP BROADCAST ARP RUNNING
     Internet address: 144.10.5.33
     Broadcast address: 144.10.5.255
     Netmask 0xffff0000 Subnetmask 0xffffff00
     Ethernet address is 00:c0:21:01:02:21
     Metric is 0
     Maximum Transfer Unit size is 1500
     3633 packets received; 868 packets sent
     0 input errors; 0 output errors
     0 collisions

Machine Y is the same accept the IP address is 144.10.5.63.

Our route table is:
ROUTE NET TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
0.0.0.0          144.10.5.2       3      2       746           ln0
144.10.0.0       144.10.5.33      1      2       137           ln0
------------------------------------------------------------------------

ROUTE HOST TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
127.0.0.1        127.0.0.1        5      0       0             lo0


Newsgroups: comp.os.vxworks
From: sapp@falcon.ssc.gov (Kevin Sapp)
Subject: RPC's
Originator: sapp@sawdust.ssc.gov
Organization: Superconducting Super Collider Laboratory, Dallas
Date: Thu, 7 Jan 1993 14:32:48 GMT

Greetings,

I have been working with VxWorks for a couple of weeks now, so I,m
at the dangerous stage !

I have RPC's working between a Sparc2 and a VxWorks MVME147, but only
at the shell.  When I execute the RPC server directly from the shell
everything works fine.  When I do a taskSpawn 100,0,20000,myRpcTest
the program dies down in the pmap_unset function during an indirect
function call off of (a1), the address that it is trying to call 
causes a bus error.

When doing the rpcgen I used the sun rpcgen to produce the client, server,
and .h files for both the sun and vxworks (is this OK?).

Any halp would be appreciated.

Also, is there a FAQ for this group? Where?
Is there a mail list ? How?

Thankx
Kevin.

-- 
----------------------------------------------------------------------------
Kevin A. Sapp                    "A civilization depends upon the quality
Superconducting Super Collider    of individual it creates"   (Dune)
sapp@sawdust.ssc.gov :>( please NO NeXT mail                   
Newsgroups: comp.os.vxworks
From: geger@phantom.den.mmc.com (George Eger (303) 971-6974)
Subject: mv167/vmechip2 dma library
Keywords: mv167 vmechip2 dma
Organization: Martin Marietta Astronautics Group
Date: Fri, 8 Jan 1993 17:15:13 GMT

Has anyone out there got a basic library to run the vmechip2's dma controller
on a mv167?  I am looking for something like:

	dmaInit();
	dmaGet(to, from, length);
	dmaPut(to, from, length);

and an optional routine to set non-blocking, completion notification,
bus priority levels and modes, and abort:

	dmaIoctl(...);

If not, we are going to build one and will post it.

Thanks,

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Fault Tolerant Avionics         ||   Fax   - (303) - 977 - 1145         ||
||Launch Systems                  ||   MS T320                            ||
||Martin Marietta Astro Group     ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================
Xref: sparky comp.os.vxworks:1170 comp.unix.bsd:10975 comp.protocols.tcp-ip:5829
From: hwajin@iphasew.com (Hwa-Jin Bae)
Newsgroups: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip
Subject: Re: Help! (75 seconds to connect() after reboot)
Date: 6 Jan 93 23:44:22 GMT
Distribution: usa
Organization: Interphase West, Santa Clara, CA

In article <1993Jan6.191411.4535@seas.smu.edu> burch@seas.smu.edu (Chris Burchett) writes:
>Unfortunately, in my application 75 seconds is somewhat too long 
>to wait.

in vxworks 5.0+, there is an undocumented call -- connectWithTimeout() which
takes the same args as connect() plus extra last arg of type 'struct timeval *'
which you may be able to use -- you can specify the delay of your own.

or you could also just try non-blocking connect() -- set socket FIONBIO
temporarily, call connect(), which should return EINPROGRESS immediately
if connect attempt is to block -- when this happens you should select()
for 'write'.  the socket will be marked writeable once's it's connected.
to verify the connection after select() returns with 'write' selected, you
can do a getpeername().  this is actually what connectWithTimeout() does.
[ i do hope this is still in vxworks, it was a few years back when i put this
into the system ]

hwajin
Xref: sparky comp.os.vxworks:1198 comp.sys.sgi:18724
From: davea@quasar.mti.sgi.com (David B.Anderson)
Newsgroups: comp.os.vxworks,comp.sys.sgi
Subject: Re: sgi CC v3.1 & VxGDB incompatible
Date: 13 Jan 93 00:05:56 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1993Jan12.101638.901@nrlvx1.nrl.navy.mil> dyer@nrlvx1.nrl.navy.mil (Doug Dyer) writes:
>Hi folks,
>
>	I am using an SGI indigo r3000 as a vxworks host
>(Iris 4D1-4.1) with cc (v3.10)  and VxGDB to debug software (v1.1).  
>The following problems occur when I load a file into the debugger:
>
>if the source code has a "struct" in it :
>	unknown symbol type 1a 
>if the source code has a "union" in it:
>	unknown symbol type 1b

Let me make a guess: those numbers are hex and are the st* value from
the symbol table.  0x1a === 26

The sgi-generated symbol tables have 3 new values as compared with
those from pre-merger-MIPS & DEC:

From /usr/include/symconst.h:
#ifdef __sgi
#define stStruct        26      /* begin Struct kind of stBlock */
#define stUnion         27      /* begin Union kind of stBlock */
#define stEnum          28      /* begin Enum  kind of stBlock */
#endif


These are to be treated just like an stBlock except that they are
specific and specify the *type* of the block.

Anywhere in GDB it tests for stBlock, simply look for any of
	stBlock stStruct stUnion stEnum
(though of course those new ones only apply to data, not code blocks,
you need not worry about that since the new ones never appear on
code blocks).

You may find that this information is of use to gdb.

Hope this helps.  This answer *is* just a guess....
[ David B. Anderson             (415)390-4263             davea@sgi.com ]
From: Dave Kim <calypso@palantir.gsfc.nasa.gov>
Newsgroups: comp.os.vxworks
Subject: Gnu assember manual
Date: Wed, 6 Jan 93 09:22:56 -0500
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Hello everyone,
I am looking for a good manual for gnu assembler manual, preferably one that is better
 than the one offered by WRS.  I am an new comer to 68xxx assembly programming and
 having to port an assembly program written under PDOS operating system to VxWorks.
If anyone out there have a good gnu as manual with examples and can share, I would 

appreciate it.

In the mean time, can anyone help me convert following PDOS assembly code to gnu as:

LEA   0(A4,D1.W),A1


Please send any response to calypso@palantir.gsfc.nasa.gov

Thank you in advance.
David Kim



ps: I have already got gnu as distribution ftp files from MIT and found manuals are not part
of the distribution.

 
Newsgroups: comp.os.vxworks
From: hjb@netcom.com (H. J. Bae)
Subject: Re: More on broadcast problem
Organization: Peaceful Star Project
Date: Sun, 10 Jan 1993 18:40:53 GMT

In article <9301081857.AA11564@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes:
>The suggestion here is that code resolving IP addresses isn't looking
>at the subnet mask. Is seems the broadcast IP address is not recognized
>as such and is forwarded to the router where the router
>of course will not forward the broadcast.

here's in_broadcastaddr() from the tahoe code:

/*
 * Return 1 if the address might be a local broadcast address.
 */
in_broadcast(in)
	struct in_addr in;
{
        register struct in_ifaddr *ia;
        u_long t;

        /*
         * Look through the list of addresses for a match
         * with a broadcast address.
         */
        for (ia = in_ifaddr; ia; ia = ia->ia_next)
            if (ia->ia_ifp->if_flags & IFF_BROADCAST) {
                if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == in.s_addr)
                     return (1);
                /*
                 * Check for old-style (host 0) broadcast.
                 */
                if ((t = ntohl(in.s_addr)) == ia->ia_subnet || t == ia->ia_net)
                    return (1);
        }
        if (in.s_addr == INADDR_BROADCAST || in.s_addr == INADDR_ANY)
                return (1);
        return (0);
}


the only reason this could fail would be some incorrect configuration
some where (at some participating node).  if you're suspecting vxworks
for not recognizing subnet bcast ip address as such, you can call
in_broadcast from the shell or write a small piece of code to find out.
using the shell's built-in debugger (assembly) you could single step
to track down the exact behavior, if you'd like.  but, as the code says,
if netif bcast ip address is incorrectly set on some node, this code
will return 0.

if you have a traditional network (the one that has one network/subnet
per physical segment of ethernet) and your target machine is not
multi-homed, it is also legal to use all 1's ip address to indicate
"broadcast to the immediately attached networks only".  trying
"255.255.255.255", for example, should work and you can avoid
the headaches.

the issue regarding the route entry:  ip_output() has to be able to
resolve the route entry for the given destination address -- to
fetch the netif pointer used throughout (including arpresolve process
which uses in_broadcast before actually sending out any arp req's).
i'd still maintain that you need to keep correct route tables for
the subnets.  given that, and given that the correct netif (which
will be in the route entry returned by rtalloc) has correct broadcast
address proper for the subnet, things should work.  all participating
machines should be checked for this. [as i'm not still sure of your
exact configuration]

if someone has any insight, i'm very interested to hear...  [guess
i'm just very very curious....  :-) ]  thanks

hwajin

-- 
Peaceful Star Project	hjb@netcom.com
2899 Ford Street	Available for peaceful, responsible work only.
Oakland, CA 94601	(510) 536-7607
Newsgroups: comp.os.vxworks
From: gday@ignatz.inde.bc.ca (Gordon Day)
Subject: Looking for contact info for IBM/PC based realtime o/s vendors
Organization: INDE Electronics, Inc.
Distribution: comp
Date: Wed, 6 Jan 1993 00:00:29 GMT

The Subject: line says it all.  I am currently looking for any
information I can get on available realtime o/s' based on the 80386
ISA bus IBM/PC platform.  Any contact addresses or recommendations
(for or against) would be _greatly_ appreciated.  This is a new area
for me (being primarily a Unix programmer) so I have no idea where to
start looking.  Some products I already have in mind (but no contact
addresses) are:

VXworks -- I know this is available for 68000-based systems, but IBM/PCs?
iRMX    -- available for IBM/PC
QNX     -- available for IBM/PC

Others?

Ta,

Gordon.

P.S.: I _will_ summarise if there is interest.

_______________________________________________________________________________
gordon day, inde electronics, +1-403-430-1446.
From: billb%kuwait@sun.com (Bill Baumann)
Newsgroups: comp.os.vxworks
Subject: Forwarding of ... & stupidness
Date: Thu, 7 Jan 93 17:57:30 CST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Forget that last message.  My mailer got out of control.

Please respond to the MAC broadcast question to baumann@gdwest.gd.com

thanks BillB.

Newsgroups: comp.os.vxworks
From: rypma@waterloo.hp.com (Ted Rypma)
Subject: Re: Forwarding of MAC broadcasts
Date: Sun, 10 Jan 1993 03:17:14 GMT
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: TIN [version 1.1.4 PL6]

Bill Baumann (billb%kuwait@sun.com) wrote:
: VxWorks is causing problems by forwarding broadcast messages.
: 
: Here's the deal : I have a development system that is broadcasting over
: FDDI to a specific IP address.  The IP address is a Unix box, and the
: FDDI MAC address is a broadcast.  I'm using the AP Labs driver.

I just read Hwa Jin's response to this and I think I have a glimmering of
an explaination.

Note that the _MAC_ address is a broadcast and the _IP_ address is not.
Now, one of the (many) failings of BSD 4.3 network code is the fact that
the "broadcastness" of the incoming frame is lost once you get into IP
protocol code. If the IP address is not broadcast, whether legitimately so
or as a result of a misunderstood subnet broadcast (due to incorrect or no
subnet mask), IP will forward if so configured. Of course, it REALLY should
NOT be forwarded because the MAC address was broadcast - information that
BSD 4.3 Tahoe quietly throws away.

BSD Networking Release 2 code nicely fixes this (I'm not sure whether Reno
code does or not, but it may).

We had the same problem in VxWorks 5.0.3 network code causing problems when
multiple subnets were in use on the same wire - we would forward another
subnet's broadcasts. I fixed this in our VxWorks networking code by just not
forwarding frames which would be retranmitted on the same interface on which
they came in. Not an ideal solution, but it looked after the immediate problem
(besides, we don't claim to be an ideal IP router and we're not a
workstation :-).

Regards,

Ted Rypma
HP Panacom Division
From: jcreem@Rapnet.Sanders.Lockheed.Com (Jeffrey M. Creem x5700)
Newsgroups: comp.os.vxworks
Subject: Booting from tape
Keywords: SCSI, booting, tape
Date: 7 Jan 93 16:30:57 GMT
Organization: Sanders Associates


Has anyone tried booting vxWorks from a SCSI tape (in our case exabyte
8500) on a mv167? We are currently exploring several boot options and are
trying to come up with the best method.

Jeff Creem
Newsgroups: comp.os.vxworks
From: hjb@netcom.com (H. J. Bae)
Subject: Re: Problem with broadcasts
Organization: Peaceful Star, Inc.
Date: Sat, 9 Jan 1993 09:40:29 GMT

In article <9301072246.AA11015@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes:
>The interface definition for machine X is:
>ln (unit number 0):
>     Flags: (0x63) UP BROADCAST ARP RUNNING
>     Internet address: 144.10.5.33
>     Broadcast address: 144.10.5.255
>     Netmask 0xffff0000 Subnetmask 0xffffff00
					^^^^^^^^^^^



>
>Our route table is:
>ROUTE NET TABLE
>destination      gateway          flags  Refcnt  Use           Interface
>------------------------------------------------------------------------
>0.0.0.0          144.10.5.2       3      2       746           ln0
>144.10.0.0       144.10.5.33      1      2       137           ln0
>------------------------------------------------------------------------
>


trying adding a net route entry for 144.10.5.0 subnet?


hwajin
From: jcn@mpl.ucsd.edu (Chris Nickles)
Newsgroups: comp.os.vxworks
Subject: re:  performance of fprintf() for floating point
Date: Tue, 12 Jan 93 08:28:24 PST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


Another approach, if you don't mind a little nitty-gritty, would be
to scale the data as an integer in small units, e. g. tenths or
hundredths of a degree, and then stuff a dot into the output string.

	Chris Nickles
	UCSD Marine Physical Lab
From: tzou@almaden.ibm.com (Shin-Yuan Tzou)
Newsgroups: comp.os.vxworks
Subject: database for VxWorks
Keywords: vxworks, database, vendor software
Date: 6 Jan 93 01:29:17 GMT
Reply-To: tzou@almaden.ibm.com (Shin-Yuan Tzou)
Organization: IBM Almaden Research Center

Are there vendors that provide database software for VxWorks?

Thanks,
Shin-Yuan Tzou
tzou@almaden.ibm.com