Troubleshooting FDE with SD Card Reader

[Normen Wohner]

I cannot use my SD Reader for keydisk purposes.
It does show up in dmesg and should be there on boot.
Since my SD reader is bundled with a 
Sony MemoryStick reader I see them both coming up
when I plug in the SD Card.
The MS umass shows first on sd0 even if empty so the
SD gets pushed to sd1.
Should I somehow MAKEDEV sd1?
I presumed it to be there?
Is this maybe a different issue all together?
Thanks for all the help!
 

Re: problem with iscsid and other Target

[gotoubunno hanayome]

I have mistake ...
> #sources
#FreeBSD Target 192.168.0.2
> #FreeBSD Target 192.168.0.3

> ## then service ctld start
>
>
#OpenBSD Initiator 192.168.0.3
> #OpenBSD Initiator 192.168.0.2
> # cat <<_EOF_> /etc/iscsi.conf
> target "array" {
> targetaddr 192.168.0.2
> targetname "iqn.2019-01.com.example:target0"
> initiatoraddr 192.168.0.3
> initiatorname "iqn.1995-11.org.openbsd.iscsid:initiat0"
> }
> _EOF_

please help me...

Re: bgpd between two 6.4 boxes. IPv6 flapping, IPv4 rock solid

[Rachel Roch]

29 Mar 2019, 18:57 by rr...@tutanota.de:

> Hi,
>
> Has anyone encountered this before ?
>
> Neighbor    AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
> EXT-V6-R2   65515 50 40 0 00:02:55 Active
> EXT-V4-R2   65515 38 37 0 00:27:42  1
> After approx just over 2 minutes, the V6 flaps, bu the V4 remains rock solid.
>
> The boxes are sitting right next to each other, connected over an OpenBSD 
> LACP trunk.
>
> I have made the pf rules as simple as possible:
>
> table  counters {self}
> table  counters {192.0.2.1,2001:DB8::1}
> pass in quick proto {tcp,udp,icmp} from  to 
>  modulate state
> pass out quick proto {tcp,udp,icmp} from  to 
>  modulate state
>
> The bgpd config is also simple:
>
> MY_ROUTER_ID_V4="192.0.2.2"
> MY_ROUTER_ID_V6="2001:DB8::2"
> MY_ASN="64515"
> AS $MY_ASN
> router-id $MY_ROUTER_ID_V4
> rde med compare always
> network inet connected
> network inet6 connected
> group its_internal_v4 {
>     remote-as 65515
>     announce IPv6 none
>     neighbor 192.0.2.1 {
>     local-address 192.0.2.2
>     descr "EXT-V4-R2"
>     }
> }
> group its_internal_v6 {
>     remote-as 65515
>     announce IPv6 none
>     neighbor 2001:DB8::1 {
>     local-address 2001:DB8::2
>     descr "EXT-V6-R2"
>     }
> }
>

Forgive me, I forgot to include what shows in the logs:

sending IPv4 unicast EOR marker
received IPv4 unicast EOR marker
received notification: HoldTimer expired
state change Established -> Idle, reason: NOTIFICATION received
state change Idle -> Connect, reason: Start
state change Connect -> OpenSent, reason: Connection opened
state change OpenSent -> OpenConfirm, reason: OPEN message received
state change OpenConfirm -> Established, reason: KEEPALIVE message received
sending IPv4 unicast EOR marker
received IPv4 unicast EOR marker

bgpd between two 6.4 boxes. IPv6 flapping, IPv4 rock solid

[Rachel Roch]

Hi,

Has anyone encountered this before ?

Neighbor    AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
EXT-V6-R2   65515 50 40 0 00:02:55 Active
EXT-V4-R2   65515 38 37 0 00:27:42  1
After approx just over 2 minutes, the V6 flaps, bu the V4 remains rock solid.

The boxes are sitting right next to each other, connected over an OpenBSD LACP 
trunk.

I have made the pf rules as simple as possible:

table  counters {self}
table  counters {192.0.2.1,2001:DB8::1}
pass in quick proto {tcp,udp,icmp} from  to  
modulate state
pass out quick proto {tcp,udp,icmp} from  to 
 modulate state

The bgpd config is also simple:

MY_ROUTER_ID_V4="192.0.2.2"
MY_ROUTER_ID_V6="2001:DB8::2"
MY_ASN="64515"
AS $MY_ASN
router-id $MY_ROUTER_ID_V4
rde med compare always
network inet connected
network inet6 connected
group its_internal_v4 {
    remote-as 65515
    announce IPv6 none
    neighbor 192.0.2.1 {
    local-address 192.0.2.2
    descr "EXT-V4-R2"
    }
}
group its_internal_v6 {
    remote-as 65515
    announce IPv6 none
    neighbor 2001:DB8::1 {
    local-address 2001:DB8::2
    descr "EXT-V6-R2"
    }
}

