Fails to sniff packages when starting in systemd service, until systemctl restart

[sezanzeb]

Brief description

My systemd service looks something like this

[Unit]
Description=asdf

[Service]
Type=simple
ExecStart=/usr/bin/python3 -u /usr/bin/foo
Restart=on-failure

[Install]
WantedBy=graphical.target

and my usage of sniff boils down to

from scapy.sendrecv import sniff
import time
while True:
    packages = sniff(
        filter="udp portrange 2000-3000",
        timeout=2,
    )
    print(packages)
    time.sleep(10)

As far as I know WantedBy=graphical.target is the latest point at which I can start the service, still, it does not detect any traffic later when I interact with my system.

I was hoping that there is a way to make scapy reset or check for changes in network interfaces or whatever to make it work, but couldn't find anything.

As soon as I do systemctl restart asdf.service it starts detecting traffic

Adding a minute of sleep via bash -c "sleep 60 && ... also makes it work.

Scapy version

2.6.1+dfsg-1

Python version

3.13.3

Operating system

6.14.0-37-generic, Ubuntu 25.04

Additional environment information

No response

How to reproduce

see above

Actual result

doesn't capture any network traffic

Expected result

captures network traffic

Related resources

No response

[sezanzeb]

Adding this to the script to delay the scapy import makes it work for my particular use-case, but it's a really bad workaround in my opinion:

import time
import requests

class ScapyService:
    def wait_until_foo_reachable(self):
        # Because scapy fails to detect any traffic if this service starts too early,
        # wait until the network is proven to work. Some sort of internal state of
        # scapy that is constructed when it is imported.
        url = "https://foo.bar.com"
        while True:
            try:
                requests.get(url)
                print(f"Successfully reached {url}")
                return
            except requests.exceptions.ConnectionError:
                print(f"Failed to reach {url}, retrying")
                pass

            time.sleep(10)

    def sniff(self, *args, **kwargs):
        # Import scapy only after wait_until_foo_reachable!
        self.wait_until_foo_reachable()

        from scapy.sendrecv import sniff

        # future calls to .sniff use the imported function instead
        self.sniff = sniff

        return sniff(*args, **kwargs)

It seems it really is required to run this before the import. Whatever you are running when I do from scapy.sendrecv import sniff, can you please lazy load it?

The consensus is that one should not run logic in constructors: https://www.reddit.com/r/AskProgramming/comments/k6fg6z/what_is_the_proper_way_of_using_constructor_it_is/, whereas you appear to be running code when merely importing the scapy module already.

In my old code, one of the worst design choices was to have stuff happen when modules are imported, because it made writing tests almost impossible. Something like the code above can be used to avoid any module-level logic.

[polybassa]

Thanks for using scapy. However, I don't think this is an issue of scapy. I recommend to have a look on your system when in the bootup required network interfaces are configured and set to "UP".

[sezanzeb]

Of course this is an issue of scapy and its architecture. If it was better designed, the workflow would be:

• python starts
• code imports everything (Maybe the system isn't fully booted yet, that's fine)
• code does whatevever it wants for an hour
• code creates scapy object (Make it object oriented)
• scapy_object.discover() (Network interfaces are up and working at this point. It discovers interfaces and does its stuff, independent of when it was imported)
• scapy_object.sniff()
• at a later, arbitrary point, you can do scapy_object.discover() again or create a new object.

No logic should be executed when importing a package. Ever. Especially not one that interacts with the system.

Having to do crazy workarounds to get scapy to not screw it up on import is proof that this is not an adequate architecture. How is anyone supposed to use scapy in systemd services like this?

If there is a way to make scapy reset all of its internal state, please share it at least.

[gpotter2]

Hi. Please remain polite and respectful. Scapy is OpenSource software we all work on on our free time, it's not acceptable to use such a tone.

You should likely make your service wait for one of the network targets. (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/)

You can also call at anytime conf.ifaces.reload() to reload interfaces, and conf.route.resync() to reload the routes.

It would be a massive undertaking to change when Scapy loads its routes and interfaces, which would be a highly breaking change. We have no plan of doing something like that ATM.

[sezanzeb]

Please don't immediatelly dismiss and close issues I have spent hours on as an error on my side. But I apologize for my earlier harsh response.

This is the output of systemctl, and you can see that my service starts after network-online.target, configured according to the link you shared:

...
Dez 21 13:52:31 laptop systemd[1]: Reached target network-online.target - Network is Online.
Dez 21 13:52:31 laptop systemd[1]: Started update-notifier-download.timer - Download data for packages that failed at package install time.
Dez 21 13:52:31 laptop systemd[1]: Started update-notifier-motd.timer - Check to see whether there is a new version of Ubuntu available.
Dez 21 13:52:31 laptop systemd[1]: Reached target timers.target - Timer Units.
Dez 21 13:52:31 laptop systemd[1]: Started cups-browsed.service - Make remote CUPS printers available locally.
Dez 21 13:52:31 laptop systemd[1]: Starting docker.service - Docker Application Container Engine...
Dez 21 13:52:31 laptop systemd[1]: Started asdf.service - asdf
...

Still, it does not detect any traffic until restarted. But

from scapy.config import conf

...
conf.ifaces.reload()
conf.route.resync()

makes it work. Thanks.

I could do this periodically if no traffic is detected, but it would be better if there was a way to do this only if needed. Maybe when networks change or something, I don't know.