detect wireless links

[Antoine Martin]

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:

• test with win32 and wifi ("jitter" value should be exposed in xpra info as 1000)
• detect on Linux and macos
• detect in html5 client (see ticket:1581#comment:3)

[Antoine Martin]

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:

• ​SCNetworkConfiguration interface provides access to the stored network configuration - in particular ​SCNetworkInterfaceCopyAll
• ​Network Interface Types and ​kSCNetworkInterfaceTypeIEEE80211
• ​SCNetworkInterface is an opaque class..

[Antoine Martin]

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

...

[Antoine Martin]

Changed ticket title to reflect the work done here. This will do for now.
Follow up: #1863

[Antoine Martin]

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.

[stdedos]

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

[Antoine Martin]

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.

[stdedos]

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)

[Antoine Martin]

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/

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/1860