Re: Fwd: 10-BETA : some network issues

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

Taylor R Campbell a écrit :
>> Date: Tue, 27 Dec 2022 16:07:46 +0100
>> From: BERTRAND Joël <joel.bertrand%systella.fr@localhost>
>>
>> 	I have written a mail to -users this morning and I have done some other
>> tests. I'm pretty sure that issue I see comes from network framework.
> 
> I haven't followed everything in your scenario, but:
> 
> 1. Does tcpdump on npflog0 report any packets being dropped?

	I have tried to add logging capability in /etc/npf.log (in a first time
only on rules that block packets).

legendre:[~] > ifconfig tap0
tap0: flags=0x8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0
        address: f2:0b:a4:38:bb:42
        status: no carrier
        inet6 2001:7a8:a8ed:1::2/64 flags 0x8<DETACHED>
        inet6 fe80::f00b:a4ff:fe38:bb42%tap0/64 flags 0x8<DETACHED>
scopeid 0x9
        inet 192.168.1.2/24 broadcast 192.168.1.255 flags 0x4<DETACHED>
legendre:[~] > ping rayleigh
PING rayleigh.systella.fr (192.168.254.1): 56 data bytes
^C
----rayleigh.systella.fr PING Statistics----
26 packets transmitted, 0 packets received, 100.0% packet loss
legendre:[~] >

legendre# tcpdump -n -i npflog0 | grep 192.168.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on npflog0, link-type PFLOG (OpenBSD pflog file), capture size
262144 bytes
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on npflog0, link-type PFLOG (OpenBSD pflog file), capture size
262144 bytes
^C42 packets captured
42 packets received by filter
0 packets dropped by kernel

	Of course, I have tried without grep, npflog0 doesn't show packets to
192.168.1.1

	Now, if I only check packets on VPN interface with:

group "vpn" on $tap_if {
    pass final all apply "log"
}

and if I try to send a ping packet to openvpn server (192.168.1.1) from
netbsd-10 client (192.168.1.2), tcpdump -n -i npflog0 returns:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on npflog0, link-type PFLOG (OpenBSD pflog file), capture size
262144 bytes
09:50:38.423630 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id
13761, seq 2, length 64
09:50:39.423710 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id
13761, seq 3, length 64
09:50:40.423691 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id
13761, seq 4, length 64
...

but no replay is received.

	If I try a ping from a lan1 workstation (192.168.10.103), ping runs as
expected (npflog0):

09:53:59.253864 IP 192.168.10.103 > 192.168.1.1: ICMP echo request, id
14290, seq 6, length 64
09:53:59.301315 IP 192.168.1.1 > 192.168.10.103: ICMP echo reply, id
14290, seq 6, length 64

	Now, as npflog0 shows packets that should be transmitted on tap0, I run
tcpdump -n -i tap0 when I try to ping 192.168.1.1 from netbsd client. No
ping packet is sent to 192.168.1.1 from netbsd client. Same constatation
with ping -I 192.168.1.2 192.168.1.1

> 2. Does tcpdump on any of the interfaces involved show where the
>    packet is getting dropped?

	Packets aren't dropped but are not sent on tap0.

> 3. What have you done to try to reproduce the problem on a simplified
>    configuration to narrow it down?  E.g., no bridge, no lagg, &c.
>    Can you find the part of the configuration where it ceases to work?

	I can stop bridge, but not lagg0.

>> 	First constatations: 10-BETA reboots when it tries to configure agr0
>> (it doesn't panic, only reboots).
> 
> 4. Do you have dmesg from the previous boot when this happens, or
>    serial console?

	No, sorry.

>> PS: /etc/rc.d/altqd stop doesn't run as expected. altqd only takes 100%
>> of a CPU and is not stopped after this command.
> 
> 5. Can you use crash(8) to find the kernel stack trace of the process
>    that's eating CPU?

	I will try, but only when I have to reboot this system (when this
server reboots, I have to restart all diskless workstations on lan1).

	Best regards,

	JB