QNX 6.1a socket problem when porting UCD4.2.3

QNX Newsgroups (Archives) qdn.public.qnxrtp.porting
1

Hello,

I am currently attempting to port ucd-snmp 4.2.3 to QNX6.1a RTOS. I am
experiencing difficulties however, and I wondered if anyone had any ideas as
to what might be the problem.
Basically, I am getting my snmp packets corrupted (or discarded?), and I am
lost for any explanation why, except that QNX is corrupting them! I know
that this seems absurd, but I have been debugging the source code for
Ucd-snmp over and over again,
and when I examine the data just after recvfrom() is called, the memory
space where the data is meant to be put is not being written to, although
snmp packets are being received.
Basically the code does the following:

creates a socket using:

sd = socket(AF_INET, SOCK_DGRAM, 0);

binds the socket to port 161 using:

bind(sd, (struct sockaddr *)&me, addr_size) // The struct
sockaddr me has sin_addr.s_addr set to INADDR_ANY

// and sin_port set to htons(161), and sin_family set to AF_INET.

receives packets from the socket using:

length = recvfrom(sd, (char *)packet, PACKET_LENGTH, 0,
(struct sockaddr *)&from, &fromlength); //
PACKET_LENGTH = 8 * 1024

Note: there is other code between the bind and receivefrom, but the socket
descriptor is not modified between the two function calls.
When I examine “packet” immediately following recvfrom(), it does not
contain the data that it should (I have confirmed that the correct data is
actually arriving at the port).
Have you ever heard of anything like this before? The snmp applications
supplied with QNX work - maybe the ucd-snmp code makes some different calls
to the kernel that cause this?

Any help on this matter would be greatly appreciated :slight_smile:.

Regards,

Tana Isaac

2

There was a bug in the stack for a while where if the
last argument to recvfrom() was less on return from the
function than the value you passed in (it’s a value
result parameter), the data was returned at the wrong offset.

So since this is an AF_INET socket, make sure fromlen
is initialized as:

char from[100]; /* for example */
fromlen = sizeof(struct sockaddr_in);

not:

fromlen = sizeof(from)


This is fixed for 6.2.

-seanb

Tana Isaac <tana.isaac@opennw.com> wrote:
: Hello,

: I am currently attempting to port ucd-snmp 4.2.3 to QNX6.1a RTOS. I am
: experiencing difficulties however, and I wondered if anyone had any ideas as
: to what might be the problem.
: Basically, I am getting my snmp packets corrupted (or discarded?), and I am
: lost for any explanation why, except that QNX is corrupting them! I know
: that this seems absurd, but I have been debugging the source code for
: Ucd-snmp over and over again,
: and when I examine the data just after recvfrom() is called, the memory
: space where the data is meant to be put is not being written to, although
: snmp packets are being received.
: Basically the code does the following:

: creates a socket using:

: sd = socket(AF_INET, SOCK_DGRAM, 0);

: binds the socket to port 161 using:

: bind(sd, (struct sockaddr *)&me, addr_size) // The struct
: sockaddr me has sin_addr.s_addr set to INADDR_ANY

: // and sin_port set to htons(161), and sin_family set to AF_INET.

: receives packets from the socket using:

: length = recvfrom(sd, (char *)packet, PACKET_LENGTH, 0,
: (struct sockaddr *)&from, &fromlength); //
: PACKET_LENGTH = 8 * 1024

: Note: there is other code between the bind and receivefrom, but the socket
: descriptor is not modified between the two function calls.
: When I examine “packet” immediately following recvfrom(), it does not
: contain the data that it should (I have confirmed that the correct data is
: actually arriving at the port).
: Have you ever heard of anything like this before? The snmp applications
: supplied with QNX work - maybe the ucd-snmp code makes some different calls
: to the kernel that cause this?

: Any help on this matter would be greatly appreciated :slight_smile:.

: Regards,

: Tana Isaac

3

You are my hero mate :slight_smile:. After 3 weeks of looking through the ucd-4.2.3
code in search of the bug that caused the problems, I’ve finally done it,
and can stop banging my head.

Thankyou very much for your help,

Tana Isaac


Sean Boudreau <seanb@qnx.com> wrote in message
news:<a40pd0$8k1$1@nntp.qnx.com>…

There was a bug in the stack for a while where if the
last argument to recvfrom() was less on return from the
function than the value you passed in (it’s a value
result parameter), the data was returned at the wrong offset.

So since this is an AF_INET socket, make sure fromlen
is initialized as:

char from[100]; /* for example */
fromlen = sizeof(struct sockaddr_in);

not:

fromlen = sizeof(from)


This is fixed for 6.2.

-seanb

Tana Isaac <> tana.isaac@opennw.com> > wrote:
: Hello,

: I am currently attempting to port ucd-snmp 4.2.3 to QNX6.1a RTOS. I am
: experiencing difficulties however, and I wondered if anyone had any
ideas as
: to what might be the problem.
: Basically, I am getting my snmp packets corrupted (or discarded?), and I
am
: lost for any explanation why, except that QNX is corrupting them! I know
: that this seems absurd, but I have been debugging the source code for
: Ucd-snmp over and over again,
: and when I examine the data just after recvfrom() is called, the memory
: space where the data is meant to be put is not being written to,
although
: snmp packets are being received.
: Basically the code does the following:

: creates a socket using:

: sd = socket(AF_INET, SOCK_DGRAM, 0);

: binds the socket to port 161 using:

: bind(sd, (struct sockaddr *)&me, addr_size) // The struct
: sockaddr me has sin_addr.s_addr set to INADDR_ANY

: // and sin_port set to htons(161), and sin_family set to AF_INET.

: receives packets from the socket using:

: length = recvfrom(sd, (char *)packet, PACKET_LENGTH, 0,
: (struct sockaddr *)&from, &fromlength); //
: PACKET_LENGTH = 8 * 1024

: Note: there is other code between the bind and receivefrom, but the
socket
: descriptor is not modified between the two function calls.
: When I examine “packet” immediately following recvfrom(), it does not
: contain the data that it should (I have confirmed that the correct data
is
: actually arriving at the port).
: Have you ever heard of anything like this before? The snmp applications
: supplied with QNX work - maybe the ucd-snmp code makes some different
calls
: to the kernel that cause this?

: Any help on this matter would be greatly appreciated > :slight_smile:> .

: Regards,

: Tana Isaac