I'm following the instructions off the book Mastering Ethereum, (https://www.onlineprogrammingbooks.com/mastering-ethereum/) and I've hit a snag.
I've set up the MetaMask extension and trying to make the first transaction via the Ropsten network. I'm getting the error:
{"error":"[ethjs-query] while formatting outputs from RPC '{\"value\":{\"code\":-32000,\"message\":\"replacement transaction underpriced\"}}'"}
MetaMask is set up on Brave. I've tried with and without VPN.
I got this error as well:
{"error":"[ethjs-query] while formatting outputs from RPC '{\"value\":{\"code\":-32000,\"message\":\"replacement transaction underpriced\"}}'"}
For me, I turned off my adblocker and it worked.
I tried again a few days later and it just worked. It might have been a problem with my VPN after all.
Related
I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!
I'm using Google's simplehttp2server go-lang program to run some tests and have encountered a recurring error. Upon executing the TLS handshake I receive the following error:
2019/12/12 12:42:55 http: TLS handshake error from 127.0.0.1:36202: read tcp 127.0.0.1:5000->127.0.0.1:36202: use of closed network connection
I have updated my go version to 1.13.5 from 1.12.9 and tried two browsers (brave + chrome) plus curl and receive the same error code each time. It happens over HTTP/2 and HTTP/1.1. I have seem other answers from across the web but am still running into this error (ex1, ex2, ex3, ex4).
Very much appreciate any feedback, advice, or admonishment. Anything to help the migraine this problem is giving me!
edit: screenshot from my curl and running of simplehttp2server
example image from curl and simplehttp2server
This error happens when you have two websockets connected to a singular address using the same port from the same machine. One of the websockets will be able to connect fine but the other wont be able to make the connection.
I was making the same mistake and when I removed the duplicate connection the error resolved.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
I've been trying to check my balance from by 3g modem via AT commands and seem to be stuck.
The device infomation is as follows:
Manufacturer: QUALCOMM INCORPORATED
Model: M6281
Revision: SSD_M6281A-0.0.1 1 [Oct 02 2008 07:00:00]
The modem has USSD capability (advertised and also present in the factory installed dashboard).
I am connecting via putty to COM4 serial port which is my modems application port. All AT commands are working fine but I am getting an error on issuing the following via putty:
AT+CUSD=1,"*111#",15
This returns a simple "ERROR". *111# is my carrier's balance check code. I suspect that there is a formatting error somewhere but I can't figure out where.
Note: If I issue a blank ussd command:
AT+CUSD=1,"",15
then I get an OK (although I later get a response +CME ERROR: retry operation) ... If I write anything within the quotation marks however, it returns an "ERROR".
Ok, I finally found the way to fix this. Apparently there was a problem in the encoding. Here is what I did:
AT+CSCS="GSM" // change character set to GSM
AT+CUSD=1,"*111#",15 // Issued balance check ussd code
It now works fine.
The default encoding was UCS2, I'd appreciate if someone can share how to convert ussd codes to UCS2 encoding in putty.
Have you tried issuing request by AT+CUSD=1,"*111#" ? (without last parameter)
AT cmmands sometimes differ due to manufacturer implementation.
We stopped being able to connect to the feedback.sandbox.push.apple.com about two days ago right in the middle of testing. I checked the certificate and it is valid. I also ran the openssl troubleshooting commands... and it all appeared ok. But we also can NOT doing any testing or work against the sandbox APNS. We are getting the following error about a malformed message response when we try and create the SSLStream connection. I have been scratching my head for a day now... thinking it was something on our end... so would really appreciate a response if others are able to test and connect to the sandbox APNS using PushSharp current version 2.1.2 ??
A call to SSPI failed, see Inner exception" Inner Exception -> "The message received was unexpected or badly formatted."
We were having the same issue using the now deprecated APNS-Sharp library (ancestor to PushSharp). I submitted a pull request for APNS-Sharp that fixes the issue based on my tests.
See https://stackoverflow.com/a/23121258/3542341
and for the pull request: https://github.com/Redth/PushSharp/pull/369/files