EtherREGEN: Installation, Usage, Difficulty, Questions thread

[k27R]

6 minutes ago, JohnSwenson said:

Did you try using the supplied SMPS powering the EtherREGEN when going router->A B->DAC? Are your Ethernet cables shielded using metal connectors? This is actually sounding like ground loops.

 

John S.

 

Yes I tried A->B with supplied SMPS and got dropouts as described.

 

And yes, both ethernet cables are using the metal connectors.  Using the SOTM CAT7.   I haven't tried different ethernet cables, I'll try some normal ones with plastic connectors.

[hieukm]

Can Uptone comment about usage of multiple Etheregen(2x-4x) will improve sound further??

[wwc]

Apologies if this has been covered already.  

 

Are the AudioQuest ethernet cables-- the higher-end ones which have silver connectors and are shielded at both ends -- compatible with the EtherRegen?   I recall reading somewhere this would be a noise producer...

[JohnSwenson]

For all of you having problems with droputs and disconnections I think I have figured out what is happening. A little background first: the endpoints most people use get an IP address from a DHCP server on your network (usually in the router). The DHCP server creates a "DHCP lease" which itsends to the endpoint, this contains an IP address and a range of time it is good for. When a music server connects to the endpoint (each protocol does this part differently) the endpoint sends this IP address to the server, which then uses it to talk to the endpoint.

 

The fun part happens when the lease expires, the endpoint then goes back to the DHCP server and says "renew my lease", in most situations the DHCP server will give it back a new lease with the same IP address it gave it the first time. BUT sometimes the new lease contains a different IP address, this is what causes the problem. The server keeps on sending the audio data to the old address, but the endpoint doesn't get it because it now has a different address. The music data goes into Ye Olde Bit Bucket.

 

Somehow the music server has to get the new IP address of the endpoint. There are a few ways of doing this:

