• This is in a VM, 64 bit, version 20151009_1400

    The picture widget shows a "missing photo" type image if no photo is chosen.

    If you click that photo, it downloads a zero-byte "picture.widget.php" file.

    I would expect some default photo, or nothing with a message that one needs to be uploaded.

    Additionally, I uploaded a test jpg but it failed. Now, it was the first one available in my pictures folder and was 3.6 MB, but if there are limits, it should be noted near the file picker.
    The failure was the "data not received" error that I received when first attempting to restore RRD data. Basically the connection timing out, it seems.

    I attempted the upload again, but it still didn't work.

  • Developer Netgate

    Thank for reporting. I'll take a look.

  • Small update:

    Not the most comprehensive test, but uploading a different file worked fine. I say not most comprehensive because it was a different format (PNG) and also much smaller (60KB).

    However, it did display and it remained constrained to the proper section. So there must be a time-out I'm hitting, which just isn't being handled, or some size limit.

    If I can test anything further, let me know.

  • Developer Netgate

    This is a spectacularly small piece of code :)

    I don't see any intentional limits, but doing a base64 encode in memory may be a factor. I'll put some error checking around that.

    The picture is stored in the config.xml file in Base64 format. Perhaps you could take a look in that file and see how it looks. The xml tag is <widget>/ <picturewidget>How much free memory does your dashboard show?

    I tested with a 4 MiB jpg and it worked correctly.

    Thank for your help.</picturewidget></widget>

  • Alright, I'm on 20151010_0904 now, fresh install.

    I chose the 3.6 MB photo and it didn't upload. Although this time it did not fail/timeout.
    I checked the config.xml in the /conf folder (let me know if that's not the right one).
    No mention of picture widget tag anywhere.

    I added the small png file, checked the conf and it shows the <picturewidget>and <picturewidget_filename>tags (as well as expected data).
    That file still works fine.

    I tried the upload of the larger jpg again. It worked this time.

    I'm going to attempt to duplicate it again by editing the conf file and removing the picture widget entries. (EDIT: I chose to restore the previous config, via console, instead of manually editing.

    Also, I would suggest moving the "New Picture" section above the existing picture, if one exists. Basically, have it directly below the title bar of the widget, so you see it appear when you click the wrench/edit icon.

    Restored the previous config from the console, no picture in the widget (as expected), chose the large file again, this time it worked.

    I'm not sure what the difference is in my testing. I'll see if I can reproduce it later.

    Also, dashboard shows this for memory:
    11% of 4058 MB

    Update 2:
    I went back to an even older config, rebooted, and tried the large upload again. It worked again, so I'm stumped. It did take a long time, but that could be something odd with my VM networking setup.

    If I get some free time, I'll install fresh again and test it. If nothing else, I'll try to remember to test it the next time I install fresh for any other reason.</picturewidget_filename></picturewidget>

  • Alright, I decided to try the factory defaults option from the GUI instead of a fresh install.

    After the reboot, I went through the wizard (the only things I changed were timezone, unchecked the box which blocks local networks on the WAN, and changed the password).
    Then I attempted the large picture upload again. It failed with a timeout error. When I refreshed the page, I had a notification about a crash report.
    I'm not sure if they were related, but I just submitted the report now. Hopefully it's helpful, either way.

    After submitting the report, I tried the large picture upload again and it appears to have failed again. The dashboard never showed more than 6% memory usage.
    I also checked via the console, using top, and everything looked fine. Only a few percent for cpu usage here and there, and memory usage seemed to match the dashboard.

    I'll have to see if there's some issue with the networking, but even if it were really slow I'd just expect it to take a long time but finish. If it is slow, I must be hitting some timeout threshold. Everything else about the GUI is very quick to respond though, so I find it odd that I would have troubles uploading a file that is 3.6mb.

    When I restored my RRD data, it is roughly 3 MB and seemed to have no issues at all.

    Quick follow-up: I just posted this reply and then checked the system. I noticed that it rebooted while I was typing. Yet the page still appears to be uploading.

    I reset to defaults again, tried again and it still timed out. I'm not going to test this too much more as it definitely isn't a critical feature.
    But I wanted to update that it seems to fail for me on a fresh config. If I upload a small file, then upload the big one, it works.
    It still takes a while, so maybe it's a networking issue on my end, or something on the server side, or a combination that just doesn't play nicely together.
    If someone can re-produce it, maybe it will be something that can get fixed. Otherwise at least there is a work-around if someone has issues.

  • @i814u2:

    I chose the 3.6 MB photo and it didn't upload.

    Khm… why on earth would anyone want to upload a 3.6MB photo (~15 Megapixels worth) to a firewall's dashboard?
    My approach would be to set up a limit, say 256kB for such things.

  • @robi:


    I chose the 3.6 MB photo and it didn't upload.

    Khm… why on earth would anyone want to upload a 3.6MB photo (~15 Megapixels worth) to a firewall's dashboard?
    My approach would be to set up a limit, say 256kB for such things.

    Yep, normally I personally wouldn't. But it was the first image file I navigated to, so I chose it just to test the feature. When it failed, I figured I would mention it.
    Setting a limit would make sense, as long as it is displayed to the user.