problem with iscsid and other Target

[hanay...@mail2tor.com]

hi! I use the OpennBSD 6.4 and FreeBSD 12.
recently, I tried OpenBSD iscsid with FreeBSD ctld.
These are gave me a good perfomance for HDD with ffs & ntfs directry in use!
But, I get the ANY Problem with iscsid and ctld.

#problem
1. iscsid didn't have "chap auth" connection.
2. iscsid lost the connection with any "big data transportation".
"dd" "mv" "cp" "mkntfs" "newfs"
3. almost zfs iscsi target lost the connection with any data transportation.
"dd" "mkntfs" "newfs"

problem 2 and 3 get the error on FreeBSD with hungup the process on OpenBSD.
I tried "pkill iscsid":
Any time stop the process safely.
but, other time crash the OpenBSD!!!

I don't use the firewall(pf and ipf).

#sources
#FreeBSD Target 192.168.0.3
# cat <<_EOF_> /etc/ctl.conf
portal-group pg0 {
discovery-auth-group no-authentication
listen 0.0.0.0
#listen [::]
}
target "iqn.1998-11.com.example:target0" {
auth-group no-authentication
portal-group pg0
 lun 0 {
  path "/dev/ada0" #problem 2
  ## cleared the data, before using:
  ## dd if=/dev/zero of=/dev/ada0 bs=32k

  #path "/dev/zvol/zpool/zvolume/array_lun0" #problem 3
  ## zfs creation was almost no problem...
  ## dd if=/dev/zero of=/dev/ada0 bs=32k
  ## zpool create zpool /dev/ada0
  ## zfs create zpool/zvolume
  ## zfs create -V 100G zpool/zvolume/array_lun0
 }
}
_EOF_
## then service ctld start


#OpenBSD Initiator 192.168.0.2
# cat <<_EOF_> /etc/iscsi.conf
target "array" {
targetaddr 192.168.0.2
targetname "iqn.2019-01.com.example:target0"
initiatoraddr 192.168.0.3
initiatorname "iqn.1995-11.org.openbsd.iscsid:initiat0"
}
_EOF_
## then rcctl -f iscsid start; iscsictl reload;


#ERRORS
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): waiting
for CTL to terminate 1 tasks
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): received
PDU with CmdSN 3817501623, while expected 3817501624
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): tasks
terminated
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): no ping
reply (NOP-Out) after 5 seconds; dropping connection
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): received
PDU with CmdSN 3817501624, while expected 3817501625
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): no ping
reply (NOP-Out) after 5 seconds; dropping connection
.
.
.
ENDLESS

I want to get the good idea...
please help me...

problem with iscsid and other Target

[gotoubunno hanayome]

hi! I use the OpennBSD 6.4 and FreeBSD 12.
recently, I tried OpenBSD iscsid with FreeBSD ctld.
These are gave me a good perfomance for HDD with ffs & ntfs directry in use!
But, I get the ANY Problem with iscsid and ctld.

#problem
1. iscsid didn't have "chap auth" connection.
2. iscsid lost the connection with any "big data transportation".
"dd" "mv" "cp" "mkntfs" "newfs"
3. almost zfs iscsi target lost the connection with any data transportation.
"dd" "mkntfs" "newfs"

problem 2 and 3 get the error on FreeBSD with hungup the process on OpenBSD.
I tried "pkill iscsid":
Any time stop the process safely.
but, other time crash the OpenBSD!!!

I don't use the firewall(pf and ipf).

#sources
#FreeBSD Target 192.168.0.3
# cat <<_EOF_> /etc/ctl.conf
portal-group pg0 {
discovery-auth-group no-authentication
listen 0.0.0.0
#listen [::]
}
target "iqn.1998-11.com.example:target0" {
auth-group no-authentication
portal-group pg0
 lun 0 {
  path "/dev/ada0" #problem 2
  ## cleared the data, before using:
  ## dd if=/dev/zero of=/dev/ada0 bs=32k

  #path "/dev/zvol/zpool/zvolume/array_lun0" #problem 3
  ## zfs creation was almost no problem...
  ## dd if=/dev/zero of=/dev/ada0 bs=32k
  ## zpool create zpool /dev/ada0
  ## zfs create zpool/zvolume
  ## zfs create -V 100G zpool/zvolume/array_lun0
 }
}
_EOF_
## then service ctld start


#OpenBSD Initiator 192.168.0.2
# cat <<_EOF_> /etc/iscsi.conf
target "array" {
targetaddr 192.168.0.2
targetname "iqn.2019-01.com.example:target0"
initiatoraddr 192.168.0.3
initiatorname "iqn.1995-11.org.openbsd.iscsid:initiat0"
}
_EOF_
## then rcctl -f iscsid start; iscsictl reload;


