blocking an IP address in LA?

[Max Waterman]

I'm trying to use git from a specific IP address in Los Angeles, CA, USA, but both git push and fetch both just hang.

If I use an IP address in Beijing, China, then it works ok.

Does anyone have any ideas what might be causing the failure from the IP address in LA?

[Max Waterman · Accepted solution]

Hrm. I had attempted similar to your first suggestion, but used the '-c' option, but 'git' didn't understand...just setting those as environment variables worked though...

...and it worked.

...so I tried it again without them, and it again worked.

I tried again after a few minutes, and it failed again. I wonder if those environment settings are cached at all.

I've not tried a different protocol, no...I use a url of the form username@bitbucket.org:repo.git

Perhaps it is some intermittent network error?

[Daniil Penkin]

These environment variables don't affect how git establishes connection, they're just for verbose logging (here's some more info on them). So I believe this is some sort of network error.

Without more details it's very hard to guess about what might cause such error. If you ever catch it with the verbose logging on, such logs might shed some light on the cause. Your URL is an SSH one, so GIT_TRACE=1 and SSH_COMMAND="ssh -vvv" are enough to give an insight into low-level connection attempt.

Hope this helps.

Cheers,
Daniil

[Max Waterman]

Yes, that helps, thanks. I know what to do when I next see the problem.

It hasn't happened since, though it has happened before and my impression is that it is consistent when it happens.

On this most recent occasion, I actually reset my connection, and that seemed to prevent it reoccurring (so often, at least).

I'm thinking it's a networking issue too, at this point...fwiw.

[Max Waterman]

OK, it's happened again, and this is what I get:

$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 SSH_COMMAND="ssh -vvv" git push origin master --tags
21:36:34.379478 git.c:418 trace: built-in: git push origin master --tags
21:36:34.383801 run-command.c:643 trace: run_command: unset GIT_PREFIX; ssh davidmaxwaterman@bitbucket.org 'git-receive-pack '\''antenna_dev/polymer_tourbuilder_client.git'\'''

and it just sits there.

What do you think?

[Max Waterman]

ah, it just finished, at 09:54:13....perhaps it's just slow - I think you'll agree that is quite slow, right?

[Daniil Penkin]

Yeah, that indeed took quite a long time.

However, on our side I see a successful connection at 13:54 UTC, which is when it finished for you. I also noted that the source IP is not LA but rather SG (which matches the time from your log above).

Let me check if I'm not missing anything.

[Max Waterman]

Yup, I am now using an IP address from Singapore. The symptoms seem quite similar...

I don't think there's much to be done. As Ace said, if I'm not back in 5 minutes, just wait longer.

[Daniil Penkin]

Ok, so I found a bit more information:

• connection established at 13:54:07
• SSH operation finished successfully at 13:54:13
• connection closed (reason 11: disconnected by user) at the same time

I see no other connection attempts in the last hour, which includes the time when you triggered the operation (as it appears in your log).

So I believe it's some networking issue, that is the request doesn't get to our edge for some reason :(

[Max Waterman]

...and another:

$ GIT_TRACE=1 GIT_CURL_VERBOSE=1 SSH_COMMAND="ssh -vvv" git fetch
14:13:12.711383 git.c:418 trace: built-in: git fetch
14:13:12.711971 run-command.c:643 trace: run_command: unset GIT_PREFIX; ssh git@bitbucket.org 'git-upload-pack '\''/antenna_dev/player-fe.git'\'''
14:30:49.706147 run-command.c:643 trace: run_command: git rev-list --objects --stdin --not --all --quiet
14:30:49.815851 run-command.c:643 trace: run_command: git rev-list --objects --stdin --not --all --quiet
14:30:49.818372 git.c:418 trace: built-in: git rev-list --objects --stdin --not --all --quiet
14:30:50.204972 run-command.c:1577 run_processes_parallel: preparing to run up to 1 tasks
14:30:50.205216 run-command.c:1609 run_processes_parallel: done
14:30:50.205436 run-command.c:643 trace: run_command: git gc --auto
14:30:50.210119 git.c:418 trace: built-in: git gc --auto
02:30:50

[Daniil Penkin · Accepted solution]

Hello @Max Waterman,

I'm not aware of any geo-based firewall filtering rules in Bitbucket. If you give me some details on the user or repository you're trying to access, I can try to track down your requests.

Can you elaborate at which step do the request hang? Specifically:

• Have you tried running the command with verbose log? E.g. GIT_TRACE=1 GIT_CURL_VERBOSE=1 SSH_COMMAND="ssh -vvv" to cover both connection types?
• Have you tried using another protocol in the clone/push URL? E.g. switch to SSH if you tried HTTPS and vice versa?

Let me know what you find. 

Cheers,
Daniil