cdhowie (OP)
|
|
May 08, 2011, 07:54:12 PM |
|
This is the result, sanitized to remove portions of my email/password at deepbit:
Thanks, that's all I need to know to fix the problem. Apparently the older PDO library doesn't support using the same query argument twice in a query. A fix is forthcoming.
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
cdhowie (OP)
|
|
May 08, 2011, 08:04:18 PM |
|
This is the result, sanitized to remove portions of my email/password at deepbit:
Thanks, that's all I need to know to fix the problem. Apparently the older PDO library doesn't support using the same query argument twice in a query. A fix is forthcoming. Fix just got pushed to the Git repository; please pull and see if the problem goes away.
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
cdhowie (OP)
|
|
May 08, 2011, 08:15:49 PM |
|
I love this one. It make switching really painless, especially after todays outage of slush's pool this proved a timesaver.
I'm glad you like it. What I noticed however that the failing pool will still be asked for work, and only he doesn't return any, the next one will be asked. Are there plans for exponential backoff in order to avoid the extra request and the extra idle time? Just a mechanism to automatically blacklist a pool should it fail, and increase the blacklist time on each subsequent failure would be cool.
This is a good idea. I've added it to the issue tracker. The problem today is that slush sometimes gives me work, but does not accept the result (timeout/502 errors/...).
Hmm, I see. I'll try to implement something so that if a pool doesn't respond normally to a share submission (e.g. it doesn't accept or reject the share, but gives some other HTTP or JSON-level error) the software will retry a few times, and disabled the pool for some time if it still can't reach the server. This will depend on the other feature being implemented first. (This one has also been added to the issue tracker.) Also I get a lot of these: 192.168.3.5 - pilum [08/May/2011:19:21:43 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22" 192.168.3.5 - pilum [08/May/2011:19:21:45 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22" 192.168.3.5 - pilum [08/May/2011:19:21:47 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22" 192.168.3.5 - pilum [08/May/2011:19:21:49 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22" 192.168.3.5 - pilum [08/May/2011:19:21:49 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22" Which makes me think that the diablo miner does not really take advantage of the long polling feature, and I start feeling bad for bombing pools with all those long poll requests. Any ideas? Hmm, that is definitely weird. Can you sniff those requests and paste the HTTP conversation (sanitizing authentication details) so that I can see what's going on?
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
pwnyboy
|
|
May 09, 2011, 12:32:27 AM |
|
Fix just got pushed to the Git repository; please pull and see if the problem goes away.
Thanks, that gets connected and accepting work now, but after maybe 3 minutes of mining, I see a random disconnect: [08/05/2011 20:27:46] Connected to server [08/05/2011 20:28:30] Result: 9f0a0a6e accepted [08/05/2011 20:28:31] Result: 6731f6a4 accepted [08/05/2011 20:28:55] Result: a0527e09 accepted [08/05/2011 20:28:59] Result: 196f2c04 accepted [08/05/2011 20:29:17] Result: 65173661 accepted [08/05/2011 20:29:21] Result: 564ba46a accepted [08/05/2011 20:29:47] Disconnected from server [08/05/2011 20:29:48] Connected to server [08/05/2011 20:30:05] Result: 40071f20 accepted [08/05/2011 20:30:24] Result: a6206ab4 accepted [08/05/2011 20:30:33] Result: 73d3021d accepted [08/05/2011 20:30:34] Disconnected from server [307.16 Mhash/sec] [9 Accepted] [0 Rejected] [RPC (+LP)] Let me know how I can help diagnose this.
|
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 03:03:54 AM |
|
Thanks, that gets connected and accepting work now, but after maybe 3 minutes of mining, I see a random disconnect:
The long-polling request is probably getting terminated. This should only happen if you have PHP's safe mode enabled -- set_time_limit() has no effect when running under safe mode, so the most likely cause here is that PHP is simply killing the script doing the long-polling request because it is running for too long. (Note that the "disconnection" message comes almost exactly two minutes after the "connection" message.) Try disabling safe mode. Safe mode can only be disabled in php.ini or your Apache configuration; .htaccess files can not disable safe mode.
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
pwnyboy
|
|
May 09, 2011, 03:27:18 AM |
|
Yes it's already disabled in php.ini:
; ; Safe Mode ; safe_mode = Off
Though I think it would be a good idea to go back and mention as dependencies (in the INSTALL file) that safe_mode should be disabled, and that this (quite obviously) requires php json support, which is an add-on for PHP versions prior to 5.3.
Anyway this could very well have something to do with long polling. I tried setting my max execution time (php.ini) to 1500 seconds, up from 30 seconds. It did the following:
[08/05/2011 23:21:44] Connected to server [08/05/2011 23:21:49] Result: be0189d3 accepted [08/05/2011 23:21:54] Result: 62cffe98 accepted [08/05/2011 23:21:58] Result: 65b66b0e accepted [08/05/2011 23:22:31] Result: 2ca96088 accepted [08/05/2011 23:22:38] Result: 8bd7c27e accepted [08/05/2011 23:22:39] LP: New work pushed [08/05/2011 23:22:47] Result: c662da7b accepted [08/05/2011 23:23:20] Result: b9b3a17f accepted [08/05/2011 23:23:30] Result: 889e14f2 accepted [08/05/2011 23:23:31] Result: 1b237f90 accepted [08/05/2011 23:23:38] Result: 9da72831 accepted [08/05/2011 23:24:33] Result: ca84878c accepted [08/05/2011 23:24:40] Disconnected from server [08/05/2011 23:24:41] Connected to server [08/05/2011 23:24:43] Result: 1b1964ce accepted [08/05/2011 23:24:57] Result: 6b5df998 accepted [08/05/2011 23:25:41] Result: 86510be4 accepted
Any other ideas?
|
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 04:04:30 AM |
|
Anyway this could very well have something to do with long polling. I tried setting my max execution time (php.ini) to 1500 seconds, up from 30 seconds. It did the following:
....
Any other ideas?
Hmm... run a packet sniffer and see what's going on with the LP request?
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
Cdecker
|
|
May 09, 2011, 11:54:33 AM |
|
Hmm, that is definitely weird. Can you sniff those requests and paste the HTTP conversation (sanitizing authentication details) so that I can see what's going on? Will do ^^
|
|
|
|
Cdecker
|
|
May 09, 2011, 12:32:44 PM |
|
Will do ^^
I should have seen it immediately: Diablo uses POST request while well behaving clients (phoenix, poclbm, ...) use GET requests. Should be a simple matter of routing POST to the same handler In the meantime I'm working on a hashrate estimate for the workers, which I'd find quite usefull. Do you accept patches/pull requests?
|
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 02:02:22 PM |
|
I should have seen it immediately: Diablo uses POST request while well behaving clients (phoenix, poclbm, ...) use GET requests. Should be a simple matter of routing POST to the same handler Ah, good catch. I should have followed the "be lenient in what you accept" rule when coding... In the meantime I'm working on a hashrate estimate for the workers, which I'd find quite usefull. Do you accept patches/pull requests?
Absolutely, as long as you release your patches under the AGPLv3. Have you patched it to accept POST for long-polling requests, or should I fix that?
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
Cdecker
|
|
May 09, 2011, 02:16:08 PM |
|
I'm not really familiar with the framework you're using, so I started by implementing the hash speed for the workers. As for the routing of the post request, I guess you'd be faster than me :-)
|
|
|
|
Cdecker
|
|
May 09, 2011, 02:35:10 PM |
|
Just issued a pull request for the hashing speed and shares in the last hour on the dashboard for each worker. Hope you like it ^^
|
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 02:39:21 PM |
|
I'm not really familiar with the framework you're using, so I started by implementing the hash speed for the workers. As for the routing of the post request, I guess you'd be faster than me :-)
It's a custom lightweight MVC framework that doesn't do terribly fancy routing, but still allows me to separate my code better. I've pushed a fix to the diablo-lp-fix branch. Can you try that and see if it fixes the issue for you? Just issued a pull request for the hashing speed and shares in the last hour on the dashboard for each worker. Hope you like it ^^
Thanks! I'll have a look later today.
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
Cdecker
|
|
May 09, 2011, 02:50:48 PM |
|
Works like a charm, and it fixed my 100% problem with Diablo too ^^
|
|
|
|
pharaon
|
|
May 09, 2011, 03:14:44 PM |
|
How to set up a "no admin ask password" to test it
|
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 03:22:20 PM |
|
Works like a charm, and it fixed my 100% problem with Diablo too ^^
Neat, I'll merge the fix into master.
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 03:22:32 PM |
|
How to set up a "no admin ask password" to test it
I'm not sure what you mean. Can you elaborate?
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
pharaon
|
|
May 09, 2011, 03:39:24 PM |
|
How to set up a "no admin ask password" to test it
I'm not sure what you mean. Can you elaborate? yes sorry.... In your Install file you say: 2. Create a MySQL user for the proxy, giving it the privileges SELECT, INSERT, UPDATE, DELETE, and LOCK TABLES on the proxy's database only. (Optional, but recommended.) Is it the same user than: 3. Set the admin user and password. This will be used when logging in to the web management console. and an other question is, when i connect on the "/" of my proxy, it ask me a login and password. Is it the same than in the admin section ? sorry for my bad english
|
|
|
|
cdhowie (OP)
|
|
May 09, 2011, 03:59:08 PM |
|
In your Install file you say: 2. Create a MySQL user for the proxy, giving it the privileges SELECT, INSERT, UPDATE, DELETE, and LOCK TABLES on the proxy's database only. (Optional, but recommended.)
Is it the same user than:
3. Set the admin user and password. This will be used when logging in to the web management console.
No. The first is a user in the MySQL database; all of the workers as well as the admin account will cause the proxy to authenticate to the database server with these credentials. The admin user is a separate set of credentials that you use to log in to the proxy management console. You can pick whatever you want for the admin credentials, but the MySQL credentials must match a MySQL user. and an other question is, when i connect on the "/" of my proxy, it ask me a login and password. Is it the same than in the admin section ?
No. When you use the "/admin" URI, it will ask for admin credentials. When you use the "/" URI it will ask for worker credentials.
|
Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ Thanks to ye, we have the final piece.PGP key fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 SerajewelKS @ #bitcoin-otc
|
|
|
pwnyboy
|
|
May 09, 2011, 05:50:16 PM |
|
Ok further to my issue, I captured one of those sessions per below: 13:43:46.455793 IP xxx.113.52046 > xxx.170.http: S 744407596:744407596(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> E..4.^@.~.ewD..qD....N.P,^.,...... . ............... 13:43:46.455904 IP xxx.170.http > xxx.113.52046: S 3067826941:3067826941(0) ack 744407597 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> E..4..@.@...D...D..q.P.N..R.,^.-.... B.............. 13:43:46.456045 IP xxx.113.52046 > xxx.170.http: . ack 1 win 16425 E..(._@.~.e.D..qD....N.P,^.-..R.P.@) ... 13:43:46.456723 IP xxx.113.52046 > xxx.170.http: P 1:489(488) ack 1 win 16425 E....`@.~.c.D..qD....N.P,^.-..R.P.@)....POST / HTTP/1.1 Connection: close Content-Length: 302 Host: bitproxy.xxxxx.com Content-Type: application/json Authorization: Basic xxx User-Agent: phoenix/v1.2
{"method": "getwork", "params": ["00000001bc66976a156c69045f8108574a73efd268ee2faed010d66f00000672000000003d9dd833b0ac46504204b3be7b9dfa2ce1295409970ac51eab2b8e0ed66d12b34dc827ba1b0098fa02ec2550000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"], "id": 1} 13:43:46.456743 IP xxx.170.http > xxx.113.52046: . ack 489 win 432 E..(W.@.@.X.D...D..q.P.N..R.,^..P...]I.. 13:43:46.956705 IP xxx.170.http > xxx.113.52046: P 1:484(483) ack 489 win 432 E...W.@.@.V4D...D..q.P.N..R.,^..P.......HTTP/1.1 200 OK Date: Mon, 09 May 2011 17:43:46 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy Set-Cookie: PHPSESSID=badcm71qo331pfnu8b9420med3; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 37 Connection: close Content-Type: application/json-rpc
{"result":true,"error":null,"id":"1"} 13:43:46.956767 IP xxx.170.http > xxx.113.52046: F 484:484(0) ack 489 win 432 E..(W.@.@.X.D...D..q.P.N..T.,^..P...[e.. 13:43:46.956948 IP xxx.113.52046 > xxx.170.http: . ack 485 win 16304 E..(.c@.~.e~D..qD....N.P,^....T.P.?..e.. 13:43:47.330166 IP xxx.113.52046 > xxx.170.http: F 489:489(0) ack 485 win 16304 E..(.e@.~.e|D..qD....N.P,^....T.P.?..d.. 13:43:47.330189 IP xxx.170.http > xxx.113.52046: . ack 490 win 432 E..(W.@.@.X.D...D..q.P.N..T.,^..P...[d.. 13:43:55.614063 IP xxx.113.52047 > xxx.170.http: S 3321044043:3321044043(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> E..4..@.~.eSD..qD....O.P...K...... ..I.............. 13:43:55.614082 IP xxx.170.http > xxx.113.52047: S 3074415693:3074415693(0) ack 3321044044 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> E..4..@.@...D...D..q.P.O.?.M...L.................... 13:43:55.614375 IP xxx.113.52047 > xxx.170.http: . ack 1 win 16425 E..(..@.~.e^D..qD....O.P...L.?.NP.@).N.. 13:43:55.615008 IP xxx.113.52047 > xxx.170.http: P 1:230(229) ack 1 win 16425 ..@.~.dxD..qD....O.P...L.?.NP.@).I..POST / HTTP/1.1 Connection: close Content-Length: 44 Host: bitproxy.xxxxx.com Content-Type: application/json Authorization: Basic xxx User-Agent: phoenix/v1.2
{"method": "getwork", "params": [], "id": 1} 13:43:55.615027 IP xxx.170.http > xxx.113.52047: . ack 230 win 432 E..(.f@.@..zD...D..q.P.O.?.N...1P....... 13:43:56.104782 IP xxx.170.http > xxx.113.52047: P 1:1133(1132) ack 230 win 432 D...D..q.P.O.?.N...1P....u..HTTP/1.1 200 OK Date: Mon, 09 May 2011 17:43:55 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy Set-Cookie: PHPSESSID=qt55pon5dn780ipddvv5b5b6i3; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 Content-Length: 596 Connection: close Content-Type: application/json-rpc
{"error":null,"result":{"midstate":"dfbbd14c8d2c37fbcc47bc795c40fe6c8785fe34516942c390fd3fc51ad5eda5","data":"00000001bc66976a156c69045f8108574a73efd268ee2faed010d66f0000067200000000684f3b8dea52cfbfb263679b2f60b4852a54003f9a515ba1fd86c967ea4c79c54dc827d61b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"} 13:43:56.104936 IP xxx.170.http > xxx.113.52047: F 1133:1133(0) ack 230 win 432 E..(.h@.@..xD...D..q.P.O.?.....1P....u.. 13:43:56.105108 IP xxx.113.52047 > xxx.170.http: . ack 1134 win 16142 E..(..@.~.e\D..qD....O.P...1.?..P.?..... 13:43:56.487939 IP xxx.113.52047 > xxx.170.http: F 230:230(0) ack 1134 win 16142 E..(..@.~.eZD..qD....O.P...1.?..P.?..... 13:43:56.487966 IP xxx.170.http > xxx.113.52047: . ack 231 win 432 E..(.i@.@..wD...D..q.P.O.?.....2P....t.. 13:43:59.944022 IP xxx.170.http > xxx.113.52026: P 2946665288:2946665812(524) ack 1221764226 win 432 E..4*\@.@..yD...D..q.P.:...HH...P.......HTTP/1.1 200 OK Date: Mon, 09 May 2011 17:42:03 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy Set-Cookie: PHPSESSID=dtmsljts7gfebhij4jhkt76e75; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 78 Connection: close Content-Type: application/json-rpc
{"error":"Invalid response from long-poll request.","result":null,"id":"json"} 13:43:59.944091 IP xxx.170.http > xxx.113.52026: F 524:524(0) ack 1 win 432 E..(*]@.@...D...D..q.P.:...TH...P...-^.. 13:43:59.944370 IP xxx.113.52026 > xxx.170.http: . ack 525 win 16294 E..(..@.~.eND..qD....:.PH......UP.?..g.. 13:43:59.981456 IP xxx.113.52026 > xxx.170.http: F 1:1(0) ack 525 win 16294 E..(..@.~.eMD..qD....:.PH......UP.?..f.. 13:43:59.981474 IP xxx.170.http > xxx.113.52026: . ack 2 win 432 E..(*^@.@...D...D..q.P.:...UH...P...-].. 13:44:00.417881 IP xxx.113.52048 > xxx.170.http: S 387224838:387224838(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> E..4..@.~.e4D..qD....P.P.......... .Ll.............. 13:44:00.417910 IP xxx.170.http > xxx.113.52048: S 3089436255:3089436255(0) ack 387224839 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> E..4..@.@...D...D..q.P.P.%._........................ 13:44:00.418212 IP xxx.113.52048 > xxx.170.http: . ack 1 win 16425 E..(..@.~.e?D..qD....P.P.....%.`P.@).z.. 13:44:00.418829 IP xxx.113.52048 > xxx.170.http: P 1:230(229) ack 1 win 16425 ..@.~.dYD..qD....P.P.....%.`P.@).u..POST / HTTP/1.1 Connection: close Content-Length: 44 Host: bitproxy.xxxxx.com Content-Type: application/json Authorization: Basic xxx User-Agent: phoenix/v1.2
{"method": "getwork", "params": [], "id": 1} 13:44:00.418849 IP xxx.170.http > xxx.113.52048: . ack 230 win 432 E..(..@.@..)D...D..q.P.P.%.`....P....... 13:44:00.948140 IP xxx.170.http > xxx.113.52048: P 1:1133(1132) ack 230 win 432 E.....@.@...D...D..q.P.P.%.`....P....u..HTTP/1.1 200 OK Date: Mon, 09 May 2011 17:44:00 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy Set-Cookie: PHPSESSID=63481nkntcud9f6m4pagb9b1t7; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 Content-Length: 596 Connection: close Content-Type: application/json-rpc
{"error":null,"result":{"midstate":"b182bf7d65f2d20ac82d0d4b565784c2068e9d74540395d99371d401a3771bd3","data":"000000010bf5756fc40209bedd2d96da3a11c0c58e17ead100c5b17f000092cc000000008580d382a53b5854437590690a3931aef8099d83a94942bf6394ac2fc7a09a9b4dc827de1b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"} 13:44:00.948266 IP xxx.170.http > xxx.113.52048: F 1133:1133(0) ack 230 win 432 E..(..@.@..'D...D..q.P.P.%......P....... 13:44:00.948593 IP xxx.113.52048 > xxx.170.http: . ack 1134 win 16142 E..(..@.~.e=D..qD....P.P.....%..P.?..C.. 13:44:01.297377 IP xxx.113.52048 > xxx.170.http: F 230:230(0) ack 1134 win 16142 E..(..@.~.e;D..qD....P.P.....%..P.?..B.. 13:44:01.297402 IP xxx.170.http > xxx.113.52048: . ack 231 win 432 E..(..@.@..&D...D..q.P.P.%......P....... 13:44:01.734129 IP xxx.113.52049 > xxx.170.http: S 3138450324:3138450324(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> E..4..@.~.e D..qD....Q.P.......... .I............... 13:44:01.734154 IP xxx.170.http > xxx.113.52049: S 3082134796:3082134796(0) ack 3138450325 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> E..4..@.@...D...D..q.P.Q.............:.............. 13:44:01.734452 IP xxx.113.52049 > xxx.170.http: . ack 1 win 16425 ...)..@.~.e+D..qD....Q.P....... 13:44:01.734985 IP xxx.113.52049 > xxx.170.http: P 1:203(202) ack 1 win 16425 P.@)....GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1 Connection: close Host: bitproxy.xxxxx.com Authorization: Basic xxx User-Agent: phoenix/v1.2
13:44:01.734999 IP xxx.170.http > xxx.113.52049: . ack 203 win 432 ..._P...K`..D...D..q.P.Q... 13:44:02.170888 IP xxx.113.52050 > xxx.170.http: S 2138553343:2138553343(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> ...............qD....R.P.w........ .. 13:44:02.170915 IP xxx.170.http > xxx.113.52050: S 3093645464:3093645464(0) ack 2138553344 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> E..4..@.@...D...D..q.P.R.eH..w.......,.............. 13:44:02.171211 IP xxx.113.52050 > xxx.170.http: . ack 1 win 16425 E..(..@.~.e'D..qD....R.P.w...eH.P.@).... 13:44:02.171933 IP xxx.113.52050 > xxx.170.http: P 1:230(229) ack 1 win 16425 ..@.~.dAD..qD....R.P.w...eH.P.@)....POST / HTTP/1.1 Connection: close Content-Length: 44 Host: bitproxy.xxxxx.com Content-Type: application/json Authorization: Basic xxx User-Agent: phoenix/v1.2
{"method": "getwork", "params": [], "id": 1} 13:44:02.171954 IP xxx.170.http > xxx.113.52050: . ack 230 win 432 E..(\.@.@.S.D...D..q.P.R.eH..w..P....7.. 13:44:02.670896 IP xxx.170.http > xxx.113.52050: P 1:1133(1132) ack 230 win 432 E...\.@.@.O^D...D..q.P.R.eH..w..P....u..HTTP/1.1 200 OK Date: Mon, 09 May 2011 17:44:02 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy Set-Cookie: PHPSESSID=m3et5o4vie44qhibp48aol5ge0; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 Content-Length: 596 Connection: close Content-Type: application/json-rpc
{"error":null,"result":{"midstate":"50c28d3c275afafd87eed724bd0d5b1847e9dbdda7e79e12ed0e6418ff49766f","data":"000000010bf5756fc40209bedd2d96da3a11c0c58e17ead100c5b17f000092cc00000000cb9cc4fb77da766429a30281b126ccec2aa1e6675f45a1067d56ff2c3bf1be654dc827de1b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"} 13:44:02.671014 IP xxx.170.http > xxx.113.52050: F 1133:1133(0) ack 230 win 432 E..(\.@.@.S.D...D..q.P.R.eM..w..P....... 13:44:02.671333 IP xxx.113.52050 > xxx.170.http: . ack 1134 win 16142 E..(..@.~.e.D..qD....R.P.w...eM.P.?..k.. 13:44:03.047103 IP xxx.113.52050 > xxx.170.http: F 230:230(0) ack 1134 win 16142 E..(..@.~.e.D..qD....R.P.w...eM.P.?..j.. 13:44:03.047124 IP xxx.170.http > xxx.113.52050: . ack 231 win 432 E..(\.@.@.S.D...D..q.P.R.eM..w..P....... 13:44:03.483509 IP xxx.113.52049 > xxx.170.http: F 203:203(0) ack 1 win 16425 P.@)....~.e D..qD....Q.P..._... 13:44:03.520512 IP xxx.170.http > xxx.113.52049: . ack 204 win 432 ...`P...K_..D...D..q.P.Q...
This is mid-stream, i.e. I let the miner run for maybe 2 minutes, then turned on the sniffer when I thought it would throw the error, so it sent in maybe 2 or 3 successful shares, then the miner threw a disconnection error per below: [09/05/2011 13:43:22] Result: f780500d accepted [09/05/2011 13:43:53] Result: 98a41184 accepted [09/05/2011 13:44:06] Disconnected from server [09/05/2011 13:44:07] Connected to server The capture looks completely normal to me, based on my (very lay) knowledge of the protocol.
|
|
|
|
|