脚本在终端与服务中运行行为不一致，WPA2连接遇本地主动断开问题

Hey there, let's break down why your WiFi connection script works perfectly in a terminal but fails with WPA2 networks when run as a service. That "local choice" deauth message usually points to differences in environment, permissions, or execution context between interactive terminal sessions and system services—here are the most actionable fixes to try:

1. Fix Command Paths & Silent Typos #

First, let's eliminate easy-to-miss issues that might be breaking the script in a service context:

• Fix the typo: You wrote killall wpa-supplicant but the correct process name is wpa_supplicant (note the underscore instead of a hyphen). This could leave old wpa_supplicant processes running, causing conflicts.
• Use absolute paths for all commands: Services have a restricted PATH variable, so relying on relative command names might fail. Update your script to use full paths:

  /usr/bin/systemctl stop dnsmasq
  /usr/bin/systemctl stop hostapd
  /usr/bin/systemctl disable hostapd
  /sbin/ifdown wlan0
  /usr/bin/killall wpa_supplicant
  /sbin/ifup --force wlan0=wlan_orange
  /usr/bin/sleep 30
  

2. Tune Your Systemd Service Configuration #

Services run in a stripped-down environment compared to your terminal. Make sure your systemd service file accounts for timing and environment needs:

• Create or update your service file (e.g., /etc/systemd/system/wifi-connect.service) with these settings:

  [Unit]
  Description=WiFi Connection Setup Script
  After=network.target
  Wants=network.target
  
  [Service]
  Type=oneshot
  ExecStart=/full/absolute/path/to/your/script.sh
  User=root
  Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  StandardOutput=journal+console  # Sends script output to logs for debugging
  
  [Install]
  WantedBy=multi-user.target
  

• Reload systemd and restart the service after changes:

  sudo systemctl daemon-reload
  sudo systemctl restart wifi-connect.service
  

3. Explicitly Control wpa_supplicant (Don't Rely on ifup) #

The ifup command can behave unpredictably in service contexts because it relies on system-wide network configs that might not be loaded properly. Replace the ifup step with explicit wpa_supplicant commands to remove ambiguity:

• Modify your script to use these lines instead of ifup --force wlan0=wlan_orange:

  # Bring up the network interface
  /sbin/ip link set wlan0 up
  # Start wpa_supplicant with your WPA2 config file (adjust path to match your system)
  /usr/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
  # Request an IP address via DHCP
  /sbin/dhclient wlan0
  

This ensures wpa_supplicant uses the exact config you expect, regardless of the service environment.

4. Check for Security Policy Restrictions #

Even as root, services can be blocked by SELinux or AppArmor from performing network operations that work in a terminal:

• Test SELinux temporarily: Disable it to rule out policy blocks:

  sudo setenforce 0
  

  If the script works after this, you'll need to create a custom SELinux policy to allow your service's network operations.
• Check AppArmor: Verify if the wpa_supplicant profile is restricting access:

  sudo aa-status | grep wpa_supplicant
  

  You can put the profile in complain mode for testing to see if it's causing issues.

5. Dig Into Logs for Detailed Clues #

Logs will almost always reveal the exact reason for the deauth. Check these sources:

• View your service's real-time logs:

  journalctl -u wifi-connect.service -f
  

• Check wpa_supplicant and kernel network logs:

  dmesg | grep wlan0
  journalctl -u wpa_supplicant.service -f
  

Look for errors like missing config files, permission denied messages, or timing issues where the interface isn't ready when the script runs.

内容的提问来源于stack exchange，提问作者ben-bibi