Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[blaquesmith]

Dlink NTP Server works, time.nist.gov works. But the Day Light Savings time offset doesn't work. Well Eastern Standard Time will spring forward this weekend I think. So that may be the "insecticon" that's harassing me. And initially I always use 0.us.pool.ntp.org (didn't work, boot hiccups! ) as my NTP Server of choice, which forced me to post something in the first place

-blaquesmith

[bluenote]

Its absolutely ridiculous that  a time request could cause reboots.  I mean, yeah, ok, maybe that server is sending back unexected results, but seriously.  Unless your code is made of tissue paper (which apparently it is) it should be able to handle the occasional exception.

I've got my 655 working (finally) as it mostly should now after several weeks of messing with it but all these things I read make me even MORE afraid to even look sideways at it.

[HazardX]

I can reproduce the time server problem, you can however stop the reboots by disconnecting the wan cable, which will let you log back into the router and "fix" your mistake.

I *suspect* that the reboots are related to measurement of uplink speed (somehow), which cased me all kinds of hassle when I updated to the new 1.22 beta (reset to defaults before and after the upgrade).

And curiously, despite the fact that I have the checkbox NOT TO MEASURE uplink speed, it SEEMS to still do it upon every restart. Or at least I get a screen saying that uplink speed measurement is being measured and the page will refresh shortly--bloody irritating every ~20 seconds when I'm reconfiguring the router, a task I've gotten very very well practiced at  .

As of so far, my impression of 1.22 is that its the same as the last 1.21 beta I was using, except 1.22 was a bigger pain about setup. And is still eating multicast mDNS traffic (in some fashion) preventing anything that uses mdns from finding each other.

Also, I don't know if its just me, but if I disable DNS relay (makes MDNS a little more reliable for some reason), and I've got the WAN port configured for a static address, and in the static WAN address I only give it one DNS server, the DIR-655 ends up handing off two static DNS server addresses to all its clients, the primary one I set for the WAN port, and 0.0.0.0. This has no affect on linux boxes (that I can find), but seems to confuse Apple Leopard machines, which try to use it as a valid DNS server... which it very much isn't.

I've got hardware version A4 by the way.

I'm also somewhat fuzzy on what uplink speed measurement is actually measuring, and/or if that's even useful to me. Especially since my DIR-655 is connected to another router as part of a larger local network segment (then the router I connect to is actually connected to the internet). This basically results in my WAN port being a LAN port.

[mazman]

The WOL issue is not a bug, it is a proper security measure.  Forwarding unicast traffic to broadcast is bad juju, and there is no other way of ensuring the PC gets the magic packet without it being on and responding to ARP requests.

Pardon my lack of networking/router knowledge, but shouldn't I be able to use the port forwarding feature of the router to wake a specific PC? After all, there is an option for Wake on Lan in the Virtual Server page under Advanced Options.

[Fatman]

Pardon my lack of networking/router knowledge, but shouldn't I be able to use the port forwarding feature of the router to wake a specific PC? After all, there is an option for Wake on Lan in the Virtual Server page under Advanced Options.

You may have me there on the existence of an Advanced Options page for WoL.  Someone who has actually logged into this router in the past year will have to comment on that option, however it makes things hopeful for you.

Normally on our products you can not pass WoL through the router because incoming traffic has to be NAT'ed to a particular IP, if that IP is not currently in the devices ARP table, it will send out ARP requests for that IP.  A machine that is off will not respond, so once your network no longer has a device to point out the MAC address of the forwarded IP the traffic can not be forwarded.

The "easy" solution is to forward that incoming port to a broadcast address so every PC on the network receives it (if you were on the LAN this is what you would do anyhow).  Problem is forwarding incoming traffic to a broadcast address is a rather bad idea.  Which is why when you mentioned WoL issue I had the gut reaction of it wasn't going to happen.

If there exists some sort of an option to allow you to forward traffic to the broadcast against our judgement, or that allows you to enter in a static MAC address for a host, then you should be functional and I take back what I said about WOL.  That said, if it is the first option is how it should work I would ask they remove that feature if the decision was mine.  Good thing it isn't.

[bluenote]

I can't speak for the port forwarding configuration on the 655, but I was able to set up WOL with my old dlink 504 by using a different internal subnet mask.  (such that, the broadcast address wasn't .255) .. because the dlink interface didnt support putting in .255 for forwarding.  But it didnt understand that if its own subnet was .128 or whatever, I could still achieve the same thing.

And there's nothing really wrong with it in a home router setup.  If you were in an enterprise environment, yes, ok, sure of course not.  But with 2 computers ... no biggie.

Cory