HDR as NAS not announcing itself as a network drive when switched to WiFi connection

[Black Hole]

Anybody know the answer to this off the top of their heads?:

As regular readers will know, I run three HDRs on HomePlugs through their Ethernet ports. I've switched one of them to a WiFi dongle (hoping data transfers might be faster and more reliable than HomePlug), and WebIF responds on the same IP address no problem (configured as manual not DHCP). OK so far...

However, now when I go through Explorer (Win7) to access them as SMB NAS drives, the HomePlug HDRs are fine but the WiFi-connected HDR won't respond (is not detected on the network). What gives?

Update: network-shares-automount still accesses the WiFi HDR fine, and I can connect through Win7 Explorer (actually, DOpus) by explicitly declaring a network drive. It's just that the HDR isn't announcing itself on the network the same as the others are (and it did before switching to WiFi).

 

[/df]

Is the client connected to the network via Ethernet or WiFi? If the former, is it possible that your network setup is blocking multicast advertisements across the LAN-WLAN bridge? I'm guessing the HomePlugs and maybe the PC connect to a LAN switch, such as the LAN interfaces of a WiFi router/modem, and that there may be some setting in the router/modem that determines whether multicast packets are allowed between the LAN and WLAN segments.

network-shares-automount is presumably set up by IP address, so that would bypass name resolution.

 

[MartinLiddle]

However, now when I go through Explorer (Win7) to access them as SMB NAS drives, the HomePlug HDRs are fine but the WiFi-connected HDR won't respond (is not detected on the network). What gives?

Is "network discovery" turned on for the WiFi network?

 

[Black Hole]

The Win7 PC is on the same WiFi network! If it can reach into the router and across the HomePlug network to discover those HDRs, why not an HDR connected on WiFi?

Nothing else has changed, just the switch of one HDR from the HomePlug set to WiFi.

 

[/df]

Is the problem HDR appearing in Explorer but not responding, or just not appearing? (I assumed the latter.)

Can you navigate to \\<HDR-name>\<share> (fill in the <>) by typing in or mapping to a drive letter?

