I had a miserable day fighting with networking issues today. You don't want to hear about it, unless I ended up solving the same problem you have (which is why I'm writing this -- for the search engines to pick up).
A few days ago, some web sites suddenly seemed mostly unaccessible (accessible, say, 5% of the time), while others were just fine. Since most Yahoo! sites were among the missing, this was a big problem.
The other day I was able to pinpoint that the problem occurred when I used my router (Corega BAR-SD) inline between my ISP and my computers. So, today I tried to get to the bottom of it.
Upgrading the router's firmware didn't solve the problem.
“The problem”, in this case, is that I could connect to some sites, but nothing would be returned before the connection would time out. So, I installed Ethereal (now called “Wireshark”), a network protocol analyzer, to watch what was happening. I'm not a network expert by any means, but I could see that there many duplicate ACKs, which is probably not good.
My brother recommend that I also sniff the traffic on the other side of the router, to see if the traffic was leaving the router properly. So, I went through the hassle to put one computer on the outside of the router, and another on the inside, and then tried to watch what happened as the from-the-inside request timed out.
Unfortunately, I used a switch rather than a hub to hook up both the router and the outside-the-router computer to my ISP, which means that the outside-the-router computer didn't see any traffic from the router itself. Doh. I don't have a non-switching hub. Sigh.
In the process of this, though, I'd run Ethereal on my wife's XP box and noticed that some apparent nasty-ware was contacting “offerapp.com” (67.29.139.222) serendipitously. So, this started the tangent of running the Anti-Spy component of Yahoo! Toolbar and Microsoft® Windows AntiSpyware, but a subsequent test still showed the traffic. Sigh. Must look into this later.
Back to my router problem, I decided that the router is probably just bad, so I rode my bike down to the Teramachi Joshin Denki to pick up another. While looking for one, I noticed that they didn't seem to sell a non-switching hub. Still, I should probably have one on hand just for the type of network-sniffing task I ran into today.
Anyway, I ended up dropping $50 on a Corega BARF-X2 router. (It's actually called “BAR-FX-2”, but it's more fun to write as “BARF-X2”.) Despite the previous Corega router apparently dying not much more than a year after having bought it, I stuck with the Corega over Buffalo (the other choice) because the BARF-X2 was likely to have a “PC Database” feature (see sidebar below).
What Corega calls its “PC Database” feature may well be a common feature among today's routers, but I'd not heard of it at all until noticing it this week while futzing with my old Corega BAR-SD.
It's a feature which allows you to reserve a specific IP in the DHCP pool for a specific computer (that is, for a specific MAC address). This allows me to, for example, set it up so that my laptop always gets 192.168.1.4, yet still leave the laptop's network settings at the simple “use DHCP” settings. It indeed uses DHCP, but because I've associated its MAC address with .4 in the router, it always gets .4.
This is very cool, especially when NAT and port forwarding are concerned: you can safely forward traffic to an IP and know that it will always reach the specific computer. My dad's router didn't have this feature, and sometimes after a power interruption, if he's unlucky, his computer won't get the IP he had before -- the one that has some ports his computer needs forwarded to it -- and he's boned. This “PC Database” feature would solve that.
One small issue is that while the BAR-SD showed computer names and WAP identifiers in its list of connected systems, the BARF-X2 does not. )-:
So, things worked just fine with the new router, but I was still wondering if I should put my Vonage VoIP modem (Motorola VG1005v) between the ISP and my router, or just as a client of the router. It's simpler for me to just put it as a client of my router, but there are some benefits to putting it inline before the router. One is that it will give voice traffic priority over data traffic. However, while that might make an important difference on a small DSL/Cable pipe, it's not relevant on my 50 Mbit uplink (it's advertised as 100 Mbit, but a speed test got only about half that).
Another benefit of putting the VoIP modem first is that I used its MAC address when signing up for a fixed public IP from my ISP. Currently, I get up to 5 private addresses (the whole building is behind NAT), but once they get the paperwork I sent in the other day, they'll give me a public IP .... but only when the device I registered connects. In a fit of stupidness the other day, I'd given the VoIP modem's MAC address. If I put the router first, I'll continue to get the private addresses.
While rummaging around the VoIP modem's configuration screens, I turned off the “DHCP/NAT on LAN Port” feature. I had an idea what it would do, but wasn't quite sure, so gave it a try. In one sense, the result was as I expected -- putting things downstream of it connected to my ISP as if it wasn't there. What I didn't (and still don't) know is how the modem itself connects in this situation. I suppose it's a DHCP client itself, consuming an IP, but I don't really know.
Anyway, I then ran into the problem of how to turn the DHCP/NAT back on. To do that, I needed to access its menus (at the fixed address of 192.168.102.1, via its LAN port), but since my ISP was giving me address like 172.16.126.241 (and I was getting those even when connected downstream via the LAN port), I felt pretty stuck.
Fast-forward several hours of futzing around and I finally figured it out: Hooked things up as ISP -> Router -> VoIP -> Computer and set my router to 192.168.102.5. I was then able to see 192.168.102.1 (the Motorola VoIP modem) from the computer, and turn DHCP/NAT back on. Ugh. Then set the router back to 192.168.1.1 where I like it, and reconfigure things so that the VoIP Modem is a simple client of my router, as are all my computers (and nothing is downstream from the VoIP modem)
By the way, why did I care about turning DHCP/NAT back on? In case we bring it with us somewhere, we want to be able to put it inline with our single-IP connection and still connect with a computer plugged into the back of the modem.