Toggle sidebar Toggle sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Bugs found in Leopard from someone who recently switched.

some people need to be nicer, OP is an OSX users, he had a problem, he want it to be solved.

Use mail.app instead of gmail? why? isn't gmail issue with safari a problem? Your suggestion doesn't fix the problem, merely ignoring it.

To OP. if this indeed is a bug in leopard, there is nothing you can do other than waiting for 10.5.3, you can submit a feedback at apple's website if you like.

I don't know if its a bug or not tho, since the problem can be happening in so many places. Do you have same network issue when connect your computer directly to router with a cable?

If you intend to try firefox for gmail, I would suggest firefox 3 beta5, which is more pleasant to use in OSX than version 2.
 
oban14 said:
2) Certain domains just aren't routable. Try a traceroute, and it's simply "no route found to host". Couldn't find any fix despite a lot of googling. These sites are largely random and they all work from XP.
Click to expand...

I suggest configuring the DNS server for your router and in network preferences to use OpenDNS. This solved a lot of internet connectivity issues for me.

If your ISP happens to be Time Warner/Adelphia/Comcast/etc... it's my belief that Leopard does have a hard time reliably connecting to their DNS services due to server setting on their end. Biased towards windows clients. This manifests as traceroute and "server not found" problems.

** i'm not affiliated w/ OpenDNS. I just think their service is better, faster, and more reliable than my ISP's. Oxford comma.
 
heatmiser said:
This is what makes this forum unique. Half the people don't actually offer solutions; they blame you for finding the problems!
Click to expand...

I have seemed to have spawned this, its simply the fact that OP made the post saying he found the problems because he switched.

I dont see the need for this, cant he just say what is wrong and then find the solutions, if you get my drift.
 
wordmunger said:
If Gmail doesn't work in Leopard, it's not a bug in Leopard, it's a bug in Gmail. I'm just saying.

That said, I've never had a problem sending large attachments in Gmail in Leopard. This suggests it's a problem with your local configuration of Gmail, not a bug in Leopard.
Click to expand...

The issue was experienced while using GMail with Safari under Leopard, but not experienced using GMail with other browsers such as FireFox and Camino (in my experience) under Leopard.
 
My traceroute to www.google.com

Code: 
 traceroute www.google.com
traceroute: Warning: www.google.com has multiple addresses; using 209.85.135.99
traceroute to www.l.google.com (209.85.135.99), 64 hops max, 40 byte packets
traceroute: sendto: No route to host
 1 traceroute: wrote www.l.google.com 40 chars, ret=-1
 *traceroute: sendto: No route to host
traceroute: wrote www.l.google.com 40 chars, ret=-1
 *traceroute: sendto: No route to host
traceroute: wrote www.l.google.com 40 chars, ret=-1
^C

To everyone: this should have nothing to do with the whole Gmail-Safari issue, since I use Firefox and can't reach Gmail under Leopard; as I previously stated, it shouldn't be a DNS-related issue, since I experienced it with OpenDNS too.
Under Windoze XP (I tried IE7, Firefox, Opera and Safari) and DamnSmallLinux (live Linux distro), I can reach those sites no problem: holy crap!!!

BTW, my girlfriend (SR MB, Leopard 10.5.2) just told me she can't access www.ansa.it (Italy's main print agency) anymore: OMG IT'S SPREADING!!!😀
 
netstat -r

Code: 
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.254      UGSc       53   349530    en1
127                localhost          UCS         0        0    lo0
localhost          localhost          UH          0        0    lo0
169.254            link#6             UCS         0        0    en1
172.16.134/24      link#8             UC          0        0 vmnet1
192.168.1          link#6             UCS         1        0    en1
192.168.1.100      localhost          UHS         1    31654    lo0
192.168.1.254      0:4:ed:6e:67:ac    UHLW       52   195808    en1    696
192.168.28         link#7             UC          1        0 vmnet8
192.168.28.1       0:50:56:c0:0:8     UHLW        0    35893    lo0

Internet6:
Destination        Gateway            Flags      Netif Expire
localhost          link#1             UHL         lo0
fe80::%lo0         localhost          Uc          lo0
localhost          link#1             UHL         lo0
fe80::%en1         link#6             UC          en1
Macintosh.local    0:1e:52:70:2e:9    UHL         lo0
ff01::             localhost          U           lo0
ff02::             localhost          UC          lo0
ff02::             link#6             UC          en1
 
