NNTP client problem (BSD Sockets)

On Mar 17, 11:14 pm, Barry Margolin <bar...@alum.mit.edu> wrote:

> But his problem is that he's not getting ANY reply to the AUTHINFO USER
> command.  His next call to recv() is not returning.

Yeah, I can't think of any obvious reason for this. My current belief
is that he has some bug in code that he hasn't show us. That or his
news server just isn't replying to that for some reason.

DS

On 2008-03-18 06:27:14 +0000, David Schwartz <davids@webmaster.com> said:

> On Mar 17, 11:14 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> 
>
> Yeah, I can't think of any obvious reason for this. My current belief
> is that he has some bug in code that he hasn't show us. That or his
> news server just isn't replying to that for some reason.
>
> DS

Here is my full code. It is probably rubbish but I'm not that great at
C just yet.

This one has me completely stumped. I have followed the RFC standard
for NNTP and the used the relevant extention standard documents so
everything should be correct.

#include <sys/types.h>
#include <sys/socket.h>

#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#include <stdio.h>
#include <stdlib.h>

#include "main.h"

int main (int argc, const char * argv[])
{
int errorReturn = 0;
size_t bufsize = 1024;
char *buffer = malloc(bufsize);

if(errorReturn != 0)
{
printf("Interface not initialised.\n");
exit(EXIT_FAILURE);
}

errorReturn = nntpOpenSocket();

if(errorReturn != 0)
{
exit(EXIT_FAILURE);
}

errorReturn = nntpConnection(buffer, bufsize);

if(errorReturn == 0)
{
errorReturn = nntpCheckWhatToDo(buffer, bufsize, sock);

if(errorReturn == 480)
{
printf("Attempting login\n");
nntpLogin(buffer, bufsize, sock);
}
else
{
printf("Unknown Server Response.\n");
exit(EXIT_FAILURE);
}
}
else
{
exit(EXIT_FAILURE);
}

nntpQuitServer(buffer, bufsize);

free(buffer);

exit(EXIT_SUCCESS);
}

int nntpOpenSocket(void)
{
const int port = 119;
int error = 0;

he = gethostbyname("news-europe.giganews.com");
sock = socket(PF_INET, SOCK_STREAM, 0);
if(sock < 0)
{
printf("Socket error.\n");
return -1;
}

their_addr.sin_family = AF_INET;
their_addr.sin_port = htons(port);
their_addr.sin_addr = *((struct in_addr *)he->h_addr);
memset(their_addr.sin_zero, '\0', sizeof(their_addr.sin_zero));
error = connect(sock, (struct sockaddr *) &their_addr, sizeof(their_addr));
if(error == -1)
{
printf("Connection error.\n");
return -1;
}

return 0;
}

int nntpConnection(char *buffer, size_t bufsize)
{
int recvStatus = 0, comCodeInt = 0;
char comCode[3];

recvStatus = recv(sock, buffer, bufsize, 0);

if(recvStatus == 0)
{
printf("Socket Blocking.\n");
return -1;
}
else if(recvStatus == -1)
{
printf("Error.\n");
return -1;
}

strncpy(comCode, buffer, 3);

comCodeInt = atoi(comCode);
printf("%d\n", comCodeInt);

if(comCodeInt == 200)
{
printf("Connection OK.\n");
}
else
{
printf("Unknown Response.\n");
return -1;
}

return 0;
}

void nntpQuitServer(char *buffer, size_t bufsize)
{
send(sock, "QUIT\r\n", 6, 0);
recv(sock, buffer, bufsize, 0);
close(sock);

printf("%s", buffer);
}

int nntpCheckWhatToDo(char *buffer, size_t bufsize, int sock)
{
char serverResponse[3];
int serverResponseProcessed = 0;

send(sock, "MODE READER\r\n", 14, 0);
recv(sock, buffer, bufsize, 0);

printf("%s", buffer);

strncpy(serverResponse, buffer, 3);
serverResponseProcessed = atoi(serverResponse);

return serverResponseProcessed;
}

int nntpLogin(char *buffer, size_t bufsize, int sock)
{
char loginName[] = "AUTHINFO USER <>\r\n";
char passwd[] = "AUTHINFO PASS <>\r\n";

send(sock, loginName, strlen(loginName), 0);
printf("Data sent\n");
recv(sock, buffer, bufsize, 0);
printf("%s", buffer);
send(sock, passwd, strlen(passwd), 0);
recv(sock, buffer, bufsize, 0);
printf("%s", buffer);

return 0;
}

On Mar 18, 12:06 pm, Niz <n...@nicetry.com> wrote:

>         send(sock, "MODE READER\r\n", 14, 0);

Boom! This is exactly what I warned you about and what Barry said you
didn't have to worry about. ;)