#ERRORS
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): waiting
for CTL to terminate 1 tasks
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): received
PDU with CmdSN 3817501623, while expected 3817501624
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): tasks
terminated
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): no ping
reply (NOP-Out) after 5 seconds; dropping connection
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): received
PDU with CmdSN 3817501624, while expected 3817501625
WARNING: 192.168.0.3 (iqn.1995-11.org.openbsd.iscsid:initiat0): no ping
reply (NOP-Out) after 5 seconds; dropping connection
.
.
.
ENDLESS

I want to get the good idea...
please help me...

Re: How to overrule bioctl "chunk already in use"

[Rachel Roch]

29 Mar 2019, 02:42 by n...@holland-consulting.net:

> On 3/28/19 10:29 AM, Rachel Roch wrote:
>
>> Hi,
>>
>> I've been following the instructions here
>> https://www.openbsd.org/faq/faq14.html 
>> 
>> <>> https://www.openbsd.org/faq/faq14.html 
>> >> > to setup softraid.
>>
>> Unfortunately I somehow messed up the original attempt through my own
>> stupidity.
>>
>
> it happens.
> And best that it happen before production than after.
>
>> So I've been trying to go through the steps again.  However nothing
>> I do can elminate the "softraid0 sd0a chunk already in use" message
>> at the "bioctl -c 1 -l sd0a,sd1a softraid0" step.
>>
>> I've tried everything !  Rebooting the server, /dev/zero to the
>> first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and
>> re-writing disk label.
>>
>> I looked at the man page and thought "ah ha !" ... maybe "-C force",
>> but nope !
>>
>
> you were close with the zeroing the head of the components.  In fact,
> I'm not sure what you did wrong, but that's the solution.
>
> I'd suggest starting by zeroing the beginning of each physical disk --
> using the r device and the c partition -- i.e.,
>
>  # dd if=/dev/zero of=/dev/rsd0c
>  # dd if=/dev/zero of=/dev/rsd1c
>
> I've had enough problems, I really suggest this unless you are
> absolutely sure your disk has never even heard of OpenBSD before you
> install it. :)  (I think I had figured out at one point that zeroing the
> RAID partitions was sufficient, but when it comes to zeroing, a little
> more is never too much. :)
>
> Now, if you were going to script this, you would put a block size and a
> count in there...but since you are just typing this at the command line,
> count to three and hit CTRL-C then do the next.  You really only have to
> clear a megabyte or so, and probably a LOT less...you can't hit CTRL-C
> fast enough, I suspect. :)
>
> By using the 'r' device and the 'c' partion, you have wiped the very
> very start of the disk -- sector zero onward.
>
> I'd reboot after that.  I don't think it's needed, but either the
> disklabel or MBR partition can be held in memory and written back out to
> disk under some circumstance, I don't recall exactly what (probably
> having to do with mounted partitions), so a reboot, and then verifying
> that fdisk sd0 shows lots of zeros everywhere including the Signature.
> NOW fdisk, create your OpenBSD partition, then your RAID disklabel
> partitions, and you should be in business.
>
> If that doesn't do it, show us your exact commands and exact output you
> are seeing.
>
> Nick.
>

Thanks Nick !  Your suggestion did the trick.

Re: openbgpd; strip private ASNs from bgp updates

[Sebastian Benoit]

open...@kene.nu(open...@kene.nu) on 2019.03.29 08:36:26 +0100:
> I forgot to add to my previous email. One thing that could be useful
> in this case is to mimic the Cisco option "neighbor x.x.x.x
> remove-private-as" which removes any private ASes from the path on any
> updates to a peer.  Just throwing it out there, cant be a very
> difficult option to implement I guess?

If as-override does what you need, i'm not to keen on adding more knobs.

That said, i'm happy to look at your diff ;)

Re: IBM x3650 M3 fatal page fault in supervisor mode

[Marco Nuessgen]

Today I successfully reproduced the installation process. 

OpenBSD 6.4
Machine type/ model: 7945B2G
Host firmware (UEFI) 1.22, build date 2018-06-04

System settings - Processors
 Power C-States 
 Report C2 to OS 
 Virtualization 
 VT-d 
 Cache Data Prefetch 
 Data Reuse 
 Execute Disable 
 Hyperthreading 

System settings - Memory
 Memory Speed Max Performance
 LV-DIMM Power 
 Memory Channel Mode 
 Socket Interleave 
 Patrol Scrub 
 Demand Scrub 
 Static Driver Impedance 
 Memory Refresh <1x>
 Thermal Mode 

System settings - Devices and I/ O Ports
 Configure IDE mode 
 Interrupt Round Robin 

System settings - Operating Modes
 Choose Operating mode 