Golcondio said:
Code: 
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.254      UGSc       53   349530    en1
127                localhost          UCS         0        0    lo0
localhost          localhost          UH          0        0    lo0
169.254            link#6             UCS         0        0    en1
172.16.134/24      link#8             UC          0        0 vmnet1
192.168.1          link#6             UCS         1        0    en1
192.168.1.100      localhost          UHS         1    31654    lo0
192.168.1.254      0:4:ed:6e:67:ac    UHLW       52   195808    en1    696
192.168.28         link#7             UC          1        0 vmnet8
192.168.28.1       0:50:56:c0:0:8     UHLW        0    35893    lo0

Internet6:
Destination        Gateway            Flags      Netif Expire
localhost          link#1             UHL         lo0
fe80::%lo0         localhost          Uc          lo0
localhost          link#1             UHL         lo0
fe80::%en1         link#6             UC          en1
Macintosh.local    0:1e:52:70:2e:9    UHL         lo0
ff01::             localhost          U           lo0
ff02::             localhost          UC          lo0
ff02::             link#6             UC          en1
Click to expand...

Interesting. What brand router do you have, and how it is configured? (DHCP, Static, if DHCP, what range, etc)
 
Router Digicom Michelangelo Wave 54.
Its IP is 192.168.1.254

I set it to serve DHCP from 192.168.1.100 onwards, therefore my IP is 192.168.1.100. I have set the port forwarding rules to that IP, of course.

I already tried to set it static, changing IP, but nothing changed, of course.
 
bump:

I can't see any of the youtube videos: the page is just plain white with blue links, and enbedded youtube videos on blogs show up grey.

EDIT: I actually tried and played one: it works! But only from embedded links...
 
Make sure your firewall is turned off, and clear the IPFW ruleset with a sudo ipfw flush. Clear out any proxy settings you might have. Flush your ARP cache with the command sudo arp -d -a.

I'd start with a few simple ICMP pings.

First, ping your own IP address. This will test your physical network interface.
Next, ping your router's internal IP address.
Next, ping the router's external IP address.
Next, ping your ISP's default gateway.
Finally, ping your DNSs.

I'd also grab a tool called Layer Four Traceroute (you can get it from Darwin Ports or Fink). LFT is faster than the built in traceroute tool, and it allows types of traces that can go unmolested by some packet-filters.



If all this fails, my next step would be to analyse the raw traffic stream with the built-in tcpdump tool or WireShark. WireShark will let you step trough a network stream packet-by-packet. You can see packets going out that may not have any reply, and you can see packets coming into your machine.
 
Ok, thanks: something works

I followed your instructions step by step, checking if anything had changed after each step, and finally, after a successful traceroute to google:

Code: 
lft -V www.google.com
Layer Four Traceroute (LFT) version 2.5
Using device en1, 192.168.1.100:53
SENT TTL=0 SEQ=1034036149 FLAGS=0x2 ( SYN )
SENT TTL=1 SEQ=1034036150 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036149 REF=1034036149 SRC=192.168.1.254
SENT TTL=2 SEQ=1034036151 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036150 REF=1034036150 SRC=151.23.224.110
SENT TTL=3 SEQ=1034036152 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036151 REF=1034036151 SRC=10.0.51.1
SENT TTL=4 SEQ=1034036153 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036152 REF=1034036152 SRC=151.6.248.65
RCVD ICMP SEQ=1034036153 REF=1034036153 SRC=151.6.52.49
SENT TTL=5 SEQ=1034036154 FLAGS=0x2 ( SYN )
SENT TTL=6 SEQ=1034036155 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036154 REF=1034036154 SRC=151.6.7.137
SENT TTL=7 SEQ=1034036156 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036155 REF=1034036155 SRC=212.245.228.18
RCVD ICMP SEQ=1034036156 REF=1034036156 SRC=213.242.65.29
SENT TTL=8 SEQ=1034036157 FLAGS=0x2 ( SYN )
SENT TTL=9 SEQ=1034036158 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036157 REF=1034036157 SRC=4.69.133.130
SENT TTL=10 SEQ=1034036159 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036158 REF=1034036158 SRC=4.69.133.138
SENT TTL=11 SEQ=1034036160 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036159 REF=1034036159 SRC=4.69.132.137
SENT TTL=12 SEQ=1034036161 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036160 REF=1034036160 SRC=4.69.132.130
SENT TTL=13 SEQ=1034036162 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036161 REF=1034036161 SRC=4.69.133.89
SENT TTL=14 SEQ=1034036163 FLAGS=0x2 ( SYN )
SENT TTL=15 SEQ=1034036164 FLAGS=0x2 ( SYN )
SENT TTL=16 SEQ=1034036165 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036164 REF=1034036164 SRC=129.250.2.101
SENT TTL=17 SEQ=1034036166 FLAGS=0x2 ( SYN )
SENT TTL=18 SEQ=1034036167 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036166 REF=1034036166 SRC=129.250.4.104
SENT TTL=19 SEQ=1034036168 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036167 REF=1034036167 SRC=129.250.2.46
SENT TTL=20 SEQ=1034036169 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036168 REF=1034036168 SRC=83.231.146.198
SENT TTL=21 SEQ=1034036170 FLAGS=0x2 ( SYN )
RCVD TCP FLAGS=0x12 ( ACK SYN ) SEQ=530690896 ACK=1034036170 REF=1034036169 SRC=208.69.34.230
RCVD TCP FLAGS=0x12 ( ACK SYN ) SEQ=530690899 ACK=1034036171 REF=1034036170 SRC=208.69.34.230
SENT TTL=13 SEQ=1034036171 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036171 REF=1034036171 SRC=4.68.120.80
SENT TTL=14 SEQ=1034036172 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036172 REF=1034036172 SRC=213.244.165.242
SENT TTL=16 SEQ=1034036173 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1034036173 REF=1034036173 SRC=129.250.2.20
TTL LFT trace to google.navigation.opendns.com (208.69.34.230):80/tcp
 1  192.168.1.254 20.8ms
 2  151.23.224.110 20.8ms
 3  10.0.51.1 20.8ms
 4  151.6.248.65 20.9ms
 5  151.6.52.49 20.5ms
 6  151.6.7.137 21.1ms
 7  212.245.228.18 21.1ms
 8  so-8-1.car1.Milan1.Level3.net (213.242.65.29) 20.5ms
 9  ae-11-11.car2.Milan1.Level3.net (4.69.133.130) 20.9ms
