nedrysoft / pingnoo

An open-source cross-platform traceroute/ping analyser.
https://www.pingnoo.com
GNU General Public License v3.0
263 stars 26 forks source link

Debugging, PKGBUILD, Theme and issues with connection #45

Closed sxiii closed 3 years ago

sxiii commented 3 years ago

Greetings dear devs!

First, I hope you don't mind that I decided to make this combined issue, if you prefer, I can re-create separate issue for the confirmed problems as well. So. I have several questions about Pingnoo. Some of these is probably bugs:

  1. AppImage version of the program likes to drop out (close) with the following error:
    (process:3538881): GLib-ERROR **: 01:22:03.440: Creating pipes for GWakeup: Too many open files
  2. In the AppImage version, I can't find how to change the theme to dark. Is that even possible?
3. I've made this PKGBUILD to use the program in ArchLinux/Manjaro/Garuda/EndeavourOS environments: ```pkgbuild pkgname=pingnoo pkgver=2021.03.21 pkgrel=1 pkgdesc="An open-source cross-platform traceroute/ping analyser." arch=(x86_64) url="https://github.com/nedrysoft/pingnoo" license=(GPL3) depends=( cmake gcc ) provides=("${pkgname%}") build() { git clone ${url} cd pingnoo git submodule update --init --recursive mkdir build cd build cmake ../ make } package() { cd pingnoo/build make DESTDIR="$pkgdir" install sudo mkdir -p /usr/share/pingnoo sudo cp -r ../bin/x86_64/Release/* /usr/share/pingnoo } ```

The program builds and it even start with the proper dark theme. Nice.

But when press "start" button, it drops out with the following (I've run strace to see what's happening): ```bash clone(child_stack=0x7f5cd3ffedf0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[4018584], tls=0x7f5cd3fff640, child_tidptr=0x7f5cd3fff910) = 4018584 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 futex(0x55625f7e6448, FUTEX_WAKE_PRIVATE, 1) = 1 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5cd2ffe000 mprotect(0x7f5cd2fff000, 8388608, PROT_READ|PROT_WRITE) = 0 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0 clone(child_stack=0x7f5cd37fddf0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[4018585], tls=0x7f5cd37fe640, child_tidptr=0x7f5cd37fe910) = 4018585 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 futex(0x55625fd03e58, FUTEX_WAKE_PRIVATE, 1) = 1 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5cd27fd000 mprotect(0x7f5cd27fe000, 8388608, PROT_READ|PROT_WRITE) = 0 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0 clone(child_stack=0x7f5cd2ffcdf0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[4018586], tls=0x7f5cd2ffd640, child_tidptr=0x7f5cd2ffd910) = 4018586 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 futex(0x55625f7edc38, FUTEX_WAKE_PRIVATE, 1) = 1 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5cd1ffc000 mprotect(0x7f5cd1ffd000, 8388608, PROT_READ|PROT_WRITE) = 0 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0 clone(child_stack=0x7f5cd27fbdf0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[4018588], tls=0x7f5cd27fc640, child_tidptr=0x7f5cd27fc910) = 4018588 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 futex(0x55625f807258, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f5dee307a00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x7f5dee307a00, FUTEX_WAKE_PRIVATE, 1) = 0 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5cd07f9000 mprotect(0x7f5cd07fa000, 8388608, PROT_READ|PROT_WRITE) = 0 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0 clone(child_stack=0x7f5cd0ff8df0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[4018590], tls=0x7f5cd0ff9640, child_tidptr=0x7f5cd0ff9910) = 4018590 rt_sigprocmask(SIG_SETMASK, [], ) = ? +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped) ```

Probably my PKGBUILD procedure is a little bit wrong in the package() function. Can you give me a hand with these? I would be happy to build a correct PKGBUILD for your package and add it (publish) to AUR, so all users of ArchLinux, Manjaro, Garuda, ando ther Arch-based distros can benefit from that and install your cool software with just one command or even search for the program from GUI. I am also ready to become a package maintainer for ArchLinux version if you teach me how to install the program after compiling for it to correctly work (the package() function in PKGBUILD). Thanks!

  1. Last but not least, this question isn't probably fully Pingnoo dependent, however. I've found an interesting issue with my connection. I am having frequently a service drop-outs at my home internet. I do have a DOCSIS 3.1 connection and Sagemcom F@st 3890V3 device that often shows some errors in the packages. I am using AppImage version of Pingnoo for this. So interesting case arises here: a) When I run "ping executable" to 1.1.1.1 with 2.5s intervals, I got 70-80-90-98% packet loss levels at my gateway (192.168.0.1). The screen is full with red stripes. Wow! What is that? b) When I run "ICMP socket" to 1.1.1.1 with same 2.5s intervals separately, I sometimes got no packet losses at my gateway, but the other times I get same loss levels. c) When I run both of a) and b) at the same time, I get the packet loss on both tests. d) I've asked a friend with the same internet to check stuff from her side, and she send me screenshots with the same issues: error packets in the DOCSIS information page, as well as packet loss in "pings" in pingnoo. She also has same modem as me.

So it might be a provider-wide error thing or modem/DOCSIS router dependent thing? Do you see is there any way to further debug these problems? My provider just kicks me away when I'm trying to ask them (Telia/Get internet, Norway).

Thank you very much for these nice program.

fizzyade commented 3 years ago

Greetings dear devs!

First, I hope you don't mind that I decided to make this combined issue, if you prefer, I can re-create separate issue for the confirmed problems as well. So. I have several questions about Pingnoo. Some of these is probably bugs:

1. AppImage version of the program likes to drop out (close) with the following error:
(process:3538881): GLib-ERROR **: 01:22:03.440: Creating pipes for GWakeup: Too many open files

Humn, I haven't seen that, although I don't really "test" the deployed images past checking that they work. I was running it for 12 hours last night and it was just running fine. Does it happen with a non appimage version (i.e build from source)? If it's AppImage only it might be difficult to trace quickly due to the way AppImages work.

Can I also confirm that you're trying one of the latest releases, there was a leak with socket handles a while back which only really seemed to cause problems on macOS as far as I could see.

1. In the AppImage version, I can't find how to change the theme to dark. Is that even possible?

What operating system? The dark mode that's built into the app is dependant on macOS. If other operating systems support dark mode, then I can look to add the support in. There's a few instances of ThemeSupport throughout the project that would need to be modified to add the required support, as it stands if you forced it to dark mode on an OS that doesn't support dark mode then you'll end up with something that is a mix of light and dark and probably not looking very pretty.

  1. I've made this PKGBUILD to use the program in ArchLinux/Manjaro/Garuda/EndeavourOS environments:

The program builds and it even start with the proper dark theme. Nice. But when press "start" button, it drops out with the following (I've run strace to see what's happening):

Probably my PKGBUILD procedure is a little bit wrong in the package() function. Can you give me a hand with these? I would be happy to build a correct PKGBUILD for your package and add it (publish) to AUR, so all users of ArchLinux, Manjaro, Garuda, ando ther Arch-based distros can benefit from that and install your cool software with just one command or even search for the program from GUI. I am also ready to become a package maintainer for ArchLinux version if you teach me how to install the program after compiling for it to correctly work (the package() function in PKGBUILD). Thanks!

ArchLinux is not something I use, I can install a VM and take a look though. I'm not familar with PKGBUILD though, sorry.

1. Last but not least, this question isn't probably fully Pingnoo dependent, however. I've found an interesting issue with my connection. I am having frequently a service drop-outs at my home internet. I do have a DOCSIS 3.1 connection and Sagemcom F@st 3890V3 device that often shows some errors in the packages. I am using AppImage version of Pingnoo for this. So interesting case arises here:
   a) When I run "ping executable" to 1.1.1.1 with 2.5s intervals, I got 70-80-90-98% packet loss levels at my gateway (192.168.0.1). The screen is full with red stripes. Wow! What is that?
   b) When I run "ICMP socket" to 1.1.1.1 with same 2.5s intervals separately, I sometimes got no packet losses at my gateway, but the other times I get same loss levels.
   c) When I run both of a) and b) at the same time, I get the packet loss on both tests.
   d) I've asked a friend with the same internet to check stuff from her side, and she send me screenshots with the same issues: error packets in the DOCSIS information page, as well as packet loss in "pings" in pingnoo. She also has same modem as me.

This happens to be on one of the hops from my ISP, the router appears to drop packages. You can test if this is the case by opening 2 terminals in linux, and then running the following command in each:

ping -t 2 -l 1 1.1.1.1

WHere the 2 is the HOP number that you are seeing packet loss on.

If I run 1 ping, it works fine. But as soon as I add in a second ping, the hop stops responding in one of the terminals, it then does this until you stop one of the pings. Ocassionally, the timeouts witll switch between the terminals, but only 1 will respond at any given time.

So it might be a provider-wide error thing or modem/DOCSIS router dependent thing? Do you see is there any way to further debug these problems? My provider just kicks me away when I'm trying to ask them (Telia/Get internet, Norway).

I'm on DOCSIS so it's entirely possible as I see the same issue.

Thank you very much for these nice program.

No worries.

fizzyade commented 3 years ago

Just to add, it should be fairly easy to create a build environment for the application on arch. I'm just installing arch, but essentially you need to install git cmake and the qt5 development libraries. There may be a couple of other things that need installing, but it should give you enough hints during the cmake command to tell you what you need to install.

fizzyade commented 3 years ago

@sxiii You can set up an arch installation to be able to compile from scratch:

pacman --noconfirm -S wget &&
pacman --noconfirm -S git &&
pacman --noconfirm -S base-devel &&
pacman --noconfirm -S qt5-base &&
pacman --noconfirm -S qt5-tools &&
pacman --noconfirm -S qt5-quickcontrols &&
pacman --noconfirm -S dbus &&
pacman --noconfirm -S python3

cd /tmp &&
wget https://github.com/Kitware/CMake/releases/download/v3.20.0-rc2/cmake-3.20.0-rc2-linux-x86_64.sh &&
chmod +x cmake-3.20.0-rc2-linux-x86_64.sh &&
./cmake-3.20.0-rc2-linux-x86_64.sh --skip-license --prefix=/usr/local

Then in your home folder (or wherever the source is to be kept):

git clone https://github.com/nedrysoft/pingnoo
cd pingnoo
git submodule update --init --recursive
mkdir build
cd build
cmake ..
make -j4

You can set the raw socket capabilities on the generated binaries which allows you to use the better ping engine by running the following command from the root of the git clone.

sudo setcap cap_net_raw+ep ./bin/x86_64/Release/Pingnoo

And you can then run it with the following command:

./bin/x86_64/Release/Pingnoo
fizzyade commented 3 years ago

