| Greetings!
I almost got back everthing I wanted from Mitch although he left off the
output from running UCX$VERSIONS.EXE, (I've asked again). I had done some
research on the recvfrom() function call and per the online help for the error
(i.e. %system-f-ivbuflen), this is a device-specific error. Much prowling
around in COMETS and the UCX conference didn't help.
From what I can see, the failure mode is exhibited when he specifies the
"struct sockaddr *from" argument as NULL. According to the documentation on
the recvfrom() function:
If "from" is nonzero, the address will be returned. If from is 0,
the address will not be returned.
If I interpret the above correctly, I don't believe specifying "from" as NULL
should produce an error (which is the case Mitch demonstrates below). If any
of you "C" gurus care to take a look at the code snippet below and make sure
he has set up the call to recvfrom() correctly, I'd be oblidged...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
P.S. Here is the reply I got back from the customer:
From: DECPA::"[email protected]" "Mitch Bollus" 14-MAR-1997 17:08:58.32
To: amcucs::swierkowski
CC: [email protected]
Subj: [[email protected]: Your ASAP call re: UCX & the recvfrom() function call...]
Greetings!
Tony Swierkowski @ Digital here with some more questions re: the call you
logged with the ASAP Hotline. I've done some preliminary research in an in-
ternal UCX support conference as well as some prowling around in a bug reporting
database but didn't see anything that jumped out at me. However I do have a
question and I'd like to get more detailed configuration information.
1) Have you installed any patches to UCX V4.1?
.. behavior was exhibited on ucx 3.3 and ucx 4.1
2) Please send me the output from $ RUN SYS$SYSTEM:UCX$VERSIONS.
.. if you really need this i can get it
3.) Please send me a code snippet with the actual call to recvfrom() in it.
static void
ft_socket_receive(Opaque unused1, int source, EvmIoId unused2)
{
# define FT_SOCK_BUFLEN sizeof(struct heartbeat)
int len, maxlen = -1;
unsigned int fromlen = 0;
char buf[FT_SOCK_BUFLEN];
char buf1[16];
struct sockaddr_in fromaddr;
#ifndef TIBOS_WIN
errno = 0;
#endif
fromlen = sizeof(struct sockaddr_in);
memset(&fromaddr,0,fromlen);
---->> the following works fine ........
while((len = recvfrom(source, buf,FT_SOCK_BUFLEN, 0,
(struct sockaddr*)&fromaddr, &fromlen)) > 0)
---->> the following gives the invalid buff error .....
/*while((len = recvfrom(source, buf,FT_SOCK_BUFLEN, 0, NULL, &fromlen)) > 0)
*/
{
maxlen = max(len, maxlen);
}
if (maxlen <= 0)
{
perror(":recvfrom");
return;
}
4) Can you send me a log file with the actual error output you're seeing?
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: Feed Sources Supported:
97/03/14 16:48:15: GSM: RSF, index = 0
97/03/14 16:48:15: GSM: TELERATE, index = 1
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: Queue_all_fixed_subjs(): # 0
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: GSM is synchronizing with feed handlers. Please wait.
ft_takeover: Takeover complete in 108 ms.
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
Cheers...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
P.S. For your reference, your call # is 1997-3326
------- End of forwarded message -------
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail1.digital.com by mts-gw.pa.dec.com (5.65/09May94) id AA19756; Fri, 14 Mar 97 17:05:35 -0800
% Received: from splash.tibco.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA10539; Fri, 14 Mar 1997 17:00:23 -0800
% Received: by flash.tibco.com (4.1/1.37) id AA20136; Fri, 14 Mar 97 16:56:32 PST
% Received: from tssgate.tibco.com(160.101.20.20) by flash.tibco.com via smap (V1.3) id sma020133; Fri Mar 14 16:56:24 1997
% Received: from celtics.23net by tekbspa.tibco.com (4.1/SMI-4.1) id AA23225; Fri, 14 Mar 97 16:56:22 PST
% Received: by celtics.23net (SMI-8.6/SMI-SVR4) id QAA01917; Fri, 14 Mar 1997 16:56:21 -0800
% Date: Fri, 14 Mar 1997 16:56:21 -0800
% Message-Id: <[email protected]>
% From: Mitch Bollus <[email protected]>
% To: amcucs::swierkowski
% Cc: [email protected]
% Subject: [[email protected]: Your ASAP call re: UCX & the recvfrom() function call...]
|
| Greetings!
I did get back the output from UCX$VERSIONS.EXE that I asked for (again) and
have crafted a note (#5392.0 in the UCX conference) with all the details. I'm
awaiting a response to this note and will update Mitch when/if I get something
back, cheers...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
P.S. Here is the base note I posted in the UCX conference...
From: AMCUCS::SWIERKOWSKI "Quot homines tot sententiae" 31-MAR-1997 11:16:04.30
To: swierkowski
CC: SWIERKOWSKI
Subj: Note re: recvfrom() call and "%SYSTEM-F-IVBUFLEN" error...
<<< LASSIE::UCXAXP$DKA0:[NOTES$LIBRARY]UCX.NOTE;1 >>>
-< DEC TCP/IP Services for OpenVMS >-
================================================================================
Note 5392.0 recvfrom() call and "%SYSTEM-F-IVBUFLEN" error... No replies
AMCUCS::SWIERKOWSKI "Quot homines tot sententiae" 206 lines 31-MAR-1997 14:19
--------------------------------------------------------------------------------
Greetings!
Environment:
------------
$ UCX SHOW VERSION
DEC TCP/IP Services for OpenVMS AXP Version V3.3
on a AlphaServer 2100A 5/300 running OpenVMS V6.2-1H3
Operating System: OpenVMS Alpha V6.2
Problem Description:
--------------------
I'm helping a partner with a problem that he is having with the recvfrom()
function call. He wants to understand the use and abuse of last two arguments
(i.e. "from" and fromlen"). He is seeing the symptoms on both UCX V3.3 and
V4.1 (full output from UCX$VERSIONS.EXE on his UCX V3.3 system is below).
Per the "DEC TCP/IP Services for OpenVMS System Service and C Socket Program-
ming" manual, the "from" argument is described as:
...
from is a buffer where recvfromplaces the address (structure)
of the socket from which the data is received.
If from is nonzero, the address will be returned. If from is 0,
the address will not be returned.
...
What he is seeing is that if he specifies the "from" argument as NULL, then
he gets an "invalid buffer length" error. I asked him for a code snippet and
the sample error output along with the output from UCX$VERSIONS.EXE. Here is
the code snippet he provided:
<--- begin code snippet --->
static void
ft_socket_receive(Opaque unused1, int source, EvmIoId unused2)
{
# define FT_SOCK_BUFLEN sizeof(struct heartbeat)
int len, maxlen = -1;
unsigned int fromlen = 0;
char buf[FT_SOCK_BUFLEN];
char buf1[16];
struct sockaddr_in fromaddr;
#ifndef TIBOS_WIN
errno = 0;
#endif
fromlen = sizeof(struct sockaddr_in);
memset(&fromaddr,0,fromlen);
---->> the following works fine ........
while((len = recvfrom(source, buf,FT_SOCK_BUFLEN, 0,
(struct sockaddr*)&fromaddr, &fromlen)) > 0)
---->> the following gives the invalid buff error .....
/*while((len = recvfrom(source, buf,FT_SOCK_BUFLEN, 0, NULL, &fromlen)) > 0)
*/
{
maxlen = max(len, maxlen);
}
if (maxlen <= 0)
{
perror(":recvfrom");
return;
}
<--- end code snippet --->
Here's the sample error output he provided:
<--- begin sample error output --->
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: Feed Sources Supported:
97/03/14 16:48:15: GSM: RSF, index = 0
97/03/14 16:48:15: GSM: TELERATE, index = 1
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: Queue_all_fixed_subjs(): # 0
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: GSM is synchronizing with feed handlers. Please wait.
ft_takeover: Takeover complete in 108 ms.
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
<--- end sample error output --->
Here's the detailed version information from SYS$SYSTEM:UCX$VERSIONS.EXE he
provided on his UCX V3.3 system (symtoms are the same on a V4.1 system):
<--- begin output from UCX$VERSIONS.EXE --->
$ RUN SYS$SYSTEM:UCX$VERSIONS
DEC TCP/IP Services for OpenVMS AXP Version V3.3
on a AlphaServer 2100A 5/300 running OpenVMS V6.2-1H3
Image Name Image ID Link Date Location
BGDRIVER UCX V3.3-7 4-MAY-1995
SYS$COMMON:[SYS$LDR]
UCX$INETACP UCX V3.3-7 4-MAY-1995 SYS$COMMON:[SYSEXE]
INETDRIVER UCX V3.3-7 18-APR-1995
SYS$COMMON:[SYS$LDR]
UCX$INET_ROUTING UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$UCXCP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$ACCESS_SHR UCX V3.3-7 4-MAY-1995 SYS$COMMON:[SYSLIB]
UCX$IPC_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$PING UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$PORTMAPPER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
SNMP_AGENT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
TELNETCLIENT UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$TELNETSYM UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
TNDRIVER UCX V3.3-7 26-APR-1995
SYS$COMMON:[SYS$LDR]
RLOGINCLIENT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
RSHCLIENT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$RCP UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$TRACE UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$MSG UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSMSG]
UCX$RPCINFO UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$RPCXDR_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$PWIPDRIVER UCX V3.3-7 18-APR-1995
SYS$COMMON:[SYS$LDR]
UCX$PWIPACP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$PWIPSHUT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX1$SDA UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$BIND_SERVER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$BIND_SERVER_XFER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$NSLOOKUP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
NFS_SERVER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$CFS_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$DNFSMOUNT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$DNFSDISMOUNT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$DNFSDRIVER UCX V3.3-7 18-APR-1995
SYS$COMMON:[SYS$LDR]
UCX$DNFSACP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
PCNFSD UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
FTPCLIENT UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
FTPC UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
FTPD UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPD_RCV UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
LPD_SMB UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPQ UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPRM UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPRSETUP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
LPD_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$SMTP_RECEIVER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$SMTP_SYMBIONT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
SMTP_MAILSHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$SMTP_PARSESHR_TV UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$UUENCODE UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$UUDECODE UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
TFTP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
BOOTP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$NTPD UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
<--- end output from UCX$VERSIONS.EXE --->
I researched this in this conference and in COMETS and nothing with this error
output jumped out at me (note 936.* does demonstrates the "%system-f-ivbuflen"
error, but in conjunction with the getsockopt() call on a UCX V2.0 system). I
saw no other references to the "%system-f-ivbuflen" error in conjunction with
the recvfrom() call on UCX V3.3 (or V4.1 for that matter.) I've gone through
the release notes for ECO 1, 2 & 4 on UCX V4.1 and found no reference to this
sort of problem and per the customer he hasn't installed any ECO's on his UCX
V4.1 environment. I don't remeber enough about UCX V3.3 to know if the above
output from UCX$VERSIONS.EXE shows one or more ECO kits has been applied or not.
I don't understand the code snippet well enough to see anything obviously
wrong in the way he is using recvfrom(), but the customer doesn't believe he
has made a fundamental programming error. FWIW, I did not that in all the
sample programs I've compared his code to, they do have one thing in common:
they *ALWAYS* specify the "from" argument as non-NULL. His failure mode is
only exhibited when the "from" argument is NULL, but if I understand the
documentation this should be okay. I'd sure appreciate any help on this, I
have no idea what to try or suggest next. If you need more information, please
call, send email or reply to this note, cheers...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
|