×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

I wonder which layer the bug is most possible and then focus on some modules.

I don't have efficient debug tools for some reason. what I can do now is inserting a piece of debug message in the spefic code . then dump the another board's hardware shared memory. Debuging the embedded real time system is very tough. If your debug task cause inappropriate workload, it may result in system status will be totally different.
That's a bug fix and custom won't be very patient.

Now I have mixed information.so I am confused.
telnet fine means problem should be upper than TCP
first channel fine, means application is good.
My code trace now is TCP task received bad message

As far as I know, students in Purdue did a big assignement like implementing an IP router. Reading only give us an overview. Engineering needs challengable projects and more hands-on experience.

Steven's looks like based on 4.2.1,isn't it?
Report

Replies, comments and Discussions:

  • 工作学习 / IT技术讨论 / Dennis2! Do you have any ideas on this bug?
    We have a board supporting TCP/IP suite. ftp server couldn't be connected twice and hung ftp client. But telnet server works well. Additionally there are two channel in this board. Only channel II has this problem. Now I have mixed information because I trace code and TCP task received second connect passive message but valid field in TCP struct is NULL and result in connect. That's an old board, RTOS no support now,and no efficient debug method. so process is very slow.
    • Sorry to disappoint you but I am not familiar with network programming (although that's on my to-learn list). Please, I'm no expert and don't treat me like one.
      My suggestion:

      Search/ask in the appropriate newsgroup(s) (http://groups.google.com, google is amazing!).

      Sorry again.
      • Thanks lot! The Network analyzer is helpful for me to analyze the problem of too much retransmission in our board or not? I want to try set small TCP segmant.
        • Oh definitely...unless you sniff the wire, you don't really know what's going on there. Sorry I forgot to suggest you that (it was on my mind).
    • try the tools "sniffer"
      I do not get what you are dealing with actually ( inplementing the software or setuping the software)

      However, using the software tools sniffer to catch the IP packet on the network and refering to the protocal after that maybe solve the problem.

      You can download the "sniffer" from the Internet or I can E_mail you it if you need.
      • Thanks lot! nice to meet network expert
        I support a board with ethernet based TCP/IP suite. I have all source code. Although I read V1,V2,V3 of comer's and RFCs and had socket API experience before, I had few hands-on experience on Networking,troubleshooting and implementation of Layer 2,3,4.
        • Re:
          If you have read those books and have socket API experience, you should/will be able to solve it. Comer's books are pretty good. It's just a pity that V2 is based on xinu not BSD (not that xinu is bad, it's just that BSD is the standard). I actually like Stevens' book, he is my God in computer area.

          Too bad Stevens died so early, at the time when he was about to publish V3 of network programming.

          I think you can try to get some source code from those rtos, I'm sure there are quite a few open sourced ones.
          • I wonder which layer the bug is most possible and then focus on some modules.
            I don't have efficient debug tools for some reason. what I can do now is inserting a piece of debug message in the spefic code . then dump the another board's hardware shared memory. Debuging the embedded real time system is very tough. If your debug task cause inappropriate workload, it may result in system status will be totally different.
            That's a bug fix and custom won't be very patient.

            Now I have mixed information.so I am confused.
            telnet fine means problem should be upper than TCP
            first channel fine, means application is good.
            My code trace now is TCP task received bad message

            As far as I know, students in Purdue did a big assignement like implementing an IP router. Reading only give us an overview. Engineering needs challengable projects and more hands-on experience.

            Steven's looks like based on 4.2.1,isn't it?