Re: snapshot boot fails with error "entry point at 0x1001000"
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> Kastus Shchuka wrote:
> “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to
> boot it.
> Boot stops at the line
>
> entry point at 0x1001000
>
> If I try bsd.rd kernel, it boots just fine. After this failure with snapshot
> I
> installed 6.7-release, and it boots without any issues.”
>
>
> I've experienced something similar, including the sensitivity to kernel size.
> As best I can observe, the EFI bootloader is being handed a different block
> of RAM than where the kernel is actually loaded (which is at a fixed address
> defined in boot.c). Which block of memory gets returned, and whether boot
> fails, seems to be dependent on the particular UEFI ROM/chipset. In my case,
> debugging over serial, I observe a page fault while the kernel is still being
> loaded into RAM.
> “Are there any other solutions than compiling a custom smaller kernel?”
>
>
> Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it
> for me:
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -303,9 +303,9 @@ efi_memprobe(void)
> bios_memmap_t *bm;
> EFI_STATUS status;
> EFI_PHYSICAL_ADDRESS
> -addr = 0x1000ULL; /* Below 256MB */
> +addr = 0x100;
>
> - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> EfiLoaderData,
> + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> if (status != EFI_SUCCESS)
> panic("BS->AllocatePages()");
> Let me know if that helps. I can't guarantee that this is actually what is
> causing your issue but it worked for me.
I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
I wonder what would it take for the patch to be accepted in -current?
Thanks,
Kastus
Re: no u-boot serial output on raspberry pi 3
On Sun, Jul 05, 2020 at 09:18:55PM +0100, testing999...@zohomail.eu wrote: > i can't get any u-boot serial output from miniroot67.fs on a raspberry > pi 3. i'm using a 'FTDI232' which cost ~$4 - USB to 3.3V jumper > cables, connecting TX to RX and vice versa on GPIO header. > > my serial console setup works without issue with a pi 1 and a pi 3, > running raspbian, with: > $ screen /dev/ttyUSB0 115200 > i had to add 'enable_uart=1' to /boot/config.txt before with console > became accessible, on the pi 3. > > i tried mounting the partitions after dd'ing miniroot67.fs and > looking for some text files to edit, but there were only binaries > > any ideas? i can only think of trying older miniroots or snapshots > next. thanks The arm64 miniroot contains a fat filesystem with raspberry pi firmware, config.txt and rpi_3 u-boot. The config.txt already has serial enabled (with pl011 uart): arm_64bit=1 enable_uart=1 dtoverlay=disable-bt kernel=u-boot.bin You can force the firmware stage which runs before u-boot to output on serial by modifying bootcode.bin as described at the end of https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md If you try miniroot67.img from a snapshot you'll get a more recent version of u-boot. May be worth trying.
Prohibit WiFi interface from transmitting?
I've installed OpenBSD 6.7 on a system that have an athn(4) wireless network adapter. Before setting up this device, I wanted to verify the configuration of pf, unbound etc. which required the interface to have an IP address, so I added the following line to /etc/hostname.athn0: inet 192.168.10.1 255.255.255.0 This enabled the interface, which allowed pf, unbound etc. to start: # ifconfig athn0 athn0: flags=8843 mtu 1500 lladdr XX:XX:XX:XX:XX:XX index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect (DS1) status: no network ieee80211: nwid "" inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 However, it also automatically made the interface start scanning: # netstat -W athn0 | grep scans 1 active scans started 0 passive scans started Is it possible to configure the athn0 interface with an IP address, but prohibit any kind of wireless communication? The reason for this is that I have to verify many systems with different configuration, which requires athn0 to be configured with an IP address. I want to do the verification and install patches before any wireless communication happens, as I can't guarantee that none of the devices within wireless range are malicious. Regards, Mogens Jensen
no u-boot serial output on raspberry pi 3
i can't get any u-boot serial output from miniroot67.fs on a raspberry pi 3. i'm using a 'FTDI232' which cost ~$4 - USB to 3.3V jumper cables, connecting TX to RX and vice versa on GPIO header. my serial console setup works without issue with a pi 1 and a pi 3, running raspbian, with: $ screen /dev/ttyUSB0 115200 i had to add 'enable_uart=1' to /boot/config.txt before with console became accessible, on the pi 3. i tried mounting the partitions after dd'ing miniroot67.fs and looking for some text files to edit, but there were only binaries any ideas? i can only think of trying older miniroots or snapshots next. thanks
Re: Prohibit WiFi interface from transmitting?
On Sun, Jul 05, 2020 at 08:37:40PM +, Mogens Jensen wrote: > I've installed OpenBSD 6.7 on a system that have an athn(4) wireless > network adapter. Before setting up this device, I wanted to verify the > configuration of pf, unbound etc. which required the interface to have > an IP address, so I added the following line to /etc/hostname.athn0: > > inet 192.168.10.1 255.255.255.0 > > This enabled the interface, which allowed pf, unbound etc. to start: > > # ifconfig athn0 > athn0: flags=8843 mtu 1500 > lladdr XX:XX:XX:XX:XX:XX > index 4 priority 4 llprio 3 > groups: wlan > media: IEEE802.11 autoselect (DS1) > status: no network > ieee80211: nwid "" > inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 > > However, it also automatically made the interface start scanning: > > # netstat -W athn0 | grep scans > 1 active scans started > 0 passive scans started > > Is it possible to configure the athn0 interface with an IP address, but > prohibit any kind of wireless communication? Setting an IP address will implicitly mark the interface UP. This is long-standing behaviour and unlikely to change. And when a wifi interfaces is marked UP it will search for access points. Since you don't have an nwid configured, what will happen is: 1) The device will send a probe request with a wildcard SSID. Afterwards it will continue to listen for beacons indefinitely. 2) The device will receive beacons which are parsed by the kernel to populate the list of networks shown by 'ifconfig athn0 scan'. Because no nwid is configured no connection attempt will be made. (Note that this is new behaviour in OpenBSD 6.7. Before 6.7, the kernel would try to find an unencrypted network to connect to.) It is impossible to exchange data frames with the system over wifi in this unassociated state because any incoming data frames will be dropped. So if that's your concern then there is no actual reason to worry. > The reason for this is that I have to verify many systems with > different configuration, which requires athn0 to be configured with an > IP address. I want to do the verification and install patches before any > wireless communication happens, as I can't guarantee that none of the > devices within wireless range are malicious. As a workaround you could add 'down' to your hostname.if file after configuring the IP: inet 192.168.10.1 255.255.255.0 down That will disable the device after IP configuration. The address will remain configured and the interface will remain inactive until marked UP. Though I cannot tell if this would satisfy your verification process.
Re: Relayd with TLS and non-TLS backends - bug
This specific Backend in my test lab is an IIS machine, but in production I have OpenBSD/HAProxy in front of IIS, Apache, Tomcat, etc. I'm not doing anything fancy either... although the certificate in the lab is signed by an internal CA. Here's the relevant output from openssl s_client: The cert verifies perfectly fine. openssl s_client -connect 192.168.42.61:443 --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-SHA384 Session-ID: C0138246D3973B3106A378C0DB503D4BCDE02C6461AB073949027C90CDCF Session-ID-ctx: Master-Key: AACBE3A3E34406F9371B4E85D4DC82C177C641C94806562053C000FE0E019D2E1456702F69DECFB6D11C4B4A12A0D555 Start Time: 1593970747 Timeout : 7200 (sec) Verify return code: 0 (ok) --- and Netcat: nc -zv 192.168.42.61 443 Connection to 192.168.42.61 443 port [tcp/https] succeeded! On Fri, Jul 3, 2020 at 9:40 PM Daniel Jakots wrote: > > On Fri, 3 Jul 2020 19:14:17 -0400, Henry Bonath > wrote: > > > Daniel, > > > > Thanks for taking the time to test this out. > > I just reloaded a test machine from scratch with -current and > > installed the HAProxy 2.0.15-4f39279 package. > > I loaded a very basic config file, and am also seeing the same exact > > issue on this one as well. > > Very strange that you are not - > > Would you mind sharing any additional details of your config file? > > Is there anything special about the certificate you have on the > > backend server? > > > > I would love to understand what is going on here and what the > > difference is with my experience. > > What is your backend running? Can you connect from the haproxy host with > nc(1) and/or openssl(1)? > > I try to do my stuff as vanilla as possible so it's an RSA key signed > by LE.
Re: An Athn ar9280 client seems to require cold boots of late?
On Mon, Jun 29, 2020 at 12:09:12PM +, Kapfhammer, Stefan wrote:
> Hi,
>
> I am using exactly the same WLE-200NX wifi card in an APU2B4. I have a
> BlackBerry KeyONE
> running at Android 8.1 / Version ABT975 which I use as hotspot for the APU2.
>
> After setting athn0 down, it is impossible to establish the connection -
> without further intervention -
> a second time.
>
> What helps is:
>
> First:
> #/bin/sh
> /sbin/ifconfig athn0
> /sbin/ifconfig athn0 down -inet -inet6 -join bbk1 -wpakey -chan -bssid
> /sbin/ifconfig athn0
>
> Second:
> Disabling the hotspot on bbk1 and re-enabling it
>
> Third:
> sh -x /etc/netstart athn0
>
> This prevents to do a coldboot on the APU2 - reducing downtime.
> AND: It works reliably everytime since month!
>
In case you missed it, a fix was proposed on the bugs@ list on Friday:
https://marc.info/?l=openbsd-bugs=159380123409160=2
The same patch is copied below.
If anyone else could confirm that this makes athn(4) work again as
a client against a WPA2 AP then I will commit this.
diff refs/heads/master refs/heads/athn-ccmpfix
blob - 3a28d87bc88a0e7b9ed6c873bd7a07682cc91a0b
blob + 1d739529d7d214bea314e50e847594dc01021a41
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -811,12 +811,20 @@ ar5008_ccmp_decap(struct athn_softc *sc, struct mbuf *
/* Sanity checks to ensure this is really a key we installed. */
entry = (uintptr_t)k->k_priv;
if (k->k_flags & IEEE80211_KEY_GROUP) {
- if (k->k_id > IEEE80211_WEP_NKID ||
+ if (k->k_id >= IEEE80211_WEP_NKID ||
entry != k->k_id)
return 1;
- } else if (entry != IEEE80211_WEP_NKID +
- IEEE80211_AID(ni->ni_associd))
- return 1;
+ } else {
+#ifndef IEEE80211_STA_ONLY
+ if (ic->ic_opmode == IEEE80211_M_HOSTAP) {
+ if (entry != IEEE80211_WEP_NKID +
+ IEEE80211_AID(ni->ni_associd))
+ return 1;
+ } else
+#endif
+ if (entry != IEEE80211_WEP_NKID)
+ return 1;
+ }
/* Check that ExtIV bit is set. */
if (!(ivp[3] & IEEE80211_WEP_EXTIV))
blob - 40725b02c43b54e10a87de333acdfd3b8270534d
blob + f7aa77ba15cae787a42fdbffb8a9d9cd2d0226d2
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -1037,12 +1037,17 @@ athn_set_key(struct ieee80211com *ic, struct ieee80211
}
if (!(k->k_flags & IEEE80211_KEY_GROUP)) {
- entry = IEEE80211_WEP_NKID + IEEE80211_AID(ni->ni_associd);
+#ifndef IEEE80211_STA_ONLY
+ if (ic->ic_opmode == IEEE80211_M_HOSTAP)
+ entry = IEEE80211_WEP_NKID +
IEEE80211_AID(ni->ni_associd);
+ else
+#endif
+ entry = IEEE80211_WEP_NKID;
if (entry >= sc->kc_entries - IEEE80211_WEP_NKID)
return ENOSPC;
} else {
entry = k->k_id;
- if (entry > IEEE80211_WEP_NKID)
+ if (entry >= IEEE80211_WEP_NKID)
return ENOSPC;
}
k->k_priv = (void *)entry;
@@ -3056,10 +3061,6 @@ athn_init(struct ifnet *ifp)
else
athn_config_pcie(sc);
- /* Reset HW key cache entries. */
- for (i = 0; i < sc->kc_entries; i++)
- athn_reset_key(sc, i);
-
ops->enable_antenna_diversity(sc);
#ifdef ATHN_BT_COEXISTENCE
@@ -3086,6 +3087,10 @@ athn_init(struct ifnet *ifp)
/* Enable Rx. */
athn_rx_start(sc);
+ /* Reset HW key cache entries. */
+ for (i = 0; i < sc->kc_entries; i++)
+ athn_reset_key(sc, i);
+
/* Enable interrupts. */
athn_enable_interrupts(sc);
@@ -3121,7 +3126,7 @@ athn_stop(struct ifnet *ifp, int disable)
{
struct athn_softc *sc = ifp->if_softc;
struct ieee80211com *ic = >sc_ic;
- int qid;
+ int qid, i;
ifp->if_timer = sc->sc_tx_timer = 0;
ifp->if_flags &= ~IFF_RUNNING;
@@ -3158,6 +3163,10 @@ athn_stop(struct ifnet *ifp, int disable)
AR_WRITE_BARRIER(sc);
athn_set_rxfilter(sc, 0);
athn_stop_rx_dma(sc);
+
+ /* Reset HW key cache entries. */
+ for (i = 0; i < sc->kc_entries; i++)
+ athn_reset_key(sc, i);
athn_reset(sc, 0);
athn_init_pll(sc, NULL);
Re: relayd multiple listen on same redirect
On 04/07/2020 14:59, Brian Brombacher wrote:
On Jul 3, 2020, at 3:34 AM, Kapetanakis Giannis
wrote:
Hi,
My setup in relayd is like this:
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
redirect radacct {
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
I want to combine it in one redirect but the redirect forwards it to the first
port defined in listen for both radius and radacct ports.
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
Is there another way to do this or do I have to stick with two redirects?
thanks,
Giannis
Hi Giannis,
I have not tested your config or my advice for your config; however, my
assumptions are sticky-address is needed per udp port conversation for radius.
By contrast, if sticky was needed for the combination of both radius/radacct on
same backend host per source address or address/port, you cannot achieve that
reliably with least-states. I don’t know the radius protocols enough to know
the requirements.
Here’s my question after all that dribbling:
Have you tried using either of the following config options?
forward to destination
forward to nat
IIRC, in the past I had multiple TCP relay ports going to their specified ports
on the backend. I only needed to split things by address family (v4/6) for my
own purposes. I cannot remember if the directives above took port into
consideration. It might not be a far stretch to make that feasible with code
changes but I haven’t seen the relayd code paths in question so that’s a
complete guess (but I’m on my way to check ;). Also since I concentrated on
TCP relays, I don’t know how effective these directives would be for redirects.
My end config has separate relays per TCP service except passive FTP relaying.
Also, make sure your pf.conf has the right anchor. Only mentioning it because
your original email skips this detail. I doubt this would be missing if you
have a working setup already, so ignore if so.
Cheers,
Brian
Thanks for the answer Brian,
You 're probabaly right and least-states might not be the best choice.
My setup is a working one, but it only has one server (for now) in the
backend table so this hasn't come up so far.
I guess the best one would be
mode source-hash [key]
least-states [sticky-address]
The least-states option selects the address with the least active
states from a given address pool and considers given weights
associated with address(es). Weights can be specified between 1
and 65535. Addresses with higher weights are selected more often.
sticky-address can be specified to ensure that multiple connections
from the same source are mapped to the same redirection address.
Associations are destroyed as soon as there are no longer states
which refer to them; in order to make the mappings last beyond the
lifetime of the states, increase the global options with set
timeout src.track.
source-hash [key] [sticky-address]
The source-hash option uses a hash of the source address to
determine the redirection address, ensuring that the redirection
address is always the same for a given source. An optional key can
be specified after this keyword either in hex or as a string; by
default pfctl(8) randomly generates a key for source-hash every
time the ruleset is reloaded. sticky-address is as described
above.
G
