Re: Strange snmpd issue with 6.7
On Sat, Nov 07, 2020 at 01:53:00PM -, Stuart Henderson wrote: > On 2020-11-06, Winfred Harrelson wrote: > > I am running OpenBSD 6.7 and am having a strange issue with snmpd(8). > > > > The issue is that it doesn't have all the arp entries but this was > > working before. I don't know exactly when this started happening > > but I just noticed today. > > > > Here is the machine in question and what I get: > > > > wharrels@styx1:/home/wharrels$ uname -a > > OpenBSD styx1 6.7 GENERIC.MP#3 amd64 > > > > wharrels@styx1:/home/wharrels$ arp -a | wc -l > > 985 > > > > Box is acting as a firewall so that is normal. Actually normal to > > have many more than that. But if I do a query from another machine > > via snmpwalk I get a completely different number of machines in > > the arp table: > > > > [wharrels@newtron ~]$ snmpwalk -v2c -c public styx1 > > ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress | wc -l > > 456 > > > > Not even close to the same number of machines. The above OID translates to > > 1.3.6.1.2.1.4.22.1.2 if you want to try this and see what you get. > > > > Should I be using a different OID to get the arp table or is there > > another way to do this? It might be that this was not working quite > > right before but I don't remember it being off like this. > > > > Any help would be appreciated, thanks. > > > > Winfred > > > > > > If you have set "filter-routes yes" then this is expected as it will > stop snmpd from seeing route updates and thus new additions to the > ARP table. I do not have that in my config file. Man page says the default is "no" so this should not be it correct? I will try adding the line with a "no" just to see if that changes anything though. > If you have not then I'd say this is a bug and best reported to > bugs@ rather than misc@. I am running 6.7 on this box so I may wait until I can get it updated to 6.8 before reporting to bugs@. > BTW you can see this table in a nicer output format: > > $ snmptable -v2c -c pulic host ip.ipNetToMediaTable I did not know that, thanks for the info. Doesn't look to be much different though. Winfred
Re: Sun t5120 LDOMs
Hi Stefan, Thank you so much for your help, I will try current. Kind regards John. On Mon, 9 Nov 2020 at 15:57, Stefan Sperling wrote: > On Mon, Nov 09, 2020 at 01:42:54PM +, John Gould wrote: > > Hi everyone, I am trying to set up a ldom on a sun t5120 machine running > > sparc64 6.8. This did work fine on 6.5. The problem I'm having is that > once > > the machine is reset to use the openbsd bootmode the machine hangs and > > asks for the root device. If one tries to answer this I get no way of > > entering > > sda which is the root device. Here is the ldom.conf file, the boot > sequence > > with the hang and the factory-default dmesg. Can someone point me in the > > right direction on how to fix this so that I can install multiple ldom's? > > Does anyone know why it's not finding ( how to make it find ) the > bootpath? > > Here is the problem: > > > mpi0 at pci8 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x04 > > vpci_intr_establish_cpu: pci_msi_setmsiq: err 6: unable to map interrupt > at msi > > 6.8 has a bug where it enables message-signaled interrupts (MSI) on some > sparc64 machines which do not actually support MSI. Various devices then > fail to attach, including your disk controller mpi0. > > This problem has been fixed after release. The fix is trivial, see below. > > You could run -current instead of 6.8 to get this fix. > > Or you could apply this patch to a 6.8-stable CVS checkout and build > your own kernel (since sparc64 doesn't have binary syspatches, you'd > be building your own kernels anyway for errata patches). > > === > RCS file: /cvs/src/sys/arch/sparc64/dev/vpci.c,v > retrieving revision 1.31 > retrieving revision 1.32 > diff -u -r1.31 -r1.32 > --- src/sys/arch/sparc64/dev/vpci.c 2020/06/25 21:43:41 1.31 > +++ src/sys/arch/sparc64/dev/vpci.c 2020/10/24 05:07:47 1.32 > @@ -1,4 +1,4 @@ > -/* $OpenBSD: vpci.c,v 1.31 2020/06/25 21:43:41 jmatthew Exp $ */ > +/* $OpenBSD: vpci.c,v 1.32 2020/10/24 05:07:47 jmatthew Exp $ */ > /* > * Copyright (c) 2008 Mark Kettenis > * > @@ -273,6 +273,8 @@ > > /* One eq per cpu, limited by the number of eqs. */ > num_eq = min(ncpus, getpropint(sc->sc_node, "#msi-eqs", 36)); > + if (num_eq == 0) > + return; > > if (OF_getprop(sc->sc_node, "msi-address-ranges", > msi_addr_range, sizeof(msi_addr_range)) <= 0) > >
Re: Sun t5120 LDOMs
On Mon, Nov 09, 2020 at 01:42:54PM +, John Gould wrote: > Hi everyone, I am trying to set up a ldom on a sun t5120 machine running > sparc64 6.8. This did work fine on 6.5. The problem I'm having is that once > the machine is reset to use the openbsd bootmode the machine hangs and > asks for the root device. If one tries to answer this I get no way of > entering > sda which is the root device. Here is the ldom.conf file, the boot sequence > with the hang and the factory-default dmesg. Can someone point me in the > right direction on how to fix this so that I can install multiple ldom's? > Does anyone know why it's not finding ( how to make it find ) the bootpath? Here is the problem: > mpi0 at pci8 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x04 > vpci_intr_establish_cpu: pci_msi_setmsiq: err 6: unable to map interrupt at > msi 6.8 has a bug where it enables message-signaled interrupts (MSI) on some sparc64 machines which do not actually support MSI. Various devices then fail to attach, including your disk controller mpi0. This problem has been fixed after release. The fix is trivial, see below. You could run -current instead of 6.8 to get this fix. Or you could apply this patch to a 6.8-stable CVS checkout and build your own kernel (since sparc64 doesn't have binary syspatches, you'd be building your own kernels anyway for errata patches). === RCS file: /cvs/src/sys/arch/sparc64/dev/vpci.c,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- src/sys/arch/sparc64/dev/vpci.c 2020/06/25 21:43:41 1.31 +++ src/sys/arch/sparc64/dev/vpci.c 2020/10/24 05:07:47 1.32 @@ -1,4 +1,4 @@ -/* $OpenBSD: vpci.c,v 1.31 2020/06/25 21:43:41 jmatthew Exp $ */ +/* $OpenBSD: vpci.c,v 1.32 2020/10/24 05:07:47 jmatthew Exp $ */ /* * Copyright (c) 2008 Mark Kettenis * @@ -273,6 +273,8 @@ /* One eq per cpu, limited by the number of eqs. */ num_eq = min(ncpus, getpropint(sc->sc_node, "#msi-eqs", 36)); + if (num_eq == 0) + return; if (OF_getprop(sc->sc_node, "msi-address-ranges", msi_addr_range, sizeof(msi_addr_range)) <= 0)
Sun t5120 LDOMs
Hi everyone, I am trying to set up a ldom on a sun t5120 machine running
sparc64 6.8. This did work fine on 6.5. The problem I'm having is that once
the machine is reset to use the openbsd bootmode the machine hangs and
asks for the root device. If one tries to answer this I get no way of
entering
sda which is the root device. Here is the ldom.conf file, the boot sequence
with the hang and the factory-default dmesg. Can someone point me in the
right direction on how to fix this so that I can install multiple ldom's?
Does anyone know why it's not finding ( how to make it find ) the bootpath?
Kind regards John
t5120-14# cat ldom.conf
domain "primary" {
memory 8G
}
domain "puffy" {
vcpu 12
memory 4G
vdisk "/alt/vm/puffy/vdisk0"
vdisk "/alt/vm/puffy/vdisk1"
vnet
}
Here is the boot sequence with the hang:-
sc>
sc> bootmode config="openbsd"
sc> reset -c
Are you sure you want to reset the system (y/n)? y
Reset | major: Reset of /SYS initiated by admin.
Reset | major: Reset of /SYS by admin succeeded.
Performing reset on the system
Chassis | critical: Host has been reset
Enter #. to return to ALOM.
Chassis | major: Host is running
SPARC Enterprise T5120, Keyboard Present
Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.33.6.b, 8192 MB memory available, Serial #85459110.
Ethernet address 0:21:28:18:0:a6, Host ID: 851800a6.
Boot device: disk File and args:
OpenBSD IEEE 1275 Bootblock 2.1
..>> OpenBSD BOOT 1.20
ERROR: /iscsi-hba: No iscsi-network-bootpath property
Trying bsd...
Booting /pci@0/pci@0/pci@2/scsi@0/disk@0,0:a/bsd
10005840@0x100+4784@0x198ad50+194164@0x1c0+4000140@0x1c2f674
symbols @ 0xfea06400 480588+165+642336+443753 start=0x100
[ using 1567880 bytes of bsd ELF symbol table ]
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.8 (GENERIC.MP) #490: Sun Oct 4 20:52:40 MDT 2020
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 8589934592 (8192MB)
avail mem = 8412905472 (8023MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: SPARC Enterprise T5120
cpu0 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu1 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu2 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu3 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu4 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu5 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu6 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu7 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu8 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu9 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu10 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu11 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu12 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu13 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu14 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu15 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu16 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu17 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu18 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu19 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu20 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu21 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu22 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu23 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu24 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu25 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu26 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu27 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu28 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu29 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu30 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu31 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu32 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu33 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu34 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu35 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu36 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu37 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu38 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu39 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu40 at
cdce(4)/urndis(4): Unexpected destination MAC address in replies leads to dropped Ethernet frames
Hi misc@, I am currently testing OpenBSD 6.8 (GENERIC.MP) #98 on an APU2c4 together with a u-blox mPCIe LTE modem (MPCI-L210-03S-00) which can be configured to present itself to the system either as a cdce(4) device or as a urndis(4) device. In both modes, the modem is attached by the kernel and the corresponding entry shows up in the ifconfig(8) output. The modem can work both in the bridge mode and in the router mode. During the tests, I activated the router mode and configured the cdce0 network interface as follows (for the entire time, the urndis0 interface remained disabled and did not appear in the ifconfig(8) output; the modem also registered properly with the LTE network): # cat /etc/hostname.cdce0 up dhcp The problem manifested itself in such a way that, while I was able to send and receive ICMP echo-request/reply messages to external IPv4 addresses via the LTE network, traffic involving other network protocols (DNS/NTP/TLS, for example) was interrupted frequently -- in that case, an in-depth analysis revealed that the corresponding reply messages forwarded by the modem towards the OpenBSD system had an unexpected destination MAC address set in the Ethernet header, and so they were dropped by the kernel in the ether_input() function defined in the /usr/src/sys/net/if_ethersubr.c file. In particular, I noticed that the destination MAC address stored in the message header (not matching the MAC address of the cdce0 interface on the receiving end) was equal to the MAC address of the inactive urndis0 interface, which also explains why the MAC address validation check failed and why most of the incoming messages were dropped. At the same time, while quickly analyzing the ether_output() code path, I noticed that the ether_resolve() function used the MAC address of the cdce0 interface as the source address, and the MAC address of the internal gateway interface of the modem as the destination address. Based on my current understanding of the problem, it is not caused by the APU2 machine, as I was able to reproduce this issue also on a Dell laptop having a WWAN slot and running the same version of OpenBSD (I could not reproduce it on Linux, though -- forwarding worked fine in this case). I wonder what would be the most effective way to investigate this issue further? I would appreciate any comments and suggestions. Best wishes, Andrzej
Re: question about hostname.carp
On 11/5/20 9:25 AM, Stuart Henderson wrote: but I prefer this multi-line vhid 41 pass secret advbase 1 advskew 0 carpdev em1 inet 10.0.1.1/24 Thats much better. I was using this "one line for all" thing following some ancient examples. Thanx very much Harri
