Messages

[amdsbwd_load]

Late reply, but I just got it to work on my apu2d4

First, be sure that you actually have an apu2 board. Some apu1 were marketed as apu2 and apu4 even tho apu2 to apu6 are completely different boards. If your board has a BR2032 battery, it's apu1, if it has LR44, it's apu2.

Second, have a reasonably recent CoreBOOT flashed that actually allows configuration of the Watchdog in BIOS (4.0.26 and higher should do).

Next, open a root shell and do a

Code Select Expand

kdload amdsbwd

If that confirms having found a Watchdog device (the message should be something like

amdsbwd0: <AMD ... Watchdog Timer> at iomem ......... on isa0

If so, continue.

1) add a Tunable amdsbwd_load, set its value to yes
2) reboot, watch the boot output for that same message from when you loaded the module by hand. If not, recheck your tunable until it properly loads the module during boot
3) reboot, enable watchdog in BIOS. I'd recommend at least 300 seconds to be on the safe side

If you ever need to reinstall your box, be sure to disable the watchdog before booting the installer, and re-enable it only after having restored your config. Not loading the module (which the installer won't do) *will* reliably reset your board after the set amount of time.

Disclaimer: works for me, your results may vary

found a note in the OpenVPN config page stating that the "Advanced" field where you can set arbitrary OpenVPN server config directives will be removed in the future due to being insecure. I'm currently using those options to push some client directives, such as "route x.x.x.x y.y.y.y" and "dchp-option DNS z.z.z.z".

I presume I can change the route-pushing to using the "IPv4 local network", but I can't figure out how to push new DNS servers using the "official" options fields. What am I missing?

Hi y'all,

I have some trouble getting dhcrelay to work properly in my setup.

I have a client behind a OPNsense box, which is connected to my corporate network via OpenVPN. The OPNsense box has the dhcrelay configured to relay all DHCP requests to my DHCP server. When the client issues a DHCPDISCOVER, I can see the agent request reaching my server, and a proper DHCPOFFER is being sent back to the OPNsense box. A packet capture on said box on the OpenVPN interface shows the packet arriving, but it's not being forwarded to the client.

From what I've read in the ISC DHCRelay package docs, it's probably because the service is bound to the LAN interface only, where it should at least have the OpenVPN interface be defined as upstream interface. But the GUI does not permit testing this assumption.

Question 1: how can I manually start the dhcrelayd with custom command line switches to test my assumption?

Question 2: If my tests prove my assumption to be correct, how do I add the command line switches in a reboot persistent manner?

Question 3: should I file a bug report on GitHub?

Is there a *plausible* reason why aliases are not allowed to have a Hyphen (-) in the name? It's kinda counter-intuitive to write the alias differently from the actual hostname (i.e. h_TD_TASSO_DC_01 as alias for TD-TASSO-DC-01)

EDIT: after some browsing the forums, I found the GitHub tracker and opened the request there.

The current design only aliases Port Numbers to names. Designing a proper ruleset for protocols that utilize both UDP and TCP (on different ports) would require at least two rule definitions (one for the TCP rule, one for the UDP rule) and at least two Ports Alias definitions (one for the TCP ports, one for the UDP ports). Creating a proper "protocol" Alias (which contains both proto and port definitions) would simplify the ruleset.

Example:

Protocol foo uses TCP port 4711 and UDP port 1234. With the current architecture, there's the following definitions

Port alias FOO_UDP -> 1234
Port alias FOO_TCP -> 4711
rule FOO_TCP -> uses Proto TCP and references Port alias FOO_TCP
rule FOO_UDP -> uses Proto UDP and references Port alias FOO_UDP

With my suggested design, there would only be one rule and one alias:

Proto Alias FOO -> TCP/4711, UDP/1234
rule Foo -> uses Proto alias FOO

EDIT: after some browsing the forums, I found the GitHub tracker and opened the request there.

To further simplify ruleset and alias definitions, it would be useful to be able to use Aliases within an Alias definition.

Consider the following simplified example. There's 2 Servers (Host_A and Host_B), that offer 3 Services. Host A offers Service_A, Host B offers Service_B, and they both offer Service_C. Right now, I would need to define 3 Aliases:

Host_A -> 10.10.10.10
Host_B -> 10.10.10.20
Hosts_AB -> 10.10.10.10, 10.10.10.20

Also, there's 3 rules for the  services

Rule Service_A uses the alias Host_A
Rule Service_B uses the alias Host_B
Rule Service_C uses the alias Hosts_AB

So far, so good. But what happens, if Host_A's IP address changes? With the current design, I'd have to check every alias and see if it contains Host_A's old IP address and change that, that would be 2 definitions to be changed in this overly simplified example (probably a few more in a production environment).

If I were able to use aliases within an alias definition, it would require only one change - the definition of Host_A. The Group definition would automatically be right again because it references the (now changed) definition of Host_A:

h_Host_A -> 10.10.10.10
h_Host_B -> 10.10.10.20
g_Group_AB -> h_Host_A, h_Host_B