Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I'm having a weird problem and hope somebody can tip me, what way should I dig to.

I'm using MacBookPro with Lion 10.7.3 both at my working place & at home.

At working place, we have a domain-based network with 802.1x authorization (more than 400 computers) and to connect it I'm using Ethernet cable. IP range is 10.10.2.*. All network settings are setup automatically by DHCP. Also, in settings, I have Network Account Server setup in the User&Groups Settings for my work Domain server - and it is available only from corporate network.

At home, I have an ADSL router, that shares Internet connection by WiFi in NAT mode. I'm using WiFi to connect it. Router gives out addresses from 192.168.1.* range and all settings are also set up by router's DHCP.

So, my problem is the following. When I come back home from the office, I open my MacBook and AirPort automatically connects my WiFi network. After this, for about 1 minute I'm able to browse sites & ping hosts successfully. But after this minute, network connection is broken down. All pings return time-out. trace route to google.com stops on 192.168.1.1 (which is my router). This lasts for 3-4 minutes. After that network connection is automatically repaired and all pings go smoothly again. At the same time, when my MacBook return timeouts, I can successfully ping any host from my wife's MacBook - so this doesn't look like router issue. When I come to the office, I don't have any issues and Internet connection is available & stable moments after ethernet cable plugged in.

Do anybody has any clues about this? What should I monitor & what settings look for resolving this issue? Please, ask, what additional information should I provide.

Hoping for good advice & thanks in advance!

UPDATE:

ifconfig en1 results

for state, when ping fails

DenisMBP:CrowdedIsland denis$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 60:33:4b:12:38:60 
    inet6 fe80::6233:4bff:fe12:3860%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
    media: autoselect
    status: active

for state, when pings are ok

DenisMBP:CrowdedIsland denis$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 60:33:4b:12:38:60 
    inet6 fe80::6233:4bff:fe12:3860%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
    media: autoselect
    status: active

UPDATE 2: I've added a cut from Console.app log, displaying the moment of Macbook wakeup, working connection, broken connection. You can get it here

UPDATE 3: I've made log of netstat & ifconfig calls for all of three states. You can found it here

UPDATE 4: I've uninstalled Cisco AnynetConnect VPN Client and issue is still reproducible. Here's log for netstat & ifconfig log file. And here's log from Console.app (see netstat log for finding time points, when network was working and was not) log file

share|improve this question
    
What is the output of ifconfig en1 when the connection is working at home? What is the output of ifconfig en1 when it is not working? –  Miles Erickson Apr 9 '12 at 1:40
    
will report back from home –  Denis Apr 9 '12 at 10:58
1  
"wired problem" <-- Is that a problem with wires or spelling? –  Chris S Apr 9 '12 at 14:36
    
that was spelling, sorry –  Denis Apr 9 '12 at 15:47
    
@Miles, I've updated question with ifconfig en1 result –  Denis Apr 9 '12 at 18:48
add comment

migrated from serverfault.com Apr 9 '12 at 14:41

This question came from our site for professional system and network administrators.

8 Answers

up vote 1 down vote accepted
+100

Update: It wasn't the VPN client causing this, but after lengthy troubleshooting (see comments) it turned out to be Skype, possibly due to UPnP related bugs.


