[arch-general] hostapd + ap_isolate
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi fellow-archers, I'm running a software accesspoint with hostapd for several years now. Since some weeks, clients cannot talk to each other directly anymore, also IPv6 broke (the latter might be related, but I'm currently trying to solve the former issue). Unfortunately, I cannot assure, that both happened at the same time. Also, I cannot correlate it to any updates or config changes. The tech stack is: + hostapd (spans two wifi: a normal and a guest net) + dhcpd (for ipv4) + radvd (for ipv6) + iptables (for routing) /etc/hostapd.conf: - ---8<---8<---8<--- bssid=bd:fe:0d:7e:80:37 driver=nl80211 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/run/hostapd ctrl_interface_group=0 ssid=VzEbpU-wwrtw8f country_code=DE hw_mode=g channel=6 beacon_int=100 dtim_period=2 macaddr_acl=1 accept_mac_file=/etc/hostapd/accept auth_algs=3 ignore_broadcast_ssid=0 wpa=2 wpa_psk=619f85f482f85d30ac69022edaabce188b4edb82910c1e40f40837e4e6599437 wpa_pairwise=CCMP bss=wlp0s12_0 ssid=RmH bssid=29:9a:f9:b2:d9:02 wpa=2 wpa_passphrase=K6VHcvEy wpa_pairwise=CCMP macaddr_acl=0 - --->8--->8--->8--- ipv4 works fine in the following directions: + from access point to any client and vice versa + from any client to any permitted target beyond the access point but it fails between wifi clients directly. The only config change, which I did within the last 6 months, is adding the second wifi on wlp0s12_0. However, I'm pretty sure, that at least IPv6 was not immediately broken. Ipv4-routes and -addresses on the clients look fine, tcpdump shows no packages when trying to ping other wifi clients (is it normal to not see outgoing packages in case of failure? - seems strange, but was the same, when pinging some bogus address from the access point). Originally, I added "ap_isolate=1" to the config of wlp0s12_0 to isolate guest wifi clients from each other - and I'm pretty sure, I did test it, and it did work (and did not break connectivity between wlp0s12 clients). However, during testing now, I even removed that directive without success. Does anyone have an idea, where else I could look? regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmFzIM0ACgkQCu7JB1Xa e1ozRhAAoXDEs1qUVCDQvP7o5XZlpGRi59imJH7ZhLABxiuKFZ2YhUoTHTX061lX lgbRSZMVAFEjD6x8Hz/uu0NvB+dYf/+W+cF6r2bRN8JXQ7UOb5qzN3CG9pt2H4gg reYYdwS7VH4U7WrdLZvshqRselcZ+x6c0vrpIiX8ni1c3w+hzEgsZ/1m9QMoy7DR 58xeAtkw879AxltjMyJyhYJT3CSjXzZ330sTpukpS7l9v8shs8JQteGckv0WH4q0 KAXW+H0MtXfDIJIwYDVxWV+5CzMeLLLZ5HTYz+U8mC4HZ6iNQ8FRKqJ6GZGZ/t7W MTNMt9V0qx2ewkAPll+u0JJKoVOOiMqqLPeuGwSTS4Vo5oc9tI7zmYC4GOi9Slsp 6WPoF1OT109KDvoWZS8dEadpMb9Pmv3HlWEo/0k5lydqTW3Ef/+8Etcf0YEoI5sf 1HCkntkeqLIUf6EAH0zqm+reebXXuOt5saWbmRUxGRvQijQOm6M5Q9QvoEqOMeQw fpVVH+2IAzN/m0DPvkiA/kUev2Gho2WRWCe0DvyZ15t4VzngXmvPIjO40Dh8w/Z1 N5sgRVDFATC+ciIestfKGe8anC9X3NO7xrQ+AhLIg2PXcZSkuYbpOJKWvMfCtJ91 2+gyoPqgh/6CXhR1tLa5Ttun9FbCSRVitVDmHg5JHUbhe4Zmz+4= =UNVM -----END PGP SIGNATURE-----
Erich Eckner via arch-general <arch-general@lists.archlinux.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi fellow-archers,
I'm running a software accesspoint with hostapd for several years now. Since some weeks, clients cannot talk to each other directly anymore, also IPv6 broke (the latter might be related, but I'm currently trying to solve the former issue). Unfortunately, I cannot assure, that both happened at the same time. Also, I cannot correlate it to any updates or config changes.
The tech stack is: + hostapd (spans two wifi: a normal and a guest net) + dhcpd (for ipv4) + radvd (for ipv6) + iptables (for routing)
/etc/hostapd.conf: - ---8<---8<---8<--- bssid=bd:fe:0d:7e:80:37 driver=nl80211 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/run/hostapd ctrl_interface_group=0 ssid=VzEbpU-wwrtw8f country_code=DE hw_mode=g channel=6 beacon_int=100 dtim_period=2 macaddr_acl=1 accept_mac_file=/etc/hostapd/accept auth_algs=3 ignore_broadcast_ssid=0 wpa=2 wpa_psk=619f85f482f85d30ac69022edaabce188b4edb82910c1e40f40837e4e6599437 wpa_pairwise=CCMP bss=wlp0s12_0 ssid=RmH bssid=29:9a:f9:b2:d9:02 wpa=2 wpa_passphrase=K6VHcvEy wpa_pairwise=CCMP macaddr_acl=0 - --->8--->8--->8---
ipv4 works fine in the following directions: + from access point to any client and vice versa + from any client to any permitted target beyond the access point
but it fails between wifi clients directly.
The only config change, which I did within the last 6 months, is adding the second wifi on wlp0s12_0. However, I'm pretty sure, that at least IPv6 was not immediately broken.
Ipv4-routes and -addresses on the clients look fine, tcpdump shows no packages when trying to ping other wifi clients (is it normal to not see outgoing packages in case of failure? - seems strange, but was the same, when pinging some bogus address from the access point).
Does the following quote, copied from https://wiki.archlinux.org/title/Network_Debugging#Tcpdump, relevant? they can only see outbound packets the firewall passes through: [https://superuser.com/questions/925286/does-tcpdump-bypass-iptables] Perhaps you should disable the firewall, or loosen it, while debugging. -- u34
Originally, I added "ap_isolate=1" to the config of wlp0s12_0 to isolate guest wifi clients from each other - and I'm pretty sure, I did test it, and it did work (and did not break connectivity between wlp0s12 clients). However, during testing now, I even removed that directive without success.
Does anyone have an idea, where else I could look?
regards, Erich
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmFzIM0ACgkQCu7JB1Xa e1ozRhAAoXDEs1qUVCDQvP7o5XZlpGRi59imJH7ZhLABxiuKFZ2YhUoTHTX061lX lgbRSZMVAFEjD6x8Hz/uu0NvB+dYf/+W+cF6r2bRN8JXQ7UOb5qzN3CG9pt2H4gg reYYdwS7VH4U7WrdLZvshqRselcZ+x6c0vrpIiX8ni1c3w+hzEgsZ/1m9QMoy7DR 58xeAtkw879AxltjMyJyhYJT3CSjXzZ330sTpukpS7l9v8shs8JQteGckv0WH4q0 KAXW+H0MtXfDIJIwYDVxWV+5CzMeLLLZ5HTYz+U8mC4HZ6iNQ8FRKqJ6GZGZ/t7W MTNMt9V0qx2ewkAPll+u0JJKoVOOiMqqLPeuGwSTS4Vo5oc9tI7zmYC4GOi9Slsp 6WPoF1OT109KDvoWZS8dEadpMb9Pmv3HlWEo/0k5lydqTW3Ef/+8Etcf0YEoI5sf 1HCkntkeqLIUf6EAH0zqm+reebXXuOt5saWbmRUxGRvQijQOm6M5Q9QvoEqOMeQw fpVVH+2IAzN/m0DPvkiA/kUev2Gho2WRWCe0DvyZ15t4VzngXmvPIjO40Dh8w/Z1 N5sgRVDFATC+ciIestfKGe8anC9X3NO7xrQ+AhLIg2PXcZSkuYbpOJKWvMfCtJ91 2+gyoPqgh/6CXhR1tLa5Ttun9FbCSRVitVDmHg5JHUbhe4Zmz+4= =UNVM -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 22 Oct 2021, u34--- via arch-general wrote:
Erich Eckner via arch-general <arch-general@lists.archlinux.org> wrote:
Hi fellow-archers,
I'm running a software accesspoint with hostapd for several years now. Since some weeks, clients cannot talk to each other directly anymore, also IPv6 broke (the latter might be related, but I'm currently trying to solve the former issue). Unfortunately, I cannot assure, that both happened at the same time. Also, I cannot correlate it to any updates or config changes.
The tech stack is: + hostapd (spans two wifi: a normal and a guest net) + dhcpd (for ipv4) + radvd (for ipv6) + iptables (for routing)
/etc/hostapd.conf: - ---8<---8<---8<--- bssid=bd:fe:0d:7e:80:37 driver=nl80211 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/run/hostapd ctrl_interface_group=0 ssid=VzEbpU-wwrtw8f country_code=DE hw_mode=g channel=6 beacon_int=100 dtim_period=2 macaddr_acl=1 accept_mac_file=/etc/hostapd/accept auth_algs=3 ignore_broadcast_ssid=0 wpa=2 wpa_psk=619f85f482f85d30ac69022edaabce188b4edb82910c1e40f40837e4e6599437 wpa_pairwise=CCMP bss=wlp0s12_0 ssid=RmH bssid=29:9a:f9:b2:d9:02 wpa=2 wpa_passphrase=K6VHcvEy wpa_pairwise=CCMP macaddr_acl=0 - --->8--->8--->8---
ipv4 works fine in the following directions: + from access point to any client and vice versa + from any client to any permitted target beyond the access point
but it fails between wifi clients directly.
The only config change, which I did within the last 6 months, is adding the second wifi on wlp0s12_0. However, I'm pretty sure, that at least IPv6 was not immediately broken.
Ipv4-routes and -addresses on the clients look fine, tcpdump shows no packages when trying to ping other wifi clients (is it normal to not see outgoing packages in case of failure? - seems strange, but was the same, when pinging some bogus address from the access point).
Does the following quote, copied from https://wiki.archlinux.org/title/Network_Debugging#Tcpdump, relevant?
they can only see outbound packets the firewall passes through: [https://superuser.com/questions/925286/does-tcpdump-bypass-iptables]
Perhaps you should disable the firewall, or loosen it, while debugging.
Thanks for the hint, but it does not apply: (one of) the clients doesn't even have a firewall enabled and I still cannot see the packages. To me, it looks, like it doesn't even try to send the pings, because it maybe thinks, the target is not reachable anyways ...
-- u34
regards, Erich
Originally, I added "ap_isolate=1" to the config of wlp0s12_0 to isolate guest wifi clients from each other - and I'm pretty sure, I did test it, and it did work (and did not break connectivity between wlp0s12 clients). However, during testing now, I even removed that directive without success.
Does anyone have an idea, where else I could look?
regards, Erich
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmFzpRMACgkQCu7JB1Xa e1rFNQ/9Fpa9lRESX9K1H5oGTxwycoDjBDbcK/6XM/ZZLLhSaq7amxItOPwHGFc4 7qc2Xm1gMfkNLKH4eaM1wLy65i3XbYbJrn2zXhLIK31YOxQkIBu4KmRZEdUfWBCq 3vyMLFU+xSY1vobQ6f407QEggdo5gQ+OVToRklvdDk7uDhyEL/Z7KFdXAl3DIvxq aDsWiFu87tLVYwddeeoa57pw33vLk2nJEcXeerDErCHzbOsCEGsR724BARbGVUlq WI682aVkdNKn6SSvEKZeSQ4jV7eZ1nn38ShL3gpYgMvX+ZzOYMPSMEGe7UIdFbJG Wy/v77ZG6luXSD9N+cjVZp2k9iHj0keZWqzldFjDG9UMqPugTVjdvx5F6ghrKcZL 3neZ5cVaiqHNHVIRMy2HvGo1aDglheFkYx5h0YvZ89TrIGdThEkrH5FDUNyCIhIl izcuUF/RFxfim6dBf3z+U9PgmEFkbl9IlkvFjykPrm8zMX9tfB47Ea+FeNUJ2Iev 4kVTRdnwxb37teG0kydFqKAA1qOlPbFOyV4dEERj3nHNFa6R/0E4FFEcLVLrnaaR Eh3eqFxdpZCT2ckVmh2Y6eEil5iryWmClwTPBm4/VAuqZiaALniE0eTggtnr/4E+ +4NynsYNo6XvHA8qqwZGEDHAX3ahD4jGwrZR0rHWMkMFncxxmBc= =1JhH -----END PGP SIGNATURE-----
Does the following quote, copied from https://wiki.archlinux.org/title/Network_Debugging#Tcpdump, relevant?
they can only see outbound packets the firewall passes through: [https://superuser.com/questions/925286/does-tcpdump-bypass-iptables]
Perhaps you should disable the firewall, or loosen it, while debugging.
Thanks for the hint, but it does not apply: (one of) the clients doesn't even have a firewall enabled and I still cannot see the packages. To me, it looks, like it doesn't even try to send the pings, because it maybe thinks, the target is not reachable anyways ...
From my experience, tcpdump connects to the interface and you will see all traffic regardless of firewall settings, given you have the permissions. In your case I'd first verify that layer 2 is working correctly (layer 2 is ethernet or wifi). So I'd use the utilities provided by "wpa_supplicant" or "iw" to see if the "hardware connection" is working as expected. If your wifi card didn't connect on layer 2 it has no reasons to configure layer 3 (IP, IPv6) and above. Regards, Uwe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 23 Oct 2021, Uwe Sauter via arch-general wrote:
Does the following quote, copied from https://wiki.archlinux.org/title/Network_Debugging#Tcpdump, relevant?
they can only see outbound packets the firewall passes through: [https://superuser.com/questions/925286/does-tcpdump-bypass-iptables]
Perhaps you should disable the firewall, or loosen it, while debugging.
Thanks for the hint, but it does not apply: (one of) the clients doesn't even have a firewall enabled and I still cannot see the packages. To me, it looks, like it doesn't even try to send the pings, because it maybe thinks, the target is not reachable anyways ...
From my experience, tcpdump connects to the interface and you will see all traffic regardless of firewall settings, given you have the permissions.
In your case I'd first verify that layer 2 is working correctly (layer 2 is ethernet or wifi). So I'd use the utilities provided by "wpa_supplicant" or "iw" to see if the "hardware connection" is working as expected.
If your wifi card didn't connect on layer 2 it has no reasons to configure layer 3 (IP, IPv6) and above.
Well, layer 2 works, if it is needed for connections between the client and the access point. Layer 2 should already see mac addresses, right? Can you point me to a command, which scans on layer 2 for all macs? I seem to only find how to see the available access points (which works as expected) and using nmap to ping around - which fails as expected :-/ Do you know any command to query the interface regarding routing information (similar to what `ip route` does on layer 3 for the whole machine)?
Regards,
Uwe
regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmFz824ACgkQCu7JB1Xa e1ovXA//cqmtbQ8ZqGh2PKY/ec7B3uq1EDR8iVNQR8t1BC0LFBNDFlisoeVlIm5L ULlnpdCESNIX0tDNBebj9KsXjIz2cCrrpfTkQES82ndCo+j0LIsf95ql1NBB3QA2 ZkK4IjsNsWD3D9PLVvHgwFOD+EEwY1g9i8GzB/PlE2ckBiXu4PrkG3LJ0S/5PpsS i04xfdjddXpgTyZCbbpL+33o5S+/Yw4aOdUHfbvJZUxIoj5TNidoLGA41RndNJ9/ SkUXKNw8AA1vUUgdbbo4VL9eCWJgrEe4z1HG1xbQyWKZ67NQtvnh4lLTtAqkJgoo m+Y50Wc6jP6fPAuKz8PXe+NRF4BbLpsu1dXZNqplbOeBkgpiRdrJmPn8Y7HErtEe M4o7W54ov8lBT4vsHXD9AGjYY6ododcMKvcePq3/OHh3c9dA4mJUPHYommf4izY5 4pPVLBQXqn6H0UMALXIyFBpOkPCifP1Ghl9ZW9QAoRPF1mbpuavlRBChSD2S0QRq Em8sfQH5gTJi9ykni5B5uBs4LsP9yBuerRr3hOQhi2nNUgN+agpXyfh7Jfk8yY+D oYJQ2CfNo9JFolVr0fB18Jq2O27WRsnExPMUjluTcaw8UqkgXNrdYjRG/o0+VfN3 yWjV+vaol6Oap40tIUzxBQxkxgitLUrROQnYp9MBoZ3W1rr5KXg= =czaz -----END PGP SIGNATURE-----
From my experience, tcpdump connects to the interface and you will see all traffic regardless of firewall settings, given you have the permissions.
In your case I'd first verify that layer 2 is working correctly (layer 2 is ethernet or wifi). So I'd use the utilities provided by "wpa_supplicant" or "iw" to see if the "hardware connection" is working as expected.
If your wifi card didn't connect on layer 2 it has no reasons to configure layer 3 (IP, IPv6) and above.
Well, layer 2 works, if it is needed for connections between the client and the access point.
Layer 2 should already see mac addresses, right? Can you point me to a command, which scans on layer 2 for all macs? I seem to only find how to see the available access points (which works as expected) and using nmap to ping around - which fails as expected :-/
Do you know any command to query the interface regarding routing information (similar to what `ip route` does on layer 3 for the whole machine)?
On layer 2 there is no routing. That's the reason why you need to configure a default route and possibly static routes. Unfortunately I'm not very experienced in debugging wifi but I'd probably start to investigate using some sniffer, e.g. Kismet [1] (not a recommendation, just the first reasonable search result). One hunch though: was there any update to hostapd that might have enabled WPA3? This might be the totally wrong direction but I've read on multiple occasions that old hardware (e.g. Android tablets from 2012) and WPA3-enabled APs don't work well together. Regards, Uwe [1] https://www.kismetwireless.net/
Regards,
Uwe
regards, Erich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 23 Oct 2021, Uwe Sauter wrote:
From my experience, tcpdump connects to the interface and you will see all traffic regardless of firewall settings, given you have the permissions.
In your case I'd first verify that layer 2 is working correctly (layer 2 is ethernet or wifi). So I'd use the utilities provided by "wpa_supplicant" or "iw" to see if the "hardware connection" is working as expected.
If your wifi card didn't connect on layer 2 it has no reasons to configure layer 3 (IP, IPv6) and above.
Well, layer 2 works, if it is needed for connections between the client and the access point.
Layer 2 should already see mac addresses, right? Can you point me to a command, which scans on layer 2 for all macs? I seem to only find how to see the available access points (which works as expected) and using nmap to ping around - which fails as expected :-/
Do you know any command to query the interface regarding routing information (similar to what `ip route` does on layer 3 for the whole machine)?
On layer 2 there is no routing. That's the reason why you need to configure a default route and possibly static routes.
Unfortunately I'm not very experienced in debugging wifi but I'd probably start to investigate using some sniffer, e.g. Kismet [1] (not a recommendation, just the first reasonable search result).
One hunch though: was there any update to hostapd that might have enabled WPA3? This might be the totally wrong direction but I've read on multiple occasions that old hardware (e.g. Android tablets from 2012) and WPA3-enabled APs don't work well together.
There's nothing wpa3-specific in the hostapd.conf, but I faintly remember considering to enable wpa3, but probably never actually did - and definitely not in the time range, when the inter-client communication broke. Just to be sure, I added "wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256" (e.g. no "SAE", there) to /etc/hostapd.conf without success. What I now did to make things just work, is: removing routes for 192.168.1.0/24 on wlan0 of the clients and adding a route for 192.168.1.13/32 only - so now packages use the default route "via 192.168.1.13" and traverse the access point at this address (which is also the router) and get routed on layer 3 there to the right target. (packets will be subject to firewall rules on the router, which is not a problem) Does someone have any suggestions on how to publish this route via dhcp? Currently, it looks to me, like the "192.168.1.0/24 dev wlan0" route is automatically added due to the subnet mask of "255.255.255.0" - and I probably cannot change the latter, as the dhcp server actually should server this very subnet on wifi. The dynamic part of the dhcpd.conf looks like: - ---8<---8<---8<---8<--- subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.20 192.168.1.254; option broadcast-address 192.168.1.255; option routers 192.168.1.13; option rfc3442 24, 192, 168, 0, 192, 168, 1, 13, 0, 192, 168, 1, 13; } - --->8--->8--->8--->8--- and the pseudo-static part looks like: - ---8<---8<---8<---8<--- host raspi0 { hardware ethernet de:ad:be:ef:42:42; fixed-address 192.168.1.2; option routers 192.168.1.13; option rfc3442 24, 192, 168, 0, 192, 168, 1, 13, 0, 192, 168, 1, 13; } - --->8--->8--->8--->8---
Regards,
Uwe
regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmF1FUgACgkQCu7JB1Xa e1oBpBAArlHWvLsaCsY62dzi8Zl3TdBKwqRwkVLV/oZfZQhjI3KDcjzED7Ih/mpl 8iDy+BaAqbvNM79qPwPc8rQ3eldOMEf5tyd9Y/LeefVVWwdno4Of6I0UAeXL1o8A j68fnf5kgT2J0uDwCwR+oCoxvcOE06BezPLm3acD52w2uScU0uKoJGwnKtpVSdjD sG0taHrzZPpdcUkrJYPYv3aDdDbMbcz1Vn3obg2GYKI/QBm+Q1UGqaC3buVAqJIw Z4jz8aoG0sugHuBUUXHM7LOEtaTsYu8NKRwTa1CkI6keRb3xEile1dA4jOOK5cgc kYXrI+xCLm0T3OzcGrvpz8mQCxTx2n8g0IuIIisB1Y3JlXVsiM8CvC3NsEtp+gXs dY8t12pbG65NgxrAnTYeigCDGrKwc2IxiaDE2Mhu4LyXr+CqxcLm5kBvpAxVzHOz 9aYEoRkrtIXuDBZoP2cxjQ7tAFvYID3Z14T80KDJuD9WRzNVOosSuWtAnHHPsp6o aZrNI5sp4vXkeJDdHroqI6cF0/v5a+WKoV4c87TioEq5C+xBGgGtFO32GKQ3CqGo 1OJYPUpu2jgbetDTtWbDmnzGknZw92nfB9IwI5++dY/FQj+djd5LgD5f58D60nKm kHp9cb5ZpX5jKJtEWiZJri9HaxhxXIZm9Wn0zy13uoZG8FzaPqU= =gz96 -----END PGP SIGNATURE-----
Uwe Sauter via arch-general <arch-general@lists.archlinux.org> wrote:
Does the following quote, copied from https://wiki.archlinux.org/title/Network_Debugging#Tcpdump, relevant?
they can only see outbound packets the firewall passes through: [https://superuser.com/questions/925286/does-tcpdump-bypass-iptables]
Perhaps you should disable the firewall, or loosen it, while debugging.
Thanks for the hint, but it does not apply: (one of) the clients doesn't even have a firewall enabled and I still cannot see the packages. To me, it looks, like it doesn't even try to send the pings, because it maybe thinks, the target is not reachable anyways ...
From my experience, tcpdump connects to the interface and you will see all traffic regardless of firewall settings, given you have the permissions.
In your case I'd first verify that layer 2 is working correctly (layer 2 is ethernet or wifi). So I'd use the utilities provided by "wpa_supplicant" or "iw" to see if the "hardware connection" is working as expected.
If your wifi card didn't connect on layer 2 it has no reasons to configure layer 3 (IP, IPv6) and above.
Regards,
Uwe
Is Uwe implying tcpdump can see packets local software is trying to send, but the firewall blocks? That is, packets that are blocked, for example, by rules in the output chain? As far as I know, tcpdump is probing the junction of the the nic and the wire. Packets that are blocked by firewall rules in the output chain can not reach that point. Which is why tcpdump can not see tham. With ascii graphic: [wire] <-> [tcpdump, if activated] <-> [nic] <-> [firewall] <-> [application] And somewhat more accurately: [wire] <-> [[nic front end] <-> [tcpdump, if actiavted] <-> [nic back end]] <-> [firewall] <-> [application] -- u34
Am 23.10.21 um 14:29 schrieb u34@net9.ga:
Uwe Sauter via arch-general <arch-general@lists.archlinux.org> wrote:
Does the following quote, copied from https://wiki.archlinux.org/title/Network_Debugging#Tcpdump, relevant?
they can only see outbound packets the firewall passes through: [https://superuser.com/questions/925286/does-tcpdump-bypass-iptables]
Perhaps you should disable the firewall, or loosen it, while debugging.
Thanks for the hint, but it does not apply: (one of) the clients doesn't even have a firewall enabled and I still cannot see the packages. To me, it looks, like it doesn't even try to send the pings, because it maybe thinks, the target is not reachable anyways ...
From my experience, tcpdump connects to the interface and you will see all traffic regardless of firewall settings, given you have the permissions.
In your case I'd first verify that layer 2 is working correctly (layer 2 is ethernet or wifi). So I'd use the utilities provided by "wpa_supplicant" or "iw" to see if the "hardware connection" is working as expected.
If your wifi card didn't connect on layer 2 it has no reasons to configure layer 3 (IP, IPv6) and above.
Regards,
Uwe
Is Uwe implying tcpdump can see packets local software is trying to send, but the firewall blocks? That is, packets that are blocked, for example, by rules in the output chain?
Sorry, that perhaps was poorly worded. You are totally write, if an egress packet is discarded by the output or any of the following hooks (see [1]), it will be dropped by the kernel and thus cannot be seen by tcpdump. I was referring to ingress packets that tcpdump / wireshark is able to capture before the firewall can filter. [1] https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
As far as I know, tcpdump is probing the junction of the the nic and the wire. Packets that are blocked by firewall rules in the output chain can not reach that point. Which is why tcpdump can not see tham. With ascii graphic:
[wire] <-> [tcpdump, if activated] <-> [nic] <-> [firewall] <-> [application]
And somewhat more accurately:
[wire] <-> [[nic front end] <-> [tcpdump, if actiavted] <-> [nic back end]] <-> [firewall] <-> [application]
-- u34
participants (3)
-
Erich Eckner
-
u34＠net9.ga
-
Uwe Sauter