This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

v18 IoT Dyson PureCool not working.

Hi,

 

The Dyson PureCool IoT device is not working with v18 - out the box configuration with HTTPs rules - worked fine with v17.x

 

See this in the logs

messageid="16002" log_type="Content Filtering" log_component="HTTP" log_subtype="Denied" status=" fw_rule_id="24" user=" user_group=" web_policy_id="12" web_policy=" category=" category_type="Acceptable" url=" content_type=" override_token=" response_code=" src_ip="10.1.1.101" dst_ip="52.16.169.92" protocol="TCP" src_port="53494" dst_port="80" bytes_sent="0" bytes_received="0" domain=" exception=" activity_name=" reason="HTTP parsing error encountered." user_agent=" status_code="403" transaction_id=" referer=" download_file_name=" download_file_type=" upload_file_name=" upload_file_type=" con_id="2394122112" app_name=" app_is_cloud="0" override_name=" override_authorizer=" used_quota="0"

 

Regards

 

-Tim



This thread was automatically locked due to age.
Parents Reply Children
  • XG SSLx starts to show you very weak / strange IoT vendors.

    I saw a camera with mismatching self signed certificates, which should not be deployed like that.

    Invalid certificates, expired certificates. 

    Looks like, they do what they want... Some vendors ignore TLS errors and simply build connections to any TLS website. 

    We are going to move more and more to IoT devices and those vendors have not enough knowledge to build Wireless devices at all. 

    Just my two cents about this. 

  • Couldn't agree more - they are a law unto themselves.

     

    It's at the point where you need a separate BSID and VLAN just for the IoT devices to do what the hell they like - in all honesty it's been that way for a while...

     

    If they cut corners like this, who's to say what they are allowing into your network?

  • If I may add to this, I had a similar problem with my TP04 fan after upgrading to SFOS18.

    However, my logs revealed that while the firewall allowed the traffic out to the WAN from the "untrusted" VLAN I have for these pesky IoT things, the same rule was then reporting "Invalid TCP State" for the incoming/return traffic.

    So in my case, I also had to go into the console but I had to use the command:

    console> set advanced-firewall tcp-seq-checking off

    I don't like switching off things that are normally on but it seems this was the only way to resolve this. I guess my question is two-fold:

    1) Can this checking be applied to a firewall rule instead of the overall config from the shell?
    2) What risks do I present to the security of my system by having this setting disabled?

    Apologies if I am hijacking this thread and I should be creating a separate one, despite the common denominators being Dyson and SFOS18.