imac ethernet takes down local network

Question

Level 1

8 points

imac ethernet takes down local network

For the last couple of months my local network has been experiencing intermittent issues whereby devices on the local network can not communicate with each other or the internet. Ping responses between devices on the local network timeout or may start responding with extraordinary long times (50 seconds).

The network consists of a single LAN segment with iMac, timecapsule, MacPro, MacBooks, MacMini Server and is served by netgear 'switches' and netgear adsl router/wireless. The iMac is 'daisy chained' off the back of the TimeCapsule using the iMac wired ethernet port. MacPro & MacMini are also hardwired.

After a process of elimination (which included selectively restarting devices ) the problem appears to be with the iMac. Even if I restart the TimeCapsule, it's only after an iMac restart, that the problem subsides, however, after an indeterminate time (days or weeks), the problem does return.

When powering off the iMac (during the problem) it's only until the Imac actually powers off that the problem stops. If I then power on, all is well.

I have installed wireshark on the iMac and the MacPro and will try a packet capture next time it happens to try and see what is going on, but in the meantime, has anyone else experienced anything like this or have any other suggestions?

Mac Pro, Mac OS X (10.5.7)

Posted on Feb 11, 2011 1:42 AM

Reply

Answer 1

luvlabs

Level 4

3,620 points

Feb 12, 2011 7:16 AM in response to DeclanSmith

This really sounds like you are getting an IP address conflict somewhere in your network.

Do you have DHCP turned on in your router or are you using static IP addresses? Do you have your Time Capsule router features turned on or off?

Since you have Netgear ADSL router, which device is issuing IP address - the Netgear or the Time Capsule?

I would retire the Netgear router, let the Time Capsule connect to your ADSL modem and handle the wired and wireless networking. You Netgear switch can still do what it is doing. If your Netgear ADSL router is also the modem, then just disable all of its router functions/features and pass the signal on to the TimeCapsule to do the work.

Reply

Answer 2

DeclanSmith Author

Level 1

8 points

Feb 12, 2011 10:51 AM in response to luvlabs

It's definitely not an IP conflict, I ruled this out in the beginning. IP addresses are a mixture of static and dynamic. Dynamic ones are issued vi the OS/X server and not by timecapsule, netgear or otherwise.

Interestingly though, the problem has re-occured and I was able to capture packets both from the iMac and the MacPro. The iMac reports trying to establish connections to various sites and failing with RST packets with a reasonable number of packets being generated (~250 over 3-4 minutes), whereas the MacPro saw a very different view of the world, seeing some 54000 packets over half this period.

Most of these are as follows:
29751 69.821860 10.0.4.57 224.0.0.251 MDNS Standard query response[Malformed Packet]

Literally, as soon as the power actually turned off, the packets stopped coming, which leads me to think this is a hardware/firmware issue with the iMac ethernet. What I am inclined to do now is disconnect the physical ethernet and try it on Wireless.

Full packet expansion below. Checksum error.

No. Time Source Destination Protocol Info
29751 69.821860 10.0.4.57 224.0.0.251 MDNS Standard query response[Malformed Packet]

Frame 29751 (60 bytes on wire, 60 bytes captured)
Arrival Time: Feb 12, 2011 18:33:26.659510000
[Time delta from previous captured frame: 0.000002000 seconds]
[Time delta from previous displayed frame: 0.000002000 seconds]
[Time since reference or first frame: 69.821860000 seconds]
Frame Number: 29751
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:dns]
[Coloring Rule Name: TTL low or unexpected]
[Coloring Rule String: ( ! ip.dst == 224.0.0.0/4 && ip.ttl < 5) || (ip.dst == 224.0.0.0/24 && ip.ttl != 1)]
Ethernet II, Src: Apple_f8:39:9c (60:fb:42:f8:39:9c), Dst: IPv4mcast_00:00:fb (01:00:5e:00:00:fb)
Destination: IPv4mcast_00:00:fb (01:00:5e:00:00:fb)
Address: IPv4mcast_00:00:fb (01:00:5e:00:00:fb)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Apple_f8:39:9c (60:fb:42:f8:39:9c)
Address: Apple_f8:39:9c (60:fb:42:f8:39:9c)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src: 10.0.4.57 (10.0.4.57), Dst: 224.0.0.251 (224.0.0.251)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x3847 (14407)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
[Expert Info (Note/Sequence): "Time To Live" > 1 for a packet sent to the Local Network Control Block (see RFC 3171)]
[Message: "Time To Live" > 1 for a packet sent to the Local Network Control Block (see RFC 3171)]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (0x11)
Header checksum: 0x8f21 [incorrect, should be 0x9449]
[Good: False]
[Bad : True]
[Expert Info (Error/Checksum): Bad checksum]
[Message: Bad checksum]
[Severity level: Error]
[Group: Checksum]
Source: 10.0.4.57 (10.0.4.57)
Destination: 224.0.0.251 (224.0.0.251)
User Datagram Protocol, Src Port: mdns (5353), Dst Port: mdns (5353)
Source port: mdns (5353)
Destination port: mdns (5353)
Length: 20
Checksum: 0x60b5 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Domain Name System (response)
Transaction ID: 0x0000
Flags: 0x8600 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for domain
.... ..1. .... .... = Truncated: Message is truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 0
Answer RRs: 10
Authority RRs: 0
Additional RRs: 0
[Malformed Packet: DNS]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Message: Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]

Reply

Answer 3

Jun 3, 2011 12:33 PM in response to DeclanSmith

DeclanSmith,

How did this turn out? I believe I have a similar problem. I've got a mixed network (linux-wired, imac-wired, macbook-wireless, pc-wireless) that is exhibiting the following behavior:

After some indeterminate, and inconsistent, period of time I lose access to the web from any computer. I also lose access to my router (Dlink DIR-655) from wired computers. I can access the router wirelessly, reboot it from the configuration screens, and all is well for another indeterminate and inconsistent period.

I had the imac connected wirelessly at first (~6 months ago) but had other connectivity problems with it. Since then, there have been a couple of times when the iMac has been powered off and the network is fine. Power it on, and the timebomb begins.

I'm in the process of going back to a wireless connection for the imac to see if that fixes the problem, but wondered what you've found.

Thanks in advance.

g2

Reply