-----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-----

Reply via email to