WTware RDP client

by **akatik** » Mon Feb 24, 2025 3:03 pm

Windows TFTP client is easier to reproduce for me.

Do I understand correctly, on the same virtual machine, with the same network environment, no other changes, only:

1. Turn off SolarWinds TFTP, start WTware TFTP service, and Windows TFTP client tftp.exe from another windows machine won't download file.

2. Turn off WTware TFTP service, start SolarWinds TFTP and Windows TFTP client tftp.exe from another windows machine can download file.

Right?

Please, send me Wireshark sniffs for both cases to investigate.

Also from Administrative command prompt please show me output of command (remove sensitive info if it's working server, I only want to see information about UDP :69 port for 0.0.0.0 and other IP addresses):

Code: Select all

netstat -anbp udp

For three cases:

1. No TFTP server running. To be sure USB :69 port is unused in this case.

2. WTware TFTP service running.

3. SolarWinds TFTP server running.

Thank you for assistance.

by **felixtech** » Sun Feb 23, 2025 9:46 pm

After way more testing of all possible scenarios and temporarily replacing WTware TFTP with SolarWinds TFTP I can now 100% sure say that there is no network issue and WTware TFTP is handling certain requests wrong. When using SolarWinds TFTP everything works perfectly fine. WTware TFTP refuses to reply to requests from terminals with PhoenixBIOS.

by **felixtech** » Sun Feb 23, 2025 8:56 pm

akatik wrote: Sun Feb 23, 2025 7:53 pm Firewall. Or broken IP stack on Windows. WTware TFTP service logs everything it receives, even if it won't answer. No log - no data from network received.

Firewall was disabled. Server and Clients are on the same network. Receiving data was confirmed with Wireshark. WTware has received the packets and chose to ignore them. But after the first successful EFI boot the logging now works properly.

akatik wrote: Sun Feb 23, 2025 7:53 pm Broken network. WTware TFTP receives first TFTP packet but does not receive sequent packet from client.

This is not the case. WTware received the read request and did not send back block 0 as required per TFTP protocol. This is not a network issue, because if WTware would have properly handled the request, I would have seen the packet in Wireshark, even if there was any issue with the firewall or network stack.

akatik wrote: Sun Feb 23, 2025 7:53 pm WTware TFTP service sends packet if it complains "Timeout occured" in log. Sure. Something is wrong with your network.

It has chosen not to respond and did not react to the incoming package. This is 100% proven that WTware refuses to respond, for whatever reason.

akatik wrote: Sun Feb 23, 2025 7:53 pm Are you using physical hardware or virtual? Misconfigured virtual network may produce such brain-damaged issues. Try physical hardware.

Virtual. VMware ESXi 8 with VMXNET3 network interface.
I do not have the option to use physical hardware at this customer. It has to work with VMware.

akatik wrote: Sun Feb 23, 2025 7:53 pm EFI can not boot with wtware.pxe. wtware.pxe is for legacy BIOS only. No way to make same binary for network boot on legacy BIOS and EFI.
Configure DHCP to send "6.2.50\bootx64.efi" for EFI clients.

This is configured for EFI. My DHCP can distinguish between EFI and BIOS. The EFI part works, the BIOS part doesn't.
I did not show any logs from the EFI part, because it works normally.

by **akatik** » Sun Feb 23, 2025 7:53 pm

felixtech wrote: Sat Feb 22, 2025 6:57 pm When a Thin Client is starting, I can see that it obtained an IP, I can also see in Wireshark that the read request packets are incoming on port 69/udp. WTware doesn't bother to reply to those requests or even to log anything.

Firewall. Or broken IP stack on Windows. WTware TFTP service logs everything it receives, even if it won't answer. No log - no data from network received.

felixtech wrote: Sat Feb 22, 2025 6:57 pm When trying with the Windows TFTP client, I get the following log output:

Code: Select all

16-35-32-583| [192.168.45.7] RRQ 24 bytes:
16-35-32-583| [192.168.45.7] 00000000: 36 2e 32 2e 35 30 2f 77 74 77 61 72 65 2e 70 78
16-35-32-583| [192.168.45.7] 00000010: 65 00 6f 63 74 65 74 00
16-35-32-583| [192.168.45.7] "6.2.50\wtware.pxe": tsize is not requested, blksize default.
16-35-32-583| [192.168.45.7] "6.2.50\wtware.pxe": "C:\Program Files (x86)\WTware\TFTPDROOT\6.2.50\wtware.pxe".
16-35-32-599| [192.168.45.7] Timeout occured while transfer "6.2.50\wtware.pxe".
16-35-32-599| [192.168.45.7] Resend block 1.

Broken network. WTware TFTP receives first TFTP packet but does not receive sequent packet from client.

felixtech wrote: Sat Feb 22, 2025 6:57 pm Again I can see in Wireshark that the read request packets come in but WTware doesn't respond to those packets.

WTware TFTP service sends packet if it complains "Timeout occured" in log. Sure. Something is wrong with your network.

Are you using physical hardware or virtual? Misconfigured virtual network may produce such brain-damaged issues. Try physical hardware.

felixtech wrote: Sun Feb 23, 2025 12:09 am After additionally configuring the EFI boot variant in the DHCP the EFI boot version now works.
..
But it doesn't actually boot.
Code: Select all
21-04-35-408| [192.168.45.204] "6.2.50\wtware.pxe": tsize is requested, blksize default.

EFI can not boot with wtware.pxe. wtware.pxe is for legacy BIOS only. No way to make same binary for network boot on legacy BIOS and EFI.

Configure DHCP to send "6.2.50\bootx64.efi" for EFI clients.

http://wtware.com/docs5/dhcp.html

by **felixtech** » Sun Feb 23, 2025 12:09 am

After additionally configuring the EFI boot variant in the DHCP the EFI boot version now works.

And the BIOS version produces log output. (I don't get why the TFTP server needed a successful EFI boot before it produced logs.)
When attempting a BIOS network boot, the terminal MAC address shows up in WTware Configurator.
But it doesn't actually boot. The error below is shown in the TFTP log.

Code: Select all

21-04-35-392| [192.168.45.204] RRQ 32 bytes:
21-04-35-408| [192.168.45.204] 00000000: 36 2e 32 2e 35 30 2f 77 74 77 61 72 65 2e 70 78
21-04-35-408| [192.168.45.204] 00000010: 65 00 6f 63 74 65 74 00 74 73 69 7a 65 00 30 00
21-04-35-408| [192.168.45.204] "6.2.50\wtware.pxe": tsize is requested, blksize default.
21-04-35-408| [192.168.45.204] "6.2.50\wtware.pxe": "C:\Program Files (x86)\WTware\TFTPDROOT\6.2.50\wtware.pxe".
21-04-35-408| [192.168.45.204] Received opcode ERR.

by **felixtech** » Sat Feb 22, 2025 6:57 pm

I have updated to WTware 6.2.50 which did not change the issue in any way.

This is the log output after starting the TFTP service:

Code: Select all

16-27-12-012| WTware TFTP server v.6.2.50 (c) 2003-2025 WTware http://www.wtware.com
16-27-12-012| Found interface 192.168.45.19/255.255.255.0 mtu 1492 mac 00:0C:29:C0:98:2B adapter Ethernet-Adapter für vmxnet3.
16-27-12-012| Bind at 0.0.0.0:69.

When a Thin Client is starting, I can see that it obtained an IP, I can also see in Wireshark that the read request packets are incoming on port 69/udp. WTware doesn't bother to reply to those requests or even to log anything.

When trying with the Windows TFTP client, I get the following log output:

Code: Select all

16-35-29-591| [192.168.45.7] RRQ 24 bytes:
16-35-29-607| [192.168.45.7] 00000000: 36 2e 32 2e 35 30 2f 77 74 77 61 72 65 2e 70 78
16-35-29-607| [192.168.45.7] 00000010: 65 00 6f 63 74 65 74 00
16-35-29-607| [192.168.45.7] "6.2.50\wtware.pxe": tsize is not requested, blksize default.
16-35-29-607| [192.168.45.7] "6.2.50\wtware.pxe": "C:\Program Files (x86)\WTware\TFTPDROOT\6.2.50\wtware.pxe".
16-35-30-591| [192.168.45.7] RRQ 24 bytes:
16-35-30-591| [192.168.45.7] 00000000: 36 2e 32 2e 35 30 2f 77 74 77 61 72 65 2e 70 78
16-35-30-591| [192.168.45.7] 00000010: 65 00 6f 63 74 65 74 00
16-35-30-591| [192.168.45.7] "6.2.50\wtware.pxe": tsize is not requested, blksize default.
16-35-30-591| [192.168.45.7] "6.2.50\wtware.pxe": "C:\Program Files (x86)\WTware\TFTPDROOT\6.2.50\wtware.pxe".
16-35-32-583| [192.168.45.7] RRQ 24 bytes:
16-35-32-583| [192.168.45.7] 00000000: 36 2e 32 2e 35 30 2f 77 74 77 61 72 65 2e 70 78
16-35-32-583| [192.168.45.7] 00000010: 65 00 6f 63 74 65 74 00
16-35-32-583| [192.168.45.7] "6.2.50\wtware.pxe": tsize is not requested, blksize default.
16-35-32-583| [192.168.45.7] "6.2.50\wtware.pxe": "C:\Program Files (x86)\WTware\TFTPDROOT\6.2.50\wtware.pxe".
16-35-32-599| [192.168.45.7] Timeout occured while transfer "6.2.50\wtware.pxe".
16-35-32-599| [192.168.45.7] Resend block 1.
16-35-32-599| [192.168.45.7] Timeout occured while transfer "6.2.50\wtware.pxe".
16-35-32-599| [192.168.45.7] Resend block 1.
16-35-34-612| [192.168.45.7] Timeout occured while transfer "6.2.50\wtware.pxe".
16-35-34-612| [192.168.45.7] Resend block 1.
16-35-34-612| [192.168.45.7] Timeout occured while transfer "6.2.50\wtware.pxe".
16-35-34-612| [192.168.45.7] Resend block 1.

Again I can see in Wireshark that the read request packets come in but WTware doesn't respond to those packets.

by **akatik** » Sat Feb 22, 2025 5:18 pm

felixtech wrote: Sat Feb 22, 2025 12:45 am I attempted to network boot. THe DHCP options are all set correctly (verified with test software) but every client gets a DHCP IP address and then shows a TFTP timeout. Testing locally on the WTware server the TFTP file can be obtained with a test client. Remotely from any different PC the TFTP server refuses to send anything back and simulates a timeout. Windows Firewall was disabled. I have checked with Wireshark and I can see that the client requests the file at the server. The server doesn't even try to send anything back and just comes up with "Timeout occured while transfer "5.6.24\wtware.pxe". Resend block 1." As proven per Wireshark, the server simulates this timeout but it doesn't occur for real.
Any ideas how to fix the TFTP server?

1. Close WTware Configurator.
2. Restart WTware TFTP service. After restart WTware TFTP service writes IP settings to log. I want to see it.
3. Run WTware Configurator.
4. In top left corner press icon with wrench. Open TFTP service.
5. Reboot thin client.
6. Save TFTP service log and send it here or to support@wtware.com

felixtech wrote: Sat Feb 22, 2025 12:45 am server. The server doesn't even try to send anything back and just comes up with "Timeout occured while transfer "5.6.24\wtware.pxe". Resend block 1." As proven per Wireshark, the server
...
As a test I then tried the CD boot version. I can get to the login screen where it shows me "CredSSP connection failed."
I am connecting to a Windows Server 2022 with all Windows Updates installed
... Or how to make NLA work?

Install new WTware version. 5.6.24 was released four years, before Windows Server 2022.

by **felixtech** » Sat Feb 22, 2025 12:45 am

Hello,

I was now playing with WTware for many hours but got absolutely nothing to work.

I attempted to network boot. THe DHCP options are all set correctly (verified with test software) but every client gets a DHCP IP address and then shows a TFTP timeout. Testing locally on the WTware server the TFTP file can be obtained with a test client. Remotely from any different PC the TFTP server refuses to send anything back and simulates a timeout. Windows Firewall was disabled. I have checked with Wireshark and I can see that the client requests the file at the server. The server doesn't even try to send anything back and just comes up with "Timeout occured while transfer "5.6.24\wtware.pxe". Resend block 1." As proven per Wireshark, the server simulates this timeout but it doesn't occur for real.

As a test I then tried the CD boot version. I can get to the login screen where it shows me "CredSSP connection failed."
I am connecting to a Windows Server 2022 with all Windows Updates installed. After disabling NLA on the server it works.

Any ideas how to fix the TFTP server? Or how to make NLA work?

WTware RDP client

unable to boot

Post a reply

Expand view Topic review: unable to boot

Re: unable to boot

Re: unable to boot

Re: unable to boot

Re: unable to boot

Re: unable to boot

Re: unable to boot

Re: unable to boot

unable to boot