Xiongmai X6E-WEQ and IPG-X6-WEQ2

Xiongmai · dual-lens IP camera, 6 MP OEM module with a pan-tilt head · X6E-WEQ

what it is

A Xiongmai electronics module sold to camera manufacturers — the housing carries no brand, and the same module ends up in housings from different companies. X6E-WEQ is built on the XM535 chip, IPG-X6-WEQ2 on the older XM530; both variants behave almost the same on the network.

Two lenses, one stream. The camera has a fixed lens and a second one on a pan-tilt head, but delivers them as a single 2304 × 2592 frame — two 2304 × 1296 images stitched vertically. Measured: the bottom lens is the movable one. Channels 2 and 3 in the RTSP URL deliver the same stitched frame, so the images can be separated only by the receiver, by cropping the top and bottom.

The body is most likely a bullet with a pan-tilt head in a single housing, but there are no dimensions or drawings at all — the module manufacturer's domain does not exist. The MAC prefix (00:12:33, 00:12:34) does not identify the manufacturer.

what we read from it

• Main stream H.265, 2304 × 2592. The configuration declares 25 fps, measured on X6E-WEQ: 12. The substream is disabled by default. A browser will not play H.265, so without an H.264 substream the preview requires transcoding.
• ONVIF: motion events computed in the camera, pan-tilt control, image settings.
• DVRIP: system information and configuration — network, NTP, encoding, cloud, address filter.
• The camera accepts at most 10 TCP connections.

SNMP does not respond.

the flag that opens ONVIF

The NetWork.OnvifPwdCheckout setting decides whether ONVIF requires a password. Measured on two units:

• true — anonymous GetUsers returns 401;
• false — ONVIF responds to everything without login, lists the accounts, and returns the stream and snapshot URLs with the username and password embedded in the URL.

This is a setting, not a firmware version: a single configuration change switches the camera either way. The manufacturer's bulletin recommends enabling ONVIF password verification. The flag state is worth checking periodically, not once.

measured pitfalls

• RTSP ignores the path. /stream0, /live/ch0, /11 and the native XM format all give the same image — a "working URL” proves nothing.
• DVRIP login goes over plaintext TCP, and the password as an 8-character hash without a nonce. A captured hash logs in just like the password.
• The camera is bound to the XMEye cloud (AppBindFlag.BeBinded = true, NAT to the cloud server) and connects outbound. A person with the linked account has access to it from outside the network.
• The factory time servers are external, including two Chinese ones. The camera restarts itself on Thursdays at 2:00 — this is the factory AutoMaintain setting.
• Continuous head movement is not symmetric: 1.2 s to the right and 1.2 s to the left does not return to the same spot, and the position reading returns −1.0. Return is possible only via a preset or the home position.
• The HTTP snapshot and an RTSP frame have different brightness — frames from these two paths cannot be compared directly.
• One MAC, two addresses. An old DHCP lease can respond alongside the new one. A scan will count two devices; which address is the correct one is stated by the camera in its network configuration.

what we cannot read

• Two separate images from the source — the camera does not separate them.
• Absolute head position.
• Anything over SNMP.
• Dimensions, weight and power — no verified datasheet; the absence of any mention of PoE does not prove that it lacks it.

full parameter list

A full parameter list for this model is not here yet — the ones described above are those we have read and verified. A missing list does not mean the device exposes nothing more.