Empty endpoint-serial-number

[yosnoop]

Hi,

Running gpclient 2.5.1 (2026-05-01) on Arch Linux. Everything works fine except that XQL query to panw_ngfw_hipmatch_raw dataset says the endpoint-serial-number of my session is not populated.

The machine is custom-made and there is no serial number (from dmidecode.) Might this be the reason? If so, is there a way to ship a random string as the serial number? SecOps insists.

Regards,
Ty

[yuezk]

Hi @yosnoop, thanks for your feedback. I will look into this.

[yosnoop]

I can now see it populates HOST_ID with /sys/class/dmi/id/product_uuid (my /sys/class/dmi/id/product_serial is empty) from the log. Thanks! Though it does not seem to get along with my custom HIP script and XDR still does not see the HOST_ID or ENDPOINT_SERIAL_NUMBER.

[yuezk]

@yosnoop, I think you can manually write the serial number to "/sys/class/dmi/id/product_serial". And since you are using the custom HIP script, you can read the "--host-id" parameter because the gpclient will pass the host ID to the HIP script via the "--host-id" parameter. And your HIP script can read the serial number from "/sys/class/dmi/id/product_serial". We can just test if this flow works or not.

[yosnoop]

Thanks for suggestion, @yuezk. I tried to ship those parameters via HIP script but XDR does not pick them up.

Tried to no avail:
. copied working values from Windows clients and tried them from HIP script
. added host-id and serial-number not only to the top level of XML but also under the host-info level

At this point, it appears that XDR takes those values only from Cortex XDR agent, not from the HIP report.

[yuezk]

what is "Cortex XDR agent"?

[yosnoop]

It's the PaloAlto's EDR agent running on client machines.

[yuezk]

Note: Parts of this reply about Cortex XDR were drafted with help from an AI assistant — I'm not familiar with Cortex XDR myself, so I'm not sure that section is accurate. Please take it with a grain of salt, and corrections are welcome.

Hi @yosnoop,

Thanks for the follow-up. Two separate things are getting mixed together here.

GlobalProtect (gpclient) sends host-id and serialno as HTTP form fields during portal/gateway login. On Linux, host-id comes from product_uuid (which matches what you're seeing in the logs).

For serialno, behavior depends on version:

• 2.6.x: product_serial → product_uuid → derived fallback. It should not be empty.
• 2.5.1 (your version): serialno was not sent in login requests at all. That likely explains the empty endpoint-serial-number in panw_ngfw_hipmatch_raw, more than a missing DMI fallback.

HIP report is separate (posture checks after connect). The default report includes <host-id> but not serial. Custom HIP XML won't populate Cortex XDR endpoint fields.

Cortex XDR gets ENDPOINT_SERIAL_NUMBER from the Cortex XDR agent (Palo Alto's EDR client), not from the GP HIP report.

Next steps:

1. Upgrade to 2.6.x — this is the most important step for serialno in login requests.
2. After upgrading, check logs for serialno during portal/gateway login.
3. If you need a specific value: write it to /sys/class/dmi/id/product_serial before connecting.
4. For XDR serial specifically, check whether the Cortex XDR agent is installed and reporting — that's outside GP HIP.

If you can share redacted login log lines after upgrading (showing serialno), we can confirm whether the remaining gap is GP-side or XDR-side.

[yosnoop]

Thanks for the detailed explanation, Kevin. I did some further investigation and wanted to share the findings. The following is by Claude, by the way.

Bug found: collect_linux_serial_number bypasses VMware conversion

When product_serial is empty (as it is on my machine), the fallback to product_uuid in collect_linux_serial_number returns the raw UUID string directly:

fn collect_linux_serial_number() -> Option<String> {
  ["sys/class/dmi/id/product_serial", "/sys/class/dmi/id/product_uuid"]
    .iter()
    .find_map(|path| read_linux_identity_file(path))
}

Since the raw UUID is non-empty, non_empty(serialno, derive_serial_number(&host_id)) in from_parts returns it directly, completely bypassing derive_serial_number and the VMware conversion. So serialno ends up as a raw UUID (00000000-0000-0000-0000-50e549e812cf) instead of the expected VMware format.

I confirmed this by temporarily patching redact_form_value to expose serialno in the logs. The fix should be:

fn collect_linux_serial_number() -> Option<String> {
  read_linux_identity_file("/sys/class/dmi/id/product_serial")
    .or_else(|| {
      read_linux_identity_file("/sys/class/dmi/id/product_uuid")
        .and_then(|uuid| serial_number::vmware_from_uuid(&uuid))
    })
}

XDR endpoint_serial_number — Prisma Access limitation

I tested both the raw UUID and the corrected VMware-format serial (VMware-00 00 00 00 00 00 00 00-00 00 50 e5 49 e8 12 cf) in the gateway login POST. Neither populated endpoint_serial_number in Cortex XDR (panw_ngfw_hipmatch_raw). I also tested with <host-id> and <serial-number> fields in the HIP XML (both at the top level and inside the host-info entry), which also had no effect.

Windows clients on our tenant do show real manufacturer serials (e.g. G62QNH4) in endpoint_serial_number, but Prisma Access appears not to populate that field from Linux/openconnect clients regardless of what is sent in serialno. This is likely a Prisma Access limitation outside gpclient's scope.

So in summary: the collect_linux_serial_number bug is real and worth fixing, but it won't resolve the XDR endpoint_serial_number gap — that appears to be on Palo Alto's side.

[yuezk]

Thanks, @yosnoop. Regarding the serial number derivation, I will fix it in the next release.