Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm trying to configure my Windows 7 PC to wake on lan (S4 and S5), but it just doesn't work. I have followed all the steps.
Changed my network adapter settings to wake on magic packet
Opened UDP port 7 on my windows firewall
Port forwarded my router on UDP port 7 to my PC
Configured BIOS (my motherboard - Intel DH67BL) to wake on LAN
I'm sending the magic packet through an android app (name: wake on lan). I used a sniffer utility on my PC to check if it was receiving the magic packet. Below is the packet details. I have a doubt here, the packet details show MAC address (as below). But, my adapter's MAC address is different. And I have set the correct MAC address while sending the magic packet. Is the app changing the MAC address before sending? Please help!
---------------------------Wake-On-LAN Magic Packet---------------------------
Time received:
09/15/12 12:13:34
UDP Header:
|-Source IP : 157.56.106.184
|-Destination IP : 192.168.1.2
|-Source Port : 3544
|-Destination Port : 52146
|-UDP Length : 117
|-UDP Checksum : 675
MAC Address:
FF FF 00 00 00 00
Raw Data (109 bytes):
00 01 00 00 8C 37 59 92 1E 68 49 48 00 00 00 34
4D 8A 27 66 D1 60 00 00 00 00 30 3A FF FE 80 00
00 00 00 00 00 80 00 F2 27 62 C7 95 47 FE 80 00
00 00 00 00 00 00 00 FF FF FF FF FF FE 86 00 64
9D 00 00 00 00 00 00 3A 98 00 00 07 D0 03 04 40
40 FF FF FF FF FF FF FF FF 00 00 00 00 20 01 00
00 9D 38 6A B8 FF 00 00 00 00 20 01 00
Thanks,
Sharath
3) Port forwarded my router on UDP port 7 to my PC
You need to forward UPD 7 and/or UDP 9 to LAN broadcast address, not to your PC's IP address.
The reason why is because when your PC is turned off, it doesn't have an IP address assigned, so the router does not have the binding with MAC address <=> IP adress in the ARP table, and can't forward the packet.
Reason: Because you don't Bind Your MAC to Your Local IP
Solution: Access to your router, use MAC Bing (or similar feature)
Note: if you use 2 or more router before your PC, you have to Mac binding and and Port forwarding on ALL router
Related
I have a self managed Kubernetes cluster consisting of one master node and 3 worker nodes. I use the Cluster Network Interface flannel within the cluster.
On all my machines I can see the following kind of kernel messages:
Apr 12 04:22:24 worker-7 kernel: [278523.379954] iptables[6260]: segfault at 88 ip 00007f9e69fefe47 sp 00007ffee4dff356 error 4 in libnftnl.so.11.3.0[7f9e69feb000+16000]
Apr 12 04:22:24 worker-7 kernel: [278523.380094] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 78 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 05:59:10 worker-7 kernel: [284329.182667] iptables[13978]: segfault at 88 ip 00007fb799fafe47 sp 00007fff22419b36 error 4 in libnftnl.so.11.3.0[7fb799fab000+16000]
Apr 12 05:59:10 worker-7 kernel: [284329.182774] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 08:29:25 worker-7 kernel: [293343.999073] iptables[16041]: segfault at 88 ip 00007fa40c7f7e47 sp 00007ffe04ba9886 error 4 in libnftnl.so.11.3.0[7fa40c7f3000+16000]
Apr 12 08:29:25 worker-7 kernel: [293343.999165] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
I narrowed it down that the messages originated in the kube-flannel-ds pods. I have log messages like this one:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t filter -C FORWARD -s 10.244.0.0/16 -j ACCEPT --wait]: exit status -1:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t nat -C POS TROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully --wait]: exit status -1:
Can someone explain what this kind of messages are indicating? Can this be a hardware problem? Does it make sense to switch form flannel to another kuberentes container network interface (CNI) - e.g. Calico?
As already mentioned in the comments debian buster uses nftables backed instead of iptables:
NOTE: iptables is being replaced by nftables starting with Debian Buster - reference here
Unfortunately the nftables are not compatible at this moment with kubernetes.
In Linux, nftables is available as a modern replacement for the kernel’s iptables subsystem. The iptables tooling can act as a compatibility layer, behaving like iptables but actually configuring nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated firewall rules and breaks kube-proxy. You could try to switch to legacy option like described here but I'm not sure about this solution as I don't have a way to test it with your Os. I solved similar case with debian with this here.
Alternative way would to switch to Calico which actually supports nftbacked with FELIX_IPTABLESBACKEND. This parameter controls which variant of iptables binary Felix uses. Set this to Auto for auto detection of the backend. If a specific backend is needed then use NFT for hosts using a netfilter backend or Legacy for others. [Default: Auto].
When installing calico with containerd please also have a look a this case.
I turned my raspberry pi to ibeacon transmitter, but my iPhone cannot detect my pibeacon signals for ranging, for example, it cannot say( push notification) whenever it's close( in the immediate distance) to pibeacon. However, my phone is working properly with other kinds of USB beacons such as Bluegiga and Radbeacon. Has anyone ever faced the same problem?
iOS devices will not detect iBeacons packets unless the ProximityUUID of the beacon packet is pre-configured into the iOS app that is searching for them. Based on the commands shown in the question, the ProximityUUID being configured with the Pi is 43F2ACD1-5522-4E0D-9E3F-4A828EA12C25
It may just be that the iOS app you are using to try to detect it as an iBeacon packet is not pre-configured to look for the above ProximityUUID.
Non-beacon BLE apps on iOS can see your Pi's advertisements, so the fact that non-beacon apps detect it can still mean this is the problem.
If you are successful in using a beacon app to detect a RadBeacon, it can probably detect the default RadBeacon Proximity UUID of 2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6. If your app can detect that, try configuring that into your Raspberry Pi start advertising command like this:
sudo hciconfig hci0 up sudo hciconfig hci0 leadv 3 sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 2F 23 44 54 CF 6D 4A 0F AD F2 F4 91 1B A9 FF A6 00 00 00 00 C8
How to advertise a eddystone UID using a raspberry pi device.Using python or hci.
I have published the URL but not understading the format of UID.
The following command will advertise 10-byte namespace identifier of 00010203040506070809, a 6-byte instance identifier of 010203040506, a zero meter Tx Power level of e7 (-25 dBm).
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 15 16 aa fe 00 e7 00 01 02 03 04 05 06 07 08 09 01 02 03 04 05 06
You actually start the advertising with:
hciconfig hci0 leadv 3
Note that if you are not running as root, you will need to precede the above commands with sudo
In terms of the format of UID, it simply contains the three fields described above. Google defines the layout here.
I recently installed a SSL certificate on my domain and now Facebook is unable to scrape my webpages for open graph content.
When I go to https://developers.facebook.com/tools/debug/og/object/ and scrape the site: https://genesispetaluma.com, I get an error "Error parsing input URL, no data was cached, or no data was scraped." When I click to see what the scraper sees, I get a message "document returned no data" at this link: https://developers.facebook.com/tools/debug/og/echo?q=https%3A%2F%2Fgenesispetaluma.com%2F. This worked perfectly before the installation of the SSL Certificate. Because I do not have a wildcard SSL certificate, I tried to scrape a site on my subdomain: http://blog.genesispetaluma.com and this passes and delivers the following information: https://developers.facebook.com/tools/debug/og/object?q=blog.genesispetaluma.com.
I have verified with the server logs that Facebook is making a request to my server: 69.171.237.115 - - [22/Aug/2014:09:44:13 -0700] "GET / HTTP/1.1" 206 6512 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
I ran a test with www.ssllabs.com and it appears that the certificate is installed correctly, with all of the intermediate certificates installed as well. My hosting company has verified that the certificate is installed correctly as well.
Any ideas why this is not working or how I can troubleshoot this? I posted this issue in the Facebook Developer forum and they have not been able to figure it out.
Any ideas why this is not working or how I can troubleshoot this?
There's one small problem that I see that might be causing the problem. The CA certificate is being sent in the chain. The CA certificate is the third certificate shown below.
You should not send the CA in the chain. Rather, the client needs to already have it and use it as a trust anchor.
Another potential issue is that the web app located at https://developers.facebook.com does not use the AddTrust External CA Root certificate as a trust anchor. If Facebook is missing the trust anchor, or does not trust the CA, then there's nothing you can do.
The final potential issue is an SSL/TLS interception proxy is at work. But I doubt Facebook is intercepting the traffic leaving their network.
There's another small problem with the server certificate. The server certificate provides a DNS name in the Common Name (CN). Placing a DNS in the Common Name is deprecated by both the IETF and CA/Browser forums. Though its deprecated, its not forbidden.
DNS names should be placed in the Subject Alternate Name (SAN), and both genesispetaluma.com and www.genesispetaluma.com are there. So that looks OK.
$ openssl s_client -connect genesispetaluma.com:443 -CAfile addtrustexternalcaroot.crt | openssl x509 -text -noout
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = PositiveSSL CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by A Small Orange LLC, OU = PositiveSSL, CN = genesispetaluma.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
86:c2:2e:29:7b:68:f7:f3:16:5d:18:27:84:1f:e4:98
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=PositiveSSL CA 2
Validity
Not Before: Mar 3 00:00:00 2014 GMT
Not After : Mar 3 23:59:59 2015 GMT
Subject: OU=Domain Control Validated, OU=Hosted by A Small Orange LLC, OU=PositiveSSL, CN=genesispetaluma.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:e1:16:f6:78:f8:10:29:e8:96:e6:3b:f1:2f:36:
3f:da:2f:cf:b8:f3:ab:cb:3b:8c:a6:09:0a:a6:3a:
f3:e9:ad:7f:d7:30:c4:ac:b3:9b:98:e0:ec:f0:2a:
75:31:e4:0b:92:76:cc:a3:49:b6:bc:35:77:29:ed:
aa:51:20:b5:c1:b0:1f:ed:ee:23:84:29:99:d4:a2:
6c:c5:5e:66:dc:7e:cf:b7:9d:88:c8:75:1a:46:ec:
ce:34:db:da:06:4e:b0:8d:21:ec:2c:db:88:8e:1f:
9b:13:76:ca:30:8c:4b:60:d5:02:f4:91:a9:d6:b3:
3b:c8:46:2d:0d:90:04:c5:39:ca:e7:e2:20:fe:57:
95:bc:40:9b:af:52:9b:fd:95:54:a6:82:f9:d7:ea:
ac:e5:08:1a:53:c2:7b:59:2b:23:a2:12:41:58:4c:
6c:f0:fe:56:77:ed:ae:0f:9a:5d:b5:32:1c:51:3b:
46:56:d2:60:a4:ad:91:56:11:a6:f4:fc:1b:94:22:
84:9f:a2:c0:80:92:01:48:58:9a:d1:01:11:5f:99:
95:05:c8:18:23:dc:72:e4:d8:01:24:f0:c6:26:23:
be:b3:09:ea:22:94:f6:04:c4:9a:67:3c:15:b1:25:
24:49:7d:60:31:5c:60:a5:f9:7b:65:9d:45:91:fd:
a4:f3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:99:E4:40:5F:6B:14:5E:3E:05:D9:DD:D3:63:54:FC:62:B8:F7:00:AC
X509v3 Subject Key Identifier:
3E:E8:E1:02:B6:36:96:64:7F:9A:84:2E:DD:17:F9:D9:C5:88:A7:EF
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: http://www.positivessl.com/CPS
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/PositiveSSLCA2.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/PositiveSSLCA2.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:genesispetaluma.com, DNS:www.genesispetaluma.com
Signature Algorithm: sha1WithRSAEncryption
53:20:9f:af:fd:c4:20:78:ed:56:ed:53:8d:29:38:3b:16:00:
ff:7f:39:fd:75:21:b1:d7:af:27:e5:08:d2:c5:77:5e:52:09:
fd:38:ba:03:a3:8c:4d:e9:8f:6e:a7:12:c4:26:b2:1f:02:96:
f8:24:94:0c:c4:74:2a:2d:2e:b4:d6:4c:ee:5f:2d:e1:b6:91:
a3:eb:d0:9a:46:fa:f5:c1:da:a0:13:11:63:56:64:08:e3:f2:
2c:7a:80:19:1f:a1:4e:ae:9e:ab:1e:27:71:ed:55:da:dc:2b:
b0:52:73:ed:e7:1b:c2:2f:5d:6a:17:90:ee:32:b2:36:ee:9c:
8e:57:5b:70:bd:08:55:1c:a2:f4:ca:ee:f4:0b:0e:d7:1a:e3:
e8:de:14:eb:d0:62:24:9a:8b:7c:c6:ab:65:35:e1:5d:a0:2f:
1f:7a:d2:96:e7:0c:12:cc:d8:e7:ff:1c:58:0c:ce:db:6d:cc:
e8:f7:09:17:57:a8:cc:b7:90:4e:f3:0a:2e:d3:56:ad:44:12:
ce:b1:4c:9b:2a:5c:3f:1e:19:95:41:7a:f9:2c:15:c5:48:c6:
bd:49:ad:f6:95:15:21:69:58:a2:0e:c2:9f:9f:c4:a9:d7:83:
a4:6f:5b:07:c5:28:65:8e:fe:fa:83:5f:5f:10:12:36:c8:c9:
f0:55:7a:a0
I tried to scrape a site on my subdomain: http://blog.genesispetaluma.com and this passes
This is odd. The certificate above does not certify blog.genesispetaluma.com. This should fail validation.
If you want to use OpenSSL's s_client to verify the chain, then go to [Root] AddTrust External CA Root and download the AddTrust External CA Root certificate. Then use the CAfile option and you should receive Verify return code: 0 (ok):
$ openssl s_client -connect genesispetaluma.com:443 -showcerts \
-CAfile addtrustexternalcaroot.crt
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A171C87253621808B164BAA1399B07D776E28EBCB8A5AB3A81D65DD66505E3AF
Session-ID-ctx:
Master-Key: 559289812A3602C49FEC4C6FEDC714D4D7B107BDB4E9AD5A811DD0606EF5114D
4DD2624EE141508E92092CF23D946185
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f4 67 cf 21 46 b8 f9 ae-ba ec da f4 2a 24 9f 5b .g.!F.......*$.[
...
00b0 - b8 97 35 30 cf c6 83 a6-14 a6 b7 16 b1 6c 50 b6 ..50.........lP.
Start Time: 1408754636
Timeout : 300 (sec)
Verify return code: 0 (ok)
Here's the certificate chain with the CA certificate:
$ openssl s_client -connect genesispetaluma.com:443 -showcerts -CAfile addtrustexternalcaroot.crt
CONNECTED(00000003)
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = PositiveSSL CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by A Small Orange LLC, OU = PositiveSSL, CN = genesispetaluma.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by A Small Orange LLC/OU=PositiveSSL/CN=genesispetaluma.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
-----BEGIN CERTIFICATE-----
MIIFNTCCBB2gAwIBAgIRAIbCLil7aPfzFl0YJ4Qf5JgwDQYJKoZIhvcNAQEFBQAw
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwHhcNMTQwMzAzMDAwMDAwWhcNMTUwMzAzMjM1
OTU5WjB+MSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxJTAjBgNV
BAsTHEhvc3RlZCBieSBBIFNtYWxsIE9yYW5nZSBMTEMxFDASBgNVBAsTC1Bvc2l0
aXZlU1NMMRwwGgYDVQQDExNnZW5lc2lzcGV0YWx1bWEuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4Rb2ePgQKeiW5jvxLzY/2i/PuPOryzuMpgkK
pjrz6a1/1zDErLObmODs8Cp1MeQLknbMo0m2vDV3Ke2qUSC1wbAf7e4jhCmZ1KJs
xV5m3H7Pt52IyHUaRuzONNvaBk6wjSHsLNuIjh+bE3bKMIxLYNUC9JGp1rM7yEYt
DZAExTnK5+Ig/leVvECbr1Kb/ZVUpoL51+qs5QgaU8J7WSsjohJBWExs8P5Wd+2u
D5pdtTIcUTtGVtJgpK2RVhGm9PwblCKEn6LAgJIBSFia0QERX5mVBcgYI9xy5NgB
JPDGJiO+swnqIpT2BMSaZzwVsSUkSX1gMVxgpfl7ZZ1Fkf2k8wIDAQABo4IBtzCC
AbMwHwYDVR0jBBgwFoAUmeRAX2sUXj4F2d3TY1T8Yrj3AKwwHQYDVR0OBBYEFD7o
4QK2NpZkf5qELt0X+dnFiKfvMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBQBgNVHSAESTBHMDsGCysG
AQQBsjEBAgIHMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cucG9zaXRpdmVzc2wu
Y29tL0NQUzAIBgZngQwBAgEwOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5j
b21vZG9jYS5jb20vUG9zaXRpdmVTU0xDQTIuY3JsMGwGCCsGAQUFBwEBBGAwXjA2
BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20vUG9zaXRpdmVTU0xD
QTIuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wNwYD
VR0RBDAwLoITZ2VuZXNpc3BldGFsdW1hLmNvbYIXd3d3LmdlbmVzaXNwZXRhbHVt
YS5jb20wDQYJKoZIhvcNAQEFBQADggEBAFMgn6/9xCB47VbtU40pODsWAP9/Of11
IbHXryflCNLFd15SCf04ugOjjE3pj26nEsQmsh8ClvgklAzEdCotLrTWTO5fLeG2
kaPr0JpG+vXB2qATEWNWZAjj8ix6gBkfoU6unqseJ3HtVdrcK7BSc+3nG8IvXWoX
kO4ysjbunI5XW3C9CFUcovTK7vQLDtca4+jeFOvQYiSai3zGq2U14V2gLx960pbn
DBLM2Of/HFgMztttzOj3CRdXqMy3kE7zCi7TVq1EEs6xTJsqXD8eGZVBevksFcVI
xr1JrfaVFSFpWKIOwp+fxKnXg6RvWwfFKGWO/vqDX18QEjbIyfBVeqA=
-----END CERTIFICATE-----
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIE5TCCA82gAwIBAgIQB28SRoFFnCjVSNaXxA4AGzANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEyMDIxNjAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDo6jnjIqaqucQA0OeqZztDB71Pkuu8vgGjQK3g70QotdA6voBUF4V6a4Rs
NjbloyTi/igBkLzX3Q+5K05IdwVpr95XMLHo+xoD9jxbUx6hAUlocnPWMytDqTcy
Ug+uJ1YxMGCtyb1zLDnukNh1sCUhYHsqfwL9goUfdE+SNHNcHQCgsMDqmOK+ARRY
FygiinddUCXNmmym5QzlqyjDsiCJ8AckHpXCLsDl6ez2PRIHSD3SwyNWQezT3zVL
yOf2hgVSEEOajBd8i6q8eODwRTusgFX+KJPhChFo9FJXb/5IC1tdGmpnc5mCtJ5D
YD7HWyoSbhruyzmuwzWdqLxdsC/DAgMBAAGjggF3MIIBczAfBgNVHSMEGDAWgBSt
vZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUmeRAX2sUXj4F2d3TY1T8Yrj3
AKwwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAow
CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDCBswYIKwYBBQUHAQEEgaYw
gaMwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9BZGRUcnVz
dEV4dGVybmFsQ0FSb290LnA3YzA5BggrBgEFBQcwAoYtaHR0cDovL2NydC51c2Vy
dHJ1c3QuY29tL0FkZFRydXN0VVROU0dDQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRw
Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCcNuNOrvGK
u2yXjI9LZ9Cf2ISqnyFfNaFbxCtjDei8d12nxDf9Sy2e6B1pocCEzNFti/OBy59L
dLBJKjHoN0DrH9mXoxoR1Sanbg+61b4s/bSRZNy+OxlQDXqV8wQTqbtHD4tc0azC
e3chUN1bq+70ptjUSlNrTa24yOfmUlhNQ0zCoiNPDsAgOa/fT0JbHtMJ9BgJWSrZ
6EoYvzL7+i1ki4fKWyvouAt+vhcSxwOCKa9Yr4WEXT0K3yNRw82vEL+AaXeRCk/l
uuGtm87fM04wO+mPZn+C+mv626PAcwDj1hKvTfIPWhRRH224hoFiB85ccsJP81cq
cdnUl4XmGFO3
-----END CERTIFICATE-----
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/OU=Hosted by A Small Orange LLC/OU=PositiveSSL/CN=genesispetaluma.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
---
No client certificate CA names sent
---
SSL handshake has read 4373 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A171C87253621808B164BAA1399B07D776E28EBCB8A5AB3A81D65DD66505E3AF
Session-ID-ctx:
Master-Key: 559289812A3602C49FEC4C6FEDC714D4D7B107BDB4E9AD5A811DD0606EF5114D4DD2624EE141508E92092CF23D946185
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f4 67 cf 21 46 b8 f9 ae-ba ec da f4 2a 24 9f 5b .g.!F.......*$.[
0010 - d3 01 c1 21 60 54 8b 1a-8f 5f 5f d5 16 e5 97 11 ...!`T...__.....
0020 - 0f 63 22 5a d3 59 f3 96-a1 3a 35 93 b9 7c 40 9d .c"Z.Y...:5..|#.
0030 - 1d 15 3c 03 04 30 7b 0c-fa fd 69 fc cf ac 32 8c ..<..0{...i...2.
0040 - e2 f2 91 48 37 9b 11 ca-f6 b4 e8 65 5f f2 90 31 ...H7......e_..1
0050 - 8c 2c 7a 74 2e 9a ab de-1f 31 05 b6 a7 6e 42 8b .,zt.....1...nB.
0060 - 6d 36 10 38 38 9f f5 1f-c8 e3 ac ce ba 95 21 4f m6.88.........!O
0070 - 21 3f 38 ef 20 33 f4 b8-86 6a 61 4b e9 cc 00 4d !?8. 3...jaK...M
0080 - ab f3 c6 24 33 3c c5 44-1c 4a f9 71 9b 3c 25 74 ...$3<.D.J.q.<%t
0090 - af 63 73 d7 b3 1b 4f cc-fe 05 76 75 02 db 5b 12 .cs...O...vu..[.
00a0 - 8d 2c 5e 7a 98 ca 95 1c-1a 04 df 6e 22 c3 f2 55 .,^z.......n"..U
00b0 - b8 97 35 30 cf c6 83 a6-14 a6 b7 16 b1 6c 50 b6 ..50.........lP.
Start Time: 1408754636
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
The Facebook team was able to determine the source of the problem. Facebook will not scrape the page unless the og:url has the protocol as well.
For example, this does not work:
meta property="og:url" content="//genesispetaluma.com/"
But this does:
meta property="og:url" content="**https:**//genesispetaluma.com/"
They should to clarify the error in the debugger so people know what's wrong.
I am currently attempting the Raspberry Pi iBeacon tutorial posted by RadiusNetworks at
http://developer.radiusnetworks.com/2013/10/09/how-to-make-an-ibeacon-out-of-a-raspberry-pi.html
but I am having issues with the connection timing out after a few seconds. I have performed a fresh build of raspbian, and have tried with 2 different dongles (AZIO V400 and IOGEAR GBU521), and I have tried with Bluez 5.8 per the tutorial as well as Bluez 5.11, both on fresh Raspbian loads.
When I call the start script I see:
pi#piBlueTest ~ $ ./start
Launching virtual iBeacon...
LE set advertise enable on hci0 returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 44
1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60
D0 F5 A7 10 96 E0 00 00 00 00 C9 00 00 00 00 00 00 00 00 00
00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 00
Complete
This triggers an "Entered" event on the iPhone using the "Locate iBeacon" app, and shows a distance in meters for a few seconds. It then shows "Distance: unknown" as the range for several more seconds, followed by an "exit" event occurring. When I run the sequence with "hcidump" running, I get
HCI sniffer - Bluetooth packet analyzer ver 5.11
device: hci0 snap_len: 1500 filter: 0xffffffff
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
status 0x0c
Error: Command Disallowed
< HCI Command: LE Set Advertising Data (0x08|0x0008) plen 44
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Data (0x08|0x0008) ncmd 1
status 0x00
< HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
min 1280.000ms, max 1280.000ms
type 0x00 (ADV_IND - Connectable undirected advertising) ownbdaddr 0x00 (Public)
directbdaddr 0x00 (Public) 00:00:00:00:00:00
channelmap 0x07 filterpolicy 0x00 (Allow scan from any, connection from any)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
status 0x00
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
status 0x00
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role slave
bdaddr B8:F6:B1:1C:15:C8 (Public)
> ACL data: handle 64 flags 0x02 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2a00
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x13
Reason: Remote User Terminated Connection
It appears that the iPhone is trying to initiate a connection to the pi, and then fails at negotiating that connection which then ends the advertisement.
I have completed the steps from the tutorial to the letter, and cannot seem to determine what is causing the disconnect. I have tried changing bluez versions, and tried different hardware, but to no avail. Any ideas what step I may be missing? I have searched everything I can think of for clues, but have not found the answer yet. Thanks in advance for any advice!
Try setting the device to "advertise and not-connectable" (3 instead of 0) instead of "advertise and connectable"
sudo hciconfig $BLUETOOTH_DEVICE leadv 3
We suddenly had a beacon going down after a few seconds due to a laptop trying to connect. Setting the device to not-connectable solved the problem.
Looks like you have it solved but I'll go ahead and post for others that may have the same problem I did and find this thread.
Like Chris, I completed the steps from the tutorial with the exception of using bluez 5.11. After some experimentation I had to change the order of the steps in the "start" script. Not sure why but this seems to be the only order in which it will work correctly. Maybe I did something wrong?
#!/bin/sh
. ./ibeacon.conf
echo "Launching virtual iBeacon..."
sudo hciconfig $BLUETOOTH_DEVICE up
sudo hciconfig $BLUETOOTH_DEVICE noleadv
sudo hciconfig $BLUETOOTH_DEVICE leadv 0
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 $UUID $MAJOR $MINOR $POWER 00 00 00 00 00 00 00 00 00 00 00 00 00
echo "Complete"
Perhaps you can stop this from happening by making whatever device is attempting a connection stop doing so. This is not normal for iOS. Did you tell it to attempt a connection? Are you sure it is the iOS device doing this? Perhaps it is your computer?
Alternately, if you cannot get it working yourself, I can provide a free .iso file with the exact code we put on the units we sell preassembled. This could eliminate a build problem. Please send a note through our sales contact if you want to try this.