2010
01.19

Shared folder access from Windows CE

Be the first to like.
Share

Scenario:

  • Headquarter (HQ) connected (MPLS VPN) to some branch sites.
  • In some of the branches, a Check Point UTM-1 Edge X (SofaWare) sits between the wireless and wired networks, enforcing security policies between them.
  • The two networks are bridged together (Layer 2) by the firewall.
  • The wireless LAN is used by some kind of next gen Barcode Scanner: an embedded device with Windows CE .NET 4.2, also able to act as a Terminal Services client.

Customer wants to install some software on the scanners, downloading it from a shared folder residing on one of HQ servers. I add the necessary (and temporary) rules on the firewalls, but the folder still cannot be reached. Windows CE complains that “The network path was not found” but the rules look good.

Luckily, the Edge firewalls provide a packet sniffer, allowing us to further investigate the issue. Just connect to the web based interface of UTM-1/SofaWare, go to SetupToolsSniffer, choose a filter string (using the familiar libpcap/tcpdump syntax), select the interface (“bridge”, in my case), and you’re set. Captured packets can then be downloaded to your PC and opened up in Wireshark.

We came up with a bunch of peculiar NetBIOS Name query requests/answers:

$ tshark -r sniffer4.cap
  1   0.000000    192.168.2.3  -> 192.168.1.10  NBNS Name query NB HQSERVER<20>
  2   0.028436    192.168.1.10 -> 192.168.2.3   NBNS Name query response
  3   1.001397    192.168.2.3  -> 192.168.2.255 NBNS Name query NB HQSERVER<20>
  4   1.251460    192.168.2.3  -> 192.168.2.255 NBNS Name query NB HQSERVER<20>
  5   1.502820    192.168.2.3  -> 192.168.2.255 NBNS Name query NB HQSERVER<20>

Some hostnames, for clarity:

  192.168.2.3  : BOSCANNER
  192.168.1.10 : HQDC1
  192.168.1.20 : HQSERVER

The Barcode Scanner (Client) asks one of the DNS/Domain Controllers in HQ if it is called HQSERVER. But HQSERVER is the server we’re trying to connect to from the Scanner (by means of \\HQSERVER\sharename)! Why in the world the device should directly ask HQDC1 if it is called HQSERVER? Using an unicast NetBIOS query, too? Obviously HQDC1 answers “no, it’s not me” (Requested name does not exist)… The Scanner then broadcasts the same query to its local network segment, but since HQSERVER sits in Headquarter, it gets no answer and generates the error “The network path was not found”.
Turns out that \\192.168.1.20\sharename causes the same dialoque, with a NetBIOS name query that seemingly asks for a server named “192.168.1.20”. It’s as if in Windows CE, UNC paths could only use names, not IP addresses.

Well, the Customer didn’t have enough time for me to properly solve/understand the issue but we worked around it by:

  • Assigning a static IP to the Windows CE device.
  • In the TCP/IP settings of Windows CE, use 192.168.1.20 (HQSERVER – where the shared folder is hosted) as DNS and WINS server.
  • Copy the needed files from the network share and revert back to DHCP.

Step two makes the Client send NetBIOS name queries to HQSERVER instead of HQDC1. This allows shared folder access to work.

Share

2 comments so far

Add Your Comment
  1. Hi,

    i have the exact same problem with the only difference that i can’t even resolve the names by using the computer where the shared folders are hosted as DNS or WINS, since NETBios is deactivated there as well, so everything just has to work over IP.

    I wanted to kindly ask if you maybe know any solutions/workarounds/hacks for this problem. The costumer is not willing to make changings in his network.

    Regards
    Mediin

    • Hi Medlin,

      if you’re not allowed to make any changes, even on the Windows CEs themselves, I doubt you’ll have much luck. Back then I wish I had had more time to check if that odd behaviour could be fixed by changing some setting on the mobile devices…

      ciao,

      Giuliano