4

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

Improve this question
5
  • 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
    Commented Apr 9, 2012 at 1:40
  • will report back from home
    – Denis
    Commented Apr 9, 2012 at 10:58
  • 1
    "wired problem" <-- Is that a problem with wires or spelling?
    – Chris S
    Commented Apr 9, 2012 at 14:36
  • that was spelling, sorry
    – Denis
    Commented Apr 9, 2012 at 15:47
  • @Miles, I've updated question with ifconfig en1 result
    – Denis
    Commented Apr 9, 2012 at 18:48

8 Answers 8

Reset to default
1
+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
Improve this answer
17
  • 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
    Commented Apr 10, 2012 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/LaunchAgents/,/Library/LaunchAgents/,/Library/LaunchDaemons/}
    – Pro Backup
    Commented Apr 10, 2012 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
    Commented Apr 11, 2012 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
    Commented Apr 12, 2012 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
    Commented Apr 13, 2012 at 18:01
2

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.

Improve this answer
6
  • 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
    Commented Apr 9, 2012 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
    Commented Apr 9, 2012 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
    Commented Apr 9, 2012 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
    Commented Apr 9, 2012 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
    Commented Apr 10, 2012 at 17:24
0

Have you tried 

lookupd -flushcache

from your Terminal.app?

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

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.

Improve this answer
1
  • 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
    Commented Apr 9, 2012 at 11:10
0

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?

Improve this answer
2
  • 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
    Commented Apr 9, 2012 at 22:45
  • Now reading that there is VPN client software installed, I would start with the suggestions from Ingmar Hupp.
    – Pro Backup
    Commented Apr 10, 2012 at 8:09
0

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.

Improve this answer
0

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.

Improve this answer
0

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?

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .