NetBurner Community Forum

I'm not sure if this is the right forum since it's sort of a software issue but it's on hardware where I can't change the software.

The problem is I'm tryng to communicate on port 1000 with the SBL2e and I was having some trouble (it had previously worked just fine). I put Wireshark on the network to watch the traffic and what I noticed is that when I open the socket to the SBL2e, I send my SYN, get an ACK back, and then before I can send back the SYN ACK (last of the three way handshake sequence) the SBL2e puts out a packet to ITSELF with an error message (60 bytes worth but nothing that I can read).

What makes me suspect this a code problem in the SBL2e is that it has it's address for both the send and receive IP addresses, the destination port is 1000 and the source port is the port number being used from my computer (and yet the IP addresses are both for the SBL2e!).

This happens no matter what computer I use to talk to it and whether I'm using telnet to port 1000 or a program that just opens a socket to the SBL2e and sends "m?<CR><LF>."

My computer (using telnet) just ignores this but the board I'm trying to connect with gets all confused. Has anyone else seen the problem before? Is there a firmware update that I can get that will fix it?

Thanks in advance for any information.

Len Morgan
CRMWD

When you say it previously worked fine, was that with telnet, or with your other h/w? Just wondering if it could be a configuration issue.

It worked with both. I haven't configured anything on the SBL2e that would have changed but I also didn't have a TCP/IP sniffer on the network until AFTER is stopped working so I don't know if has been there all along or not.

len

Hi Len,

Just trying to pick up anything obvious. You said:

"My computer (using telnet) just ignores this but the board I'm trying to connect with gets all confused."

But also said:

"It worked with both. I haven't configured anything on the SBL2e that would have changed but I also didn't have a TCP/IP sniffer on the network until AFTER is stopped working so I don't know if has been there all along or not."

Wouldn't it have always confused your board, both before and after? Meaning it should have never worked with anything but telnet?

You're absolutely right and that's why it's so confusing. I'm pretty sure there is some sort of bug on the SBL2e, it's just a matter of figuring out why it should really matter one way or the other. As I said, my computer doesn't care (or doesn't listen which amounts to the same thing).

It occurred to me that one other thing I forgot I did was to upgrade the firmware in the netburner. Maybe that's why things were working before and now don't. I can't remember the exact chronology of events but the upgrade was right in the same time frame.

Anyway, I hope somebody from Netburner will look into this. I can supply a TCP/IP trace of what's happening if that will help.

len morgan

Len,

This is a customer site, not a netburner support site, so you should contact them directly if you think there is a problem with your device. It seems like you took my comments to mean I thought there was a bug in the device, that is not true. I actually was thinking there could be an inconsistency in your test setup.

Hello Len,

Did you ever find out the cause of the problem?

Yes and no. After putting WireShark on the network I was able to see that the SBL2e was sending one packet, after a socket was opened to it, where the source AND destination were both the NetBurner! This did not seem to upset my putty client on Windows but the Rabbit module that is doing the polling gets very confused by this.

What ends up happening is that the Rabbit sends a command of "M?<CR><LF>" to the SBL2e right after this odd packet (above). When the SBL2e ACKs this packet, it only ACKs 1 byte even though all 4 bytes were sent in the same packet. This leaves the SBL2e waiting for three more bytes and the rabbit is waiting for the last three bytes to be acknowledged (only one was acknowledged by the SBL2e.

At that point, things just get screwed up until the socket times out and the whole process starts over.

I would love to contact NetBurner support about this but I only got 90 days of support which expired about a week before this problem showed up so I either have to buy ANOTHER development system or pay for a support incident to fix THEIR problem (the packet it sends to itself can't be right although a case should be made that the rabbit shouldn't be affected by it since the packet wasn't addressed to it anyway).

len

Hello Len,

For any network device, if the source and destination IP address were the same, the packet should never be able to reach your PC. Please contact us at the NetBurner sales extension and I can assure you we will not charge you for support if this is our problem.