Description
I have just installed the latest version of witr (v0.3.3) on Windows to inspect the ports opened by running processes, especially TCP ports in the LISTEN state.
Unfortunately, the Ports tab does not appear to work correctly on Windows.
Windows
Environment:
- OS: Windows 11 Pro (German locale)
- witr: v0.3.3
- Shell: PowerShell 7.5.2
- Tested both as a normal user and as Administrator
In the Ports tab, only open UDP ports are displayed. TCP ports in the LISTEN state are missing completely.
However, when pressing a (Toggle All), TCP ports suddenly become visible as well. At that point, however, the TUI becomes unusable: the display is corrupted, rows can no longer be selected, and scrolling up/down does not work correctly.
In other words, enabling Toggle All makes the Ports tab effectively unusable.
I have attached a screenshot showing the resulting display.
Interestingly, the TCP ports that become visible after enabling Toggle All are not shown with the state LISTEN, but as ABHÖREN (German Windows localization). In my terminal this is partially displayed as ABH?REN.
This may be related to the fact that Windows is using a German locale and could indicate an additional localization/encoding issue.
The behavior is identical when running witr as Administrator or as a normal user.
Linux comparison
I also tested witr v0.3.3 on Ubuntu 24.04, running inside a QEMU/KVM virtual machine (not WSL2).
The behavior is different there:
Unprivileged user
When running witr as a normal user, the Ports tab shows no ports at all:
- no UDP ports
- no TCP ports
This also remains the case after using Toggle All.
Root
When running witr as root, the behavior is almost the opposite of Windows:
- UDP ports are not shown by default
- TCP ports are shown
- after pressing
a (Toggle All), both TCP and UDP ports are displayed
Unlike on Windows, the TUI remains fully functional in this state. Rows can be selected and the table can be scrolled normally.
Expected behavior
The Ports tab should consistently display the available TCP and UDP sockets according to their state and the user's privileges.
In particular:
- TCP sockets in
LISTEN state should be visible without requiring Toggle All.
Toggle All should reveal the other socket states without breaking the TUI.
- The Ports table should remain fully interactive after toggling all states.
- Port state names should ideally not depend on the localized output of the underlying operating system, or should at least be handled correctly for non-English Windows installations.
Actual behavior
| Platform |
User |
Default |
After Toggle All |
| Windows |
normal user |
UDP only |
TCP appears, but TUI becomes unusable |
| Windows |
Administrator |
UDP only |
TCP appears, but TUI becomes unusable |
| Ubuntu 24.04 |
normal user |
no ports |
no ports |
| Ubuntu 24.04 |
root |
TCP only |
TCP + UDP, TUI works correctly |
This makes me suspect that there may be platform-specific issues in the port enumeration/parsing code, particularly around Windows socket state parsing and/or localized command output.
The Windows-specific rendering issue after Toggle All may be a separate TUI/terminal handling problem.
Screenshot
Attached: witr Ports tab after enabling Toggle All on German Windows.
Disclaimer
This bug report was written with the assistance of ChatGPT. The technical observations, test results, environments, and reproduction details are my own.
To Reproduce
No response
OS
Windows 11 Pro
Version
v0.3.3
Architecture
amd64
Additional context
No response
Description
I have just installed the latest version of
witr(v0.3.3) on Windows to inspect the ports opened by running processes, especially TCP ports in theLISTENstate.Unfortunately, the Ports tab does not appear to work correctly on Windows.
Windows
Environment:
In the Ports tab, only open UDP ports are displayed. TCP ports in the
LISTENstate are missing completely.However, when pressing
a(Toggle All), TCP ports suddenly become visible as well. At that point, however, the TUI becomes unusable: the display is corrupted, rows can no longer be selected, and scrolling up/down does not work correctly.In other words, enabling
Toggle Allmakes the Ports tab effectively unusable.I have attached a screenshot showing the resulting display.
Interestingly, the TCP ports that become visible after enabling
Toggle Allare not shown with the stateLISTEN, but asABHÖREN(German Windows localization). In my terminal this is partially displayed asABH?REN.This may be related to the fact that Windows is using a German locale and could indicate an additional localization/encoding issue.
The behavior is identical when running
witras Administrator or as a normal user.Linux comparison
I also tested
witrv0.3.3 on Ubuntu 24.04, running inside a QEMU/KVM virtual machine (not WSL2).The behavior is different there:
Unprivileged user
When running
witras a normal user, the Ports tab shows no ports at all:This also remains the case after using
Toggle All.Root
When running
witras root, the behavior is almost the opposite of Windows:a(Toggle All), both TCP and UDP ports are displayedUnlike on Windows, the TUI remains fully functional in this state. Rows can be selected and the table can be scrolled normally.
Expected behavior
The Ports tab should consistently display the available TCP and UDP sockets according to their state and the user's privileges.
In particular:
LISTENstate should be visible without requiringToggle All.Toggle Allshould reveal the other socket states without breaking the TUI.Actual behavior
Toggle AllThis makes me suspect that there may be platform-specific issues in the port enumeration/parsing code, particularly around Windows socket state parsing and/or localized command output.
The Windows-specific rendering issue after
Toggle Allmay be a separate TUI/terminal handling problem.Screenshot
Attached:
witrPorts tab after enablingToggle Allon German Windows.Disclaimer
This bug report was written with the assistance of ChatGPT. The technical observations, test results, environments, and reproduction details are my own.
To Reproduce
No response
OS
Windows 11 Pro
Version
v0.3.3
Architecture
amd64
Additional context
No response