[Bug 233683] IPv6 ND neighbor solicitation messages fail to arrive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233683 --- Comment #10 from Kristof Provost --- (In reply to Bjoern A. Zeeb from comment #7) > That all said, bridges used to be special wen it came to IPv6; I don't know > if this was changed in more recent times. kp@ might know. They're not really, but IPv6 depends heavily on multicast working, and that sometimes catches people out with if_bridge. If addresses are assigned to bridge members multicast will not work correctly for those addresses. IP(v6) addresses must always be assigned to the bridge itself and not to member interfaces. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255705] Routing does not honor mbuf_tag PACKET_TAG_IPFORWARD correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705 Andrey V. Elsukov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2568 ||28 -- You are receiving this mail because: You are the assignee for the bug.
Re: debugnet_any_ifnet_update: Bad dn_init result
On Mon, Feb 07, 2022 at 12:57:40PM +0100, Franco Fichtner wrote: > Hi, > > Looking at https://cgit.freebsd.org/src/commit/?h=65366903c3a29 > and seeing it is still the case in stable/13 would it make sense to > remove the printf() as it seems to be irritating users... > > debugnet_any_ifnet_update: Bad dn_init result from igb0 (ifp > 0xf80003663800), ignoring. > debugnet_any_ifnet_update: Bad dn_init result from igb1 (ifp > 0xf800038b9800), ignoring. > > So far the only reports are for igb(4). Do you have any idea what triggers the message in the first place? I haven't seen it on my igb-using systems.
Re: debugnet_any_ifnet_update: Bad dn_init result
Hi Mark, > On 28. Feb 2022, at 15:51, Mark Johnston wrote: > > Do you have any idea what triggers the message in the first place? I > haven't seen it on my igb-using systems. No but I have hardware here that does this. Short dmesg scan: # dmesg | grep igb2 igb2: port 0x4000-0x401f mem 0xf7d0-0xf7d1,0xf7d2-0xf7d23fff irq 36 at device 0.0 on pci3 igb2: NVM V0.6 imgtype6 igb2: Using 1024 TX descriptors and 1024 RX descriptors igb2: Using 4 RX queues 4 TX queues igb2: Using MSI-X interrupts with 5 vectors igb2: Ethernet address: f4:90:ea:00:2d:9d igb2: netmap queues/slots: TX 4/1024, RX 4/1024 debugnet_any_ifnet_update: Bad dn_init result from igb2 (ifp 0xf800035ea000), ignoring. Context for dn_init messages: # dmesg | grep -C1 dn_init igb0: link state changed to UP debugnet_any_ifnet_update: Bad dn_init result from igb0 (ifp 0xf80003752800), ignoring. igb1: link state changed to UP debugnet_any_ifnet_update: Bad dn_init result from igb1 (ifp 0xf800035e8800), ignoring. intsmb0: at device 20.0 on pci0 -- amdtemp0: on hostb5 debugnet_any_ifnet_update: Bad dn_init result from igb2 (ifp 0xf800035ea000), ignoring. lagg0: link state changed to DOWN It appears this happens on all interfaces that get configured during init. The device has a fourth device that doesn't appear to have this issue: # dmesg | grep igb3 igb3: port 0x6000-0x601f mem 0xf7e0-0xf7e1,0xf7e2-0xf7e23fff irq 40 at device 0.0 on pci4 igb3: NVM V0.6 imgtype6 igb3: Using 1024 TX descriptors and 1024 RX descriptors igb3: Using 4 RX queues 4 TX queues igb3: Using MSI-X interrupts with 5 vectors igb3: Ethernet address: f4:90:ea:00:2d:9e igb3: netmap queues/slots: TX 4/1024, RX 4/1024 vlan1: changing name to 'igb3_vlan43' igb3: promiscuous mode enabled Can also share full dmesg if you want or deliver other info. Cheers, Franco
DHCP Server over IPsec (may be IPsec and raw sockets issue)
Hello, I'm running FreeBSD stable/12. I'm running kea-dhcp server and strongswan. DHCP Relay packets are received over IPsec, but kea-dhcp couldn't receive packets while in "raw" socket mode. When the kea-dhcp is configured to "udp" sockets, DHCP Relay packets can be received. As you know, when dhcp server is configured to use UDP sockets, it can not receive dhcp bootp broadcasts on same local network. Both IPsec VTI mode and IPsec legacy mode behaves same way. I tried to change net.inet.ipsec.filtertunnel but didnt work. Also, I tried to work dhcp-relay and IPsec together, isc-dhcrelay daemon is forwarding requests but cannot read the received response. I think that the problem is same. As a workaround, I moved the kea-dhcp to a vnet jail that connected with an epair. IPsec is left on the parent system. With this solution, it works. But it's ugly solution. Is there any way to work IPsec and "raw" sockets together? Thank you. Regards
Re: Current with RSS and EPAIR and without INET6.
Hi there , yes good point , the first ifdef should go inside the RSS ifdef .
Will modify it to also work with INET6 only. Thanks for the feedback.
Santi
> On 28 Feb 2022, at 08:14, Zhenlei Huang wrote:
>
>
>
>>> On Feb 27, 2022, at 8:59 PM, Santiago Martinez
>>> wrote:
>>>
>>> Hi Everyone,
>>>
>>> While testing RSS and EPAIR I have find out that it is required to have
>>> kernel compiled with INET6 when enabling RSS+EPAIR.
>>>
>>> I usually remove everything that i do not use from the kernel, like SCTP
>>> and INET6, etc.
>>>
>>> After compiling with "option RSS" i noticed that iocage failed to start,
>>> checking the dmesg buffer clearly showed why.
>>>
>>> [321] link_elf_obj: symbol rss_soft_m2cpuid_v6 undefined
>>> [321] linker_load_file: /boot/kernel/if_epair.ko - unsupported file type
>>>
>>> I added two ifdef INET6 on the if_epair and solve the issue, still not sure
>>> if completely correct.
>>>
>>> Best regards.
>>>
>>> Santi
>>>
>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c
>>> index 629de981d5b0..235e5098ebd8 100644
>>> --- a/sys/net/if_epair.c
>>> +++ b/sys/net/if_epair.c
>>> @@ -74,6 +74,8 @@ __FBSDID("$FreeBSD$");
>>> #ifdef RSS
>>> #include
>>> #include
>>> +#endif
>>> +#ifdef INET6
>>> #include
>>> #endif
>>>
>> The newly added ifdef should be wrapped around by RSS.
>> And also is "opt_inet6.h" header required?
>> And maybe ifdef INET is also required as someone need IPv4 only.
>>
>> #ifdef RSS
>> #include
>> #include
>> +#ifdef INET6
>> #include
>> +#endif
>> #endif
>>
>> #include
>> @@ -220,9 +222,11 @@ epair_menq(struct mbuf *m, struct epair_softc *osc)
>>case ETHERTYPE_IP:
>>rss_soft_m2cpuid_v4(m, 0, &bucket);
>>break;
>> +#ifdef INET6
>>case ETHERTYPE_IPV6:
>>rss_soft_m2cpuid_v6(m, 0, &bucket);
>>break;
>> +#endif
>>default:
>>bucket = 0;
>>break;
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Re: Current with RSS and EPAIR and without INET6.
On 28 Feb 2022, at 21:16, Santiago Martinez wrote: > Hi there , yes good point , the first ifdef should go inside the RSS ifdef . > Will modify it to also work with INET6 only. Thanks for the feedback. > Santi > > Can you copy me on your updated patch? I’ll commit that. Thanks for finding and reporting this. Kristof
[Bug 237921] wpi: Memory leak in function wpi_free_tx_ring of sys/dev/wpi/if_wpi.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237921 Yusuf Khan changed: What|Removed |Added CC||yusisameri...@gmail.com --- Comment #4 from Yusuf Khan --- (In reply to PauAmma from comment #3) I believe that is the point of the patch, to bring over that patch designed for wpi_reset_tx_ring to wpi_free_tx_ring -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 237921] wpi: Memory leak in function wpi_free_tx_ring of sys/dev/wpi/if_wpi.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237921 --- Comment #5 from Yusuf Khan --- (In reply to Yusuf Khan from comment #4) check* not patch -- You are receiving this mail because: You are on the CC list for the bug.
