MVP and Powerline Networking: Incompatible?

[mdnttoker]

I'm hoping somebody out there has hit upon this issue already. I'm having problems with my MVP and Netgear HDX101 Powerline 200mbps adapters.

GB-PVR and SageTV work great when the MVP is plugged directly into my router, but as soon as I plug the MVP into the powerline adapters (plugged into the same outlet to get max rated speed), and the powerline to my router, the MVP won’t load (after a hard reboot: get the infinite Loading Application....).

Now here’s the interesting part: if I get SageTV or GB-PVR loaded onto the MVP while the MVP is directly connected to the router, turn the MVP off (sleep), and then move the MVP's ethernet connection to the Netgear powerline adapters without power cycling the MVP, everything works great after waking the MVP from sleep.

So I’ve determined the problem is the Netgear HDX101 Powerline adapters. Either because:

1) They don’t do half duplex (is there anyway to determine this?), or

2) The MVP refuses to search across more than 1 MAC address (each Powerline adapter has its own MAC address). Although, I have confirmed that the MVP does get its own IP address across these hardware MAC's.

3) Some other unknown issue…

The only thing that really bugs me though is that as long as I don’t power cycle the MVP, and load the firmware first via the router, it works fine until the next power cycle. So I’m not really sure where to go from here.

Has anyone experienced anything like this using powerline adapters?

Anyone have any suggestions on where to go from here? Any way to confirm half/full duplex operation?

Thanks,

-Dan

[sub]

I'm not familiar with the Netgear HDX101 Powerline adapters, but I can tell you I used the Homeplug Turbo 85Mbps powerline adapters for a while, and they were able to boot the MVP without any problems.

[mvallevand]

90% of my real use of the MVP is using IOGear 14Mb HomePlug powerline adaptors and I've never experienced any problems, other than on one plug in my house which only delivers between 1 and 2.5 Mb. Naturally it is the one closest to my stereo.

Martin

[mdnttoker]

It's defintely not a throughput issue. I get about 20-30 mbps (actual throughput) between my family room and my office.

The issue is: The Hauppauge software loads up fine across the Netgear Powerline Routers HDX101, even after a power cycle.

SageTV and GB-PVR, however, will not load across the Powerline Routers after a power cycle.

If I load SageTV or GB-PVR first after a hard cycle, then transfer the ethernet cable to the Powerline Routers, both SageTV and GB-PVR come out of sleep mode just fine, and the MVP works great until the next power cycle occurs.

I'm just trying to figure out why SageTV and GB-PVR have a hard time on initial load after a power cycle, while the Hauppauge software does not.

-Dan

[sub]

If its not making it past the loading application stage, then your network is probably loosing a lot of UDP packets.

The next release of GB-PVR has a much more fault tolerant TFTP server which will correctly handle resends etc.

[csy]

Hi mdnttoker, I'm a telco engineer specialising in Ethernet, and I suspect I know what is going on based on other users experiences and similiar experiences in the telco world.

When the MVP is powered-on, the MVP Ethernet hardware will auto-negotiate with the Ethernet link partner (eg Ethernet switch, Netgear Powerline adapters, etc), and providing the partner is a standard 10/100 auto-negotiating port, then both will negotiate to 100/full-duplex. This is correct operation and what should happen.

However when the MVP operating system loads (dongle.bin), I suspect the MVP does a 'reset' on its Ethernet port, causing the port to re-auto-negotiate with the link partner. The link partner (eg Ethernet switch or Netgear Powerline adapters) may not see 'link' fail, therefore doen't re-negotiate nor advertise its speed/duplex capabilities to the MVP. Because the MVP does not see any advertisements, it self-detects speed however cannot detect duplex and therefore falls-back to half-duplex mode, therefore the MVP ends up configuring its port to 100/half-duplex assuming the link partner is a 10/100 device. So in conclusion you end up with is a duplex mismatch because the MVP is half-duplex and the link partner (eg Ethernet switch, Netgear Powerline adapters, etc) is still using its original negotiated full-duplex.

Duplex mismatches causes packet loss, hence corrupted data, which may explain why the MVP is locking-up.

Some Ethernet devices detect Ethernet 'link-down' quicker than others, which is why some switches/NIC's do detect the very short link-down interval (MVP Ethernet reset) and renegotiates speed/duplex correctly to 100/full-duplex. But some other Ethernet devices don't detect the very short Ethernet link-down interval, resulting in the MVP incorrectly default to half-duplex mode.

I therefore suspect the root-cause of MVP lock-up is due the MVP reseting (or initialising) its Ethernet port when its operating system loads. This needs to be represented back to Hauppauge as a fault so they can fix it!

There is no easy work-around to your problem. Another user purchased a configurable Ethernet switch and connected the MVP directly to it and configured the switch port facing the MVP to 100/half. Another alternative is to find a cheap unmanaged switch that can detect the very short link-down interval and does correctly re-negotiate 100/full with the MVP, and insert that inline between the MVP and the Powerline adapter.

[mdnttoker]

Thanks for the replies csy & sub.

SUB-Is there any program I could load onto my laptop & connect to one side to see what kind of UDP loss I'm getting through the Netgear adapters?

CSY-I have an old 10/100 switch I used in college, will try inserting that in between and see what happens.

I've also attached two Ethereal logs I got from the Powerline and the DirectToRouter configurations. (linked due to size restrictions on this board)

After about packet #710, the Powerline log shows repeated UDP packets being sent over and over, while the DirectToRouter log shows continued variations in the UDP packet content throughout.

So perhaps both of you are right, and UDP packet loss could explain the failure of SageTV and GB-PVR to load, and the loss is caused by the MVP resetting its port.

But what explains the Hauppauge software GUI loading fine? Does it load just because the interface is so small, it's not as subject to UDP packet loss? Or does the Hauppauge software not generate a new MAC upon bootup as the SageTV or GB-PVR dongles do?

Thanks!
-Dan

MVP DirectToRouter Ethereal logs:
http://www.mysharebox.com/dl.php?key=1393002

MVP via PowerLine Ethereal logs:
http://www.mysharebox.com/dl.php?key=8015995

[sub]

SUB-Is there any program I could load onto my laptop & connect to one side to see what kind of UDP loss I'm getting through the Netgear adapters?

Not that I know of. The next release will indicate in the logs if packets needed to be resent, giving you an indication that this has occurred.

But what explains the Hauppauge software GUI loading fine?

A more robust TFTP server in the Hauppauge software could explain this. If this is indeed the cause, then hopefully the next GB-PVR release should be just as good at booting the MVP as the Hauppauge software.

[mvallevand]

A more robust TFTP server in the Hauppauge software could explain this. If this is indeed the cause, then hopefully the next GB-PVR release should be just as good at booting the MVP as the Hauppauge software.

Will the new server respond on both port 69 and 16869? Also will it serve up a file other then dongle.bin and dongle.bin.ver, specifically dongle.bin.config. (dongle being replaced by the gbpvr setting).

Martin

[sub]

GB-PVR's TFTP server only listens on 16869.

Its not a normal file based TFTP server. It'll only handle requests for dongle.bin and dongle.bin.ver. The dongle.bin request is translated to whatever dongle the user has selected in the config app. The dongle.bin.ver is dynamically generated from dongles modification date/time. The next release is just the same, but better able to cope with lost packets when transferring dongle.bin.