FastEthernet stops working on Duet in bridge mode, any ideas?

[WB3FFV]

I have a Duet, and have it setup in bridge mode, which overall seems to work just fine.

The problem I am running into, is every so often, it can be a couple days, or even a week or two, but the FastEthernet on the back of the Receiver will just turn off and stop working. When this happens, the lights on the network jack on the receiver just turn off, and link back to the Cisco Catalyst switch goes down as I see the loss of link light. So it's like it just decides to power down the FastE.

I have tried unplugging, and replugging the cable, and even restarting the switch for grins, but the only solution that works is unplugging the SB receiver, and then plugging it back in. Once I do that, bingo the link comes right back up and it goes on it's way.

I have tried different ports, and even other devices in the port the receiver was on, with no problems, it's just the SB receiver that seems to shut down after some random period of time.

According to the status page from the server, it says the receiver is running firmware version 65, not sure if there are any updates, or how to apply them if needed, but do know something just isn't quite right..

Regards...

[WB3FFV]

Wow, has nobody run into this issue??

[kantblue]

Hi WB3FFV

Its quite possible that no one else has seen this because.

1. I would guess that Bridge mode is probably the least used mode for the Duet Receiver.
2. Cisco equipment is more likely to be found in the business environment than the home market.

How are you setting the IP address of the receiver, possibly you have a dhcp router connected to your switch somewhere or have you manually assigned an ip address?

I'm thinking it could be a dhcp leasing problem?


kantblue

[WB3FFV]

To answer your comments, One, I was actually initially looking for Hybrid mode (not sure if there is any way to switch on the fly), but somehow ended up in Bridge that other than the stated issue seems to work well. As to the second, I mentioned Cisco, and agree what I have here is pretty much all manageable commercial grade gear, but I would hope if anything it would increase reliability of a link.

As to setting the IP address, this is done via DHCP, and in fact I have the MAC address's from the receiver and controller loaded into the servers config so it gets a static assignment from the DHCP server when requested, which works flawless and had for a long time when both units ran wireless to an AP. By having a static assignment handed to the units, it's simple to take and see what's online and responding with monitoring software. The DHCP server is a FreeBSD server running ISC's DHCPd code, so is very mainstream for sure.

When I say the link is going out, and really if you look at the back of the SB Receiver, there are two LED's associated with the receivers FastEthernet port, and when it drops, both of the LED's go dark. At that time of course, the link indicator on the switch also goes out. So it's like the network port is actually shutting down, without any reason I can think of on my end, in fact usually nothing is playing, heck nobody may even be in the room. The only reason I pick it up instantly each time it happens if that I have a network monitor that pings the units, and it pages when the stuff drops, I run look and sure enough the network port is down on the receiver..

Hi WB3FFV

Its quite possible that no one else has seen this because.

1. I would guess that Bridge mode is probably the least used mode for the Duet Receiver.
2. Cisco equipment is more likely to be found in the business environment than the home market.

How are you setting the IP address of the receiver, possibly you have a dhcp router connected to your switch somewhere or have you manually assigned an ip address?

I'm thinking it could be a dhcp leasing problem?


kantblue

[kantblue]

Hi WB3FFV

There is no way to switch between modes on the receiver without a reset.

What colour is the light on the front of the Receiver when this happens?

I know you have tried restarting the switch when this happens, but have you tried restarting your DHCP server without touching the Receiver? Does it come back up?

I did try setting static IPs with MAC addresses on my Receiver, but still found that from time to time it had still somehow acquired the wrong IP. I could check this using the Controller. I never looked at the back of the Receiver to see if the lights were out in this situation though, so you could have a different problem.

You don't say if you have a Controller, but if you do what does the Advanced Settings>Player information say about the Receivers state, ip addresses etc when the port lights are out?

Could be a hardware fault of course, but that feels to me to be unlikely?

I didn't mean to suggest that Cisco equipment would be better or worse than any other, as you say it should be more reliable if anything, but I only meant to suggest that your situation hasn't got lots of responses because most users would be using home-based networking gear.


kantblue

[WB3FFV]

Bummer, that is what I thought when I got it setup. I had tried to get it configured before in Hybrid mode, and was having a hell of a time, so when it came up in bridge mode I just went with it. I guess the bottom line was, I was attempting to use the Ethernet port on the receiver, as I had it in all wireless mode before, and with a GigE into a switch that sits inches from the Receiver, it just made no sense to keep it linked to an AP half way across the house.

I do have a controller, and will wait till it drops again (sometimes a day or two, sometimes it can be a week plus) and will go into settings like you said and check and see what it thinks. Everything else in this house uses DHCP as well, and it's all working, so hard time imagining anything is wrong with it, but I can put it in debug mode as well if desired when the unit is acting up. I guess the other reason I doubt the DHCP server can be involved is that when it's dead as I said the lights are off on the port, and there is no link to the switch, so there is no possible way it could reach the DHCP server as the network port is turned off for whatever reason, so there is no connectivity.

Well on top of all that, I think the display has deteriorated for whatever reason, to the point it's just dim as heck, and has been for a long time. I can't be in a brightly lit room, and best have my glasses on so I can see really well, or I can hang up even using the controller. I am very much looking forward to that new touch coming out, as I have the feeling it will be high on my list, to replace the duet. With a nice big color screen, and an ever better digital outputs, it's a shoe in to my network..

I will let the sucker drop again and check what you suggested, but that has to wait till the next drop..

[kantblue]

Hi WB3FFV

The ability to change modes using the controller, indeed to setup true static ip addresses this way has long been a feature request from users on these forums. It seems to keep getting pushed into the next firmware build which is frustrating.

I wasn't suggesting there is any problem with your DHCP setup, but rather that the Duet Receiver IMHO has some problems using DHCP, even with MAC address assignment. Since I went the true static route with my Receiver using the NET:Udap application I haven't had to reboot anything for some time.

It may well be that when the Receiver has issues with DHCP, the lights on the back are off - I've never checked this, but a power on/off did make it work again for me when I was using DHCP, so it could be the same problem.

Of course you do realise that now you are waiting for this fault to occur, it won't happen again !

All the best
kantblue

[WB3FFV]

Yes, I agree, you would think stuff like the ability to change network settings and such would be in the basic core of the product, but as you said people have been waiting a long time for that..

I also see what your saying about the DHCP and using static addressing, the one thing you mention that didn't ring a bell is the NET:Udap application? What is this, and if it's something I can use, I can sure put statics into the units and see what they do. I for sure don't have to use DHCP, usually most things do so it makes it convenient. If the fix is as simple as that, I'd be happy to leave statics on the units.

Oh, and I see you know my luck.. Actually see, posting this and starting the thread will not fix the unit, as it won't mess up anymore as I expect it to mess up.. LOL

[Mnyb]

You can set true static on the controller by ssh to it and edit the file:

etc/network/interfaces

To activate, on the controller settings > advanced > remote login

Then use a ssh client of you liking and edit.

But the receiver need net::udap

[kantblue]

Hi WB3FFV

The NET:udap information is here:

http://projects.robinbowes.com/Net-UDAP/trac

You should find it a breeze after all that CISCO management stuff !

kantblue

PS
might be best to wait until you get your problem re-occuring, it may be nothing to do with this - although I have found the system to be much more reliable with static IP addressing.