Forum Replies Created

Viewing 15 posts - 721 through 735 (of 756 total)
  • Author
    Posts
  • in reply to: [Solved] Unit won’t connect from 4G network #895
    Radu
    Keymaster

    It does look normal, but the header is missing. This results in the 400 Error code. The image shows a dash on each row. For other units there’s the user agent there.

    What’s strange is that a few days ago, 11000016 was working fine . Did anything change in the network setup?

    For Rick’s unit, 11000009 the problem was from the beginning.

    But both units worked perfectly here, while running the tests.

    in reply to: [Solved] Unit won’t connect from 4G network #891
    Radu
    Keymaster

    @Rick, the problem for 11000009:
    [Fri Dec 12 21:46:27 2014] [debug] protocol.c(792): [client 72.47.*.*] Request header field is missing ‘:’ separator: \x01\xff\xff\xff
    [Fri Dec 12 21:46:27 2014] [error] [client 72.47.*.*] request failed: error reading the headers


    @Lars
    , the problem for 11000016:
    [Fri Dec 12 21:44:42 2014] [debug] protocol.c(792): [client 178.255.*.*] Request header field is missing ‘:’ separator: /\xf3\x01\xff\xff\xff
    [Fri Dec 12 21:44:42 2014] [error] [client 178.255.*.*] request failed: error reading the headers

    • This reply was modified 7 years, 12 months ago by Radu.
    in reply to: [Solved] Unit won’t connect from 4G network #889
    Radu
    Keymaster

    Good idea. Support forum created and this topic moved.

    Regarding the problem, I have investigated things further. Must say this seems to be an elusive bug and I have wasted a few hours to track it already.

    Apparently the two units get to the server with their User Agent info stripped. Probably other parts of the packages are changed as well. Also the source IP is null. I don’t know what on their route changes their HTTP headers. Local tests didn’t show this issue, and it is impossible to consider a malfunction of any kind.

    I can only assume a firewall would be able to have this intrusive result.

    With the User Agent info removed and no source IP, the server denies the packages with a HTTP 400 Error code (Bad request).

    I will see what I can do about this.

    • This reply was modified 7 years, 12 months ago by Radu.
    in reply to: Firmware upgrade #883
    Radu
    Keymaster

    Feel free to post a link Mike!

    in reply to: [Solved] Unit won’t connect from 4G network #878
    Radu
    Keymaster

    Here is a snapshot of the access log. Because the packets are not landing on data.uradmonitor.com, the server issues a HTTP 400.

    As the unit is unable to get a valid reply, it auto-resets after 5 minutes. See the ts parameter, which is the local time of the unit in seconds, it never goes over 240 (=4×60 seconds, on the fifth it resets).

    Two units are currently having this problem, 11000016 and 11000009 . I will find out why.

    in reply to: [Solved] Unit won’t connect from 4G network #877
    Radu
    Keymaster

    Lars, I found the problem

    Your unit resolves the server DNS as it would be uradmonitor.com instead of data.uradmonitor.com

    The packets are hitting the wrong server.

    I will see what I can do at my end.

    • This reply was modified 7 years, 12 months ago by Radu.
    in reply to: Networking Issues #874
    Radu
    Keymaster

    So I am correct in assuming that on routers that send it we have a problem, on those that don’t we’re fine.

    in reply to: Networking Issues #872
    Radu
    Keymaster

    @vinz, first I didn’t know what you were talking about 🙂


    @ben
    , I agree, but it mostly serves prototyping or DIY. The offer you’ve mentioned is sent by the router, right?

    in reply to: Networking Issues #867
    Radu
    Keymaster

    I think you’re right Ben. And this makes it strange: to get inconsistent behaviour depending on the network!

    I have a router that I know was causing some problems with uRADMonitor units. I’ll need to find it and run some tests before I can report back.

    The DHCP code was mainly written by me, and in the last revision I added the hostname option (in the form uRADMonitor-). Previously you would only see the MAC, the allocated IP and no hostname. I might have done something wrong so hopefully things will clarify.

    Another option is checking it against the Arduino implementation, but I find that complicated with all the Arduino libs and custom I/O code.

    in reply to: Client side charts #864
    Radu
    Keymaster

    Sounds great! And nice work

    in reply to: 12000012 – My uRADMonitor installation #862
    Radu
    Keymaster

    Looks great, Peter! Congrats on the nice installation.

    in reply to: Networking Issues #860
    Radu
    Keymaster

    The 02…. are locally administered addresses. Nothing special about them just that they are free. To register universal administered addresses I will have to pay some money. I will do that in the future.

    Vinz, are you getting the same issues with DHCP? can you post more details?

    In my local tests, DHCP was fine, so it’s a bit hard for me to replicate this for a fix:

    in reply to: [Solved] Unit won’t connect from 4G network #859
    Radu
    Keymaster

    I’m afraid there were no updates. So the change must have been local. Yes, currently there are several IP used. The one for data is correct: 23.239.13.18.

    Lars, just as a note, I don’t think this is physical, nevertheless if you are unable to find the problem, you can send the unit back anytime to get a replacement.

    in reply to: Security: invalid data injection #796
    Radu
    Keymaster

    Hello Vinz,

    I think you have covered pretty much everything to secure the problem and even beyond that to detect if a device is behaving suspicious.

    Also @Jeff ‘s suggestion on checking upload interval is important in limiting invalid data.

    Unless anyone has anything else to add, I will propose this as solution, and standardise it in a specs document written for the next firmware release.

    in reply to: Security: invalid data injection #792
    Radu
    Keymaster

    Indeed patching would automate the production of unique firmware binaries, without compiling the source code every time.

    But there is also the approach presented here: https://www.uradmonitor.com/topic/automated-device-ids/

    The eeprom can also be written without changing the firmware using a separate script, after main firmware is written.

Viewing 15 posts - 721 through 735 (of 756 total)