ip address allocation

As you have an address clash, I suspect that you have a mix of statically assigned and DHCP assigned addresses or just a simple clash of fixed addresses.

Easiest way to fix this is to use DHCP to assign the all IP addresses. Then you don't need to worry about who has which address. You do need to ensure that ALL devices are set to use DHCP though. Then go into your router setup (assuming the router is acting as your DHCP server) and you can reserve addresses for devices such as your streamer/NAS. Then their addresses won't change.

My first question would be what is your router? Any half way decent one would not allow this to occur.

This usually happens when a device which has been powered down is started up again and in the meantime a new device has been added to the network.

SB has it right - use DHCP throughout.  Switch EVERYTHING off (including your smartphone, ipad, TV etc) then power up the Airport Extreme (this is the DHCP server). Allow it to settle then turn on your other devices ONE by ONE, allowing each to come fully on stream to its 'ready' status before turning on the next device.

The Extream will reallocate a unique address as each device requests an IP address during its startup routine.  These new addresses will be remembered during subsequent power cycling.

IF you add a new device to your network (like an NDS perhaps), make sure all the other network devices are powered up and in the 'ready' status; the Extreme will not then attempt to re-use any ip addresses.

If this doesn't work, call a house clearance company, not an IT guy - sell him your kit and buy yourself a piano or something that doesn't use networking.

Hope (some of) this helps     

Chris did mention Airport Extreme, Gary.

The only time this happened to me was when i accidentally set a fixed ip in a dhcp range

People have suggested the three options you have:
i) use DHCP to manage all IP address assignments completely dynamically
ii)  use DHCP to manage all IP address assignments but in the router setting page, after a device has been given an address, set it to "reserved" and it will always get that IP
iii) ensure the DHCP pool does not cover the entire subnet (eg starts at 100) and statically allocate addresses outside of the pool range (eg below 100) to some devices.

Option i) is easy and most often works, but things can move around and (rarely) this can be a limitation.

Option ii) is convenient and almost always works, providing stability (and familiarity) for the rare problems with Option i).

Option iii) is rarely necessary (eg adding a wireless access point / switch using a second router in non-router mode, non-DHCP mode), and not needed for your audio devices. But it works as long as you manage all the details by yourself to avoid conflicts.

If there is any chance both of these have their DHCP server functionality enabled, and they're on the same subnet, then conflicts such as the one you have at the moment are very likely or inevitable. Take a look to ensure this is not the root of the problem before digging elsewhere or exploring anything more complex than Option i).

Best wishes. Although others have moved from streaming to async USB, it works for many more people than it doesn't, so fear not and boldly solve your issue!

Regards, alan

Please explain more how you have this configured.  Is the express connected to the extreme by wifi? 

You might want to review this explanation from Apple:  http://support.apple.com/kb/HT4145

I agree with Alan, a mixture of option 1 and option 2 is the way to go. in option 2 reserve your NAS IP address, and let everything else be dynamic as in option 1,

DHCP is used extensively in networks both commercially and in small simple home networks. It works well, and as part of its protocol will cater for addresses already being statically assigned etc so as not to cause clashes etc. But there are certain power on sequences that will fool this.. So best like DHCP handle it all and set all your end points to DHCP. The Apple devices make it easy to reserve specific IP addresses within DHCP.

However if you have two competing DHCP servers on the same network (subnet) such as on both the Extreme and. Express then they will confuse the devices requesting an address and it may be what you have happening here.

Simon

Wat, DHCP is a standardised automatic IP addressing assignment protocol and does simply that for millions the world over.. No user intervention required at all . However if you want to get the best out of Naim with saved Nstream playlists you need to lock the NAS IP address.. That is more about Naim.

UPnP along with Bonjour and many other standard and proprietary applications use discovery properties of underlying network protocols (usually multicast) that work behind the scenes and most are not even aware they are doing their stuff which is as it should be...

The issues when people add complexity.. And throw together consumer equipment that are trying to do the same thing or cut corners without understanding the impact which stops the underlying networking as it should.

Keep it simple, use quality equipment, and you won't have issues along with millions of others. USB has the spectre of driver and sub system conflicts.. again keep it simple and these potential issues should be minimised. 

Simon

If you reset an AirPort Extreme and AirPort Express to their factory defaults, and use the Apple AirPort Utility, this is exactly what happens.

That said - there are a lot of under-engineered (in terms of software) UPnP renderers out there that make the addressing / multicast discovery sequence significantly slower than it needs to be.

It could also be said that UPnP AV's time may have passed, in favor of more efficient network discovery and control methods–consider that Wi-Fi was largely in its infancy when the first UPnP AV devices appeared on the market–and that no one was considering 384 kHz / 32-bit uncompressed PCM!

To clarify - one of the interesting developments within the realm of UPnP / DLNA compliant streaming products has been the tendency toward "custom" applications, on a per-manufacturer basis, where much of the functionality of the device is implemented using proprietary APIs.

This makes it much more difficult to use a streaming control application from one manufacturer on another manufacturer's products (even when the underlying hardware and/or software is similar). It also makes the troubleshooting process more convoluted, once network congestion, addressing and/or discovery issues raise their ugly heads.

It may just be my opinion, but I feel that this is an area that manufacturers should probably look to their retailers (and their customers) for a bit of guidance, before UPnP devolves into a host of proprietary implementations that ultimately results in its replacement with something else.

