This can cause warnings to show up (#1855). We should detect wifi connections and set a high jitter value, making us ignore late acks and adapting better.
server and win32 client code added in r19523.
Still TODO:
Improvements and Linux support added in r19561.
On my laptop, I now get the correct adapter type detected for my wlan:
Network interfaces found:
* lo (index=1)
* IPv4: 127.0.0.1
* IPv6: ::1
* virbr0 (index=3)
* IPv4: 192.168.124.1
no ethtool interface speed available for virbr0
{'firmware-version': 'N/A', 'bus-info': 'N/A', 'version': '2.3', 'driver': 'bridge', 'adapter-type': 'wireless'}
* virbr0-nic (index=4)
* wlan0 (index=5)
* IPv4: 192.168.1.28
no ethtool interface speed available for wlan0
{'firmware-version': '01-e791c176', 'bus-info': '0000:3a:00.0', 'version': '7.35.180.119', 'driver': 'brcmfmac', 'adapter-type': 'wireless'}
* IPv6: fe80::a7b5:a760:9c90:dc0e%wlan0
no ethtool interface speed available for wlan0
{'firmware-version': '01-e791c176', 'bus-info': '0000:3a:00.0', 'version': '7.35.180.119', 'driver': 'brcmfmac', 'adapter-type': 'wireless'}
Gateways found:
* INET
[0] 192.168.1.1, wlan0, True
...
I was also hoping that the "statistics" sysfs directory would contain some errors after I walked out of range of the AP with the laptop, but no such luck. Wherever the wireless transmit / receive errors are stored, it isn't obvious.
For macos:
Partial macos support added in r19565.
Only problem with this one is that there is no way to get from a socket (or its file descriptor) to the SCNetworkInterface required by Apple's API..
So we only match the details if we have the BSD interface name (ie: en0, but usually we don't have it...) or if there is only one interface to choose from.
Here's what Network_info shows now:
* lo0 (index=1)
* IPv6: ::1
* IPv6: fe80::1%lo0
* IPv4: 127.0.0.1
* gif0 (index=2)
* stf0 (index=3)
* en0 (index=4)
* IPv6: fe80::a00:27ff:fe51:bf14%en0
{'name': 'en0', 'hardware-address': '08:00:27:51:bf:14', 'adapter-type': 'Ethernet', 'protocols': ('DNS', 'IPv4', 'IPv6', 'Proxies', 'SMB')}
* IPv4: 192.168.1.5
{'name': 'en0', 'hardware-address': '08:00:27:51:bf:14', 'adapter-type': 'Ethernet', 'protocols': ('DNS', 'IPv4', 'IPv6', 'Proxies', 'SMB')}
Gateways found:
* INET
[0] 192.168.1.1, en0, True
...
Changed ticket title to reflect the work done here. This will do for now. Follow up: #1863
To verify that this is working as intended, connect via a wireless link and check:
$ xpra info | grep jitter client.jitter=1000
The value for jitter should be non-zero for wireless links, and zero for ethernet.
Well, I don't see that coming on my laptop :/ (check attachment for Intel(R) Centrino(R) Ultimate-N 6300 AGN Driver)
xpra v2.4-r19614 both client and server
Right-clicking the tray icon --> Information nothing responds for
xpra start ssh://user@ip --start=gnome-terminal
MS Windows exposes this adapter as 802.3:
{'index': 3, 'product-name': 'Intel(R) Centrino(R) Ultimate-N 6300 AGN Driver', \
'description': 'Intel(R) Centrino(R) Ultimate-N 6300 AGN Driver', \
'adapter-type': 'Ethernet 802.3', \
'caption': '[00000003] Intel(R) Centrino(R) Ultimate-N 6300 AGN Driver', \
'GUID': '{6AF32174-49DF-4CAC-A970-8AB13BF62B12}', 'speed': 450000000, \
'id': 3, 'name': 'Intel(R) Centrino(R) Ultimate-N 6300 AGN'}
So there isn't much we can do. The driver should report itself as wireless.
Can I pass it with a client environment variable, or a (long) flag manually? (I do remember the server passing, however I'd wish I could "forget" about the server)
Can I pass it with a client environment variable, or a (long) flag manually? (I do remember the server passing, however I'd wish I could "forget" about the server)
As of r19642 you can overrule the network "adapter-type" detection code on the client with the env var:
set XPRA_NETWORK_ADAPTER_TYPE=wifi
On the server, you can achieve a similar result with:
XPRA_ACK_JITTER=1000 xpra start ...
The problem with the server setting is that it will apply to all clients, whether they are actually wireless or not, which can have detrimental effects when they're not.
You can find beta builds with these changes here: https://xpra.org/beta/
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1860