netbios: `nbns_resolve` with a list of names now raises `TypeError: unhashable type: 'list'` (since #5115)

[IcantFind-a-username]

Brief description

Since #5115 ("netbios: key the NBNS resolver cache by name"), calling nbns_resolve with a list of names fails in the cache lookup, because the list is used inside the cache key (qname, raw). Before #5115 the same call did not fail there: it went on to build the request from the list and pass it to sr1.

The type hint says qname: str, so a list may simply not be supported; if so, please close this. Reporting it because the behavior changed with the cache change, and scapy fields otherwise accept lists (one packet per value).

Scapy version

master at c5e9a5b (2026-09-26)

Python version

3.10

Operating system

Linux (Docker)

Additional environment information

No response

How to reproduce

from unittest import mock
from scapy.layers.netbios import nbns_resolve

with mock.patch("scapy.layers.netbios.conf.route.get_if_bcast", return_value=["192.0.2.255"]):
    nbns_resolve(["ALPHA", "BETA"], iface="test")

Actual result

  File ".../scapy/config.py", line 395, in __contains__
    if not super(CacheInstance, self).__contains__(item):
TypeError: unhashable type: 'list'

Expected result

Either the pre-#5115 behavior, or a clear error saying that only a single name is accepted. (An empty list now fails the same way in the cache lookup; before #5115 it failed later, while sending.)

Related resources

#5115 (cc @KernelClint). Found by differential testing of recent pull requests and reproduced by hand on current master.

[KernelClint]

Before #5115 a list got past the cache only because the cache key was empty for every lookup without raw=True. That's the bug #5115 fixed. Every name shared one cache entry, so a second lookup returned the first name's answer.

A list didn't work before either. Only the first name was sent, the reply didn't match the request, and the call ended in TimeoutError. With raw=True, a list already failed at the cache key.

The one input that did work before and fails now is a bytearray name. That's also outside the str type hint, but it is a real change. We could raise a clear error for anything that is not a single str or bytes name, but I'll defer to @gpotter2 on how he'd like to handle this.

[IcantFind-a-username]

Thanks for the clear explanation. That makes sense: if a list never worked (only the first name sent, then a timeout), the new TypeError isn't a regression of supported behavior. The bytearray case you found is the real change, and a clear error for anything that isn't a single str/bytes name would cover both (it was also one of the options under Expected result). Happy for this to be retitled or closed as you and gpotter2 prefer.

[gpotter2]

I expected it to work with a list, let's mark this a regression.

[KernelClint]

We can add list support, but reverting #5115 won't get there because a list didn't truly work before it either. That would also bring back the shared cache entry.

Should a list return one result per name?