turn off the endpoint then turn it back on (unplug it, many endpoint's power switch just puts them in low power mode), sometimes this may need to off for 10 to 15 minutes.

 

Unplug the Ethernet cable for 10 to 15 minutes.

 

Reboot the music server

 

This gets the server back talking to the endpoint.

 

In many instances this is all that is required, from then on the DHCP coninues to renew the lease with the same address it gave out the second time.

 

For some systems it might take two times for the DHCP server to settle down.

 

Another option is to make sure the address of the endpoint never changes, there are two ways to do this:

set a static IP address on the endpoint. Not all endpoints allow you to do this.

Set a reserved IP address on your DHCP server, almost all allow you to do this, the endpoint still asks for a lease or renewal, but you reserve a specific address for that specific endpoint, the DHCP server HAS to always use that one.

 

Most people's system do not have the problem in the first place. For the ones that potentially do have this issue there seems to be some sort of trigger that causes the DHCP server to behave this way, it usually has to do with something "new" in the system. A new endpoint will almost always trigger this. Sometimes the same endpoint but with a different configuration, or a network with a significant change. Simple switches will usually not trigger this, but managed switches (or different configuration of the same switch) being added, or taken out can also trigger this.

 

So while this seems to happen when you add the EtherREGEN it is probably not anything inherently wrong with the EtherREGEN, but rather that you have significantly changed your network topology that is somehow triggering this behavior in t your DHCP server.

 

Ether just living with it until the DHCP server settles down or clamping down the IP address of the endpoint should get rid of the issue. If you want to spend time playing with different network configurations, endpoints etc, I would recommend you reserve the IP address of your endpoint so the DHCP server cannot mess you up in the future.

 

Note: I do not know exactly what the triggers are or exactly how the DHCP server determines when something is "new". And most likely different models behave differently. So please don't ask questions like "will my system have this problem?" "Exactly what do I do if I have it?" "Which router should I buy so it won't happen to me?" I don't know the answers to those questions. Tomorrow I probably will not know the answers either. So please don't ask.

 

What I know about it is already in this post.

 

If you do have the problem and you follow the advice above and it does not go away, please post THAT, we will try and get to the bottom of it.

 

John S.

[Nenon]

8 minutes ago, JohnSwenson said:

For all of you having problems with droputs and disconnections I think I have figured out what is happening. A little background first: the endpoints most people use get an IP address from a DHCP server on your network (usually in the router). The DHCP server creates a "DHCP lease" which itsends to the endpoint, this contains an IP address and a range of time it is good for. When a music server connects to the endpoint (each protocol does this part differently) the endpoint sends this IP address to the server, which then uses it to talk to the endpoint.

 

The fun part happens when the lease expires, the endpoint then goes back to the DHCP server and says "renew my lease", in most situations the DHCP server will give it back a new lease with the same IP address it gave it the first time. BUT sometimes the new lease contains a different IP address, this is what causes the problem. The server keeps on sending the audio data to the old address, but the endpoint doesn't get it because it now has a different address. The music data goes into Ye Olde Bit Bucket.

 

Somehow the music server has to get the new IP address of the endpoint. There are a few ways of doing this:

turn off the endpoint then turn it back on (unplug it, many endpoint's power switch just puts them in low power mode), sometimes this may need to off for 10 to 15 minutes.

 

Unplug the Ethernet cable for 10 to 15 minutes.

 

Reboot the music server

 

This gets the server back talking to the endpoint.

 

In many instances this is all that is required, from then on the DHCP coninues to renew the lease with the same address it gave out the second time.

 

For some systems it might take two times for the DHCP server to settle down.

 

Another option is to make sure the address of the endpoint never changes, there are two ways to do this:

set a static IP address on the endpoint. Not all endpoints allow you to do this.

Set a reserved IP address on your DHCP server, almost all allow you to do this, the endpoint still asks for a lease or renewal, but you reserve a specific address for that specific endpoint, the DHCP server HAS to always use that one.

 

Most people's system do not have the problem in the first place. For the ones that potentially do have this issue there seems to be some sort of trigger that causes the DHCP server to behave this way, it usually has to do with something "new" in the system. A new endpoint will almost always trigger this. Sometimes the same endpoint but with a different configuration, or a network with a significant change. Simple switches will usually not trigger this, but managed switches (or different configuration of the same switch) being added, or taken out can also trigger this.

 

So while this seems to happen when you add the EtherREGEN it is probably not anything inherently wrong with the EtherREGEN, but rather that you have significantly changed your network topology that is somehow triggering this behavior in t your DHCP server.

 

Ether just living with it until the DHCP server settles down or clamping down the IP address of the endpoint should get rid of the issue. If you want to spend time playing with different network configurations, endpoints etc, I would recommend you reserve the IP address of your endpoint so the DHCP server cannot mess you up in the future.

 

Note: I do not know exactly what the triggers are or exactly how the DHCP server determines when something is "new". And most likely different models behave differently. So please don't ask questions like "will my system have this problem?" "Exactly what do I do if I have it?" "Which router should I buy so it won't happen to me?" I don't know the answers to those questions. Tomorrow I probably will not know the answers either. So please don't ask.

 

What I know about it is already in this post.

 

If you do have the problem and you follow the advice above and it does not go away, please post THAT, we will try and get to the bottom of it.

 

John S.

 

I just checked my Comcast/Xfinity device. The lease time of its DHCP server is 7 days. Just FYI.

 

[Dutch]

FYI; Clients actually start to try to renew their IP address with a DHCP server after half of the lease time has elapsed.

[Nenon]

5 minutes ago, Dutch said:

FYI; Clients actually start to try to renew their IP address with a DHCP server after half of the lease time has elapsed.

 

Yep, and under any normal circumstances, the IP address would not change.

The two most common causes for DHCP IP changes would be:

1. A restart of the DHCP server (i.e. the Xfinity cable modem in my case).

2. Connecting another device that acts as a DHCP server on the network. 

 

[Account Closed]

7 minutes ago, Dutch said:

FYI; Clients actually start to try to renew their IP address with a DHCP server after half of the lease time has elapsed.

Still, the best thing is to lock down the IP address in the router's DHCP server. This is not difficult thing to do. Just do a search for the procedure for your router.

[Dutch]

I don’t get it though. IP addresses can always change so clients need to check cached IP entries of other hosts on the network regularly using DNS, mDNS or whatever.

 

I’m wondering if the etherREGEN a L2 or L3 (or L2+) switch and if it’s configured correctly to support multicast for mDNS etc.

 

Of course since I don’t have my Etherregen yet (missed the delivery guy today) I also don’t have the issue yet, let alone troubleshooted it (if I even get the issue). I do feel here we’re attacking the effect and not the cause. Though the cause could be anywhere..I for sure don’t envy John here! 🙄 I hope the above proves to be a good workaround!

[BahamaBob]

1 hour ago, JohnSwenson said:

For all of you having problems with droputs and disconnections I think I have figured out what is happening. A little background first: the endpoints most people use get an IP address from a DHCP server on your network (usually in the router). The DHCP server creates a "DHCP lease" which itsends to the endpoint, this contains an IP address and a range of time it is good for. When a music server connects to the endpoint (each protocol does this part differently) the endpoint sends this IP address to the server, which then uses it to talk to the endpoint.

 

The fun part happens when the lease expires, the endpoint then goes back to the DHCP server and says "renew my lease", in most situations the DHCP server will give it back a new lease with the same IP address it gave it the first time. BUT sometimes the new lease contains a different IP address, this is what causes the problem. The server keeps on sending the audio data to the old address, but the endpoint doesn't get it because it now has a different address. The music data goes into Ye Olde Bit Bucket.

 

Somehow the music server has to get the new IP address of the endpoint. There are a few ways of doing this:

turn off the endpoint then turn it back on (unplug it, many endpoint's power switch just puts them in low power mode), sometimes this may need to off for 10 to 15 minutes.

 

Unplug the Ethernet cable for 10 to 15 minutes.

 

Reboot the music server

 

This gets the server back talking to the endpoint.

 

In many instances this is all that is required, from then on the DHCP coninues to renew the lease with the same address it gave out the second time.

 

For some systems it might take two times for the DHCP server to settle down.

 

Another option is to make sure the address of the endpoint never changes, there are two ways to do this:

set a static IP address on the endpoint. Not all endpoints allow you to do this.

Set a reserved IP address on your DHCP server, almost all allow you to do this, the endpoint still asks for a lease or renewal, but you reserve a specific address for that specific endpoint, the DHCP server HAS to always use that one.

 

Most people's system do not have the problem in the first place. For the ones that potentially do have this issue there seems to be some sort of trigger that causes the DHCP server to behave this way, it usually has to do with something "new" in the system. A new endpoint will almost always trigger this. Sometimes the same endpoint but with a different configuration, or a network with a significant change. Simple switches will usually not trigger this, but managed switches (or different configuration of the same switch) being added, or taken out can also trigger this.

 

So while this seems to happen when you add the EtherREGEN it is probably not anything inherently wrong with the EtherREGEN, but rather that you have significantly changed your network topology that is somehow triggering this behavior in t your DHCP server.

 

Ether just living with it until the DHCP server settles down or clamping down the IP address of the endpoint should get rid of the issue. If you want to spend time playing with different network configurations, endpoints etc, I would recommend you reserve the IP address of your endpoint so the DHCP server cannot mess you up in the future.

 

Note: I do not know exactly what the triggers are or exactly how the DHCP server determines when something is "new". And most likely different models behave differently. So please don't ask questions like "will my system have this problem?" "Exactly what do I do if I have it?" "Which router should I buy so it won't happen to me?" I don't know the answers to those questions. Tomorrow I probably will not know the answers either. So please don't ask.

 

What I know about it is already in this post.

 

If you do have the problem and you follow the advice above and it does not go away, please post THAT, we will try and get to the bottom of it.

 

John S.

I'm having to reboot my ER every few hours with my endpoint (Logitech Transporter/ROON in squeezebox mode). However, if I connect the endpoint to the "A" side of the ER the dropouts don"t occur and everything works normally.

 

[Dutch]

Roon emulates LMS which uses broadcasts. IIRC the etherREGEN is two switches in one, perhaps they aren’t passing the broadcast traffic to each other but only locally explaining why all hosts connected to the A side does work.

 

[Nenon]

If the etherREGEN was not passing broadcast traffic, there would be A LOT of issues, and most things would not work at all. ARP is broadcast. Hosts within the same network would not be able to communicate at all without ARP or broadcast. 

[Dutch]

Yes, you’re absolutely right about that @Nenon the switch should also send the arp request to all ports except the one that received it from and update its internal mac-port tables. If all that is working though and it reaches both A and B side consistently and keeps the tables in sync and stores the right mac addresses one would probably need to figure out the detailed workings of the applications (I for example don’t know all the details of LMS) on a network level and sniff the network traffic on both the A and B side to see what’s amiss.

[wwc]

6 hours ago, wwc said:

Apologies if this has been covered already.  

 

Are the AudioQuest ethernet cables-- the higher-end ones which have silver connectors and are shielded at both ends -- compatible with the EtherRegen?   I recall reading somewhere this would be a noise producer...

After reading up, I can refine my question:   Assuming the Audioquest cables are in fact shield tied, is the potential AC leakage loop NOT an issue if only ONE of these cables is inserted into the the EtherRegen "A" side?   

[wwc]

5 minutes ago, wwc said:

After reading up, I can refine my question:   Assuming the Audioquest cables are in fact shield tied, is the potential AC leakage loop NOT an issue if only ONE of these cables is inserted into the the EtherRegen "A" side?   

Further refinement after speaking with AudioQuest:  their cables are only tied (grounded) at one end for this very reason-- so it sounds like it's not an issue.

 

[Iving]

per AQ: "We do not tie the drains on the input #1 end. Only on the #2 end, destination end. This helps reduce overall system noise for better audio performance."

[Nenon]

On 11/14/2019 at 7:25 AM, dminches said:

Just another data point.

 

Here is my setup:

 

What I have been noticing is that I am periodically losing a connection on my IOS app with the Roon Server.  This isn't happening when music is playing, only when I have paused the music or when the playlist or album has ended.  The connection is eventually re-established within 10 seconds or so.

 

I am not saying this is due to the ER but I don't recall this happening before I added the ER.  

 

 

@dminches - Since I did not have time today to complete your other request, can I help troubleshooting this? 

 

First, and most importantly, can you install an app called "Fing - Network scanner" on your IOS device? It would scan your network and find your Roon Server. Next time this happens, can you try to ping the Roon Server from Fing? Also, try to ping your ultraRendu at the same time.

 

Second, would it be possible to remove the Trendnet Switch and connect everything to the etherREGEN? Less things, easier to troubleshoot.

 

Third, some reports earlier pointed out to a power supply problems and/or network cable problems. Just to reduce the number of variables, can you confirm if the problem still happens with the stock power supply? And if you have any other ethernet cables to test would be nice. This may even sound like a stupid suggestion... it does not make any sense to me, but just to avoid some really really odd stupidly crazy scenario.

[Nenon]

On 11/14/2019 at 7:13 AM, BigAlMc said:

Interesting (tho I may be stretching the definition of 'interesting' here) data point. When I try to connect to the NUC on Putty it's unavailable and I get a network error. Despite music playing. Power cycle the ER and then Putty connects fine.

 

On 11/14/2019 at 11:43 AM, BigAlMc said:

nteresting. One more thing to try I guess.

 

But as my Server NUC only has one LAN port I guess I'd need to change from:

 

Router to A side of ER, Server to A side of ER, B side of ER to EndPoint

 

To:

 

Router to previous AQVOX switch, AQVOX to Server, AQVOX to A side of ER, B side of ER to EndPoint?

 

Addition of an extra switch in the chain seems counter intuitive to resolving network issues. But might be worth a go

 

@BigAlMc before you try to introduce another switch and complicate things even more, can you please try a couple things?

 

1. Please follow @lmitche suggestion below:

On 11/14/2019 at 2:44 PM, lmitche said:

I'd make sure you NUC endpoint is set at 100mbps and the server to 1000mbps. Plug the endpoint in the B side of the ER, and the server into the A side along with your router connection. This way you don't need any autonegotiation.

 

2. If the issue continues, and you still cannot connect with putty to the NUC, can you please try to:

   a. Ping your NUC from the same computer putty is not working.

   b. Check the arptables on the computer putty is not working. That is typically done with command 'arp -a', but if it does not work, let me know what OS you are using, and I will give you the exact commend.

 

BTW, are you unable to connect to the NUC that's connected on the A-side or the NUC on the B-side? Or is it both? Try to use putty to both and perform #2 to the NUC(s) that is(are) not working. 

[Puma Cat]

9 hours ago, wwc said:

Apologies if this has been covered already.  

 

Are the AudioQuest ethernet cables-- the higher-end ones which have silver connectors and are shielded at both ends -- compatible with the EtherRegen?   I recall reading somewhere this would be a noise producer...

No. While the Audioquest Ethernet cables are shielded, the shields are not connected at both ends, that is, one end is (colloquially referred to as) "floating", so they will not conduct leakage currents "downstream". 

[wwc]

Optical Modules:  I have the Startech #SFP1000ZXST.

https://www.startech.com/Networking-IO/sfp/modules/1000base-zx-sfp-module~SFP1000ZXST

It is Gigabit, Single Mode.

Is this compatible with the SFP cage on the ERegen?

[Superdad]

47 minutes ago, wwc said:

Optical Modules:  I have the Startech #SFP1000ZXST.

https://www.startech.com/Networking-IO/sfp/modules/1000base-zx-sfp-module~SFP1000ZXST

It is Gigabit, Single Mode.

Is this compatible with the SFP cage on the ERegen?

Sure, those will work fine.  Just be sure to use the same type at both ends and of course use Single-mode fiber optic cabling.

[JohnSwenson]

7 hours ago, Dutch said:

I don’t get it though. IP addresses can always change so clients need to check cached IP entries of other hosts on the network regularly using DNS, mDNS or whatever.

 

I’m wondering if the etherREGEN a L2 or L3 (or L2+) switch and if it’s configured correctly to support multicast for mDNS etc.

 

Of course since I don’t have my Etherregen yet (missed the delivery guy today) I also don’t have the issue yet, let alone troubleshooted it (if I even get the issue). I do feel here we’re attacking the effect and not the cause. Though the cause could be anywhere..I for sure don’t envy John here! 🙄 I hope the above proves to be a good workaround!

Hi Dutch,

Yes I have extensively tested multicast and mDNS, they both work fine in every scenario I've tested.

 

BTW, there is only one switch in the EtherREGEN--in the A side. One of the ports on the A side switch sends data through the "special sauce" which goes into a format converter which is not a switch. Whatever packets come in go out without any modification.

 

John S.

[JohnSwenson]

Hi All,

Here are some more focused procedures to try for those of you having connection issues.

 

First off, I want to establish general network connectivity without bringing audio protocols into this, i.e. make the network connections work first, THEN try and play music. With this we can separate issues with network connectivity from things like Roon or LMS etc.

 

To do these tests you will need a way to find the IP addresses of your devices (servers, endpoints, etc.) and be able to "ping" them. A ping just sends a command to a device that says "send me a reply." This is a low level test to see if the communication is working at all.

 

Fortunately there are some tools that make this fairly easy. I'm just going to list one for Windows and one for Mac; there are MANY others. Use what you wish. Nenon mentioned one for iOS, (thanks Nenon for helping with this, we really appreciate it).

 

Windows :

https://www.advanced-ip-scanner.com

Mac:

https://www.iwaxx.com/lanscan/

 

These programs will scan your network and show all the devices, including name and IP address. They allow you to ping the device and make sure it is responding.

 

Some of the names are really weird and you may not be able to identify your devices. If this is the case, turn off your audio related devices (NAS, server, endpoint etc) and do a scan. Then turn on one device, do a rescan, note what was added--and do this for each device. Write down the name and IP address of the audio related devices (you don't need to write down phones, TVs, printers, ovens, toasters etc.)

 

What I want you to do is run this process WITHOUT the EtherREGEN in the network. Take it out, turn off all the audio devices, turn them back on (no particular order) then run the scan, write the names and IP addresses down, do a ping on each device, make sure they all respond.

 

Then put the EtherREGEN in the network and do the process all over again. See if any of the IP addresses have changed and if they can all still be pinged.

 

If the devices still respond to a ping, start playing music, when you have the connectivity issues, do the scan again and check the pings. Note if any of the IP addresses have changed

 

This information will be a really good starting point for finding out what is going on.

 

Thanks,

 

John S.

[soares]

Hi guys, will someone help me with the right SFP module to use with the eR? 
Tks Jorge

[cat6man]

for android, i recommend the app "fing" for ipscanning

for linux, the 'angry ip scanner'