Author
Topic: Frustrating new Network issue (Read 4596 times)

I'm having an issue with my 0810 setup that makes no sense whatsover and is yet again driving me crazy.I installed 0810 successfully in the network configuration cable modem->router->core->internal network. In this configuration, everything seems to be working OK.

However, I tried removing the router to give me: cable modem->core->internal network. In this configuration, I can access the net from the core without a problem, but I can't access http at all from any PCs on the internal network. I can ping lmce.org without a problem, however. Switching back to the 1st configuration fixes things consistently. Switching back to the second configuration breaks things consistently.

I captured some data with wireshark. This is a request for linuxmce.org from firefox on a windows PC on the internal network

...and then nothing, no data. Firefox is stuck at 'Waiting for reply.' This happens with any website I try. Does anyone have any idea what might be going on? Could this be an issue with my provider? Any help would be greatly appreciated as the WAF is quickly decreasing and I have a lot of work on this that I want to do.

Packets 1 and 3 in the second trace are from a previous session, so ignore those.

It looks like your cable modem is operating in bridge mode - does your model have a router mode? (worthwhile googling it because often they do and just need a small hack to enable it) Its just that router mode can make things much easier to follow and get working than a bridge.

Can you try doing the same browsing actually on the core rather than a machine in the internal network? Just to eliminate any routeability issues. Also, can you do a full ifconfig on eth0 so we can check the default gateway, subnet masks, etc? Finally, print out the routing table.

When you say you can ping linuxmce.org, do you mean from the same PC that is having the browsing issues? If so, have you tried any other protocols?

Could be a routing issue, could be a NAT issue, could be filtering at the ISP...

Like colinjones says, it might be the ISP. I've had issues with Comcast and RCN blocking things if you change the device/computer that is plugged into the cablemodem in the past. Give them a call and ask, especially if it is only HTTP that is being blocked (that indicates routing is fine so probably not the LMCE box).

colinjones:Http access works fine from the core, even in both configurations (internal network working, internal network not working), which makes me a bit worried that maybe it's not an ISP issue. I can print out DNS information and routing tables when I get back in front of the PC, but he DNS information looked good for both the core and the clients in that DNS and gateway information seemed valid. The only protocols I've tried so far are http and ping, though it looks like whatever protocol Yahoo IM is using is also affected.

Duh, yes hari is probably on to it. ICMP is very small, the http get request is small, but the http reply is large. I'd set the MTU to a super-low number to test, like 900 or something to be sure. If that works, then increase it bit by bit.

Doesn't really explain why it works fine from the core though - unless the issue is fragmentation between the modem and the core (seems unlikely). Also, the MTU sets the size for outbound packets, these are inbound - the MTU isn't communicated to the other side... still thinking through this one... pete, can you get those pieces of info? (wasn't asking for DNS, not really interested in that)

hmmm. if not MTU, certainly something like it that only effects small packets like the others suggested. The only other thing that springs readily to mind is a NAT issue. (the core fw NATs through to your internal network) but the evidence doesn't support that. It would work from the core but not the internal network (as you have) but not even the inital SYN/ACKs would work, which isn't what you have....

Another interesting piece of data is that when I reconfigure to the modem->router->core->internal network (i.e. working) state, I call dhclient -r to release followed by dhclient to renew dhcp info. After that, I can access the internet from the core, but I still have the same problem with PCs on the internal network. They only start working after a full reboot of the core.

Apparently, setting the MTU on windows machines (especially vista) is rather a pain to do. Instead I followed your previous advice and upped the eth0 (external) MTU to 1500. Things seem to be working after that. I'm not sure why the initial settings were different, as both adapters are onboard devices on the core, but this is a new phenomenon on 0810. The tx queue length is also different, inexplicably.

Thanks a lot for the help guys, it's truly appreciated and I think I can get back to real work now.

Apparently, setting the MTU on windows machines (especially vista) is rather a pain to do. Instead I followed your previous advice and upped the eth0 (external) MTU to 1500. Things seem to be working after that. I'm not sure why the initial settings were different, as both adapters are onboard devices on the core, but this is a new phenomenon on 0810. The tx queue length is also different, inexplicably.

is this surely new on 0810? We maybe get that MTU via DHCP. You may want to check that and verify the proper MTU with your provider. You may want to try a txqlen of 1000.

Quote

Thanks a lot for the help guys, it's truly appreciated and I think I can get back to real work now.

Good news! btw 576 is the "correct" MTU for the Internet, I have never seen any options in DHCP to set this, but IP generally has MTU/MSS minimum protocols for determining things like this. It does it for a path rather than an interface, so I'm not sure how it applies... can't remember the detail now. But either way, that value must be coming from the cable modem/provider

Good news! btw 576 is the "correct" MTU for the Internet, I have never seen any options in DHCP to set this, but IP generally has MTU/MSS minimum protocols for determining things like this. It does it for a path rather than an interface, so I'm not sure how it applies... can't remember the detail now. But either way, that value must be coming from the cable modem/provider

The Internet has no MTU, but your interfaces have. So I really don't understand what you mean with "correct for the Internet" (btw it was not working with 576). The BOOTP/DHCP option is 26, called "Interface MTU".The MSS is the maximum segment size for tcp connections. That one is calculated for the "path". There are options to tweak that on routers (e.g. "adjust-mss" on cisco routers), but that only works for tcp. So better use proper MTUs everywhere and allow ICMP fragmentation needed to avoid such kind of problems.