Azure CLI VHD upload failing at 0.5 % - azure
so, I have been trying for hours now to upload a VHD to Azure.
I downloaded a VHD by exporting on one Azure tenant on another domain, now I'm trying to upload it on another Azure account to attach it to a VM.
Steps (based on this article):
Exported VHD on tenant 1 (T1)
Logged into Azure CLI on PC with tenant 2 (T2)
Created a disk through Azure CLI T2 with upload bytes parameter set (30GB - 32213303808 bytes)
Granted access to disk on T2
Started upload with AzCopy.exe copy "D:\Downloads\disk.vhd "https://[sasurl]" --blob-type PageBlob
As soon as the upload starts, it gets stuck on 0.5 %, after about 55 minutes it just spits out that the upload has failed.
Log file:
2021/02/12 20:08:27 0.5 %, 0 Done, 0 Failed, 1 Pending, 0 Skipped, 1 Total, 2-sec Throughput (Mb/s): 14.1551
2021/02/12 20:08:28 INFO: [P#0-T#0] Page blob throughput tuner: Target Mbps 4048
2021/02/12 20:08:29 INFO: [P#0-T#0] Page blob throughput tuner: Target Mbps 4054
2021/02/12 20:08:29 PERF: primary performance constraint is Unknown. States: X: 0, O: 0, M: 0, L: 0, R: 1, D: 0, W: 480, F: 0, B: 96, E: 0, T: 577, GRs: 96
2021/02/12 20:08:29 0.5 %, 0 Done, 0 Failed, 1 Pending, 0 Skipped, 1 Total, 2-sec Throughput (Mb/s): 11.1397
2021/02/12 20:08:30 INFO: [P#0-T#0] Page blob throughput tuner: Target Mbps 4060
2021/02/12 20:08:31 INFO: [P#0-T#0] Page blob throughput tuner: Target Mbps 4066
2021/02/12 20:08:31 ==> REQUEST/RESPONSE (Try=1/11.1957784s[SLOW >3s], OpTime=11.1957784s) -- REQUEST ERROR
PUT [redacted SAS url]
Content-Length: [4194304]
User-Agent: [AzCopy/10.8.0 Azure-Storage/0.10 (go1.13; Windows_NT)]
X-Ms-Client-Request-Id: [redacted]
X-Ms-Page-Write: [update]
X-Ms-Range: [bytes=398458880-402653183]
X-Ms-Version: [2019-12-12]
--------------------------------------------------------------------------------
ERROR:
-> github.com/Azure/azure-pipeline-go/pipeline.NewError, /home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/error.go:157
HTTP request failed
Put [redacted SAS url]: net/http: TLS handshake timeout
goroutine 214 [running]:
github.com/Azure/azure-storage-azcopy/ste.stack(0xc092e4ea20, 0xc04e193300, 0x0)
/home/vsts/work/1/s/ste/xferLogPolicy.go:232 +0xa4
github.com/Azure/azure-storage-azcopy/ste.NewRequestLogPolicyFactory.func1.1(0xdb74a0, 0xc000653560, 0xc001189300, 0x10, 0x3, 0x0, 0xc00168fa20)
/home/vsts/work/1/s/ste/xferLogPolicy.go:146 +0x7ac
github.com/Azure/azure-pipeline-go/pipeline.PolicyFunc.Do(0xc00175c640, 0xdb74a0, 0xc000653560, 0xc001189300, 0xc00168faf0, 0x2030004, 0xa, 0x2030005)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:43 +0x4b
github.com/Azure/azure-storage-azcopy/ste.NewVersionPolicyFactory.func1.1(0xdb74a0, 0xc000653560, 0xc001189300, 0xc0010cac40, 0xc0010cabf0, 0x40c7c0, 0xc00175c6e0)
/home/vsts/work/1/s/ste/mgr-JobPartMgr.go:78 +0x1b8
github.com/Azure/azure-pipeline-go/pipeline.PolicyFunc.Do(0xc00126c2e0, 0xdb74a0, 0xc000653560, 0xc001189300, 0x10, 0x10, 0xb939e0, 0xa)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:43 +0x4b
github.com/Azure/azure-storage-blob-go/azblob.responderPolicy.Do(0xda72e0, 0xc00126c2e0, 0xc0011b0820, 0xdb74a0, 0xc000653560, 0xc001189300, 0x0, 0x12e2360, 0xc0010cac50, 0x4310d8)
/home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go#v0.10.1-0.20201022074806-8d8fc11be726/azblob/zz_generated_responder_policy.go:33 +0x5a
github.com/Azure/azure-storage-blob-go/azblob.anonymousCredentialPolicy.Do(...)
/home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go#v0.10.1-0.20201022074806-8d8fc11be726/azblob/zc_credential_anonymous.go:54
github.com/Azure/azure-storage-azcopy/ste.(*retryNotificationPolicy).Do(0xc001234560, 0xdb74a0, 0xc000653560, 0xc001189300, 0x0, 0x0, 0x0, 0xc0010cad70)
/home/vsts/work/1/s/ste/xferRetryNotificationPolicy.go:59 +0x62
github.com/Azure/azure-pipeline-go/pipeline.PolicyFunc.Do(0xc0012345c0, 0xdb74a0, 0xc000653560, 0xc001189300, 0xc000653560, 0xc001234dd0, 0xc000000001, 0x0)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:43 +0x4b
github.com/Azure/azure-storage-azcopy/ste.NewBlobXferRetryPolicyFactory.func1.1(0xdb74e0, 0xc0001c7440, 0xc001189200, 0x10, 0xb411a0, 0x64492d747301, 0xc00168f340)
/home/vsts/work/1/s/ste/xferRetrypolicy.go:384 +0x70f
github.com/Azure/azure-pipeline-go/pipeline.PolicyFunc.Do(0xc00175c690, 0xdb74e0, 0xc0001c7440, 0xc001189200, 0xc00168f440, 0x30, 0x28, 0x8)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:43 +0x4b
github.com/Azure/azure-storage-blob-go/azblob.NewUniqueRequestIDPolicyFactory.func1.1(0xdb74e0, 0xc0001c7440, 0xc001189200, 0x10, 0xb411a0, 0x40d001, 0xc00168f340)
/home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go#v0.10.1-0.20201022074806-8d8fc11be726/azblob/zc_policy_unique_request_id.go:19 +0xb5
github.com/Azure/azure-pipeline-go/pipeline.PolicyFunc.Do(0xc00126c320, 0xdb74e0, 0xc0001c7440, 0xc001189200, 0xc00168f428, 0x35, 0xc0007d03c0, 0xc0010cb138)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:43 +0x4b
github.com/Azure/azure-storage-blob-go/azblob.NewTelemetryPolicyFactory.func1.1(0xdb74e0, 0xc0001c7440, 0xc001189200, 0x1, 0x0, 0x1, 0xc0017100a0)
/home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go#v0.10.1-0.20201022074806-8d8fc11be726/azblob/zc_policy_telemetry.go:34 +0x164
github.com/Azure/azure-pipeline-go/pipeline.PolicyFunc.Do(0xc0001c74d0, 0xdb74e0, 0xc0001c7440, 0xc001189200, 0xc0001c74d0, 0xc001189200, 0xc0010cb208, 0x40d06f)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:43 +0x4b
github.com/Azure/azure-pipeline-go/pipeline.(*pipeline).Do(0xc0007ce040, 0xdb74e0, 0xc0001c7440, 0xda73e0, 0xc0011b0820, 0xc001189200, 0x30, 0xc000000638, 0x12, 0x0)
/home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/core.go:129 +0x88
github.com/Azure/azure-storage-blob-go/azblob.pageBlobClient.UploadPages(0xc000000600, 0x5, 0x0, 0x0, 0x0, 0xc000000608, 0x30, 0xc000000638, 0x12, 0x0, ...)
/home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go#v0.10.1-0.20201022074806-8d8fc11be726/azblob/zz_generated_page_blob.go:805 +0x5b0
github.com/Azure/azure-storage-blob-go/azblob.PageBlobURL.UploadPages(0xc000000600, 0x5, 0x0, 0x0, 0x0, 0xc000000608, 0x30, 0xc000000638, 0x12, 0x0, ...)
/home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go#v0.10.1-0.20201022074806-8d8fc11be726/azblob/url_page_blob.go:87 +0x336
github.com/Azure/azure-storage-azcopy/ste.(*pageBlobUploader).GenerateUploadFunc.func1()
/home/vsts/work/1/s/ste/sender-pageBlobFromLocal.go:96 +0x8f3
github.com/Azure/azure-storage-azcopy/ste.createChunkFunc.func1(0x3c)
/home/vsts/work/1/s/ste/sender.go:179 +0x1ae
github.com/Azure/azure-storage-azcopy/ste.(*jobsAdmin).chunkProcessor(0xc000054000, 0x3c)
/home/vsts/work/1/s/ste/JobsAdmin.go:433 +0xe6
created by github.com/Azure/azure-storage-azcopy/ste.(*jobsAdmin).poolSizer
/home/vsts/work/1/s/ste/JobsAdmin.go:362 +0x682
2021/02/12 20:08:31 ==> REQUEST/RESPONSE (Try=1/11.1957784s[SLOW >3s], OpTime=11.1957784s) -- REQUEST ERROR
PUT [redacted SAS url]
Content-Length: [4194304]
User-Agent: [AzCopy/10.8.0 Azure-Storage/0.10 (go1.13; Windows_NT)]
X-Ms-Client-Request-Id: [redacted]
X-Ms-Page-Write: [update]
X-Ms-Range: [bytes=394264576-398458879]
X-Ms-Version: [2019-12-12]
--------------------------------------------------------------------------------
ERROR:
-> github.com/Azure/azure-pipeline-go/pipeline.NewError, /home/vsts/go/pkg/mod/github.com/!azure/azure-pipeline-go#v0.2.3/pipeline/error.go:157
HTTP request failed
And it just goes on like this for thousands of lines, at the end of the log there's this:
2021/02/12 19:56:56 INFO: [P#0-T#0] Page blob throughput tuner: Target Mbps 98705
2021/02/12 19:56:57 ==> REQUEST/RESPONSE (Try=14/2m0.3843703s[SLOW >3s], OpTime=38m15.4275233s) -- RESPONSE STATUS CODE ERROR
PUT https://md-impexp-vpwbn0cr4mj2.z18.blob.storage.azure.net/3ntgq1cq2rsj/abcd?comp=page&si=a01312d5-4da8-41d1-acc6-7466f702a447&sig=-REDACTED-&sr=b&sv=2018-03-28&timeout=901
Content-Length: [4194304]
User-Agent: [AzCopy/10.8.0 Azure-Storage/0.10 (go1.13; Windows_NT)]
X-Ms-Client-Request-Id: [36e705e8-9f5d-45a1-4574-7e994292da82]
X-Ms-Page-Write: [update]
X-Ms-Range: [bytes=398458880-402653183]
X-Ms-Version: [2019-12-12]
--------------------------------------------------------------------------------
RESPONSE Status: 500 Operation could not be completed within the specified time.
Content-Length: [246]
Content-Type: [application/xml]
Date: [Fri, 12 Feb 2021 19:56:56 GMT]
Server: [Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0]
X-Ms-Client-Request-Id: [36e705e8-9f5d-45a1-4574-7e994292da82]
X-Ms-Error-Code: [OperationTimedOut]
X-Ms-Request-Id: [f91ed41a-c01e-0008-4f78-011552000000]
X-Ms-Version: [2019-12-12]
Response Details: <?xml version="1.0" encoding="utf-8"?> <Error><Code>OperationTimedOut</Code><Message>Operation could not be completed within the specified time. </Message>
So what am I doing wrong? Tried both CLI and PowerShell.
I stumbled upon a good solution myself:
Since I was uploading a VHD of a disk already on Azure, instead of using the downloaded VHD I used the original VHD export URL as the source of the disk.
Related
Bluetooth LE connection drops immediately after connecting
I'm building an application (runs on central device) in which I can scan, connect, pair, & reconnect in LE to a specific target device (peripheral device). My application is able to scan for Bluetooth LE devices and I have set the connection function. When I run my application, it scans until it find the target device and then it starts the connecting process. On the target side (peripheral), I can see my central device was able to connect to it but the connection is dropped immediately. I think this is because it didn't find any compatible service (I think that just means there was no recognizable GATT attirubute/application/service?). I tried to connect to the same peripheral device through bluetoothctl and the connection drops immediately which makes me think something is missing from my target device (peripheral). I'm wondering if I need to implement anything else before I try to connect to my peripheral device? Is it disconnecting because it didn't find any recognizable service on my central? This is what I have from btmon on the peripheral side with another connection which was successful: Connection request Read remote supported features (understood remote as target device) Turn off scan Read remote extended features Remote name request Found this in the BTMON. "Attribute not found" possibly the issue? > ACL Data RX: Handle 128 flags 0x02 dlen 11 #23 [hci0] 16.564046 ATT: Read By Group Type Request (0x10) len 6 Handle range: 0x0001-0xffff Attribute group type: Primary Service (0x2800) < ACL Data TX: Handle 128 flags 0x00 dlen 24 #24 [hci0] 16.564325 ATT: Read By Group Type Response (0x11) len 19 Attribute data length: 6 Attribute group list: 3 entries Handle range: 0x0001-0x0005 UUID: Generic Access Profile (0x1800) Handle range: 0x0006-0x000f UUID: Generic Attribute Profile (0x1801) Handle range: 0x0010-0x0012 UUID: Device Information (0x180a) < ACL Data TX: Handle 128 flags 0x00 dlen 11 #25 [hci0] 16.564349 ATT: Read By Type Request (0x08) len 6 Handle range: 0x0001-0xffff Attribute type: Unknown (0x2b3a) > HCI Event: Number of Completed Packets (0x13) plen 5 #26 [hci0] 16.580038 Num handles: 1 Handle: 128 Count: 1 > ACL Data RX: Handle 128 flags 0x02 dlen 11 #27 [hci0] 16.596035 ATT: Read By Group Type Request (0x10) len 6 Handle range: 0x0013-0xffff Attribute group type: Primary Service (0x2800) > HCI Event: Number of Completed Packets (0x13) plen 5 #28 [hci0] 16.596041 Num handles: 1 Handle: 128 Count: 1 < ACL Data TX: Handle 128 flags 0x00 dlen 9 #29 [hci0] 16.596267 ATT: Error Response (0x01) len 4 Read By Group Type Request (0x10) Handle: 0x0013 Error: Attribute Not Found (0x0a) > ACL Data RX: Handle 128 flags 0x02 dlen 9 #30 [hci0] 16.620082 ATT: Error Response (0x01) len 4 Read By Type Request (0x08) Handle: 0x0001 Error: Attribute Not Found (0x0a)
golang spanner test library crashes after a while
Spanner GO library crashes after few mins perhaps after this query (although this has been successful earlier) Version cloud.google.com/go/spanner v1.11.0 2021/02/01 00:45:32.564971 spannertest.inmem: Querying: SELECT * FROM tenant_config WHERE commit_time > "2021-02-01T00:44:32Z" Crashinfo panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0xae3bcb] goroutine 214 [running]: cloud.google.com/go/spanner/spannertest.(*server).ExecuteSql(0xc00009b4a0, 0xf74c00, 0xc0001e8270, 0xc0003e8c60, 0xc00009b4a0, 0xc0001e8270, 0xc0008a4ba0) /Users/mpathak/Development/gopkgs/pkg/mod/cloud.google.com/go/spanner#v1.11.0/spannertest/inmem.go:491 +0x3b google.golang.org/genproto/googleapis/spanner/v1._Spanner_ExecuteSql_Handler(0xd0f8a0, 0xc00009b4a0, 0xf74c00, 0xc0001e8270, 0xc00088b020, 0x0, 0xf74c00, 0xc0001e8270, 0xc0004f4060, 0x14) /Users/mpathak/Development/gopkgs/pkg/mod/google.golang.org/genproto#v0.0.0-20201019141844-1ed22bb0c154/googleapis/spanner/v1/spanner.pb.go:3581 +0x217 google.golang.org/grpc.(*Server).processUnaryRPC(0xc0003a1500, 0xf7e800, 0xc00018a900, 0xc00089a000, 0xc0001ac2a0, 0x152c7d8, 0x0, 0x0, 0x0) /Users/mpathak/Development/gopkgs/pkg/mod/google.golang.org/grpc#v1.32.0/server.go:1194 +0x50a google.golang.org/grpc.(*Server).handleStream(0xc0003a1500, 0xf7e800, 0xc00018a900, 0xc00089a000, 0x0) /Users/mpathak/Development/gopkgs/pkg/mod/google.golang.org/grpc#v1.32.0/server.go:1517 +0xcfd google.golang.org/grpc.(*Server).serveStreams.func1.2(0xc000606140, 0xc0003a1500, 0xf7e800, 0xc00018a900, 0xc00089a000) /Users/mpathak/Development/gopkgs/pkg/mod/google.golang.org/grpc#v1.32.0/server.go:859 +0xa1 created by google.golang.org/grpc.(*Server).serveStreams.func1 /Users/mpathak/Development/gopkgs/pkg/mod/google.golang.org/grpc#v1.32.0/server.go:857 +0x204
This seems to be caused by a bug in the ExecuteSql method implementation of spannertest. The session pool of the Spanner client will execute a ping statement every 50 minutes to keep sessions alive on the backend. These SELECT 1 statements are executed without a transaction, which means that the backend should default to a single-use read-only transaction. The inmem server of spannertest assumes that the client will always specify a TransactionSelector: https://github.com/googleapis/google-cloud-go/blob/c7ecf0f3f454606b124e52d20af2545b2c68646f/spanner/spannertest/inmem.go#L491 I've opened an issue for it here: https://github.com/googleapis/google-cloud-go/issues/3639
Changing BGP packet size less than 19 and greater than 4096
I am working with bgp implementation on ubuntu. I want to do some malformation in bgp packets , bgp restrict us on size between 19 to 4096 , however for testing purpose I am changing the size less than 19 and greater than 4096. After this when I send this packet from one to second, on established bgp session between two speakers, second one should send notification message containing error: bad message length. But I am not getting that rather it is showing malformed packet in wireshark and also I am not able to open that packet in wireshark. Can anybody help me in this malformation of packet and to get notification error. Just for information: I have tried every packets like open, update and keepalive. malformed open packet:
UPDATED ANSWER BELOW
The BGP packet shown in Wireshark has marker field (16 x ff) followed by length 16 (00 10).
Thus, this is indeed the scenario that you wanted to test: your tester BGP speaker sent a BGP packet with an incorrect length, and the remote BGP speaker under test should respond by sending back a NOTIFICATION packet with error code "Message Header Error" and error sub-code "Bad Message Length".
Wireshark is showing the malformed BGP packet that was sent from the tester BGP speaker to the BGP speaker under test. Wireshark is correct to complain that it is a malformed BGP packet: it is malformed because the length is invalid. Evidently, Wireshark is not very specific about what it doesn't like about the packet.
You should look in the TCP stream in the reverse direction (source 10.0.0.2 destination 10.0.0.1) and look for the BGP NOTIFICATION packet that the BGP speaker under test sent back.
UPDATED ANSWER STARTS HERE
Based on the error message ([Error] bgp_read_packet error: Connection reset), it looks like you are testing Free Range Routing, or one of its predecessors Quagga or Zebra.
I reproduced the scenario you are testing.
I am running a Free Range Routing (FRR) BGP speaker with the following configuration:
Current configuration:
!
frr version 7.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-31-121
log file /var/log/frr/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp neighbor-events
!
router bgp 100
neighbor X.X.X.X remote-as 200
!
line vty
!
end
I use the following Python test program to send a message with a "too short" header:
#!/usr/bin/env python3
import socket
BGP_IP = 'Y.Y.Y.Y'
SHORT_MSG = (b'\xff\xff\xff\xff\xff\xff\xff\xff' # First 8 bytes of marker
b'\xff\xff\xff\xff\xff\xff\xff\xff' # Last 8 bytes of marker
b'\x00\x10' # Length 16
b'\x01') # Open
def main():
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Socket created")
sock.connect((BGP_IP, 179))
print("Socket connected")
sock.send(SHORT_MSG)
print("Short message sent")
while True:
data = sock.recv(1)
if data == b'':
print("Connection closed or reset")
break
print("Received:", data)
if __name__ == "__main__":
main()
Replace X.X.X.X with the IP address of the tester, and replace Y.Y.Y.Y with the IP address of the BGP speaker under test.
In this scenario, the BGP speaker under test does indeed send the correct NOTIFICATION message.
Here is what the FRR log reports:
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] Timer (connect timer expire)
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] ConnectRetry_timer_expired (Active->Connect), fd -1
2019/02/09 21:49:05 BGP: 172.31.17.121 [Event] Connect start to 172.31.17.121 fd 26
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] Non blocking connect waiting result, fd 26
2019/02/09 21:49:05 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:05 BGP: 172.31.17.121 went from Active to Connect
2019/02/09 21:49:05 BGP: 172.31.17.121 [Event] Connect failed 111(Connection refused)
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] TCP_connection_open_failed (Connect->Active), fd 26
2019/02/09 21:49:05 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:05 BGP: 172.31.17.121 went from Connect to Active
2019/02/09 21:49:08 BGP: [Event] BGP connection from host 172.31.17.121 fd 26
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from Idle to Active
2019/02/09 21:49:08 BGP: 172.31.17.121 [FSM] TCP_connection_open (Active->OpenSent), fd 26
2019/02/09 21:49:08 BGP: 172.31.17.121 passive open
2019/02/09 21:49:08 BGP: 172.31.17.121 Sending hostname cap with hn = ip-172-31-31-121, dn = (null)
2019/02/09 21:49:08 BGP: 172.31.17.121 sending OPEN, version 4, my as 100, holdtime 180, id 172.31.31.121
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from Active to OpenSent
2019/02/09 21:49:08 BGP: 172.31.17.121 bad message length - 16 for OPEN
2019/02/09 21:49:08 BGP: %NOTIFICATION: sent to neighbor 172.31.17.121 1/2 (Message Header Error/Bad Message Length) 2 bytes 00 10
2019/02/09 21:49:08 BGP: 172.31.17.121 [FSM] BGP_Stop (OpenSent->Idle), fd 26
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from OpenSent to Deleted
Note the "Bad Message Length" message.
Here is what the test program reports:
Socket created
Socket connected
Short message sent
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\x00'
Received: b'\x17'
Received: b'\x03'
Received: b'\x01'
Received: b'\x02'
Received: b'\x00'
Received: b'\x10'
Connection closed or reset
Note that this is the correct Bad Message Length NOTIFICATION.
Here is the Wireshark decode of the bad message:
Here is the Wireshark decode of the NOTIFICATION:
If the test program terminates without attempting to read the NOTIFICATION message, then the BGP speaker under test will not be able to send the NOTIFICATION message on the wire. This is because it will receive a TCP RST message before it is able to send the NOTIFICATION. This is most likely why you did not see the NOTIFICATION on the wire.
Indeed, I was able to reproduce this hypothesis by modifying the test program as follows:
#!/usr/bin/env python3
import socket
import struct
BGP_IP = '172.31.31.121'
SHORT_MSG = (b'\xff\xff\xff\xff\xff\xff\xff\xff' # First 8 bytes of marker
b'\xff\xff\xff\xff\xff\xff\xff\xff' # Last 8 bytes of marker
b'\x00\x10' # Length 16
b'\x01') # Open
def main():
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Socket created")
sock.connect((BGP_IP, 179))
print("Socket connected")
sock.send(SHORT_MSG)
# Trick TCP into sending a RST when the socket is closed
on_off = 1
linger = 0
sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', on_off, linger))
print("Socket linger time set to 0")
# Close the socket
sock.close()
print("Socket closed")
# Terminate without reading the response NOTIFICATION
if __name__ == "__main__":
main()
Using this test program, the NOTIFICATION is missing from the Wireshark trace (exactly as you reported it):
Note that I had to jump through some hoops (specifically setting the linger time to zero) to force the test program to send a RST as opposed to a FIN ACK. (See Sending a reset in TCP/IP Socket connection for details.)
If the test program sends a FIN ACK instead of a RST (which happens if you gracefully close the socket, or even terminate normally without closing the socket), then the BGP speaker under test will be able to send the NOTIFICATION after receiving the FIN ACK but before sending its own FIN ACK.
Panic in Golang http.Client with high concurrent excecutions
I am creating a system which is a http server in golang that will perform several request to another API based in every request that come to it. e.g curl localhost:8080/users?ids=1,2,3,4 will perform several concurrent gets to: api.com/user/1 api.com/user/2 api.com/user/3 api.com/user/4 I am having a problem, the http.Client is getting my a panic, when it has a heavy concurrent requests (if I hit localhost:8080/users?ids=1,2,3,4.....40 with AB with 4 concurrent, or hitting refresh in my browser) The proglem appears to be with the sentence (line 159) resp, _ := client.Do(req) My code is here (Not so large... 180 lines): http://play.golang.org/p/olibNz2n1Z The panic error is this one: goroutine 5 [select]: net/http.(*persistConn).roundTrip(0xc210058f80, 0xc21000a720, 0xc210058f80, 0x0, 0x0) /usr/local/go/src/pkg/net/http/transport.go:879 +0x6d6 net/http.(*Transport).RoundTrip(0xc210058280, 0xc21005b1a0, 0x1, 0x0, 0x0) /usr/local/go/src/pkg/net/http/transport.go:187 +0x391 net/http.send(0xc21005b1a0, 0x590290, 0xc210058280, 0x0, 0x0, ...) /usr/local/go/src/pkg/net/http/client.go:168 +0x37f net/http.(*Client).send(0xc21001e960, 0xc21005b1a0, 0x28, 0xc21001ec30, 0xc21005f570) /usr/local/go/src/pkg/net/http/client.go:100 +0xd9 net/http.(*Client).doFollowingRedirects(0xc21001e960, 0xc21005b1a0, 0x2ab298, 0x0, 0x0, ...) /usr/local/go/src/pkg/net/http/client.go:294 +0x671 net/http.(*Client).Do(0xc21001e960, 0xc21005b1a0, 0xa, 0x0, 0x0) /usr/local/go/src/pkg/net/http/client.go:129 +0x8f main.buscarRecurso(0xc21000a650, 0xb, 0xc2100526c0) /Users/fscasserra/Documents/workspace/Luna/multiget-api/multiget.go:159 +0x131 created by main.obtenerRecursos /Users/fscasserra/Documents/workspace/Luna/multiget-api/multiget.go:106 +0x197 Can anyone help me? Best regards, Fer
I will put money on the panic coming from calling Close() on a nil resp.Body. Always check your errors! In general, if a function returns a value and an error, the response value may not be usable in the case of a non-nil error. Any exceptions to this should be well documented.
How to send mail to #m.facebook.com with mail command line
I want to update my facebook status by sending an email to xxx#m.facebook.com. It works with Thunderbird or webmail. But with mail command of Linux, it does not send emails to xxx#m.facebook.com but works with emails to #gmail.com and others. How can I send emails to xxx#m.facebook.com by using the mail or sendmail command? Below is the log from mail.log: Aug 4 04:02:34 s17773461 sm-mta[28533]: s7492YBE028533: from=<root#xxxx>, size=397, class=0, nrcpts=1, msgid=<201408040902.s7492YQJ028532#xxxx>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1] Aug 4 04:02:34 s17773461 sendmail[28532]: s7492YQJ028532: to=xxx#m.facebook.com, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30053, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (s7492YBE028533 Message accepted for delivery) Aug 4 04:02:34 s17773461 sm-mta[28535]: s7492YBE028533: to=<xxx#star.c10r.facebook.com>, ctladdr=<root#xxxx> (0/0), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=120397, relay=msgin.t.facebook.com. [173.252.113.23], dsn=5.0.0, stat=Service unavailable Aug 4 04:02:34 s17773461 sm-mta[28535]: s7492YBE028533: s7492YBE028535: DSN: Service unavailable