The python3 dependency is for the deployment script, if you are looking to create a packaged version of pingnoo, then you will need to study this script (and the ones in the pingnoo_support_python folder and create a new Linux deployment target of "arch".

The deployment script runs autonomously and generates the deployable image without and user interaction, everything is passed into the deploy.py via command line switches. This is because packaging for each and every platform is a time drain without doing it via the script, my CI system (TeamCity) runs every build on all target platforms and then notifies be when it's finished and supplies me with images ready to upload to GitHub, it saves me a lot of time and reduces the chance of errors.

fizzyade commented 3 years ago

I've added the instructions for arch Linux under docs/build/arch.md

fizzyade commented 3 years ago

@sxiii I've completed most of the work on the actual packaging side for arch Linux, I need to add support for it in the deployment script though.

sxiii commented 3 years ago

Humn, I haven't seen that, although I don't really "test" the deployed images past checking that they work. I was running it for 12 hours last night and it was just running fine. Does it happen with a non appimage version (i.e build from source)? If it's AppImage only it might be difficult to trace quickly due to the way AppImages work.

I've got also my AppImage working for hours. This problem actually arises if I try to run like 2 or 3 test at the same time. I haven't tested that with non-appimage version because the built-from-source version failed to even start scanning for me.

The version I'm using for all tests is Pingnoo.2021.03.21-develop.x86_64.

What operating system? The dark mode that's built into the app is dependant on macOS. If other operating systems support dark mode, then I can look to add the support in. There's a few instances of ThemeSupport throughout the project that would need to be modified to add the required support, as it stands if you forced it to dark mode on an OS that doesn't support dark mode then you'll end up with something that is a mix of light and dark and probably not looking very pretty.

Manjaro basically. But I can test as well on other Arch-based distros as well (Garuda, EndeavourOS etc.). I do have dark theme everywhere enabled by default and the compiled-from-source version appreciate that and boots dark theme MOSTLY, I think it's all dark with exception of top-ribbon.

ArchLinux is not something I use, I can install a VM and take a look though. I'm not familar with PKGBUILD though, sorry.

PKGBUILD's are basically the same as pure clean bash (scripts) with some default variables and functions, that allows all the ArchLinux (AUR) community to auto-build and pack all the programs out there. Pretty neat. Not much (if any) additional time needed to understand PKGBUILD.

This happens to be on one of the hops from my ISP, the router appears to drop packages. You can test if this is the case by opening 2 terminals in linux, and then running the following command in each:

ping -t 2 -l 1 1.1.1.1

WHere the 2 is the HOP number that you are seeing packet loss on.

If I run 1 ping, it works fine. But as soon as I add in a second ping, the hop stops responding in one of the terminals, it then does this until you stop one of the pings. Ocassionally, the timeouts witll switch between the terminals, but only 1 will respond at any given time.

Sadly, i got: Time to live exceeded at all times for -t 2 and -t 1. :D

Thanks for your fast and precious answer!

sxiii commented 3 years ago

pacman --noconfirm -S wget && pacman --noconfirm -S git && pacman --noconfirm -S base-devel && pacman --noconfirm -S qt5-base && pacman --noconfirm -S qt5-tools && pacman --noconfirm -S qt5-quickcontrols && pacman --noconfirm -S dbus && pacman --noconfirm -S python3

I think you basically can reach the same goal not doing this step by step: pacman --noconfirm -S wget git base-devel qt5-base qt5-tools qt5-quickcontrols dbus python3

Also wget, dbus and python3 are usually preinstalled out of the box (AFAIK) on Manjaro and a lot of other Arch-based distros with GUI. Python3 is default in here for long time.

UPD: Thanks for the overall instructions, I will try to incorporate the Cmake of your recommendation into PKGBUILD and see where this leads.

Thanks also for the docs and deployment script, this seems to be soon possible to add into AUR when we finish testing and then you have official support of 10+++ Arch-based distros, which are ones fastest on the market.

P.S. Additional short intro into PKGBUILD. Take any Arch-based distro. You first download the PKGBUILD file in empty directory (let's say ~/pingnoo). Enter this dir with terminal, then just run makepkg. That's it. You will receive ready .tar.zst file in case everything went fine that you could just `sudo pacman -U ./pingnooand it will install the package. When everything works, we could take this PKGBUILD, I will add some stuff and upload it to AUR. Later, all users in the world could just:yay -S pingnoo` and pingnoo's PKGBUILD will be downloaded from the AUR automatically and executed for any user who has arch-helper YAY or maybe PIKAUR or any other AUR Arch helper that user prefer, there's plenty of them. That's the flexibility and comfort. And the only thing I am uncertain right now is on the package() part which is where to put the resulting build files after successfully building. That's what is there currently:

        cd pingnoo/build
        make DESTDIR="$pkgdir" install
        sudo mkdir -p /usr/share/pingnoo
        sudo cp -r ../bin/x86_64/Release/* /usr/share/pingnoo

So basically I take all the files from bin/x86_64/Release/* and put them into new folder /usr/share/pingnoo. But I will need to research where should I actually put which files.

sxiii commented 3 years ago

Update: YAY! Thanks! Your procedure works! Probably the addition of CMake helped, but I'm not sure fully.

Here's the new PKGBUILD file anyways if you like to give it a try: ``` pkgname=pingnoo pkgver=2021.03.21 pkgrel=1 pkgdesc="An open-source cross-platform traceroute/ping analyser." arch=(x86_64) url="https://github.com/nedrysoft/pingnoo" license=(GPL3) depends=( cmake gcc wget # base-devel qt5-base qt5-tools qt5-quickcontrols dbus python3 ) provides=("${pkgname%}") build() { wget https://github.com/Kitware/CMake/releases/download/v3.20.0-rc2/cmake-3.20.0-rc2-linux-x86_64.sh chmod +x cmake-3.20.0-rc2-linux-x86_64.sh sudo ./cmake-3.20.0-rc2-linux-x86_64.sh --skip-license --prefix=/usr/local git clone ${url} cd pingnoo git submodule update --init --recursive mkdir build cd build cmake .. make -j cd .. sudo setcap cap_net_raw+ep ./bin/x86_64/Release/Pingnoo } package() { cd pingnoo/build make DESTDIR="$pkgdir" install sudo mkdir -p /usr/share/pingnoo sudo cp -r ../bin/x86_64/Release/* /usr/share/pingnoo } ```

After you put it into empty directory, go there from teminal and just makepkg (on any Arch-based distro). After compiling, we just sudo pacman -U ./pingnoo* and then we run it like this: /usr/share/pingnoo/Pingnoo. It works for me! The only issue I have, is with dark theme now (and provider, but that's different story): https://imgur.com/a/WYF3fLI

Thanks for your help. I will prepare the package information and upload the file into AUR soon, so all Arch users will benefit.

fizzyade commented 3 years ago

@sxiii thanks for that. There are a few issues with that package script (although you've got further than I did last night).

This is my PKGBUILD.

# Maintainer: Your Name <hello@nedrysoft.com>
pkgname=pingnoo
pkgver=2021.03.19
pkgver() {
  cd "$pkgname"
  git log -1 --format=%cd --date=short | sed 's/-/./g'
}
pkgrel=1
epoch=
pkgdesc="An open-source cross-platform tool for ping/traceroute analysis."
arch=('x86_64')
url="https://www.pingnoo.com"
license=('GPL')
groups=()
depends=()
makedepends=('cmake' 'base-devel' 'qt5-base' 'qt5-tools' 'qt5-quickcontrols' 'dbus')
checkdepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git" 'git submodule update --init --recursive')
noextract=()
md5sums=('SKIP')
validpgpkeys=()

prepare() {
        cd "${pkgname{}"
        git submodule update --init --recursive
}

build() {
        cmake -B build -S "${pkgname}"
        make -j4 -C build
}

check=()
package=()

A few notes from me on your script:

If you fix these things and then post the changed script, I will take a look again and give you feedback and if necessary how it worked installing on a clean arch environment.

Thanks for your efforts!

Also, to point out, you'll also need to look at deploy.py and add support for arch to it as I mentioned earlier, this is critical as it's part of the CI system for ensuring that the application compiles and packages correctly and provides me with an image that I can directly add to releases on GitHub.

There's also the issue of gpg keys, signing the package. I have the gpg keys, so will have to build and push to the arch repository myself.

fizzyade commented 3 years ago

pacman --noconfirm -S wget && pacman --noconfirm -S git && pacman --noconfirm -S base-devel && pacman --noconfirm -S qt5-base && pacman --noconfirm -S qt5-tools && pacman --noconfirm -S qt5-quickcontrols && pacman --noconfirm -S dbus && pacman --noconfirm -S python3

I think you basically can reach the same goal not doing this step by step: pacman --noconfirm -S wget git base-devel qt5-base qt5-tools qt5-quickcontrols dbus python3

Yes, you can, but for clarity these are all on their own lines, those instructions are more for my benefit than others, the instructions tell me exactly what I need to do to configure a container that is capable of building Pingnoo via my TeamCity CI server.

Also wget, dbus and python3 are usually preinstalled out of the box (AFAIK) on Manjaro and a lot of other Arch-based distros with GUI. Python3 is default in here for long time.

Don't assume anything, you need to add all dependencies otherwise somebody somewhere will say "it doesn't work". My testing environment for Arch does not have these packages installed, it's a Linux container and is the one that will be used to build the package, so those dependencies need to be there otherwise the build won't work.

UPD: Thanks for the overall instructions, I will try to incorporate the Cmake of your recommendation into PKGBUILD and see where this leads.

Thanks also for the docs and deployment script, this seems to be soon possible to add into AUR when we finish testing and then you have official support of 10+++ Arch-based distros, which are ones fastest on the market.

P.S. Additional short intro into PKGBUILD. Take any Arch-based distro. You first download the PKGBUILD file in empty directory (let's say ~/pingnoo). Enter this dir with terminal, then just run makepkg. That's it. You will receive ready .tar.zst file in case everything went fine that you could just `sudo pacman -U ./pingnooand it will install the package. When everything works, we could take this PKGBUILD, I will add some stuff and upload it to AUR. Later, all users in the world could just:yay -S pingnoo` and pingnoo's PKGBUILD will be downloaded from the AUR automatically and executed for any user who has arch-helper YAY or maybe PIKAUR or any other AUR Arch helper that user prefer, there's plenty of them. That's the flexibility and comfort. And the only thing I am uncertain right now is on the package() part which is where to put the resulting build files after successfully building. That's what is there currently:

        cd pingnoo/build
        make DESTDIR="$pkgdir" install
        sudo mkdir -p /usr/share/pingnoo
        sudo cp -r ../bin/x86_64/Release/* /usr/share/pingnoo

So basically I take all the files from bin/x86_64/Release/* and put them into new folder /usr/share/pingnoo. But I will need to research where should I actually put which files.

all files need to be where they are after the build, i.e the libraries (things like libICMPPacket and so on) live next to the Pingnoo binary. There's a folder at this level called "Components" which is where the plugins live, Pingnoo expects (on linux) that the Components folder is in the same folder as the Pingnoo executable.

Additionally (off the top of my head, you can verify this by looking in the application main.cpp) there are some other folders which it may use to check for plugins, specifically in the users home folder. This allows the user to install plugins without needing root privileges.

fizzyade commented 3 years ago

@sxiii regarding the light ribbon, what window manager are you using? If I can find out how to read the light/dark state then I can switch the GUI to use dark mode, I will have to write extra code and move themesupport into it's own library (I had plans to do this anyway) as it's duplicated in a few places.

fizzyade commented 3 years ago

Humn, I haven't seen that, although I don't really "test" the deployed images past checking that they work. I was running it for 12 hours last night and it was just running fine. Does it happen with a non appimage version (i.e build from source)? If it's AppImage only it might be difficult to trace quickly due to the way AppImages work.

I've got also my AppImage working for hours. This problem actually arises if I try to run like 2 or 3 test at the same time. I haven't tested that with non-appimage version because the built-from-source version failed to even start scanning for me.

Try with the latest source code, I have made changes to the ping engine and route engine, there were issues with the route engine when running > 2 tests which I've fixed.

The version I'm using for all tests is Pingnoo.2021.03.21-develop.x86_64.

What operating system? The dark mode that's built into the app is dependant on macOS. If other operating systems support dark mode, then I can look to add the support in. There's a few instances of ThemeSupport throughout the project that would need to be modified to add the required support, as it stands if you forced it to dark mode on an OS that doesn't support dark mode then you'll end up with something that is a mix of light and dark and probably not looking very pretty.

Manjaro basically. But I can test as well on other Arch-based distros as well (Garuda, EndeavourOS etc.). I do have dark theme everywhere enabled by default and the compiled-from-source version appreciate that and boots dark theme MOSTLY, I think it's all dark with exception of top-ribbon.

ArchLinux is not something I use, I can install a VM and take a look though. I'm not familar with PKGBUILD though, sorry.

PKGBUILD's are basically the same as pure clean bash (scripts) with some default variables and functions, that allows all the ArchLinux (AUR) community to auto-build and pack all the programs out there. Pretty neat. Not much (if any) additional time needed to understand PKGBUILD.

This happens to be on one of the hops from my ISP, the router appears to drop packages. You can test if this is the case by opening 2 terminals in linux, and then running the following command in each: ping -t 2 -l 1 1.1.1.1 WHere the 2 is the HOP number that you are seeing packet loss on. If I run 1 ping, it works fine. But as soon as I add in a second ping, the hop stops responding in one of the terminals, it then does this until you stop one of the pings. Ocassionally, the timeouts witll switch between the terminals, but only 1 will respond at any given time.

Sadly, i got: Time to live exceeded at all times for -t 2 and -t 1. :D

From you executing ping from a terminal? If so, that's your firewall dropping ICMP packets.

Thanks for your fast and precious answer!

sxiii commented 3 years ago

Hmm your PKGBUILD is way smaller and cleaner than mine...

This is mine current version: ``` # Maintainer: Den Ivanov aka sxiii pkgname=pingnoo pkgver=2021.03.21 pkgrel=1 pkgdesc="An open-source cross-platform traceroute/ping analyser." arch=(x86_64) url="https://github.com/nedrysoft/pingnoo" license=(GPL3) depends=( cmake gcc wget # base-devel qt5-base qt5-tools qt5-quickcontrols dbus python3 ) provides=("${pkgname%}") build() { wget https://github.com/Kitware/CMake/releases/download/v3.20.0-rc2/cmake-3.20.0-rc2-linux-x86_64.sh chmod +x cmake-3.20.0-rc2-linux-x86_64.sh sudo ./cmake-3.20.0-rc2-linux-x86_64.sh --skip-license --prefix=/usr/local git clone ${url} cd pingnoo git submodule update --init --recursive mkdir build cd build cmake .. make -j cd .. sudo setcap cap_net_raw+ep ./bin/x86_64/Release/Pingnoo } package() { cd pingnoo/build make DESTDIR="$pkgdir/" install # install -Dm755 "${srcdir}/${pkgname}/bin/x86_64/Release/Pingnoo" "${pkgdir}/usr/bin/${pkgname}" mkdir -p "${pkgdir}/usr/share/${pkgname}/" install -Dm755 "${srcdir}/${pkgname}/bin/x86_64/Release/Pingnoo" "${pkgdir}/usr/share/${pkgname}" cp -r ${srcdir}/${pkgname}/bin/x86_64/Release/lib* "${pkgdir}/usr/share/${pkgname}/" cp -r ${srcdir}/${pkgname}/bin/x86_64/Release/Components "${pkgdir}/usr/share/${pkgname}/" cp -r ${srcdir}/${pkgname}/bin/x86_64/Release/translations "${pkgdir}/usr/share/${pkgname}/" cp ${srcdir}/${pkgname}/bin/x86_64/Release/helper "${pkgdir}/usr/share/${pkgname}/" ln -s ${pkgdir}/usr/bin/pingnoo "${pkgdir}/usr/share/Pingnoo" } ```

I've added all the stuff and it seems it works more or less okay but yes you're right it shouldn't have sudo and there are some issues. Like I have to symlink the program myself after building, the symlink from PKGBUILD does not work for me for some reason: sudo ln -s /usr/share/pingnoo/Pingnoo /usr/bin/pingnoo.

I'd be really happy if you could push pingnoo to AUR yourself, also, please note that in this case you will also need to add .SRCINFO file in the same directory where PKGBUILD will be to successfully push everything:

pkgbase = pingnoo
    pkgver = whatever
    pkgrel = 1
    arch = x86_64
    license = GPL
    makedepends = cmake
    makedepends = git
    provides = pingnoo
    conflicts = pingnoo
    source = git+http://github.com/nedrysoft/pingnoo.git
    md5sums = SKIP

And then you could push it. I'd be happy to try & test your PKGBUILD from AUR as soon as it's ready and rate your package!

fizzyade commented 3 years ago

Hmm your PKGBUILD is way smaller and cleaner than mine... This is mine current version:

I've added all the stuff and it seems it works more or less okay but yes you're right it shouldn't have sudo and there are some issues. Like I have to symlink the program myself after building, the symlink from PKGBUILD does not work for me for some reason: sudo ln -s /usr/share/pingnoo/Pingnoo /usr/bin/pingnoo.

I'd be really happy if you could push pingnoo to AUR yourself, also, please note that in this case you will also need to add .SRCINFO file in the same directory where PKGBUILD will be to successfully push everything:

pkgbase = pingnoo
  pkgver = whatever
  pkgrel = 1
  arch = x86_64
  license = GPL
  makedepends = cmake
  makedepends = git
  provides = pingnoo
  conflicts = pingnoo
  source = git+http://github.com/nedrysoft/pingnoo.git
  md5sums = SKIP

And then you could push it. I'd be happy to try & test your PKGBUILD from AUR as soon as it's ready and rate your package!

Mine was unfinished, I hadn't done the actual packaging part only the build! 📦

There are still issues with the script you just posted, as I mentioned above, depends is wrong and makedepends is missing, cmake doesn't need to be downloaded at the build step. The version needs to be generated from git.

A mix of what I did and what you've done should give the desired result.

fizzyade commented 3 years ago

I'm also installing manjaro.

fizzyade commented 3 years ago

@sxiii I have created a branch and pushed what I've been working on.

https://github.com/nedrysoft/pingnoo/tree/feat/arch

I need to copy the desktop entries so that the resulting installation is integrated into the desktop.

fizzyade commented 3 years ago

@sxii regarding dark mode, I've created an issue. I will add support for operating systems other than macOS.

https://github.com/nedrysoft/pingnoo/issues/47

Under macOS I use the cocoa API to discover and react to theme changes, however it's much more complex on Linux, there's a hacky cheat way which I will add initially which will be labelled "System", you'll be able to select:

"System" <- hacky detection, probably will work in most situations "Light" <- force light mode "Dark" <- force dark mode

fizzyade commented 3 years ago

@sxiii btw I'm happy to give you credit for this once we've finalised it!

fizzyade commented 3 years ago

I just pushed more changes, now it creates the desktop entry so after installation it's integrated into the desktop.

sxiii commented 3 years ago

@fizzyade You're my hero :)) Thanks! I'll review your new branch right away!

sxiii commented 3 years ago

Took your first part and combined with my package(). Fixed small typos and stripped unneeded rows. Also took the Arch branch.

Here's what I got: ```PKGBUILD pkgname=pingnoo pkgver=2021.03.31 pkgver() { cd "$pkgname" git log -1 --format=%cd --date=short | sed 's/-/./g' } pkgrel=1 pkgdesc="An open-source cross-platform tool for ping/traceroute analysis." arch=('x86_64') url="https://www.pingnoo.com" license=('GPL') # had to remove base-devel, probably manjaro has a bug (it's installed but does not see it) makedepends=('cmake' 'qt5-base' 'qt5-tools' 'qt5-quickcontrols' 'dbus') provides=('pingnoo') conflicts=('pingnoo') source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git#branch=feat/arch") md5sums=('SKIP') validpgpkeys=() prepare() { cd "${pkgname}" git submodule update --init --recursive } build() { cmake -B build -S "${pkgname}" make -j4 -C build } package() { make -C build DESTDIR="$pkgdir/" install mkdir -p "${pkgdir}/usr/share/${pkgname}/" install -Dm755 "${srcdir}/${pkgname}/bin/x86_64/Release/Pingnoo" "${pkgdir}/usr/share/${pkgname}" cp -r ${srcdir}/${pkgname}/bin/x86_64/Release/* "${pkgdir}/usr/share/${pkgname}/" ln -s ${pkgdir}/usr/bin/pingnoo "${pkgdir}/usr/share/Pingnoo" } ```

Builds for me, the result is 6mb file, installs fine. No desktop icon, though. Probably last thing to improve in here (before adding to AUR) is to add removal of all the folders after we finish building the package (rm -rf src pkg pingnoo?)...

fizzyade commented 3 years ago

make install does nothing, in pingnoo "make install" creates a deploy images.

/usr/share is for data, not binaries.

You need to pull my version and try that, I tested it on manjaro, so no idea why base-devel is causing you problems.

The stuff to do with ldconfig is critical, as is pingnoo.install which invokes ldconfig and also does setcap

sxiii commented 3 years ago

make install does nothing, in pingnoo "make install" creates a deploy images.

Aha, well. Should remove that

/usr/share is for data, not binaries.

I know that. However I wasn't able to spread the files into /usr/bin/pingnoo and /usr/share/pingnoo (when I did that, the program couldn't find files and just quit).

You need to pull my version and try that, I tested it on manjaro, so no idea why base-devel is causing you problems.

Maybe I just need to update my system (doing it now).

The stuff to do with ldconfig is critical, as is pingnoo.install which invokes ldconfig and also does setcap

Ok I'll check this part right after my update finishes. Thanks!

fizzyade commented 3 years ago

make install does nothing, in pingnoo "make install" creates a deploy images.

Aha, well. Should remove that

/usr/share is for data, not binaries.

I know that. However I wasn't able to spread the files into /usr/bin/pingnoo and /usr/share/pingnoo (when I did that, the program couldn't find files and just quit).

You need to pull my version and try that, I tested it on manjaro, so no idea why base-devel is causing you problems.

Maybe I just need to update my system (doing it now).

The stuff to do with ldconfig is critical, as is pingnoo.install which invokes ldconfig and also does setcap

this is where the cmake flag -CMAKE_SKIP_RPATH comes to the rescue, along with installing pingnoo.conf and also running ldconfig after installation and uninstallation.

Ok I'll check this part right after my update finishes. Thanks!

Remove your installation of pingnoo, clone the repo and then go into pkg and run makepkg, the software should build and pop out the package.

sudo pacman -U

after which you should be able to go straight to the menu in manjaro and find pingnoo installed under internet/networking, it should launch without any issues.

I need to fix the precedence of the ping engines when ICMPPingEngine is available, currently it's always picking the command ping engine which is a workaround for AppImage really.

Let me know how you get on.

sxiii commented 3 years ago

Let me know how you get on. Compiled OK until the package() stage, and then:

==> Starting package()...
cp: cannot stat 'pingnoo/pkg/pingnoo.conf': No such file or directory
fizzyade commented 3 years ago

it's because it's not in the master branch, go into your clone, then edit the PKGBUILD file:

source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git")

should be:

source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git#branch=feat/arch")

This is purely an issue because I haven't merged the branch in so it pulls from develop but the extra files aren't in develop, just modifying that file to pull from the right branch should fix it.

sxiii commented 3 years ago

it's because it's not in the master branch, go into your clone, then edit the PKGBUILD file:

source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git")

should be:

source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git#branch=feat/arch")

This is purely an issue because I haven't merged the branch in so it pulls from develop but the extra files aren't in develop, just modifying that file to pull from the right branch should fix it.

Yes I was doing this first with my test file and then forgot to fix in your file, LOL.

sxiii commented 3 years ago

Yes, done again from scratch with only branch fix, that works. Icon and everything. :) Both ICMP and Ping scanning, without root, too.

The only thing that's left is the dark theme and then I just need to start finally analyze the results I get.

Thanks again for the nice work! Hope this will be pushed to the main repo as well as AUR pretty soon! (By the way, you can add the desktop icon and all the additional files in the AUR repo for pingnoo as well).

sxiii commented 3 years ago

About pings: got TTL exceeded on all hops (when pinging 1.1.1.1 I have a total of 6) from 1 to 5 (sudo ping -t 1 -l 1 1.1.1.1 to sudo ping -t 5 -l 1 1.1.1.1 shows TTL exceeded), but when I'm doing it with the target 1.1.1.1 (sudo ping -t 6 -l 1 1.1.1.1), it gets normal output:

[sa@alienware17 ~]$ sudo ping -t 6 -l 1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=9.09 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=8.70 ms

Also, with latest version, got no packet loss shown (tested for several minutes to an hour or so) to 1.1.1.1, but when I replace it with a domain like yandex.ru, I got 50%-60% losses at my gateway, back again. And same stands when I try hostname of 1.1.1.1, which is "one.one.one.one", I got 100% losses. WEIRD! Might that be KINDA DNS issue? o__o

fizzyade commented 3 years ago

About pings: got TTL exceeded on all hops (when pinging 1.1.1.1 I have a total of 6) from 1 to 5 (sudo ping -t 1 -l 1 1.1.1.1 to sudo ping -t 5 -l 1 1.1.1.1 shows TTL exceeded), but when I'm doing it with the target 1.1.1.1 (sudo ping -t 6 -l 1 1.1.1.1), it gets normal output:

[sa@alienware17 ~]$ sudo ping -t 6 -l 1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=9.09 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=8.70 ms

Also, with latest version, got no packet loss shown (tested for several minutes to an hour or so) to 1.1.1.1, but when I replace it with a domain like yandex.ru, I got 50%-60% losses at my gateway, back again.

ttl exceeded is exactly what you expect to get (or no reply). the -t switch sets the maximum ttl, it's how it figures out the route. To figure out the route and to calculate the latency to a target, we ping the destination with the ttl set to the hop number, we either get a reply of ttl exceeded which tells us the IP of the router at that hop + the round trip time to that hop or we get no reply, in which case that hop is dropping ICMP packets.

sxiii commented 3 years ago

ttl exceeded is exactly what you expect to get (or no reply). the -t switch sets the maximum ttl, it's how it figures out the route. To figure out the route and to calculate the latency to a target, we ping the destination with the ttl set to the hop number, we either get a reply of ttl exceeded which tells us the IP of the router at that hop + the round trip time to that hop or we get no reply, in which case that hop is dropping ICMP packets.

Ok, so there's no issue then in here with that. But why the "1.1.1.1" has no losses while "one.one.one.one" hostname has 100% losses, or yandex.ru has 50-70% losses, is still a riddle to me. Interestingly, when I do mtr 1.1.1.1, it still shows 40-50-60% losses at my gateway.

fizzyade commented 3 years ago

I don't know. pingnoo doesn't care, it does a DNS lookup and then uses the IP address, tracing to 1.1.1.1 or one.one.one.one is exactly the same, no difference.

I will try to add support for dark mode on Linux this evening.

sxiii commented 3 years ago

Thank you @fizzyade you're really knowledgeable and helpful and you do things fast. :) Really eager to try the dark mode when it will be ready and the AUR version. :) BTW, I like the Kdenlive approach on the themes: it "follows" with it having the system theme, but there's also a submenu that allows me to still switch themes. That's nice.

fizzyade commented 3 years ago

Thank you @fizzyade you're really knowledgeable and helpful and you do things fast. :) Really eager to try the dark mode when it will be ready and the AUR version. :) BTW, I like the Kdenlive approach on the themes: it "follows" with it having the system theme, but there's also a submenu that allows me to still switch themes. That's nice.

A quick hack.

image
fizzyade commented 3 years ago

@sxiii there is a branch feat/darkmode

clone and compile this version. In order to get the dark mode working properly, you will need to add -style=gtk2 to the command line when you launch Pingnoo.

/usr/local/bin/pingnoo/Pingnoo -style=gtk2

It should hopefully look ok (I haven't tested on manjaro, only on Ubuntu). I need to figure out some stuff with selecting the qt style, on my ubuntu if I use -style=gtk2 then Qt crashes, I have to use -style=qt5ct which does work on Ubuntu, but not on manjaro!

It also may not correctly switch colors when the theme is changed while the application is running.

fizzyade commented 3 years ago

The latest push should try to select the gtk2 theme without having to do the above steps.

sxiii commented 3 years ago

@fizzyade fetched the feat/darkmode branch, compiled successfully, and tried to run from the pingnoo/bin/x86_64/Release but then:

"The application does not have a main window, exiting. (please check Components are installed correctly)"

However components are in place. Thought also about taking two branches (feat/arch and feat/darkmode) but I'm frankly don't know how to combine them both into one...

[sa@alienware17 Release]$ ./Pingnoo -style=qt5ct
QApplication: invalid style override 'qt5ct' passed, ignoring it.
    Available styles: bb10dark, bb10bright, kvantum-dark, kvantum, cleanlooks, gtk2, cde, motif, plastique, qt5ct-style, Windows, Fusion
"The application does not have a main window, exiting. (please check Components are installed correctly)"
fizzyade commented 3 years ago

from terminal:

export QT_QPA_PLATFORMTHEME=gtk2 ./Pingnoo

i don’t know why you can’t run it.

fizzyade commented 3 years ago

feat/arch only contains the stuff for packaging, there is no other changes that are relevant in that branch.

fizzyade commented 3 years ago

I have been unwell today, but I just pulled the code on manjaro, compiled and ran it and dark mode worked as expected.

(there are a few text and control rendering issues, spacing and sizing is wrong)

image
fizzyade commented 3 years ago

I have merged the darkmode and arch branches into develop and created an arch test package.

https://github.com/nedrysoft/pingnoo/releases/tag/2021.04.03

for some reason, the dark mode doesn't activate as expected, but this version does fix the half dark/half light mode that was occurring in previous releases when the OS was set to a dark theme.

you can force it to use the system theme by launching it:

/usr/local/bin/pingnoo/Pingnoo --style=gtk2

and/or right click on the icon in the launcher menu, select Edit Application... and then add:

--style=gtk2

after the application executable, so it reads:

/usr/local/bin/pingnoo/Pingnoo --style=gtk2

It should then launch in dark mode (or light if the OS theme is set).

The repo is also set up with my deployment script which creates the package, the PKGBUILD file is actually a template now (PKGBUILD.in) and deploy.py uses the template to generate the correct PKGBUILD file with version, architecture and dependencies which are discovered by the script.

fizzyade commented 3 years ago

I will sort out the AUR today.

fizzyade commented 3 years ago

Should now be available in the AUR.

sxiii commented 3 years ago

Hi @fizzyade !

Thank you very much for your nice work! Just fetched it from AUR and it compiled without any issues.

However, there's several issues, still:

As for dark theme, it seems to be working ok but hard to know without program correctly working :)

I will test as well from a different laptop and installation to see if the issue is only on my local machine here or everywhere.

Thanks. Den

fizzyade commented 3 years ago

@sxiii argh, I know what's going on 0.0.0, the cmake build assumes that the code is checked out from git where in this case it isn't. I'll figure out the best way of fixing this and let you know when there's a fix.

Sorry. I switched from git to tarball because of comments on the arch repo, but it's broken the build.

fizzyade commented 3 years ago

@sxii yeah and because it's 0.0.0 all the components other than core fail to load because they need a later version than that.

fizzyade commented 3 years ago

@sxii should be working now.

sxiii commented 3 years ago

@fizzyade tested everything, running for over an hour, no issues. Dark theme works perfectly. Happy to see everything spins! :) 👍🏻

fizzyade commented 3 years ago

Awesome. I'm going to close this issue now, if you have any other issues related to this then feel free to re-open it.

Any other issues, thoughts, ideas etc open a new issue.

Thanks for your feedback/help/testing on this.