10  ae-4-4.ebr2.Frankfurt1.Level3.net (4.69.133.138) 40.8ms
11  ae-2.ebr1.Dusseldorf1.Level3.net (4.69.132.137) 40.6ms
12  ae-1-100.ebr2.Dusseldorf1.Level3.net (4.69.132.130) 41.2ms
13  ae-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) 60.6ms
14  ae-12-53.car2.Amsterdam1.Level3.net (4.68.120.80) 40.8/*ms
15  verio-level3-ge.Amsterdam1.Level3.net (213.244.165.242) 40.5/*ms
16  xe-2-0-0.r23.amstnl02.nl.bb.gin.ntt.net (129.250.2.101) 61.5ms
17  xe-0-2-0.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.20) 60.6/*ms
18  p64-2-0-0.r23.londen03.uk.bb.gin.ntt.net (129.250.4.104) 81.3ms
19  xe-3-1.r01.londen03.uk.bb.gin.ntt.net (129.250.2.46) 61.4ms
20  83.231.146.198 61.1ms
21  [target] google.navigation.opendns.com (208.69.34.230):80 61.8ms

I can now do google searches, but gmail and yahoo are still off-limits:

Code: 
lft -V www.gmail.com
Layer Four Traceroute (LFT) version 2.5
Autoconfigured to source tcp/25, destination tcp/25.
LFT: UDP connect(); unable to determine interface: Connection refused
Using device en0, ioctl: Can't assign requested address
broadcasthost (255.255.255.255):25
SENT TTL=0 SEQ=1129733618 FLAGS=0x2 ( SYN )
SENT TTL=1 SEQ=1129733619 FLAGS=0x2 ( SYN )
SENT TTL=2 SEQ=1129733620 FLAGS=0x2 ( SYN )
SENT TTL=3 SEQ=1129733621 FLAGS=0x2 ( SYN )
SENT TTL=4 SEQ=1129733622 FLAGS=0x2 ( SYN )
SENT TTL=0 SEQ=1129733623 FLAGS=0x2 ( SYN )
SENT TTL=1 SEQ=1129733624 FLAGS=0x2 ( SYN )
SENT TTL=2 SEQ=1129733625 FLAGS=0x2 ( SYN )
SENT TTL=3 SEQ=1129733626 FLAGS=0x2 ( SYN )
SENT TTL=4 SEQ=1129733627 FLAGS=0x2 ( SYN )
SENT TTL=5 SEQ=1129733628 FLAGS=0x2 ( SYN )
SENT TTL=6 SEQ=1129733629 FLAGS=0x2 ( SYN )
SENT TTL=7 SEQ=1129733630 FLAGS=0x2 ( SYN )
SENT TTL=8 SEQ=1129733631 FLAGS=0x2 ( SYN )
TTL LFT trace to nf-in-f83.google.com (64.233.183.83):25/tcp
**  [25/tcp failed]  Try alternate options or use -V to see packets.

What should I aim for, when monitoring packets?
 
I find this interesting:

Using device en0, ioctl: Can't assign requested address
Click to expand...

Because it would seem that you connect to the internet using en1. Tell me, are you using ethernet or airport? Have you made changes to the service order in the Network Settings system preference?

lft -V www.gmail.com fails for you, but try lft -V -D en1 www.gmail.com
 
chrisblaze said:
Just confirmed that bug, it happen to me also, but I think he meant "Hysterical" and not Hilarious.
Click to expand...

It seems to me that he might be Italian and Hilarious is the English translation he used.😉

EDIT: I just tried the hysterical thing, and it didn't crash. It may not happen all the time?

EDIT: Nevermind. Didn't change the setting properly. It crashed 🙂
 
Re: the traceroute thing...

For traceroute, Windows uses IMCP packets, however... OS X (and Linux) use UDP packets, by default.

Use the -I flag if you want OS X traceroute to act like Windows' tracert...

Edited to add:

(Some routers may block all UDP packets).... man traceroute for more details...
 
ElectricSheep said:
I find this interesting:



Because it would seem that you connect to the internet using en1. Tell me, are you using ethernet or airport? Have you made changes to the service order in the Network Settings system preference?

lft -V www.gmail.com fails for you, but try lft -V -D en1 www.gmail.com
Click to expand...

I do connect with en1, which is mapped to my airport; i never changed anything in the service order: moreover, whatever happened to me, it happened suddenly, without any intervention on my part (I surely never tamper with settings that work: I learned it the hard way on Gentoo, where the system broke every time I upgraded a perfectly good driver/packet).

About the gmail thing:
Code: 
lft -V -D en1 www.gmail.com
Layer Four Traceroute (LFT) version 2.5
Autoconfigured to source tcp/25, destination tcp/25.
Using device en1, 192.168.1.100:25
SENT TTL=0 SEQ=1991304104 FLAGS=0x2 ( SYN )
SENT TTL=1 SEQ=1991304105 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1991304104 REF=1991304104 SRC=192.168.1.254
SENT TTL=2 SEQ=1991304106 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1991304105 REF=1991304105 SRC=151.23.224.98
SENT TTL=3 SEQ=1991304107 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1991304106 REF=1991304106 SRC=10.0.31.1
SENT TTL=4 SEQ=1991304108 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1991304107 REF=1991304107 SRC=151.6.248.73
SENT TTL=5 SEQ=1991304109 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1991304108 REF=1991304108 SRC=151.6.52.53
SENT TTL=6 SEQ=1991304110 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=1991304109 REF=1991304109 SRC=151.6.7.137
RCVD ICMP SEQ=1991304110 REF=1991304110 SRC=151.6.0.174
SENT TTL=7 SEQ=1991304111 FLAGS=0x2 ( SYN )
SENT TTL=8 SEQ=1991304112 FLAGS=0x2 ( SYN )
SENT TTL=9 SEQ=1991304113 FLAGS=0x2 ( SYN )
SENT TTL=10 SEQ=1991304114 FLAGS=0x2 ( SYN )
SENT TTL=11 SEQ=1991304115 FLAGS=0x2 ( SYN )
SENT TTL=7 SEQ=1991304116 FLAGS=0x2 ( SYN )
SENT TTL=8 SEQ=1991304117 FLAGS=0x2 ( SYN )
SENT TTL=9 SEQ=1991304118 FLAGS=0x2 ( SYN )
SENT TTL=10 SEQ=1991304119 FLAGS=0x2 ( SYN )
SENT TTL=11 SEQ=1991304120 FLAGS=0x2 ( SYN )
SENT TTL=12 SEQ=1991304121 FLAGS=0x2 ( SYN )
SENT TTL=13 SEQ=1991304122 FLAGS=0x2 ( SYN )
SENT TTL=14 SEQ=1991304123 FLAGS=0x2 ( SYN )
SENT TTL=15 SEQ=1991304124 FLAGS=0x2 ( SYN )
SENT TTL=16 SEQ=1991304125 FLAGS=0x2 ( SYN )
SENT TTL=12 SEQ=1991304126 FLAGS=0x2 ( SYN )
SENT TTL=13 SEQ=1991304127 FLAGS=0x2 ( SYN )
SENT TTL=14 SEQ=1991304128 FLAGS=0x2 ( SYN )
SENT TTL=15 SEQ=1991304129 FLAGS=0x2 ( SYN )
SENT TTL=16 SEQ=1991304130 FLAGS=0x2 ( SYN )
SENT TTL=17 SEQ=1991304131 FLAGS=0x2 ( SYN )
SENT TTL=18 SEQ=1991304132 FLAGS=0x2 ( SYN )
TTL LFT trace to ik-in-f19.google.com (66.249.91.19):25/tcp
 1  192.168.1.254 20.7ms
 2  151.23.224.98 20.6ms
 3  10.0.31.1 20.6ms
 4  151.6.248.73 20.9ms
 5  151.6.52.53 21.2ms
 6  151.6.7.137 20.9ms
 7  151.6.0.174 20.7ms
**  [25/tcp failed]  Try alternate options or use -V to see packets.

Still no idea...

Re: the traceroute thing...

For traceroute, Windows uses IMCP packets, however... OS X (and Linux) use UDP packets, by default.

Use the -I flag if you want OS X traceroute to act like Windows' tracert...

Edited to add:

(Some routers may block all UDP packets).... man traceroute for more details...
Click to expand...

Code: 
traceroute -I www.gmail.com
traceroute: Warning: www.gmail.com has multiple addresses; using 66.249.91.18
traceroute to googlemail.l.google.com (66.249.91.18), 64 hops max, 60 byte packets
traceroute: sendto: No route to host
 1 traceroute: wrote googlemail.l.google.com 60 chars, ret=-1
 *traceroute: sendto: No route to host
traceroute: wrote googlemail.l.google.com 60 chars, ret=-1
 *traceroute: sendto: No route to host
traceroute: wrote googlemail.l.google.com 60 chars, ret=-1
 *
traceroute: sendto: No route to host

My router works fine, it traces www.google.com correctly, after all...
 
Golcondio said:
...
My router works fine, it traces www.google.com correctly, after all...
Click to expand...

Yes, but there are other routers along the route other than just your router. 😉 My ISP blocks ICMP on some of their routers, for example.

Regardless, I see the traceroute -I didn't work for you. However, I tried the same Google IP# in your example on a Mac here and the trace worked fine...
 
localoid said:
Yes, but there are other routers along the route other than just your router. 😉 My ISP blocks ICMP on some of their routers, for example.

Regardless, I see the traceroute -I didn't work for you. However, I tried the same Google IP# in your example on a Mac here and the trace worked fine...
Click to expand...

Yeah, shame on me for not thinking about it 😛

I still suspect it must be related to Leopard, since it all started after I updated the system to 10.5.2...
 
wordmunger said:
If Gmail doesn't work in Leopard, it's not a bug in Leopard, it's a bug in Gmail. I'm just saying.

That said, I've never had a problem sending large attachments in Gmail in Leopard. This suggests it's a problem with your local configuration of Gmail, not a bug in Leopard.
Click to expand...

Likewise, if Chess crashes with one of its voices, the bug is in Chess.
 
My router works fine, it traces www.google.com correctly, after all...
Click to expand...

[/quote]

Unless its randomly dropping packets. I did some digging into your RTM_LOSING: Kernel Suspects Partitioning message, and its caused when the kernel thinks that a route is failing (due to excessive dropped packets).

Your symptoms seem consistent with a flapping route; a connection that comes up-then goes down-then comes up-then goes down. You know that you reach the internet through interface en1 come hell or high-water, so explicitly specifying the use of that interface should always work.

Every time the link goes down, the kernel has to find a new route to send packets. Windows may be more tolerant of a crappy connection than Leopard. I will do some digging to see if there are some route parameters or sysctl variables that you can set to keep routes more resilient to a flapping link.

In the mean time, try running some long ping sessions; a few hundred or even a thousand packets. Ping your router and check for % packet loss. Ping some outside host, and check for % packet loss.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back