This is one area that I believe Linn may have figured out, with the glaring exception of the software update and system configuration process (which Devialet beats hands down)–again - just my opinion.

David, I am with you in hoping that improvements are to come.  Although I enjoy the benefits of a networked system, most notably one server "serving" two hi fi setups, I can understand the temptation of a direct (USB, etc) connection when such is not desired.

NB -- How the heck can Devialet, via a software update, add 30 watts per channel to their hardware??? At least that is what I heard they did!

The behavior of the modulator used to drive the digital portion of the Devialet output stage can be modified in software (DSP firmware?); the (digital) power stages consist of four half-bridge transistors that can be configured in three different ways, the performance of which directly depends on the manner in which the modulator is configured to drive them (think four small buckets, each with its own stream of marbles, being emptied 768,000 times per second).

Wat, fair points.. Just one thing, DHCP does check to see if any device on the network responds to a given IP address before that IP address is given out to a new device.

Simon

Wat, I have a slightly different view.

I think part of the problem is that the components and systems were designed some time ago, and to do a specific job (in this case to negotiate the IP addresses in a network where there is a single DHCP master) as arranged by the network professionals configuring the network.

Although DHCP wasn't designed for home networks, it usually does just because most home networks are very simple; because of this there is usually only one router in the network and that is therefore the undisputed DHCP master.  The problem comes when people who don't understand the technology start wanting to configure much more complex networks.  So they just add additional components without understanding the implications and expect the technology to sort it out for them.

To give an analogy, it's like people who plug a washing machine a dishwasher and a microwave oven into the same 13A socket using multi-plug and complain that the fuse blows all the time.

Until the protocols catch up with the expectations of people who have insufficient knowledge to understand what they are expecting, problems will occur.  Unfortunately it takes time for the RFC process to accept and ratify new protocols, and both sides of this (both the rapid change in the demand and the delay in the response) are human problems not technical problems.

I am not sure.  DHCP can be extremely robust for many environments from the most basic home environment to a DHCP scope on a private global WAN. DHCP is designed (and is updated from time to time with extensions to its RFPs) to allow multiple DHCP servers on the same network - you may want to do this for load balancing or managing latency issues for example.

However as is so often the case many of the issues the poor consumer sees are down to poor basic software implementation of the client host or server or errant config when the user strays from a simplest or default behaviour.

As always KIS...

Thanks to all for your suggestions, sorry for the late reply, I've been a bit busy.

It seems the first thing I need to do is perhaps to establish which devices are trying to control ip address allocation, and stop all but one of them from doing so. In answer to Barts question, my network is as follows:

In my kitchen near the phone line -

Talktalk ADSL router (D-Link DSL3680) with WiFi disabled, connected by ethernet to -

Airport Extreme (current 802.11ac version) with Unitiserve connected by ethernet.

In my living room -

Airport Express (older style 802.11n version) connected to Superuniti by ethernet.

In another room, I have an identical Airport Express purely to extend WiFi coverage to that end of the house.

I originally had the Superuniti connected by wifi, but it often failed to find the network at all, even though other devices could see and use it perfectly well. This problem rarely occurs now I have the AE next to it. Running a long ethernet cable to it would be difficult, but probably something I need to do.

Hi

In your opening post you make no mention of the ADSL bit of your network just an airport extreme base station being the router. Have you set the D-Link to be in modem only mode (if that is possible) because if not, just turning off wireless doesn't disable DHCP and there is the source of your problem...

Most every router no matter how cheap has the ability to turn of DHCP allocation.

In many commercial environments, the DHCP scope is intentionally limited; for data center environments, it is not unusual for there to be multiple pools (managed by the same redundant cluster) for different types of devices (say, SSH clients vs. temporary virtual machine images).

A good balance of static IPs as well as a limited pool of dynamic IPs (some pre-assigned, others distributed in sequence of availability) generally works pretty well for UPnP / DLNA setups.

Chris, what I do is let my home broadband router run DHCP ( I do turn off its wi fi) and turn off DHCP in my connected Apple devices (Airport Extreme etc).  I like the Apple wifi coverage and simplicity of setup here in the home, and the broadband router can do a perfectly acceptable job of running DHCP.  It's wifi capabilities are poor, so that's what I rely on Apple for.

This is another way to attack the problem.

+1  

Yes I agree the ADSL router was the crucial missing bit...

if you are using the ADSL device as a router and not as a modem only, I would absolutely use that as the DHCP server and disable the Apple device DHCP server. The ADSL router DHCP server ideally needs the values it has obtained from your ISP (also through typically your ISP's DHCP) such as your ISP  local directory name lookup servers and assign these vales to your clients for efficient operation.

Simon

PS David.. In the environment you mention using multiple scopes then my commercial designs  will typically use a centralised cluster of DHCP servers with remote helpers on the edge routers with the DHCP clients on the edge subnets. In this case the scopes pertain to different subnets...  However I was not sure it's really relevant for basic  home networking we are discussing here so I didn't expand.. But yes DHCP is very versatile.

OK, so I've checked my router settings, and the Talktalk router was the active DHCP server. The Airport Extreme was in Bridge mode, which as I understand it, means it wouldn't have been able to allocate ip addresses. So I'm not sure I've achieved anything yet!