A5000 - diving in at the deep end!

[rubber_jonnie]

Keep us informed.

So far, no joy. I have tried SMB1 on my Windows Server 2016 (Basically much the same as Win10), Win 7 and Windows Vista, and each time the connection times out at the A5000.

What is interesting is that there is a connection attempt, I can see a SYN packet from the A5000, a SYN, ACK from the Server back to the A5000.

What I should see next is the A5000 responding with an ACK to the server, but it never does, so the TCP/IP 3 way handshake is never completed so the connection is ended by the A5000.

[HigashiJun]

@rubber_jonnie

It's just weird...

Setting a network is not so complicated, but troubleshooting it can sometimes be a nightmare.

ACORNs seem to add another level of difficulty to the task.

ECONET was not so bad after all.

[rubber_jonnie]

@rubber_jonnie

It's just weird...

Setting a network is not so complicated, but troubleshooting it can sometimes be a nightmare.

ACORNs seem to add another level of difficulty to the task.

ECONET was not so bad after all.

Yeah, it really is quite painful. Going to try Win 7 again, but with the SQE test switch on my AUI adapter turned off (Note ping still works fine on this setting)

[rubber_jonnie]

So I quickly switched back to BNC connections and I still see the same, SYN, SYN/ACK back from the fileserver, then the A5000 fails to send and ack back to the fileserver, a Win7 laptop.

Very, very odd

[rubber_jonnie]

Ok, so I have followed some SMB1 security setup details from Stardot, and also added the A5000 to LMHOSTS and tested on W10, W7, Vista and XP.

Security is also set to allow access without a username or password.

The result is the same when I try to connect, the TCP 3 way handshake fails because the final ACK is not sent back from the A5000.

This is a pretty fundamental TCP fail. No 3-way handshake means no connection, so we aren't even getting far enough to use SMB.

Ping works from the A5000 and from all the other machines, but that is ICMP, so not quite the same.

The machine where the share resides is doing a tcp retransmission for it's SYN/ACK, so that means that we have two possible scenarios.
The SYN/ACK from the Windows machine is being ignored, so the A5000 just never responds.
The SYN/ACK from the Windows machine never arrives at the A5000, so it never sends a response.
If I set up a mirror port on my switch and capture with Wireshark when I try to connect, if I can see the SYN/ACK heading towards the A5000 but then nothing comes back, then I will know it's the A5000.

If I don't see the SYN/ACK at the port then it's getting lost between the Windows machine and the switch.

Might also sound silly, but I will change the cable, you never know.

More on this later...

[stephen_usher]

You have got the correct netmask on both ends don't you?

Also, what's the routing table on the A5000 look like?

[rubber_jonnie]

You have got the correct netmask on both ends don't you?

Also, what's the routing table on the A5000 look like?

Yes, it's all a 24 bit netmask and I can ping from each machine to each other with no issues. I can also ping outside devices on the internet such as 8.8.8.8, so TCP/IP is working, but for some reason when I try to connect to another machine using SMB, I don't get the final SYN back, so I need to work out how far it is getting.

As for the routing table, difficult to say, as the route command isn't showing me the routing tables when I use the -a switch, but arp -a does show up any devices I have pinged.

It's a flat 192.168.1.0/24 network, so routing shouldn't be an issue, plus if I ping, the destination is found.

I need to figure out if the SYN/ACK from the Windows machine is getting to the A5000, because the SYN arrives from the A5000 at the Windows machine just fine, which suggests routing is not an issue.

[stephen_usher]

There will be an internal routing table within the TCP/IP stack to tell the system which hardware interface to route the packets to/from.

You need to check if this is being set up correctly as some TCP/IP stacks don't do this and they have to be set manually,

It's the equivalent of 'netstat -r' or 'route'

[HigashiJun]

As you wrote, it's really odd.

Has somebody managed to connect his machine on Stardot forum ?

[rubber_jonnie]

There will be an internal routing table within the TCP/IP stack to tell the system which hardware interface to route the packets to/from.

You need to check if this is being set up correctly as some TCP/IP stacks don't do this and they have to be set manually,

It's the equivalent of 'netstat -r' or 'route'

I tried both commands earlier and neither show me anything, I just come straight back to the CLI. In addition, I can ping the A5000 from any of my test machines just fine, so it is reachable. There is no netstat...

I did set up a mirror port on my switch earlier today, and the SYN/ACK isn't getting lost up to that point, which means it's the cable, the NIC or a TCP stack issue on the A5000. I don't believe the AUI adapter is bad, as it had the same problem of the A5000 not responding to the SYN/ACK when I tested using the BNC cable yesterday.

Ideally I need to get a packet capture as close as possible to the machine, which would mean a packet capture on the machine itself (Unlikely), or something between my switch and the machine.

BTW I just figured out that whilst I can't see the full routing table by using "route get -host <HOSTNAME>" I can look at individual routes and they look fine and are auto added:

PXL_20231124_144143063.jpg

Of note is that when I used 8.8.8.8 as my target, it resolved to dns.google

And in fact if I do a "route get -net 192.168.1.0 255.255.255.0" I get this:

PXL_20231124_144653568.jpg

So the default route to the rest of the network is via the ethernet card.

So unless the cable is faulty, there is an issue either with my cable (I will try another), the NIC or the software.