Camera E1 (FW 4.5.20_0020) — NAS/SMB setup fails at "permission verification" — packet-level diagnosis shows camera never opens an SMB session despite successful discovery

Developer Hub
, ,
1

Camera E1 (FW 4.5.20_0020) — NAS/SMB setup fails at “permission verification” — packet-level diagnosis shows camera never opens an SMB session despite successful discovery

Hi Aqara team and community,

I’m reporting a reproducible NAS storage bug on two Camera E1 units, diagnosed down to the packet level. I’ve already sent a detailed report to support@aqara.com on 15/08 (no response yet as of this post), and wanted to also share it here in case a staff member can pick it up or others are hitting the same issue.

Devices: 2x Camera E1, firmware 4.5.20_0020, algorithm 3.6.0 (both identical). Both have a microSD card inserted and confirmed working.

History: NAS storage was previously working correctly on one of these two cameras. After adding a second, new E1 to the account, NAS broke on BOTH cameras — including the one that was previously working. Both were factory reset and re-added fresh, and NAS setup now fails identically on both with: “Verification of permission is not okay, try again.”

Testing performed: To rule out a server-side cause, I tested against two completely different SMB servers on the same LAN as the cameras:

  1. TrueNAS SCALE 25.10.6, with a dedicated SMB user (username/password).
  2. A separate, minimal Samba container configured for fully open guest-only access (no credentials required at all).
  3. QNAP Storage, with a dedicated SMB user (username/password).

Both failed identically. Both servers were confirmed reachable and correctly configured — a Windows 11 PC on the same subnet connects to one of the shares successfully using the same credentials.

Packet-level finding (the key result): In every attempt, the camera successfully completes NetBIOS discovery (UDP port 137) — sends a valid NBSTAT query, receives a well-formed reply with server name/workgroup (confirmed via hex dump, fully RFC-compliant). After that, the camera never sends a single packet to port 139 or port 445 — no SMB session is ever attempted, regardless of whether the target requires auth or not. This was confirmed across repeated attempts with extended capture windows on both test servers.

Since this reproduces identically against two independent SMB implementations, the server side is ruled out. The failure is isolated to the camera’s own client logic between successful discovery and session initiation.

Ruled out: network/VLAN isolation, SMB protocol version mismatch, NTLM/auth incompatibility, packet corruption (initially suspected a UDP checksum issue, traced to TX checksum offload on a test VM’s NIC — fixed and confirmed not the cause), SD card issues, stale pairing state, server misconfiguration.

Has anyone else on 4.5.20_0020 seen this? Would appreciate any input from Aqara staff on whether this is a known regression, and whether a firmware fix or rollback is possible given it was working before. Raw packet capture in a follow-up reply below.

Thanks!
Luca

2

Hi there, it looks like you’re experiencing a support-related issue. We’ve automatically created a support ticket for you and will reach out via the forum email within the next two business days.

If other members have any suggestions or insights on this topic, feel free to share!

3

Follow-up with the raw packet capture referenced above, for anyone who wants to verify directly.

This is the NetBIOS Name Service (NBNS) exchange between the camera (CAMERA_IP) and the test SMB server (SERVER_IP) during a NAS setup attempt. Captured with tcpdump -i <iface> host <camera-ip> and port 137 -n -X.

Camera’s NBSTAT query (wildcard name, type 0x21):

HH:MM:SS.ssssss IP CAMERA_IP.46127 > SERVER_IP.137: UDP, length 50
        0x0000:  4500 004e e12d 4000 4011 e74a XXXX XXXX  E..N.-@.@..J....
        0x0010:  XXXX XXXX b42f 0089 003a 97f1 0260 0010  ...../...:...`..
        0x0020:  0001 0000 0000 0000 2043 4b41 4141 4141  .........CKAAAAA
        0x0030:  4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
        0x0040:  4141 4141 4141 4141 4100 0021 0001       AAAAAAAAA..!..

Server’s reply — valid, well-formed, RFC-compliant (clean checksum after ruling out a TX-offload red herring on the test VM’s NIC):

HH:MM:SS.ssssss IP SERVER_IP.137 > CAMERA_IP.46127: UDP, length 229
        0x0000:  4500 0101 0782 4000 4011 c043 XXXX XXXX  E.....@.@..C....
        0x0010:  XXXX XXXX 0089 b42f 00ed 2780 0260 8400  ......../..'..`.
        0x0020:  0000 0001 0000 0000 2043 4b41 4141 4141  .........CKAAAAA
        0x0030:  4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
        0x0040:  4141 4141 4141 4141 4100 0021 0001 0000  AAAAAAAAA..!....
        0x0050:  0000 00ad 0753 4552 5645 5220 2020 2020  .....SERVER.....
        0x0060:  2020 2020 0004 0053 4552 5645 5220 2020  .......SERVER...
        0x0070:  2020 2020 0304 0053 4552 5645 5220 2020  .......SERVER...
        0x0080:  2020 2020 2004 0001 025f 5f4d 5342 524f  ..........__MSBRO
        0x0090:  5753 455f 5f02 0184 0057 4f52 4b47 524f  WSE__....WORKGRO
        0x00a0:  5550 2020 2020 2020 2020 2020 0084 0057  UP..........W
        0x00b0:  4f52 4b47 524f 5550 2020 2020 2020 2020  ORKGROUP........
        0x00c0:  2020 1d04 0057 4f52 4b47 524f 5550 2020  ....WORKGROUP..
        0x00d0:  2020 2020 2020 2020 1e84 0000 0000 0000  ................
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0100:  00                                       .

Decoding this reply: server name SERVER, browser service entry __MSBROWSE__, workgroup WORKGROUP — all correctly formed NBSTAT response fields, nothing malformed or unexpected.

Immediately after this exchange, a wider capture on ports 137/138/139/445 shows nothing further from the camera — no SYN to 139, no SYN to 445, for the remainder of the capture window (well beyond the app’s error response time). This was reproduced across multiple attempts against two different SMB servers with identical results.

Happy to re-capture and share a full .pcap file directly if Aqara engineering wants to inspect it in Wireshark.

2 Likes
4

Hi there, our support team will reach out to you and send you the beta firmware shortly.

5

Hi there,

many thanks for the update and I can confirm that I have got also the email response with a beta version of the IOS App.

Already made some tests with this temporary App and I was able to configure again from scratch both cameras using and pointing to an external NAS.

Thanks and Regards,
Luca

3 Likes
6

I have the same issue on Aqara E1 FW 4.5.20_0012 and the latest app version iOS V6.3.9. Do you have a timeline when the bug fix will be released? Thank you.

7

Hi there,

here the response I have got from Aqara Technical Support :

  • This issue will be resolved and improved in the new version of the Aqara Home app (V6.4.0) within this month if all process test smoothly

So in general will be fixed soon but without any specific ETA time frame.
If you need it, probably, you can also contact them via mail and ask for having the beta version of the App.

Regards,
Luca

2 Likes
8

“TrueNAS SCALE 25.10.6, with a dedicated SMB user (username/password).”

Try to restart the camera after fill and save user/pass credentials.