No announcement yet.

HttpGetPort & HttpSetPort

  • Filter
  • Time
  • Show
Clear All
new posts

  • HttpGetPort & HttpSetPort

    First of all I am using an Xport_AR SDK R13.

    I have found what I believe to be an issue with the HttpSetPort and HttpGetPort functions. Here are my conclusions:

    - HttpSetPort takes a uint32_t for a port number. When entering a number between 0 - 65535 this function seems to properly accept and change the port to the corresponding number.

    - HttpGetPort is supposed to return a uint32_t for the port number that got set but when trying to display this number using a sprintf( temp, "%lu", HttpGetPort( pServer) ) and then writing that temp value out the debug port the values only print out correctly up to 32767 which tells me that they are only displaying up to an int16_t. Once using a value of 32767 or above I get values like 4294934528 as a response. After much debugging and discussion with a co-worker it was found after printing out HttpGetPort that once going beyond 32767 which would be 0x00007FFF that the values are not unsigned but seem to be signed extended longs. For example when inputing a value of 32768 in HttpSetPort and then calling HttpGetPort the value is 4294934528 which is 0xFFFF8000. And 65535 is 0xFFFFFFFF. So this was the cause of our problem because we are trying to send out the port number over our network expecting it to be an unsigned 32 bit value when it seems to be a sign extended 16 bit value.

    After figuring this out I did a quick test in code:

    HttpSetPort( pHttpServer, 32768 );

    HttpSetPort( pHttpServer, HttpGetPort(pHttpServer) );

    After running this code I then telnet'ed to the Xport and typed the following commands:

    show http
    HTTP Server Settings:
    HTTP State : On (Running)
    HTTP Port : -32768
    HTTPS Port : 443
    Max Timeout : 10 seconds
    Max Bytes : 40960
    Logging : On
    Max Log Entries : 50
    Log Format : %h %t "%r" %s %B "%{Referer}i" "%{User-Agent}i"
    Logs : 7 entries (1533 bytes)

    This shows I believe that this function does not seem to be handling uint32_t values but possibly manipulating them so that they are no longer 32 bit values but 16 bit values and a conversion back causes them to be sign extended. Just thought I would try to display the problem I have seen it.

  • #2
    Sorry, I'm unable to reproduce the problem you're seeing.

    I'm testing with XPort AR SDK v3.4.0.0R13, and the only modification I've made is in sample0.c as follows:

    int SampleApp(CommandLine *pC, HttpServer *pH)
        HttpServer *pHttpServer = (HttpServer *)pH;
        HttpSetPort( pHttpServer, 32768 );
        HttpSetPort( pHttpServer, HttpGetPort(pHttpServer) ); 
        return 0;
    Then when I telnet in, I get the following output:
    (config)#show http
    HTTP Server Settings:
       HTTP State      : On (Running)
       HTTP Port       : 32768
       HTTPS Port      : 443
       Max Timeout     : 10 seconds
       Max Bytes       : 40960
       Logging         : On
       Max Log Entries : 50
       Log Format      : %h %t "%r" %s %B "%{Referer}i" "%{User-Agent}i"
       Logs            : 16 entries (2645 bytes)

    So, unable to reproduce, I took a deeper look at the code, and I don't see anything to explain what you're seeing. I DID, however, fix a display problem in http/https ports on the web manager http configuration page. (Ports that were over 32767 were displaying as negative numbers.) The CLI display code looks fine.

    So, what I'd recommend to do next is the following:

    1. Verify your sdk install is clean and try just the changes I made above. See if you have the same results as I do.
    2. Verify your paradigm tools are up to date. You should be using Paradigm C++ 6.00.045 Service Pack 6 Hotfix 9 (as of today 4/2/2009).
    3. Restore factory defaults. See if this fixes any issues you are seeing.

    If you think of any more useful information, let me know.
    Thomas Cook
    Evolution OS
    Lantronix, Inc.