NNTP client problem (BSD Sockets) - Unix

This is a discussion on NNTP client problem (BSD Sockets) - Unix ; Okay I'm having some problems with an NNTP client I am trying to write. I have sent the username after recieving the requires authentification command, but the program hangs on recv(). Basically I'm meant to recv a command saying that ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: NNTP client problem (BSD Sockets)

  1. NNTP client problem (BSD Sockets)

    Okay I'm having some problems with an NNTP client I am trying to write.
    I have sent the username after recieving the requires authentification
    command, but the program hangs on recv().

    Basically I'm meant to recv a command saying that the server requires a
    password as to be expected. I know that I have sent the username
    command correctly as the send() command has returned the correct number
    but the server just does not respond.

    I then tried to implement the socket using O_NONBLOCKING but that did
    not even let me connect. I have a feeling I am missing something very
    very simple here but it is not jumping out at me.

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

    send(sock, loginName, sizeof(loginName), 0);
    recv(sock, buffer, bufsize, 0);
    printf("%s", buffer);
    send(sock, passwd, sizeof(passwd), 0);
    recv(sock, buffer, bufsize, 0);
    printf("%s", buffer);

    return 0;
    }

    The username and password have been removed. Does anyone know what
    might be going wrong here? It seems to be a blocking issue but I have
    no idea how to correct it.

    Any help is appreciated.


  2. Re: NNTP client problem (BSD Sockets)

    Niz wrote:
    > Okay I'm having some problems with an NNTP client I am trying to write.
    > I have sent the username after recieving the requires authentification
    > command, but the program hangs on recv().
    >
    > Basically I'm meant to recv a command saying that the server requires a
    > password as to be expected. I know that I have sent the username command
    > correctly as the send() command has returned the correct number but the
    > server just does not respond.
    >
    > I then tried to implement the socket using O_NONBLOCKING but that did
    > not even let me connect. I have a feeling I am missing something very
    > very simple here but it is not jumping out at me.
    >
    > int nntpLogin(char *buffer, size_t bufsize, int sock)
    > {
    > char loginName[] = "AUTHINFO USER \r\n";
    > char passwd[] = "AUTHINFO PASS \r\n";
    >
    > send(sock, loginName, sizeof(loginName), 0);


    I don't know that this is the cause of your problem, but won't
    sizeof() return the number of characters including the null
    terminator, thus causing send() to send a zero byte after the
    CRLF? That seems like not what you want to do.

    - Logan

  3. Re: NNTP client problem (BSD Sockets)

    On 2008-03-16 19:05:58 +0000, Logan Shaw said:
    >
    > I don't know that this is the cause of your problem, but won't
    > sizeof() return the number of characters including the null
    > terminator, thus causing send() to send a zero byte after the
    > CRLF? That seems like not what you want to do.
    >
    > - Logan


    Thanks for the reply. I changed it to use strlen() instead but still
    get the same problem as noted in my original post. Even using a
    constant still produces the same problem so I doubt it has anything to
    do with that.


  4. Re: NNTP client problem (BSD Sockets)

    In article <2008031618095616807-niz@nicetrycom>, Niz
    wrote:

    > Okay I'm having some problems with an NNTP client I am trying to write.
    > I have sent the username after recieving the requires authentification
    > command, but the program hangs on recv().
    >
    > Basically I'm meant to recv a command saying that the server requires a
    > password as to be expected. I know that I have sent the username
    > command correctly as the send() command has returned the correct number
    > but the server just does not respond.


    Send() returning just means that the bytes have been buffered in the
    local kernel, it doesn't mean anything has actually been sent. Although
    unless something's wrong, they should be sent in a fraction of a second.

    >
    > I then tried to implement the socket using O_NONBLOCKING but that did
    > not even let me connect. I have a feeling I am missing something very
    > very simple here but it is not jumping out at me.
    >
    > int nntpLogin(char *buffer, size_t bufsize, int sock)
    > {
    > char loginName[] = "AUTHINFO USER \r\n";
    > char passwd[] = "AUTHINFO PASS \r\n";
    >
    > send(sock, loginName, sizeof(loginName), 0);
    > recv(sock, buffer, bufsize, 0);
    > printf("%s", buffer);
    > send(sock, passwd, sizeof(passwd), 0);
    > recv(sock, buffer, bufsize, 0);
    > printf("%s", buffer);
    >
    > return 0;
    > }
    >
    > The username and password have been removed. Does anyone know what
    > might be going wrong here? It seems to be a blocking issue but I have
    > no idea how to correct it.
    >
    > Any help is appreciated.


    I have you tried doing a packet capture to see what's being sent and
    received on the wire?

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

  5. Re: NNTP client problem (BSD Sockets)

    On Mar 16, 11:09 am, Niz wrote:

    I know you may be thinking that you'll just do things the quick way
    first and clean it up later, but it will save you a lot of trouble to
    do it right from the beginning.

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


    You throw away the return value. What if you only received one byte
    and didn't get the whole message?

    > printf("%s", buffer);


    The '%s' specifier is for C-style strings. You don't have a C-style
    string, you just have an arbitrary collection of characters. So why
    are you treating it as a string?

    > send(sock, passwd, sizeof(passwd), 0);
    > recv(sock, buffer, bufsize, 0);
    > printf("%s", buffer);


    Same problem, you ignore the return value and then pretend you have a
    string when you don't.

    > return 0;
    >
    > }


    If you 'telnet' to the NNTP server and send these two strings, do you
    normally get a reply after the 'AUTHINFO PASS' line?

    DS

  6. Re: NNTP client problem (BSD Sockets)

    On 2008-03-17 05:53:20 +0000, David Schwartz said:

    > On Mar 16, 11:09 am, Niz wrote:
    >
    > I know you may be thinking that you'll just do things the quick way
    > first and clean it up later, but it will save you a lot of trouble to
    > do it right from the beginning.
    >
    > You throw away the return value. What if you only received one byte
    > and didn't get the whole message?


    That is just for ease of reading on the newsgroup. The return value is
    checked in my actual code.

    >
    >> printf("%s", buffer);

    >
    > The '%s' specifier is for C-style strings. You don't have a C-style
    > string, you just have an arbitrary collection of characters. So why
    > are you treating it as a string?


    I was under the impression that a string was an arbitary collection of
    characters. Anyway it is irrelavant at the moment due to the fact that
    it never reaches this point anyway .

    The %s printf statement works fine for a malloced array of char, what
    is the best option to use?
    >
    > If you 'telnet' to the NNTP server and send these two strings, do you
    > normally get a reply after the 'AUTHINFO PASS' line?
    >
    > DS


    Ah, doh never thought to use Telnet to check this.



  7. Re: NNTP client problem (BSD Sockets)

    On Mar 17, 1:21 am, Niz wrote:

    > >> printf("%s", buffer);


    > > The '%s' specifier is for C-style strings. You don't have a C-style
    > > string, you just have an arbitrary collection of characters. So why
    > > are you treating it as a string?


    > I was under the impression that a string was an arbitary collection of
    > characters. Anyway it is irrelavant at the moment due to the fact that
    > it never reaches this point anyway .


    No. A C-style string is an array of non-zero characters with a
    terminating zero. An arbitrary collection of characters is *NOT* a C-
    style string and can be disastrous to pass it to functions that take C-
    style strings.

    > The %s printf statement works fine for a malloced array of char, what
    > is the best option to use?


    You can loop through all of the received characters, using the length
    returned from 'recv', and output then with '%c' if they are printable.
    You can also convert them into a C-style string by adding a
    terminating zero. (You may or may not need to handle any embedded
    zeroes, it depends on the protocol.)

    > > If you 'telnet' to the NNTP server and send these two strings, do you
    > > normally get a reply after the 'AUTHINFO PASS' line?


    > Ah, doh never thought to use Telnet to check this.


    It may be that the server simply does not send a reply to this line.

    DS

  8. Re: NNTP client problem (BSD Sockets)

    In article
    <05b4e0dc-cdf7-455f-9ff3-00d16596518c@x41g2000hsb.googlegroups.com>,
    David Schwartz wrote:

    > On Mar 17, 1:21 am, Niz wrote:
    >
    > > >> printf("%s", buffer);

    >
    > > > The '%s' specifier is for C-style strings. You don't have a C-style
    > > > string, you just have an arbitrary collection of characters. So why
    > > > are you treating it as a string?

    >
    > > I was under the impression that a string was an arbitary collection of
    > > characters. Anyway it is irrelavant at the moment due to the fact that
    > > it never reaches this point anyway .

    >
    > No. A C-style string is an array of non-zero characters with a
    > terminating zero. An arbitrary collection of characters is *NOT* a C-
    > style string and can be disastrous to pass it to functions that take C-
    > style strings.
    >
    > > The %s printf statement works fine for a malloced array of char, what
    > > is the best option to use?

    >
    > You can loop through all of the received characters, using the length
    > returned from 'recv', and output then with '%c' if they are printable.
    > You can also convert them into a C-style string by adding a
    > terminating zero. (You may or may not need to handle any embedded
    > zeroes, it depends on the protocol.)


    NNTP is a text-based protocol, there should never be any embedded nulls.

    >
    > > > If you 'telnet' to the NNTP server and send these two strings, do you
    > > > normally get a reply after the 'AUTHINFO PASS' line?

    >
    > > Ah, doh never thought to use Telnet to check this.

    >
    > It may be that the server simply does not send a reply to this line.


    NNTP is a simple request/reply protocol. Every request generates a
    reply.

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

  9. Re: NNTP client problem (BSD Sockets)

    On Mar 17, 2:21 pm, Barry Margolin wrote:

    > NNTP is a text-based protocol, there should never be any embedded nulls.


    Right, but if you do get one, you really don't want to blow up. For
    example, if you keep accumulating data and use 'strchr' to check for a
    newline, a single received zero will cause your program to fail.
    That's just not robust.

    > > It may be that the server simply does not send a reply to this line.


    > NNTP is a simple request/reply protocol. Every request generates a
    > reply.


    Which leads to the question, is that a [defined] request? I don't know
    this particular aspect of NNTP in enough detail, but it may be legal,
    for example, for the server to return a "no password is needed" reply
    to the "AUTHINFO USER" command, leaving the "AUTHINFO PASS" not being
    a legal request in that context.

    DS

  10. Re: NNTP client problem (BSD Sockets)

    In article
    <9ad242a2-dd7f-43ca-8cae-e69acfdb1dbd@b1g2000hsg.googlegroups.com>,
    David Schwartz wrote:

    > On Mar 17, 2:21 pm, Barry Margolin wrote:
    >
    > > NNTP is a text-based protocol, there should never be any embedded nulls.

    >
    > Right, but if you do get one, you really don't want to blow up. For
    > example, if you keep accumulating data and use 'strchr' to check for a
    > newline, a single received zero will cause your program to fail.
    > That's just not robust.
    >
    > > > It may be that the server simply does not send a reply to this line.

    >
    > > NNTP is a simple request/reply protocol. Every request generates a
    > > reply.

    >
    > Which leads to the question, is that a [defined] request? I don't know
    > this particular aspect of NNTP in enough detail, but it may be legal,


    Yes, it's the standard way to specify a username and password.

    > for example, for the server to return a "no password is needed" reply
    > to the "AUTHINFO USER" command, leaving the "AUTHINFO PASS" not being
    > a legal request in that context.


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

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

  11. Re: NNTP client problem (BSD Sockets)

    On Mar 17, 11:14 pm, Barry Margolin 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

  12. Re: NNTP client problem (BSD Sockets)

    On 2008-03-18 06:27:14 +0000, David Schwartz said:

    > On Mar 17, 11:14 pm, Barry Margolin 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


    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
    #include

    #include
    #include
    #include

    #include
    #include

    #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;
    }


  13. Re: NNTP client problem (BSD Sockets)

    On Mar 18, 12:06 pm, Niz 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]
    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

  14. Re: NNTP client problem (BSD Sockets)

    Niz wrote:
    > On 2008-03-18 06:27:14 +0000, David Schwartz said:
    >
    > > On Mar 17, 11:14 pm, Barry Margolin 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

    >
    > 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.
    >


    > 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.



  15. Re: NNTP client problem (BSD Sockets)

    On 2008-03-19, William Ahern wrote:
    > Niz wrote:
    >> On 2008-03-18 06:27:14 +0000, David Schwartz said:
    >>
    >> > On Mar 17, 11:14 pm, Barry Margolin 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

    >>
    >> 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.
    >>

    >
    >> 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/


    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.
    >
    >



    --


  16. Re: NNTP client problem (BSD Sockets)

    On Mar 18, 8:31 pm, Jim Cochrane 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

  17. Re: NNTP client problem (BSD Sockets)

    On 2008-03-18 23:56:00 +0000, David Schwartz said:

    > On Mar 18, 12:06 pm, Niz 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]
    > 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.


  18. Re: NNTP client problem (BSD Sockets)

    Jim Cochrane wrote:
    > On 2008-03-19, William Ahern wrote:


    >> 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/


    > 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

  19. Re: NNTP client problem (BSD Sockets)

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

    > Jim Cochrane wrote:
    > > On 2008-03-19, William Ahern wrote:

    >
    > >> 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/

    >
    > > 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.


    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 ***

  20. Re: NNTP client problem (BSD Sockets)

    On 2008-03-20, Barry Margolin wrote:
    > In article <47e1f278$0$16656$4c368faf@roadrunner.com>,
    > Logan Shaw wrote:
    >
    >> Jim Cochrane wrote:
    >> > On 2008-03-19, William Ahern wrote:

    >>
    >> >> 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/

    >>
    >> > 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.

    >
    > 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.
    >


    Well, if the result of the defect is that a log file grows larger
    unnecessarily, that could be considered an annoying side effect. :-)

    Even if not, I think some developers would fix the problem in order to
    make their system more robust, as long as it's affordable - does not
    take a long time to fix/test.


    [I didn't see Logan's original response from my news server for some
    reason. Perhaps they have a bug :-)]

    --


+ Reply to Thread
Page 1 of 2 1 2 LastLast