GP: include clientgpversion in {ssl-vpn/login.esp,global-protect/getconfig.esp} requests
I doubt it ever matters, but the official client sends it, and we already send the
identical-contents-but-differently-named `app-version` in the
/ssl-vpn/getconfig.esp request, so we should send this too for consistency
Signed-off-by: Daniel Lenski <email address hidden>
- Juniper: pass any `--local-id=TNCC_*` to TNCC script
- GPST: override host-id, os-version, or app-version with `--local-id`, and pass
any other `--local-id=HIP_*` to HIP script
Signed-off-by: Daniel Lenski <email address hidden>
This version allows the specification of multiple such MAC addresses, which
may be necessary for some VPNs which try to match all network device
identifiers to try to confirm the client hardware that they're running on.
Signed-off-by: Daniel Lenski <email address hidden>
Add CLI option --local-id, generic id_options structure, and API function openconnect_set_id_option
… and use these instead of AnyConnect specific {platform_version,device_uniqueid,device_type}
The `mobile_` prefix is misleading, since there's nothing specific to mobile OSes in the identifiers sent,
but I guess we're stuck with it at least for `openconnect_set_mobile_info` (since it's now in the library API).
Signed-off-by: Daniel Lenski <email address hidden>
Save GlobalProtect version reported by portal and parrot it back as client version
It appears that the GlobalProtect client and server software are versioned
together, so that if the portal server reports version 'X.Y.Z-W', then
the server will be satisfied that the client is up-to-date if it reports
the same value as the 'app-version' in the gateway configuration request
(/ssl-vpn/getconfig.esp).
Examples of the version tag in GlobalProtect portal XML in the wild:
There don't actually appear to be meaningful differences between the
GlobalProtect app versions in terms of backwards-incompatible protocol
changes, so this will allow OpenConnect to Just Work™ on newer server
versions that may insist on newer client versions.
Caveats:
1. The <version> tag in portal XML often contains leading/trailing space which
we need to strip.
2. If the portal XML doesn't contain <version>, or if the user connects
straight to the gateway interface, we still need a default emulated
'app-version' to fall back to.
3. As with everything else GlobalProtect, the naming of this field in the
wire protocol is incredibly inconsistent. It's called 'app-version' in
the gateway config request, which appears to be what servers frequently
verify, but it's called 'client-version' in the XML HIP report (even
though 'clientVer=4100' elsewhere in the protocol).
4. Ideally, we would allow end users to override the version reported to the
client when needed. That should be easy to do once we merge some form of https://gitlab.com/openconnect/openconnect/-/merge_requests/103.
Signed-off-by: Daniel Lenski <email address hidden>