In case you don't see it, you send the other side the zero at the end
of this command. So when you send the next command, the server sees it
as:

MODE READER\r\n [valid request, replied to]
<nul>AUTHINFO USER ...\r\n [invalid, not a request]

The server thinks the 'nul' terminates the string, so it doesn't see
the line terminator at the end. Since it doesn't see the line
terminator, it doesn't consider it a fully-formed request.

You really should make a 'send nntp command' function that takes a
'char *'. This will ensure you get the length right.

DS

Niz <niz@nicetry.com> wrote:
> On 2008-03-18 06:27:14 +0000, David Schwartz <davids@webmaster.com> said:
> 
>
> Here is my full code. It is probably rubbish but I'm not that great at
> C just yet.
>
> This one has me completely stumped. I have followed the RFC standard
> for NNTP and the used the relevant extention standard documents so
> everything should be correct.
>
<snip>
>         he = gethostbyname("news-europe.giganews.com");

This early in the development cycle some might consider it rude to subject
Giganews' servers to your early tests. At some point a developer has no
choice but to let loose his creation into the wild, come what may, but this
early in the process I'd strongly suggest to setup leafnode or maybe INN or
something on your development box.

It's not likely, but your malformed data could be triggering a bug in their
server software. At the very least, you might be filling up their logs w/
noise. They may never notice, but that's beside the point.

On 2008-03-19, William Ahern <william@wilbur.25thandClement.com> wrote:
> Niz <niz@nicetry.com> wrote: 
><snip> 
>
> This early in the development cycle some might consider it rude to subject
> Giganews' servers to your early tests. At some point a developer has no
> choice but to let loose his creation into the wild, come what may, but thi
s
> early in the process I'd strongly suggest to setup leafnode or maybe INN o
r
> something on your development box.
>
> It's not likely, but your malformed data could be triggering a bug in thei
r
> server software. At the very least, you might be filling up their logs w/

However, triggering a bug is usually considered good news by the
developers of the target software, as long as the bug gets reported with
enough information such that it can be fixed.

> noise. They may never notice, but that's beside the point.
>
>


--

On Mar 18, 8:31 pm, Jim Cochrane <allergic-to-s...@no-spam-
allowed.org> wrote:

> However, triggering a bug is usually considered good news by the
> developers of the target software, as long as the bug gets reported with
> enough information such that it can be fixed.

It certainly should be. Whether it actually is ...

DS

On 2008-03-18 23:56:00 +0000, David Schwartz <davids@webmaster.com> said:

> On Mar 18, 12:06 pm, Niz <n...@nicetry.com> wrote:
> 
>
> Boom! This is exactly what I warned you about and what Barry said you
> didn't have to worry about. ;)
>
> In case you don't see it, you send the other side the zero at the end
> of this command. So when you send the next command, the server sees it
> as:
>
> MODE READER\r\n [valid request, replied to]
> <nul>AUTHINFO USER ...\r\n [invalid, not a request]
>
> The server thinks the 'nul' terminates the string, so it doesn't see
> the line terminator at the end. Since it doesn't see the line
> terminator, it doesn't consider it a fully-formed request.
>
> You really should make a 'send nntp command' function that takes a
> 'char *'. This will ensure you get the length right.
>
> DS

Thank you, thank you, thank you!

Wow, what a silly bug. Sometimes you can't see the forest for the trees.

As for using the Giganews server, I guess you are right. I'll look into
a Mac OS X compatible news server to use to test out my code.

Jim Cochrane wrote:
> On 2008-03-19, William Ahern <william@wilbur.25thandClement.com> wrote:
 

> However, triggering a bug is usually considered good news by the
> developers of the target software, as long as the bug gets reported with
> enough information such that it can be fixed.

Developers, yes.  Operators are a different story, though.  They
want to know about the bug initially, but thenceforth, they want
it not to be triggered.

- Logan

In article <47e1f278$0$16656$4c368faf@roadrunner.com>,
Logan Shaw <lshaw-usenet@austin.rr.com> wrote:

> Jim Cochrane wrote: 
> 
> 
>
> Developers, yes.  Operators are a different story, though.  They
> want to know about the bug initially, but thenceforth, they want
> it not to be triggered.

If the bug is in a server and only impacts broken clients, and doesn't
cause any annoying side effects, I suspect neither will give it very
high priority.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

On 2008-03-19, David Schwartz <davids@webmaster.com> wrote:
> On Mar 18, 8:31 pm, Jim Cochrane <allergic-to-s...@no-spam-
> allowed.org> wrote:
> 
>
> It certainly should be. Whether it actually is ...
>
> DS

Yep - it depends on the developers' moods at the time, how important the
project is, how busy and/or efficient people are, etc...   But those who
take pride in their work and have a goal to develop high-quality systems
are going to, in general, be happy to receive a useful bug report.

--