Samsung BD-DT7800
network interference occurred, please try again later

UPDATED - 31/12/2012 & 09/01/2013 - the report below is still relevant, so please read first, then goto SOLVED.

I have a Samsung PVR model BD-DT7800. I recently bought a wireless AP, set-up a DHCP server, and since that time I have had nothing but trouble getting the 7800 on the Internet:

network interference occurred, please try again later

The 7800 worked perfectly on a static wired IP.

Now, experimenting, I found that it works if I run the DHCP server on my WAN router, but doesn't if the DHCP server is running on some other box - the wireless AP, or a networked Linux box, for example, even though it picks up a DHCP IP. This suggested to me that somehow the 7800 couldn't find the network gateway unless the DHCP server was on the gateway.

Using the excellent Wireshark, I analysed the traffic. Herein lies the problem. The 7800 has a messed up DHCP stack, and continues to broadcast on an old DHCP IP lease, even though it has a new (and different!) DHCP IP lease.
So, the DHCP server gives it a new lease (call this A). The 7800 accepts the new IP lease A - BUT from previous network activity, it still has an old lease (call this B). Now we get:

Source B---->Where is gateway? - please tell A

But of course, there is no source IP B, so the DHCP server fails in an ACK (IP B DOES NOT exist on the network!), and if the DHCP server is NOT on the gateway, it seems the 7800 cannot find it's way!

Strangely, the 7800 broadcasts to (see SSDP) with the CORRECT IP A.

This issue appears to be related to this Android bug - See 'issue 3' on this well documented page Android Bug

I guess the only real solution is when Samsung fix this with a firmware upgrade - currently this is version 1009.0 (UPDATE 01/04/2013 - there is a new firmware update released 29th March, 2013 v1010.0, but the same issues seem to be apparent). - 27/12/2012


This bloody error message started happening again, and as I was adjusting network settings over the last few days after buying another wireless AP, I went through what I changed. It turns out the MTU values are the issue on the routers! I have a cisco router, and changed a few MTU values thus:

1) dialer 0 = MTU 1492
2) ATM 0 = MTU 1492
3) VLAN 1 = MTU1492

Now, experimenting, any permutation of these interface MTU's make the 7800 produce the error message. Setting MTU values back to default (in cisco's case 'no mtu'), then the 7800 connects first time, everytime!

So, what I think happens, due to a mismatch of MTU values (I don't know how to change the 7800 MTU value, even if a DHCP server allots a set MTU value as mine did), is that the 7800 cannot get a response, and thus cannot get past the gateway (or find it). And, I expect (can't really tell, as the 7800 is a 'black box' so no way to see what is going on), as it cannot find it's way, old DHCP IP are still used somehow.

As an exercise, I changed MTU value[s] randomly on each interface on my router, and sure enough I could stop/start the 7800 from connecting to the network/Internet at will. So, ensure your router[s] has/have MTU values at 1500. Now also, I limit MTU values on devices individually, keeping all routers on 1500 MTU.

A further update - using wireshark again, I have found that this device sends mangled DHCP replies that the DHCP server cannot understand and therefore cannot reply. So I think this is the main issue that causes all the above problems. - updated 31/12/2012; 09/01/2013