What about trying the WiFi dongle on one of the other HDRs (not that I'm doubting your configuration control)?

Once upon a time the nbtstat command used to be helpful in resolving this sort of problem, and I think it may still be even though "NBT" doesn't play any part in the current file server protocol stack.

 

[Black Hole]

Is the problem HDR appearing in Explorer but not responding, or just not appearing?

Not listed.

Can you navigate to \\<HDR-name>\<share> (fill in the <>) by typing in or mapping to a drive letter?

I can connect through Win7 Explorer (actually, DOpus) by explicitly declaring a network drive.

\\<IP address>\Media, actually.

What about trying the WiFi dongle on one of the other HDRs (not that I'm doubting your configuration control)?

Well, I suppose I could, just to eliminate configuration bugs, but I very much expect to see the same result.

What I'm looking for is a rationale why this should be. I know the HomePlugs operate as their own little network independent of the router (remove the router link and communications purely within the HomePlug network carry on regardless) - does WiFi operate the same way? If so, maybe the router is an integral part in resource discovery that simply doesn't work when the communications are purely within WiFi.

 

[prpr]

even though "NBT" doesn't play any part in the current file server protocol stack.

It most certainly does. NBT = Netbios over TCP(/IP) and is the basis for SMB networking (was originally over Netbios, or Netbeui, depending). Now also capable of SMB over TCP directly. I've been playing with this stuff since 1986.

What I'm looking for is a rationale why this should be. I know the HomePlugs operate as their own little network independent of the router (remove the router link and communications purely within the HomePlug network carry on regardless) - does WiFi operate the same way? If so, maybe the router is an integral part in resource discovery that simply doesn't work when the communications are purely within WiFi.

Sometimes I'm amazed by how little people know about the fundamentals of networking.
What you call a router is actually a switch (between ethernet ports), a bridge between ethernet and Wireless and a router to, well, route between networks (in most people's cases, between what they call their LAN and the internet (or WAN)).
I suggest you go and do some reading, work out the differences between the above terms, and what constitutes layer 2 and layer 3 network operations.
The routing part of your router has nothing to do with resoure discovery. Nor does the switching/bridging part. It is entirely a peer-peer thing. Lookup the Browser protocol.
Suggest you install Wireshark on a PC and learn how to use it as well.

 

[Black Hole]

Sometimes I'm amazed by how little people know about the fundamentals of networking.

Mostly we don't need to. Modern consumer computing is about "plug and play", and unless you're in at the beginning there's an awful lot of information to assimilate all in one go to catch up. Rather like newcomers to CF at its current state instead of following developments.

Suggest you install Wireshark on a PC and learn how to use it as well.

Oh yes? And spend how long pouring over raw hex data dumps? I would have to be really motivated to do that.

If you know the answer to this problem, just tell me - I bet I know plenty of other things you don't know and don't wish or have time to work out.

 

[/df]

...NBT = Netbios over TCP(/IP) and is the basis for SMB networking (was originally over Netbios, or Netbeui, depending). Now also capable of SMB over TCP directly...

OP's system surely isn't using an RPC version of INT 21h, though maybe (SMB over TCP/IP) a distant descendant of it, and yet I believe he would get useful info from the archaically named nbtstat.

AFAIK a set of compatible HomePlugs connected to a single household mains create something that is architecturally a LAN switch. OP therefore has something like this:

+--------+   +-------------------+ +--------+
| W7 PC  |   | other LAN devices | |  HDR1  |
+--------+   +---------^---------+ +--------+
    ^                  |                ^
    |                  v                |
    v          +-------------+          v
+--------+     |             |     +--------+
|  WLAN  | <-> | AP<->switch | <-> | HP LAN |
+--------+     |       ^     |     +--------+
    ^          |       V     |          ^
    |          |     modem   |          |
    v          +-------------+          v
+--------+             ^            +--------+
|  HDR3  |             |            |  HDR2  |
+--------+             v            +--------+
                      ISP

And the change was just to put HDR3 on the wireless LAN instead of the HomePlug LAN?

And the HP LAN, WLAN, and any directly attached LAN devices are all using the same IPv4 subnet (eg 192.168.1.0/24)?

And the PC was always on the WLAN?

I still suspect there is an issue with multicast on the WLAN.

 

[Black Hole]

OP therefore has something like this:

Yep, bang on.

And the change was just to put HDR3 on the wireless LAN instead of the HomePlug LAN?

And the HP LAN, WLAN, and any directly attached LAN devices are all using the same IPv4 subnet (eg 192.168.1.0/24)?

And the PC was always on the WLAN?

Yes, yes, and yes. That's why it seems so weird.

 

[/df]

Can't disagree as to weirdness.

As to resolution, you could (but probably already have) try turning everything off and restarting. I'd go for this order: all off, then start modem/router, PC, the HDR that I labelled as 3; observe; then HP LAN, then HDRs labelled 1, 2; observe.

You might also see what happens with the PC and HDR3 connected to the modem/router's Ethernet sockets instead of the WLAN.

Otherwise I think you'll need some more instrumentation to proceed, such as the previously suggested nbtstat and Wireshark. The latter comes with protocol "dissectors" so at least your hex dumps are displayed in some sort of structure and at best almost all the relevant protocol exchanges are fully interpreted).

 

[prpr]

If you know the answer to this problem, just tell me

I don't, but I told you how to find out for yourself. Set Wireshark running with a "udp port 138" capture filter (and possibly a display filter of "browser") and look at the data and see what you can spot. Only you know what's on your network and where and what to expect. Look for what's the Master Browser as well. That can have a significant bearing on this sort of stuff. It's a hideous thing really, this Browser protocol, but what do you expect from M$?

I bet I know plenty of other things you don't know and don't wish or have time to work out.

Certainly. But I wasn't asking. You were.

 

[Black Hole]

I was unaware of the concept of a "master browser", that bears further reading.

It's not so much the "why" as what to do to regain the functionality. It seems to me there is no easy solution other than to put the relevant unit back onto the HomePlug connection - suppose I did analyse everything and figure out what was causing it, that doesn't imply there is an intervention which would make it work, so the investigation would be just curiosity (not a bad thing in itself, but the ability to pursue such curiosity diminishes, and what abilities I have left are already consumed elsewhere).

So what I am left with is a compromise (until I hard-wire everything): have the convenience of discoverability by returning HDR4 to the HomePlug network (but the inconvenience of the HomePlug network freezing up when transferring data and crashing the transfer), or the convenience of data transfers working reliably over WiFi (but the inconvenience of having to explicitly declare the connection instead of it being "just there").

 

[/df]

This paper explains that some types of HomePlug simulate multicast frames by means of multiple unicast frames, and this IETF note lists problems with multicast in WiFi standards.

So my hypothesis is that the wireless LAN part of the modem/router is not handling multicast frames correctly, which might be fixed either by some setting in its admin page, or by replacing the device. Connecting the problem HDR to the HP LAN by-passes the issue, as might perhaps some smb.conf setting on the HDR.

Knowing the model of modem/router might help.

Not apparently relevant, but this guy found out the surprising significance of changing the default "network name" on his HP LAN.

 

[Black Hole]

That looks like a smoking gun to me, thanks for going to that much trouble, but could it equally well be the WiFi dongle as the router's WiFi?

Knowing the model of modem/router might help.

Netgear DGND3700v2

Not apparently relevant, but this guy found out the surprising significance of changing the default "network name" on his HP LAN.

For what it's worth, I made sure my HomePlug network has a non-default password!

 

[/df]

That looks like a smoking gun to me, thanks for going to that much trouble, but could it equally well be the WiFi dongle as the router's WiFi?
...

Not so likely. Tests using the modem/router's Ethernet ports, and/or just an Ethernet cable from PC to HDR, could be enlightening.

The Netgear DGND3700v2 looks quite capable. Its firmware, based on Linux 2.6.30, has ReadyMedia (MiniDLNA) and ReadyShare (Samba, I guess). Its telnet server is said to be locked down although it may be possible to enable it. There was a long-running issue with WiFi isolation apparently fixed with v1.1.00.23, but that's not the problem here.

Having said that, the web interface only offers 2 settings that might possibly be relevant: UPnP (on would require multicast) and RIP (RIP-2M would require multicast). Someone with an earlier model (N300) had success by rolling back the firmware, but you might also be able to try a newer version if yours isn't up-to-date. Otherwise, there might be some further settings available from the command line through telnet.

 

[prpr]

So my hypothesis is that the wireless LAN part of the modem/router is not handling multicast frames correctly, which might be fixed either by some setting in its admin page, or by replacing the device.

It was crap like this with wireless that pushed me away from domestic kit.

but this guy found out

We have something in common there.

and RIP

What use is RIP on a flat network? Actually, what use is RIP on any network? Anyone with sense would use something else.

 

[Black Hole]

The projected benefits do not justify the expenditure of resources required to achieve.

 

[MartinLiddle]

It was crap like this with wireless that pushed me away from domestic kit.

As a matter of interest, what do you use?

 

[prpr]

The answer is in there somewhere. You just have to find it.