The Audiotron appears to be unable to work with a WINS server. There is no way to specify one in the Web UI. I tried various approaches to get this work:
- force global browse master on gw by running the Samba nmbd server with the appropriate smb.conf file (Audiotron finds the browse master on gw, but apparently ignores the information about hosts in other subnets)
- limit and eventually turn off the firewall rules dropping packets between the wired and wireless portions of my network (I do have holes for smb traffic, but it doesn't matter. I can get to //chef/media just fine using smbclient via wireless)
- redirect 137/138/139 tcp/udp from gw to chef (doesn't work because of heavy use of broadcasts in the smb protocol)
- Allow remote hosts in the Audiotron WebUI (no visible effect)
- Hardcode the specific share name \\chef\media in the Audiotron WebUI (no visible effect)
- make heavy use of tcpdump on all systems involved (except the Audiotron which is a closed box)
- search Google (and this blog is among the first 20 hits when I search for [audiotron browse master]...)
- make sure all the passwords are right for the media user, both in the Audiotron and on chef (checked)
- confirmed using nmblookup that I can't see chef, when browsing the wireless broadcast domain (duh, of course not. It's a separate /24.)
- The Audiotron aborts browsing the subnet, if it can't find a running smbd on gw (how annoying)
In some cases chef shows up in the Audiotron log with "No IP reply". The Turtle Beach docs are fairly unhelpful on this whole thing.
Since WINS is not supported by the Audiotron and hardcoding paths on the Audiotron doesn't seem to have any effect, I'm thinking about bringing the songs closer to the Audiotron: Mount the media partition via NFS from Chef on gw, then export the NFS mount from gw via Samba to the wireless side.
How ugly.
I searched more and found a note in the Audiotron FAQ that the Audiotron does indeed support WINS, but the server information has to come from DHCP. The option for isc-dhcpd is netbios-name-servers in dhcp.conf. That might work. I'll try that when we are back from shopping. It's Black Friday after all.
...
Finally! It's working.
Serving netbios-name-servers via dhcp didn't seem to have any visible effect.
The magic config options that made it work were "dns proxy = yes" and "wins proxy = yes"in smb.conf on gw. Then I went into manual configuration mode on the Audiotron and set it explicitly to get the music from \\chef\media.
Samba on chef was not configured to use the WINS nmbd on gw, so nmbd didn't serve IP information for chef, even though it served the name as part of the list when queried.
So, in the end, as usual, it was operator error. I could have saved myself quite some pain by configuring chef as WINS client of gw, or run a WINS server on chef outright and serve chef's IP as WINS server to the Audiotron via dhcp. Actually, that's not a bad idea, I'd rather not have smbd/nmbd running on gw...
Not tonight, though, now that Patricia is happily listening to music served by this crazy infrastructure.
So, here's what I'm going to try next:
- run WINS server on chef
- serve chef as netbios-name-server in dhcpd.conf for the audiotron
- turn off nmbd and smbd on gw
- Verify I can still listen to music...
Update:
The Audiotron appears to ignore the dhcp option netbios-name-servers. With only nmbd running on gw, being the WINS server, and the Audiotron manually set to go to \\chef\media, it finds my songs just fine. Good enough for me.
A curious note:
When the Audiotron tries to resolve a remote name it queries first for "A? CHEF.", it gets a NXDomain in my network. Then it uses the fully qualified domain name "A? chef.domain.comm". Not a typo, it actually appears to append an 'm' to the query. I couldn't find the source of the extra 'm'. Even reset the Audiotron to factory defaults and started over, still queries an extra 'm'.
No comments:
Post a Comment