System settings - Legacy Support
 Rehook INT 19h 
 Legacy Thunk Support 

Boot Manager
 Change Boot Order
  
  
  

The install medium must be the first in the boot order list.
You have to boot without using the Boot-Manager (F12).

Re: athn0: bad ROM checksum 0x2c64

[Stefan Sperling]

On Sun, Feb 10, 2019 at 07:12:38PM +0100, Sebastian Reitenbach wrote:
> I get the same bad ROM checksum message with the broken device,
> and indeed, the device that worked before, now gives the same bad ROM checksum
> message when I insert it. It only give a different checksum:
> previously working device: 0x2243
> non-working device: 0x2c64
> 
> cheers,
> Sebastian

This should fix attach but there's some other remaining problem.
The device detaches itself again when I try to use it.

diff 709e530bc956c51de2da4aff727d8da450babdc4 /usr/src
blob - 74025dba1aff37e328c92779398e428caef72c04
file + sys/dev/ic/ar9287.c
--- sys/dev/ic/ar9287.c
+++ sys/dev/ic/ar9287.c
@@ -100,7 +100,8 @@ voidar9280_spur_mitigate(struct athn_softc *, 
struct 
 int
 ar9287_attach(struct athn_softc *sc)
 {
-   sc->eep_base = AR9287_EEP_START_LOC;
+   sc->eep_base = (sc->flags & ATHN_FLAG_USB) ?
+   AR9287_HTC_EEP_START_LOC : AR9287_EEP_START_LOC;
sc->eep_size = sizeof(struct ar9287_eeprom);
sc->ngpiopins = (sc->flags & ATHN_FLAG_USB) ? 16 : 11;
sc->led_pin = 8;
blob - 340b28c2f84de4d40f15c42f13b1727a6f497bb0
file + sys/dev/ic/ar9287reg.h
--- sys/dev/ic/ar9287reg.h
+++ sys/dev/ic/ar9287reg.h
@@ -60,6 +60,7 @@
  * ROM layout used by AR9287 (2GHz only).
  */
 #define AR9287_EEP_START_LOC   128
+#define AR9287_HTC_EEP_START_LOC   256
 #define AR9287_NUM_2G_CAL_PIERS3
 #define AR9287_NUM_2G_CCK_TARGET_POWERS3
 #define AR9287_NUM_2G_20_TARGET_POWERS 3

Re: openbgpd; strip private ASNs from bgp updates

[openbsd]

I forgot to add to my previous email. One thing that could be useful
in this case is to mimic the Cisco option "neighbor x.x.x.x
remove-private-as" which removes any private ASes from the path on any
updates to a peer.  Just throwing it out there, cant be a very
difficult option to implement I guess?

On Thu, Mar 28, 2019 at 2:55 PM  wrote:
>
> That will indeed help. Will check it out.
>
> How I have solved it now is by having network statements on the edge
> (/24s). To make the internal routing work I announce more specific
> prefixes from the internal router, so externally I announce a /24
> (from edge to peering partners) but internally I announce two /25s
> (from internal to edge). That way internet knows how to find my /24
> and edge knows how to find its way internally due to /25 being more
> specific compared to /24.
>
> On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit  wrote:
> >
> > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100:
> > > Hello,
> > >
> > > That would unforunately affect all the prefixes announced to the edge
> > > router from the internal router. I need it to be only prefixes
> > > announced to my peering partners.
> > >
> > > /Oscar
> > >
> > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras  wrote:
> > > >
> > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote:
> > > > > Hello,
> > > > >
> > > > > Is there a way to make openbgpd strip private ASNs from updates it
> > > > > sends to certain neighbors?
> > > > > I am using openbgpd on my edge routers and distribute routes generated
> > > > > internally to the rest of the world. However, the internal routers use
> > > > > private ASNs and this is obviously frowned upon by my peering
> > > > > partners.
> > > > >
> > > > > I can of course have network statements on my edge routers but that
> > > > > assumes the prefixes will always be reachable via said edge router,
> > > > > something I can never be certain of. I would rather the updates rely
> > > > > on the prefix actually being announced from the source.
> > > > >
> > > >
> > > > Perhaps with transparent-as ?
> >
> > In current (snapshots) there is "as-override":
> >
> >  as-override (yes|no)
> >  If set to yes, all occurrences of the neighbor AS in the AS
> >  path will be replaced with the local AS before running the
> >  filters.  The Adj-RIB-In still holds the unmodified AS path.
> >  The default value is no.
> >
> > this is a neighbor option and used on the session to a peer that uses a
> > private AS.
> >
> > You dont say much about your network structure, but if your edge router has
> > a normal As number, and your internal ebgp peers have private As numbers,
> > this option will help.
> >
> > /Benno
> >