xpra icon
Bug tracker and wiki

Opened 5 months ago

Closed 5 months ago

Last modified 4 months ago

#1860 closed enhancement (fixed)

detect wireless links

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.4
Component: network Version: 2.3.x
Keywords: Cc:

Description

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)

Attachments (2)

xpra-net-info.log (5.6 KB) - added by stdedos 4 months ago.
xpra-bug-report.log (86.4 KB) - added by stdedos 4 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 months ago by Antoine Martin

Status: newassigned

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:

Last edited 5 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 5 months ago by 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

...
Last edited 5 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 5 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed
Summary: detect network jitterdetect wireless links

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

comment:4 Changed 4 months ago by 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.

comment:5 Changed 4 months ago by 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

Changed 4 months ago by stdedos

Attachment: xpra-net-info.log added

Changed 4 months ago by stdedos

Attachment: xpra-bug-report.log added

comment:6 Changed 4 months ago by 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.

comment:7 Changed 4 months ago by 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)

comment:8 Changed 4 months ago by 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/

Note: See TracTickets for help on using tickets.