EtherREGEN: Installation, Usage, Difficulty, Questions thread

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.

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

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...

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.

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

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. 

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.

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!

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.

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.

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. 

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.

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?   

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.

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."

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". 

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?

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.

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.

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

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

for linux, the 'angry ip scanner'