Re: ix(4) stopped working after upgrade to OpenBSD 6.8
On Sun, Jan 16, 2022 at 4:46 PM Stuart Henderson wrote: > Do both ix0 and ix1 break, or just ix1? > > One important difference visible in dmesg is that ix starts using MSI-X. > Some time ago, I noticed that ix1 isn't usable. I don't think it even shows up in ifconfig -a on OpenBSD 6.7. I didn't worry much about it because I was only using ix0, but it could be a clue. I'm going to see if I can get the patch working that Patrick sent to the list recently.
Re: ix(4) stopped working after upgrade to OpenBSD 6.8
Am Sun, Jan 16, 2022 at 06:38:08PM - schrieb Stuart Henderson:
> On 2022-01-16, Ax0n wrote:
> > I have a SuperMicro X9DRH-7TF that's been chugging along diligently in a
> > data center. I've been upgrading the vmm instances it hosts but I let the
> > host get pretty far behind. After running sysupgrade to 6.8, the system
> > never came back online. I have the Supermicro BMC IPMI, so I used that to
> > mount remote CD-ROMs to complete the upgrade to 6.9 and 7.0. The network
> > still doesn't work, from the install images or after it's been upgraded.
> > There have been "mem address conflict" messages on this hardware for as
> > long as I can remember. OpenBSD 6.4 at least. They may or may not be a red
> > herring.
> >
> > I mounted the OpenBSD 6.7 cd67.iso and I was able to get it on the network
> > again. Somewhere between 6.7 and 6.8, ix(4) broke with this hardware, an
> > integrated dual-port Intel X540.
>
> Do both ix0 and ix1 break, or just ix1?
>
> One important difference visible in dmesg is that ix starts using MSI-X.
Can you give this a go? I remember issues with broken MSI-X bars or so,
but that was on some Ryzen.
Patrick
diff --git a/sys/arch/amd64/pci/pci_machdep.c b/sys/arch/amd64/pci/pci_machdep.c
index 72456c32829..1cdc33757ee 100644
--- a/sys/arch/amd64/pci/pci_machdep.c
+++ b/sys/arch/amd64/pci/pci_machdep.c
@@ -96,6 +96,8 @@
#include
#endif
+intpci_check_msix_bar(pci_chipset_tag_t, pcitag_t);
+
/*
* Memory Mapped Configuration space access.
*
@@ -497,6 +499,36 @@ msix_delroute(struct pic *pic, struct cpu_info *ci, int
pin, int vec, int type)
pci_msix_table_unmap(pc, tag, memt, memh);
}
+/*
+ * BIOS assigns BAR addresses for every PCI device, but some BIOS are bugged
and
+ * map an illegal address, say for instance an address outside the ppb(4)
range.
+ * When this occurs, OpenBSD rewrites the BAR address as 0.
+ * This BAR might be the MSI-X BAR, therefore we consider address 0 as a bad
BAR
+ * address and fail MSI-X mapping. It's not greatest solution but since we
+ * never correct bad addresses for BARs, this at least prevents us from using
+ * MSI-X when we know it won't work.
+ */
+int
+pci_check_msix_bar(pci_chipset_tag_t pc, pcitag_t tag)
+{
+ pcireg_t table;
+ bus_addr_t base;
+ int bir, off;
+
+ if (pci_get_capability(pc, tag, PCI_CAP_MSIX, , NULL) == 0)
+ return (ENODEV);
+
+ table = pci_conf_read(pc, tag, off + PCI_MSIX_TABLE);
+ bir = (table & PCI_MSIX_TABLE_BIR);
+ bir = PCI_MAPREG_START + bir * 4;
+
+ if (pci_mem_find(pc, tag, bir, , NULL, NULL) ||
+ base == 0)
+ return (ENODEV);
+
+ return (0);
+}
+
int
pci_intr_map_msix(struct pci_attach_args *pa, int vec, pci_intr_handle_t *ihp)
{
@@ -507,7 +539,8 @@ pci_intr_map_msix(struct pci_attach_args *pa, int vec,
pci_intr_handle_t *ihp)
KASSERT(PCI_MSIX_VEC(vec) == vec);
if ((pa->pa_flags & PCI_FLAGS_MSI_ENABLED) == 0 || mp_busses == NULL ||
- pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0)
+ (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0) ||
+ pci_check_msix_bar(pc, tag))
return 1;
if (vec > PCI_MSIX_MC_TBLSZ(reg))
diff --git a/sys/dev/pci/pci_map.c b/sys/dev/pci/pci_map.c
index 3cc0e61c0df..9567e83c363 100644
--- a/sys/dev/pci/pci_map.c
+++ b/sys/dev/pci/pci_map.c
@@ -135,7 +135,12 @@ obsd_pci_mem_find(pci_chipset_tag_t pc, pcitag_t tag, int
reg, pcireg_t type,
u_int64_t waddress, wmask;
int s, is64bit;
- is64bit = (PCI_MAPREG_MEM_TYPE(type) == PCI_MAPREG_MEM_TYPE_64BIT);
+ if (type == -1)
+ is64bit = (PCI_MAPREG_MEM_TYPE(pci_conf_read(pc, tag, reg))
+ == PCI_MAPREG_MEM_TYPE_64BIT);
+ else
+ is64bit = (PCI_MAPREG_MEM_TYPE(type) ==
+ PCI_MAPREG_MEM_TYPE_64BIT);
if (reg < PCI_MAPREG_START ||
#if 0
Re: AX210 wifi
holy crap, rather than maintain the drivers and net80211 layer, they are just building compat for the linux version? i guess this approach seems very rational for something as large as amdgpu... stefan, your commits help to demystify more 802.11 chips and system for me. over the years, hundreds of hours of hard-fought understanding of these things until they become your second nature, all condensed into each commit. it's very educational from my point of view. Stefan Sperling [s...@stsp.name] wrote: > On Sun, Jan 16, 2022 at 05:51:03PM +0300, Alex Beakes wrote: > > FreeBSD has tested iwlwifi with Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420. > > Wifi 6E, ty-a0-gf-a0-63.ucode. > > > > Is there a way of implementing this and making the wifi module work. > > > > https://wiki.freebsd.org/WiFi/Iwlwifi > > I will likely work on AX210 suport sometimebut this year. > If anyone else has already done work on this and can provide working diffs > against the OpenBSD drivers I would be happy to review them. > > Since FreeBSD has decided to no longer help with developing iwm or iwx > drivers, but implement a completely different approach instead, there is > no chance of cross-polination between the projects to make this any easier.
Re: GRE IP6/IP6 not working as soon as pf is enabled
yes, thats correct and just to make sure you got my last email. I was able to fix my issue inthe meantime by adding allow-opts > On 16. Jan 2022, at 12:40, David Gwynne wrote: > > you've set the net.inet.gre.allow sysctl to 1, right? > >> On 16 Jan 2022, at 17:05, Markus Wipp wrote: >> >> Hi David, >> >> First of all thank you so much taking the time for my question! >> >>> My first impression is that you're confusing where to apply policy to >>> the encapsulated traffic. "pass on gre proto gre" implies you're >>> trying to pass GRE packets as they go over gre(4) interfaces, but >>> it's the unencapsulated packets that go over gre(4), and the GRE >>> encapsulated packets will go over your "underlay" or physical >>> interfaces, which looks like em0 according to tcpdump. >> >> Yes, it might be that I’m a little bit confused right now, after all the >> “Experiments” I already did to make this work. >> >>> Your pass rule should let everything work though. Those two rules are >>> your entire ruleset? >> >> Yes, those two rules are all I have (I reduced my whole rule set to this to >> sort out things) >> In the meantime I changed it to the following as per your and Georgs >> suggestion. >> >> In file: >> pass log (all, to pflog0) >> # pass the GRE encapsulated traffic >> pass inet6 proto gre >> # let ping6 over gre(4) work >> pass on gre inet6 proto icmp6 >> #pass on gre proto gre no state >> >> >> doas pfctl -s rules >> pass log (all) all flags S/SA >> pass inet6 proto gre all >> pass on gre inet6 proto ipv6-icmp all >> >> With these rules I get, so at least I can see the reply on em0: >> >> doas tcpdump -nvei em0 ip6 or icmp6 or proto gre >> tcpdump: listening on em0, link-type EN10MB >> 07:54:28.107820 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: >> 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd >> 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:597c >> seq:0) (len 64, hlim 64) [flowlabel 0x71e6] (len 108, hlim 64) >> 07:54:28.156366 34:81:c4:e0:4b:79 00:0d:b9:44:ec:dc 86dd 170: >> 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) >> gre [] 86dd 2a01:qqq::ss::1 > 2a01:qqq::ss::2: icmp6: echo reply >> (id:597c seq:0) [flowlabel 0xa8f7b] (len 64, hlim 64) [flowlabel 0xa8f7b] >> (len 116, hlim 243) >> 07:54:29.109744 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: >> 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd >> 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:597c >> seq:1) (len 64, hlim 64) [flowlabel 0x71e6] (len 108, hlim 64) >> 07:54:29.166480 34:81:c4:e0:4b:79 00:0d:b9:44:ec:dc 86dd 170: >> 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) >> gre [] 86dd 2a01:qqq::ss::1 > 2a01:qqq::ss::2: icmp6: echo reply >> (id:597c seq:1) [flowlabel 0xa8f7b] (len 64, hlim 64) [flowlabel 0xa8f7b] >> (len 116, hlim 243) >> 07:54:30.110067 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: >> 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd >> 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:597c >> seq:2) (len 64, hlim 64) [flowlabel 0x71e6] (len 108, hlim 64) >> 07:54:30.156013 34:81:c4:e0:4b:79 00:0d:b9:44:ec:dc 86dd 170: >> 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) >> gre [] 86dd 2a01:qqq::ss::1 > 2a01:qqq::ss::2: icmp6: echo reply >> (id:597c seq:2) [flowlabel 0xa8f7b] (len 64, hlim 64) [flowlabel 0xa8f7b] >> (len 116, hlim 243) >> >> Unfortunately it never reaches gre0: >> >> doas tcpdump -nvei gre1051 ip6 or icmp6 or proto gre >> tcpdump: listening on gre1051, link-type LOOP >> 07:54:28.107741 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo >> request (id:597c seq:0) [icmp6 cksum ok] (len 64, hlim 64) >> 07:54:29.109675 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo >> request (id:597c seq:1) [icmp6 cksum ok] (len 64, hlim 64) >> 07:54:30.110004 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo >> request (id:597c seq:2) [icmp6 cksum ok] (len 64, hlim 64) >> >> >>> The bare "pass" rule not letting this work makes me feel like there's >>> more to this though. >> >> Yes, I also think that there must be more to it, but I just don’t see the >> trees for the forrest here. >> >> Thanks >> Markus >> >
Re: GRE IP6/IP6 not working as soon as pf is enabled
you've set the net.inet.gre.allow sysctl to 1, right? > On 16 Jan 2022, at 17:05, Markus Wipp wrote: > > Hi David, > > First of all thank you so much taking the time for my question! > >> My first impression is that you're confusing where to apply policy to >> the encapsulated traffic. "pass on gre proto gre" implies you're >> trying to pass GRE packets as they go over gre(4) interfaces, but >> it's the unencapsulated packets that go over gre(4), and the GRE >> encapsulated packets will go over your "underlay" or physical >> interfaces, which looks like em0 according to tcpdump. > > Yes, it might be that I’m a little bit confused right now, after all the > “Experiments” I already did to make this work. > >> Your pass rule should let everything work though. Those two rules are >> your entire ruleset? > > Yes, those two rules are all I have (I reduced my whole rule set to this to > sort out things) > In the meantime I changed it to the following as per your and Georgs > suggestion. > > In file: > pass log (all, to pflog0) > # pass the GRE encapsulated traffic > pass inet6 proto gre > # let ping6 over gre(4) work > pass on gre inet6 proto icmp6 > #pass on gre proto gre no state > > > doas pfctl -s rules > pass log (all) all flags S/SA > pass inet6 proto gre all > pass on gre inet6 proto ipv6-icmp all > > With these rules I get, so at least I can see the reply on em0: > > doas tcpdump -nvei em0 ip6 or icmp6 or proto gre > tcpdump: listening on em0, link-type EN10MB > 07:54:28.107820 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: > 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd > 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:597c > seq:0) (len 64, hlim 64) [flowlabel 0x71e6] (len 108, hlim 64) > 07:54:28.156366 34:81:c4:e0:4b:79 00:0d:b9:44:ec:dc 86dd 170: > 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) gre > [] 86dd 2a01:qqq::ss::1 > 2a01:qqq::ss::2: icmp6: echo reply (id:597c > seq:0) [flowlabel 0xa8f7b] (len 64, hlim 64) [flowlabel 0xa8f7b] (len 116, > hlim 243) > 07:54:29.109744 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: > 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd > 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:597c > seq:1) (len 64, hlim 64) [flowlabel 0x71e6] (len 108, hlim 64) > 07:54:29.166480 34:81:c4:e0:4b:79 00:0d:b9:44:ec:dc 86dd 170: > 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) gre > [] 86dd 2a01:qqq::ss::1 > 2a01:qqq::ss::2: icmp6: echo reply (id:597c > seq:1) [flowlabel 0xa8f7b] (len 64, hlim 64) [flowlabel 0xa8f7b] (len 116, > hlim 243) > 07:54:30.110067 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: > 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd > 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:597c > seq:2) (len 64, hlim 64) [flowlabel 0x71e6] (len 108, hlim 64) > 07:54:30.156013 34:81:c4:e0:4b:79 00:0d:b9:44:ec:dc 86dd 170: > 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) gre > [] 86dd 2a01:qqq::ss::1 > 2a01:qqq::ss::2: icmp6: echo reply (id:597c > seq:2) [flowlabel 0xa8f7b] (len 64, hlim 64) [flowlabel 0xa8f7b] (len 116, > hlim 243) > > Unfortunately it never reaches gre0: > > doas tcpdump -nvei gre1051 ip6 or icmp6 or proto gre > tcpdump: listening on gre1051, link-type LOOP > 07:54:28.107741 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo > request (id:597c seq:0) [icmp6 cksum ok] (len 64, hlim 64) > 07:54:29.109675 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo > request (id:597c seq:1) [icmp6 cksum ok] (len 64, hlim 64) > 07:54:30.110004 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo > request (id:597c seq:2) [icmp6 cksum ok] (len 64, hlim 64) > > >> The bare "pass" rule not letting this work makes me feel like there's >> more to this though. > > Yes, I also think that there must be more to it, but I just don’t see the > trees for the forrest here. > > Thanks > Markus >
Fwd: GRE IP6/IP6 not working as soon as pf is enabled
Hi all, I got this information from Peter, which did the trick! I now have my complete rule-set with a block default policy working! Thanks to David and Georg as well for their help! Best regards Markus > Begin forwarded message: > > From: "Peter J. Philipp" > Subject: Re: GRE IP6/IP6 not working as soon as pf is enabled > Date: 16. January 2022 at 08:03:39 CET > To: Markus Wipp > > Hi, > > You look like you might understand german so I have a german link for you: > > https://wiki.freifunk-franken.de/w/Benutzer:PeterPhilipp#GRE_konfigurieren_mit_pf_trick > > It seems that when the remote end is Linux that they put in an intermediate > header with an empty option into the GRE packet. The "allow-opts" option > should pass this in pf. > > Wish you best of luck! > > -peter > > On Sat, Jan 15, 2022 at 08:10:44PM +0100, Markus Wipp wrote: >> Hi all, >> >> This is my first mail to an OpenBSD list, so I hope I chose the correct one. >> >> I???m trying to get a GRE tunnel in combination with pf working a few days >> now >> on my OpenBSD (OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021) >> >> If I disable pf with pfctl -d the connection is working and I can ping. >> However as soon as I enable pf with pfctl -e the ping stops working (even >> with a configuration that >> should allow all traffic according my understanding) >> >> The GRE interface looks like: >> >> gre0: flags=8051 mtu 1476 >> index 44 priority 0 llprio 6 >> encap: vnetid none txprio payload rxprio packet >> groups: gre >> tunnel: inet6 2a02::yyy:zzz::1 --> 2a00:::::10 ttl 64 >> nodf ecn >> inet6 fe80::20d:b9ff:fe44:ecdc%gre1051 --> prefixlen 64 scopeid 0x2c >> inet6 2a01:qqq::ss::2 --> prefixlen 128 >> >> The simplified pf-Rule looks like: >> >> pass >> pass on gre proto gre no state >> >> tcpdump shows the following: >> >> doas tcpdump -nvei gre0 ip6 and icmp6 or proto gre >> tcpdump: listening on gre0, link-type LOOP >> 19:29:15.124113 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo >> request (id:9e45 seq:18) [icmp6 cksum ok] (len 64, hlim 64) >> 19:29:16.124438 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo >> request (id:9e45 seq:19) [icmp6 cksum ok] (len 64, hlim 64) >> 19:29:17.1248112a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo >> request (id:9e45 seq:20) [icmp6 cksum ok] (len 64, hlim 64) >> >> and >> >> doas tcpdump -nvei em0 ip6 and icmp6 or proto gre >> tcpdump: listening on em0, link-type EN10MB >> 19:51:06.126497 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: >> 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd >> 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:9e45 >> seq:1329) (len 64, hlim 64) [flowlabel 0x367f] (len 108, hlim 64) >> 19:51:07.126815 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: >> 2a02::yyy:zzz::11 > 2a00:::::10: gre [] 86dd >> 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:9e45 >> seq:1330) (len 64, hlim 64) [flowlabel 0x367f] (len 108, hlim 64) >> 19:51:08.127252 00:0d:b9:44:ec:dc 34:81:c4:e0:4b:79 86dd 162: >> 2a02::yyy:zzz::1 > 2a00:::::10: gre [] 86dd >> 2a01:qqq::ss::2 > 2a01:qqq::ss::1: icmp6: echo request (id:9e45 >> seq:1331) (len 64, hlim 64) [flowlabel 0x367f] (len 108, hlim 64) >> >> >> And >> >> doas tcpdump -nvei pflog0 >> tcpdump: WARNING: snaplen raised from 116 to 160 >> tcpdump: listening on pflog0, link-type PFLOG >> 19:55:03.962579 rule 0/(ip-option) [uid 0, pid 74650] pass in on em0: >> 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) >> gre [] 86dd [|ip6] [flowlabel 0xa8f7b] (len 116, hlim 243) >> 19:55:04.964864 rule 0/(ip-option) [uid 0, pid 74650] pass in on em0: >> 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) >> gre [] 86dd [|ip6] [flowlabel 0xa8f7b] (len 116, hlim 243) >> 19:55:05.963947 rule 0/(ip-option) [uid 0, pid 74650] pass in on em0: >> 2a00:::::10 > 2a02::yyy:zzz::1: DSTOPT (type 0x04: len=1) >> gre [] 86dd [|ip6] [flowlabel 0xa8f7b] (len 116, hlim 243) >> >> >> Thanks in advance for any hints on how to solve this issue >> >> Best regards >> Markus >> signature.asc Description: Message signed with OpenPGP
