site_archiver@lists.apple.com Delivered-To: Macnetworkprog@lists.apple.com On Sep 30, 2005, at 6:50 AM, Eric Dahlman wrote: Howdy, -Marc On Sep 29, 2005, at 8:43 PM, Marc Krochmal wrote: Hi Eric, <http://developer.apple.com/qa/qa2001/qa1176.html> Thanks. -Marc On Sep 29, 2005, at 6:19 PM, Eric Dahlman wrote: Howdy, Thanks, -Eric P.S. Both machines are running Tiger with the latest updates. This email sent to marc@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists.... I have sent the trace in a separate message. Just some extra information here. At present mDNSresponder is taking up about 50% of my CPU and is about 864 K in size. When I went home last night my powerbook did not show any of this traffic and when I came in to the office it also did not. I noticed it after about half an hour and switching users, sorry I cannot say exactly when it started or if fast user switching was a contributing factor. I also started a packet trace with Ethereal to watch http traffic during this time but alas it got too big to be manageable. I will describe those problems in my next installment as I think they have a different cause but still may be related ;-) The reason that mDNSResponder is using 50% CPU is not because it's sending these packets, it's because mDNSResponder is receiving and processing all these packets. Given you're having this problem and the "Slashdot" problem, I think this is happening somewhere in the kernel or in your Ethernet hardware. In the packet trace, every mDNS packet has the same IP identifier, meaning that this is the exact same packet being sent by the kernel over and over. Hopefully someone else on the list can provide more information about how to debug this. Could you capture a full packet trace in tcpdump format and then send it to me. In trying to track down another problem I have noticed that there is a huge amount of mdns generated by my machine. This is on the order of 1400 packets a second, that is kind of much I assume. I have included the details on one of these packets below. My machine is on a private net with IP 192.168.172.13 and the other machine (steinbit) is on the other side of a nat with a internet visible IP 204.72.xx.xx (to protect the innocent). If it matters my machine is a laptop that regularly moves between two different private networks natted to the internet (work and home). I would appreciate any idea about what is going on an what I can do to stop it. No. Time Source Destination Protocol Info 4 0.001356 192.168.172.1 224.0.0.251 MDNS Standard query response PTR steinbit._afpovertcp._tcp.local Frame 4 (191 bytes on wire, 191 bytes captured) Ethernet II, Src: Cisco-Li_20:09:1e (00:0f:66:20:09:1e), Dst: 01:00:5e:00:00:fb (01:00:5e:00:00:fb) Internet Protocol, Src: 192.168.172.1 (192.168.172.1), Dst: 224.0.0.251 (224.0.0.251) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x18 (DSCP 0x06: Unknown DSCP; ECN: 0x00) Total Length: 173 Identification: 0xa2a7 (41639) Flags: 0x00 Fragment offset: 0 Time to live: 254 Protocol: UDP (0x11) Header checksum: 0xcbda [correct] Source: 192.168.172.1 (192.168.172.1) 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: 153 Checksum: 0x0000 (none) Domain Name System (response) Transaction ID: 0x0000 Flags: 0x8400 (Standard query response, No error) Questions: 0 Answer RRs: 1 Authority RRs: 0 Additional RRs: 4 Answers _afpovertcp._tcp.local: type PTR, class IN, steinbit._afpovertcp._tcp.local Name: _afpovertcp._tcp.local Type: PTR (Domain name pointer) Class: IN (0x0001) Time to live: 1 hour, 15 minutes Data length: 11 Domain name: steinbit._afpovertcp._tcp.local Additional records steinbit-2.local: type AAAA, class FLUSH, addr fe80::20d: 93ff:fe65:a43e Name: steinbit-2.local Type: AAAA (IPv6 address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 16 Addr: fe80::20d:93ff:fe65:a43e steinbit-2.local: type A, class FLUSH, addr 204.72.172.188 Name: steinbit-2.local Type: A (Host address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 4 Addr: 204.72.172.188 steinbit._afpovertcp._tcp.local: type SRV, class FLUSH, priority 0, weight 0, port 548, target steinbit-2.local Name: steinbit._afpovertcp._tcp.local Type: SRV (Service location) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 8 Priority: 0 Weight: 0 Port: 548 Target: steinbit-2.local steinbit._afpovertcp._tcp.local: type TXT, class FLUSH Name: steinbit._afpovertcp._tcp.local Type: TXT (Text strings) Class: FLUSH (0x8001) Time to live: 1 hour, 15 minutes Data length: 1 Text: _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/marc% 40apple.com This email sent to site_archiver@lists.apple.com