Try disabling your Cisco AnyConnect(?) VPN client (if you're not sure how, open Activity Monitor, find a process named acvpnagent and quit it).

From your description, it may well be the case that the VPN client is either failing to establish a tunnel or taking a rather long to do so, either of which could cause the apparent loss of the default route you're describing (you can ping anything on your local network, but nothing past the router).

If disabling the above (and any other) VPN client doesn't resolve it, please add the results of:

  • ifconfig (not just ifconfig en1 - there's an interface utun0 appearing in your log)
  • netstat -rnfinet

... at each of these stages:

  • immediately after connecting to your Wifi (while the network seems to be up)
  • during the problem
  • and after recovery
share|improve this answer
    
I've updated question with link to the log with netstat & ifconfig results for all 3 states; the interesting thing about acvpnagent, that reports from it do appear in Console log, but when I run Activity Monitor displaying all processes - it's not there, so I can't find place where I can kill it from. Am I missing anything? –  Denis Apr 10 '12 at 20:12
1  
acvpnagent might be launched on demand by launchd. Each item that is started by launchd has a corresponding .plist file in one of these locations: /System/Library/LaunchAgents/, /System/Library/LaunchDaemons/, ~/Library/LaunchAgents/, /Library/LaunchAgents/, /Library/LaunchDaemons/. When you can't find it please post the output of $ ls -l {/System/Library/LaunchAgents/,/System/Library/LaunchDaemons/,~/Library/LaunchAg‌​ents/,/Library/LaunchAgents/,/Library/LaunchDaemons/} –  Pro Backup Apr 10 '12 at 20:26
    
Thanks for the logs. The utun0 seems unrelated (probably just a Find my Mac/Back to my Mac artifact), but the VPN client is still the likely perpetrator. So please try to disable it. launchctl list | grep -i cisco should give you the launchctl job name and help you locate the matching plist file (in one of the locations @ProBackup described above). Once you've got that, you can disable it with launchctl unload -w thatfile.plist (and resume with launchctl load -w thatfile.plist). –  Ingmar Hupp Apr 11 '12 at 2:14
1  
Ok, now we're getting somewhere. It's Wifi, so there's a whole bunch of things that could be going wrong here. If possible, see if it also occurs when you turn wireless off and connect to the router with an ethernet cable. If it doesn't happen on ethernet, poke around the Wifi settings (start by changing the password and then the channel, especially if it's set to "Auto"). –  Ingmar Hupp Apr 12 '12 at 20:40
1  
@IngmarHupp, I've successfully reproduced the issue, when Macbook was connected to the router via ethernet cable. But, I've by accidence find out the reason of time-outs. It's Skype launched. That's explains, why earlier my Wife's macbook failed to reproduce the issue and why I succeeded to do it yesterday (Skype was launched). When I quit Skype, timeouts go away in a few seconds. Do you have any ideas about where to go from here? –  Denis Apr 13 '12 at 18:01
show 13 more comments

I have seen something similar to this; I do not have a fix (wish I did).

The problem is that Lion speculatively brings up the interface immediately with its last known address (presumably based on the router or AP; it does store that information in one of the system plists), while querying the DHCP server to find out if that address is actually available. If the DHCP server returns DHCPNAK, the interface becomes unconfigured while it properly negotiates a new address, at which point the interface is brought back up.

Theoretically (although probably not in practice on a small home network) your computer could have the same address as another computer on the network during that initial speculative phase.

share|improve this answer
    
I'm confused about the fact, that connection works first for few minutes, than it's broken for 3-5minutes and than it works again. About computer with the same address - this is not the case, I have a reserved IP addresses lists, based on MAC addresses, setup on router –  Denis Apr 9 '12 at 11:00
    
I'm confused by your confusion. It comes up with the last known address for a few minutes (I don't know why this takes so long but I have seen it), releases that when the DHCP server tells it "no you may not use that address" (which is based on it not remembering addresses forever), comes back when it gets a new address from the DHCP server. "About computer with the same address", I did say theoretically; don't read too much into it, it's saying why Apple's choice to try to reuse the last known address immediately was a bad idea in general, not an explanation of your problem. –  geekosaur Apr 9 '12 at 11:08
2  
Under this scenario, if @Denis comes home from work with a "last known address" on the 10.10.2.0/24 network, how could that address possibly work to communicate on his 192.168.1.0/24 network? –  Miles Erickson Apr 9 '12 at 14:33
    
"last known address (presumably based on the router or AP". Meaning it remembers the last known address per network. But the DHCP server at home does not remember addresses for that long (at least the ones built into commodity routers don't; a standalone DHCP server often does retain lease records after expiration). –  geekosaur Apr 9 '12 at 14:39
1  
I'm not aware of one. BUT: you updated with ifconfig output, it shows up and a valid address even when not working, so it's not the problem I've been describing. –  geekosaur Apr 10 '12 at 17:24
show 1 more comment

Have you tried

lookupd -flushcache 

from your Terminal.app?

share|improve this answer
    
nope, will try it –  Denis Apr 9 '12 at 10:58
2  
It's sudo dscacheutil -flushcache in Leopard and later (lookupd was Tiger and earlier). –  geekosaur Apr 9 '12 at 11:09
2  
I really don't see what the DNS cache could possibly do to make ICMP pings fail... –  Chris S Apr 9 '12 at 14:40
    
sudo dscacheutil -flushcache didn't help –  Denis Apr 9 '12 at 18:44
add comment

Do you have any other nodes on your home network? You might have an IP address conflict, which would cause traffic from your router to be diverted to a "rogue" host rather than to your MacBook Pro.

share|improve this answer
    
what do you mean by nodes? if you're talking about other computers - that's not the case. I have reserved IP list set up on the router, so IP address for my laptop is reserved and not used by anything else –  Denis Apr 9 '12 at 11:10
add comment

Have you tried disabling ipv6? (system preferences > networking > airport > advanced)

Another try (when using encryption like WPA on your home WiFi) is to repair keychain. Start keychain.app and press: Alt + Cmd + A.

Other times it helps to delete the "known wifi" network and re-enter it's password on next connect.

Is there a "Firewire" device listed in your list of Network devices (like Ethernet, Airport, etc.), when "Firewire" is listed and not used as networking connection, try to remove "Firewire" from the list.

Does this issue also occur when using the wired ethernet connection?

What does console.app show around the moment the connection changes from working into stopping at the local router?

share|improve this answer
    
Thanks for many options, I'll try them all one by one. For now, I've updated questions with link to a log cut from Console.app. Hope, that's helpful. Yep, I have Firewire device listed and will remove it. And no, I don't have such issue, when using a wired ethernet connection. –  Denis Apr 9 '12 at 22:45
    
Now reading that there is VPN client software installed, I would start with the suggestions from Ingmar Hupp. –  Pro Backup Apr 10 '12 at 8:09
add comment

I didn't see this, but it helped me when my Macbook Air wouldn't keep the wifi connection.

Intel-based Macs: Resetting the System Management Controller (SMC)

http://support.apple.com/kb/HT3964

This tech article resets some hardware. It takes 2 minutes and might work.

share|improve this answer
add comment

Is it correct that you are using the wired and wireless connections at the same time?

MacAuthEvent en1   Auth result for: 50:67:f0:85:fa:f4  MAC AUTH succeeded
kernel  wlEvent: en1 en1 Link UP
kernel  AirPort: Link Up on en1
kernel  en1: BSSID changed to 50:67:f0:85:fa:f4

This "multihoming" setup can more often cause issues in comparison to having a single link.

I would suggest using only 1 connection at a time. Either unplug the ethernet cable or disable wireless.

share|improve this answer
add comment

Skype version 5.3.0.1074 has got a preference (tab: Advanced) to use Skype to connect to WiFi-hotspots.

When that 'use Skype to connect to WiFi-hotspots' setting is enabled, please try to disable it.

Does that differ? Otherwise, could we rule out that Skype is the cause? Try connecting with and without Skype being started. Does that change anything?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.