Ask Your Question
0

TCP client to server data to NSS listener, NBT (NetBIOS over TCP)

asked 2020-11-19 15:52:59 +0000

mi7WSuser gravatar image

updated 2020-11-19 17:04:41 +0000

Hi, So I have successfully established TCP connection with the 3-way handshake (SYN, SYN-ACK, ACK) to a listening port on Windows "139" which so happen to be a NetBIOS Session Service SMB listening application - this is between NXP FRDM K64F as CLIENT development board and the PC as LISTENER/SERVER.

I have now programed the FRDM to send out raw data (String: "Hello World...") over this connection but the data is not getting ACK'ed.

Setting aside that my packet is not ACK'ed by the PC, as far as passing data and PC response back, is this WireShark capture VALID exchange between the FRDM and the PC? I'm asking because I'm trying to understand all the details of code in the FRDM as far as what to do in callback functions, e.g. recv(), send(), sent(), poll(), err()...

The following talks about what I see on WS. Can someone explain if this is valid and what the last packets exchanged are doing?

After 3-way handshake connection:

  1. WS captures and tags raw data packet FRDM sent via TCP driver code as an NBSS protocol packet from FRDM IP:port to PC IP: 139, and Message Type: "NBSS Continuation Message". The plain data payload has been wrapped correctly by FRDM (driver) code for TCP headers and passed to the IP layer, to ethernet and out, Seq=1 Ack=1 Len=32. WireShark sees it as NBSS packet and I see my string in the detail of the log as NetBios Session Service Continuation data: (hex format of) "Hello World..."
  2. PC IP:139 response back with NBSS, Message type: "Negative session response" (0x83), Error code: Unspecified error (0x8f)
  3. For some reason I still have to debug, FRDM re-sends the data (retries = 2) probably because it was not ACK'ed the first time (sent() callback not called) as deciphered by the protocol stack in the board. WS tags the packet the same type NBSS Continuation Message.
  4. Still no ACK for the data packet, BUT, the PC (re)sent the TCP ACK, I think for the last 3-way handshake connection establishement? Or, Was that the ACK for data packet I sent?
  5. The PC sends 2x more [TCP Retransmission] PC:139 -> FRDM:port [FIN, PSH, ACK], ...
  6. FRDM finally replies back from FRDM:port -> PC:139 [RST,ACK]

NOTES:

  • After 1x data transmission I actually close the TCP connection. I don't do loops.
  • Port Listener free SW utility I'm running on the PC listener/server did not see / not displayed the raw data on port 139
  • I don't know or understand how to use echotool.exe to catch and display my data. I can't figure out from the -help shown switches to use with the command.

Any comments?

Thanks. MI

edit retag flag offensive close merge delete
add a comment

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-11-19 17:03:09 +0000

grahamb gravatar image

updated 2020-11-19 17:05:34 +0000

As noted in your previous question, you can't simply throw strings at a listening service and expect anything good to come if it. Port 139 is used for the Netbios Session Service (NBSS) and unless you're intending to emulate a Windows NBSS client on your FRDM board is of no use to you at all.

You can't simply run other tools on ports that are already in use.

For echotool help run echotool /? That shows you need to use /p tcp /s <my port> to make it listen on a port of your choice. Choose a port > 49152 as that's likely to be unused. You may have to add a firewall rule (or turn off the firewall if you don't care about security) to allow echotool to receive packets external to the pc. Configure your FRDM board to use the same port as echotool is listening on.

You should really look for support in a forum for your board or software stack. This isn't a Wireshark question and is really off-topic for this site.

edit flag offensive delete link more

Comments

I understand what you are saying @grahamb. However, I have found that by researching some more on TCP state machine, transition diagram, and looking more closely to WS segment captures, WS has helped me figure out what's really going and I just learned that the PC port actually did send me an ACK in some form (as NBSS) as embedded within the NBSS and TCP packets. E.g. Under SEQ/ACK analysis section: "This is an ACK to the segment in frame: 85, and such. I saw which segment was ACK'ed and the flow of state transition which I'm trying to "master" in a way, while making my own decision what really needs to happen instead of going from ESTABLISHED->(data send)->RSTbyPC, I need to do ESTABLISHED->(send data)->processPCACK->FINtoPC, or such logical way within state machine conditions in the LWIP/TCPIP protocol stack in the ...(more)

mi7WSuser gravatar imagemi7WSuser ( 2020-11-19 20:05:41 +0000 )edit

P.S. And in case anyone is wondering why I'm doing such code updates or TCP state transition analysis in the FRDM board's existing LWIP protocol stack's code, that's because most of what exists in the code are catered for the FRDM board as a web SERVER only (that base code in the FRDM SDK which I started from). As far as when I succeeded in establish a client connection initiated by the FRDM, that operation STILL works alongside with the client connection. I haven't tried that yet again now that I'm also sending data. That's why I had to practically start from scratch to make a connection as the CLIENT on the board. In lieu of that, as a server-only-mode, it does NOT handle the "ACK" that was sent in the form of the NBSS raw packet within the behavioral-operation as a ...(more)

mi7WSuser gravatar imagemi7WSuser ( 2020-11-19 21:32:52 +0000 )edit

As I've mentioned a few times, you cannot use either an existing listening service or run your own service, such as echotool, on the same port as an existing service for your experiments. You MUST use a currently unused port.

Wireshark is indeed valuable when trying to determine network issues, but it's a microscope. Someone needs to interpret what the tool shows and unfortunately that requires a considerable amount of networking knowledge.

The appropriate forum for your issues would be one for lwIP as that's the software causing you problems. A quick search for lwIP and FRDM64 shows results such as this that appears to create a web server using the board.

grahamb gravatar imagegrahamb ( 2020-11-19 21:41:37 +0000 )edit
add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

Asked: 2020-11-19 15:52:59 +0000

Seen: 1,614 times

Last updated: Nov 19 '20