Jump to content

zoggy

Members
  • Content Count

    555
  • Joined

  • Last visited

Community Reputation

13 Good

About zoggy

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. the logical place is to go look at the security forum section about this issue which had nothing hence why I posted there and noted.
  2. @limetech sorry for the cross post, but I came here looking to see if the CVE was already addressed.
  3. offical site: https://zombieloadattack.com/ “ZombieLoad,” as it’s called, is a side-channel attack targeting Intel chips, allowing hackers to effectively exploit design flaws rather than injecting malicious code. Intel said ZombieLoad is made up of four bugs, which the researchers reported to the chip maker just a month ago. Almost every computer with an Intel chips dating back to 2011 are affected by the vulnerabilities. AMD and ARM chips are not said to be vulnerable like earlier side-channel attacks. additional info: https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/ and patches: https://techcrunch.com/2019/05/14/intel-chip-flaws-patches-released/
  4. I can confirm you will get a marvell warning from the plugin (although a bit vague): I get it because I have a Supermicro's SAS2LP-MV8 controller (based on the Marvell 9480 host controller). "Marvell" never shows up in my syslog anywhere. As others have noted, some Marvell controllers are fine (never been a problem and still is fine on 6.7.0) but it is more of piece of mind to us another brand for reliability.
  5. what is different from 6.7.0 final and 6.7.0-rc8?
  6. just curious if this RC is going to be final.. as 6.7.0rc started in jan
  7. you can just ssh to your unraid box and do "ifconfig eth0" for the info. also the unraid gui dashboard says the info as well but just more tedious as you have to change the drop down from general info > counters > errors to see everything.
  8. from your test, looks like you did tcp testing and see the problem. so now you could try udp and see if it also has an issue. but regardless now you should packet capture and see what happens at the dips. you can use wireshark and do an io graph to make it easy to align and search. example: side question, what mtu are you using and have you checked your nic stats to make sure you dont have runts/giants and/or errors?
  9. you should load up iperf3 / ethr and test internally from within your own network. eliminate as many networking elements and unknown variables you can. may find out your isp just has bad peering.. or your firewall rules are the cause.. etc
  10. updated from previous rc. so far no fireworks
  11. to add additional information that is not as dry: https://www.bleepingcomputer.com/news/security/runc-vulnerability-gives-attackers-root-access-on-docker-kubernetes-hosts/
  12. mover is fine for me, # grep mover /var/log/syslog Jan 26 08:05:01 husky root: mover: started Jan 26 08:14:54 husky root: mover: finished Jan 27 01:13:42 husky emhttpd: shcmd (4862): /usr/local/sbin/mover |& logger & Jan 27 01:13:42 husky root: mover: started Jan 27 01:15:52 husky root: mover: finished
  13. main announcement thread needs to be updated to point to this RC instead of rc1
  14. man you have a lot of stuff going on your box.. whats the specs? (curious how whats needed for all those dockers/vm/etc) finally got to the part in the video where you are showing the dashboard and I can see the specs there I also agree about the blue color when the switch is toggled on (ex: dockers).
  15. yes, but when you aren't on the dashboard that banner info box is nice to have. so really the redundant one is in the dashboard but it does make it nice when you want to screen shot and you dont have to include all of the window just to include the stats. you can collapse the server info box and leave it like that where it only takes up a little room.