Announcement

Collapse
No announcement yet.

Tunnel sample app

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tunnel sample app

    I have been trying to get the Tunnel sample application to work on the MatchPortAR. In my first attempt I managed to brick the MpAR. Do you have to wait a certain amount of time after a Tftp upload of new firmware?

    In my second attempt with a new MpAR I was first able to load the Sockets sample app which worked. The Tunnel sample app did not send characters out the serial port. A comment in the code says to disable CLI. What does that mean? Disable Telnet CLI?

    The sample code sets the Line1 protocol to None. The web page shows that Line 1 is then Disabled. I enabled Line 1 and did a submit, but now the MpAR is in continuous reboot.

    Also, even though I build a custom SDK, the MpAR will still be running the standard tunnel applications? It appeared that port 10002 was still active. Also the processes page showed Daemon processes for both serial ports.

    Ed

  • #2
    It will stop rebooting if I enter the CLI through the serial port by holding down the '!' key. I can then find it with DeviceInstaller and see the web pages. If I do a Factory Reset then it comes back up and it does not reboot, but if I then reset the MpAR it stays in continuous reboot.

    When I try to load the V1.0.0.3R1 firmware back on, it says the image is invalid. I built the sample apps with SDK_IMAGE_PARTITION_SIZE_BYTES set to 768000 like the documentation said because I am using a standard MpAR. Is that a problem?

    Comment


    • #3
      Hi Ed,
      Any idea what version of the SDK you are using? What is the $Id of the tunnel.c? Did you make any changes? Correct, the Line needs to be DISABLED if you plan to handle I/O on the serial line.
      Regards,
      Garry

      Comment


      • #4
        Hi Garry,

        I'm using SDK version 1.1.0.0R1 which I downloaded from the forum. Here is the $Id line from tunnel.c:
        /* $Id: tunnel.c,v 1.7 2008/03/11 00:17:21 scook Exp $ */

        I haven't made any changes to it.

        Ed

        Comment


        • #5
          Hi

          The Problem is this codesegment -->

          Code:
             // {
             //     struct input_stream_with_const_char_ptr inputStream;
             //     static const char configForm[] =
             //         "<?xml version=\"1.0\" standalone=\"yes\"?>"
             //         "<configrecord version=\"0.1.0.0T0\">"
             //             "<configgroup name=\"line\" instance=\"%d\">"
             //                 "<configitem name=\"protocol\">"
             //                     "<value>none</value>"
             //                 "</configitem>"
             //             "</configgroup>"
             //         "</configrecord>"
             //     ;
             //     char config[200];
          
             //     /* Fill in the one-based line number. */
             //     sprintf(config, configForm, SDK_SERIAL_PORT + 1);
             //     /* Configure the serial port */
             //     if(
             //         ! StreamInitWithConstCharPtr(&inputStream, config) ||
             //         ! XMLImportFromStream(
             //             &inputStream.inStream, TLogWriteMessage, NULL
             //         )
             //     )
             //     {
          			//sprintf(buffer, "Error...Configure the serial port...\r\n");
          			//SerialWrite(0, buffer, strlen(buffer), true);
             //         closesocket(tcpServerSock);
             //         closesocket(udpServerSock);
             //         TLOG(TLOG_SEVERITY_ERR, "Could not set serial protocol to none");
             //         return -1;
             //     }
             // }
          xml code do not work corectly

          best regards

          Comment


          • #6
            We have been able to reproduce this problem on our end, and are in the midst of determining some kind of work around, at least until the next release of the SDK which fixes this problem. I will update this forum thread when I have more information.

            Comment


            • #7
              Workaround for the Problem in Sample tunnel.c

              I have attached an updated copy of tunnel.c with a work around for this problem. The difference between this version and the old, is the use of a complete XML fragment for all "configitems" related to the line.

              We have a bug in the way the default values of unspecified configitems are processed, which is fixed in the next release of the SDK. The original version of the tunnel.c sample just specifies the value of the configitem which needs to be modified. This is the correct approach and can be used with the release of the next version of the SDK in a few weeks.

              To replace the firmware image on your Matchport AR which contains the old tunnel.c causing constant reboots, you can use the "Recover Firmware" option in the DeviceInstaller.

              Many thanks Ed for reporting this bug. This was a great find.
              Attached Files

              Comment


              • #8
                Thanks James. I'll give it a try. I do have a couple general questions.

                What should SDK_IMAGE_PARTITION_SIZE_BYTES be set to when running on a standard MatchPortAR? The SDK User's Guide says 768000. What partition size is used by standard firmware?

                Comment


                • #9
                  Standard FW uses 768000.

                  Comment


                  • #10
                    The new tunnel app still causes problems on my MatchPort. After loading this sample app it appears that the MatchPort is corrupted. It may not respond to !xyz on the serial port. The web pages do not display correctly. Loading other sample apps that previously worked does not help. The only reliable recovery mechanism I have found so far is to reload the standard Lantronix firmware using serial recover and format the file system.

                    Comment


                    • #11
                      Darn, I thought for sure this would solve your problem. Let me think about this and get back to you tomorrow.

                      Comment


                      • #12
                        After you have done your serial recovery, use !xyz and from the command line execute "reload factory defaults". Then try reloading the sample tunnel application provided in a previous post and observe the results. Please be sure not to change the sample tunnel app for the purposes of this test.

                        Even as I was working on my end to reproduce your problem, I was always able to access the command line using !xyz. I am beginning to wonder if we are seeing a different problem.

                        Comment


                        • #13
                          Hi Ed,
                          Did you attempt a:
                          reload factory defaults
                          ??? I found that after the cinfig area was corrupted, it needed to be reset.

                          Comment


                          • #14
                            The problem with the 'new' tunel.c application is that the config buffer is too small for the sprintf. You probably need to set it to 1024.

                            Comment


                            • #15
                              Different file transfers

                              I tried the tunneler sample, using two Real Term consoles, one for Net, other one for serial. Typing characters works fine, transfer looks good.

                              But, when transferring files, I get different results between Net2Ser and Ser2Net. I use the same file from both sources. Settings and parameters are the same on both RealTerm console.

                              Ser2Net: received file is identical to source.

                              Net2Set: there is a NULL character inserted between each LF and CR.

                              As a result, content and size file are different.


                              Anyone sees what might be causing this?
                              Thanks

                              Comment

                              Working...
                              X