[arch-general] tcpdump (was: hostapd + ap_isolate)

[u34 at net9.ga]

Uwe Sauter via arch-general <arch-general at 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