Messages

No reply yet? Maybe I should shorten my question:

Are your UPS outlets switched off after OPNsense shutdown or do your UPS outlets stay enabled after OPNsense shutdown?

Hey OPNsenseis :)

I configured NUT with an Eaton 5PX UPS. On power loss OPNsens shuts down as expected, but doesn't switch of the UPS. If power returns before battery depletion, there is no power cycle and my OPNsense stays off. I did some investigation and believe this is a bug, but before writing a bug report, I like to have some confirmation of this behaviour from other users.

What I did for testing:

• Pulled the power cord:
  OPNsense shuts down, UPS stayed on
• ran upsdrvctl -t shutdown from shell as suggested in [1]: Output looked promising:
  Network UPS Tools - UPS driver controller 2.7.4
  *** Testing mode: not calling exec/kill
  [...]
     0.001167   Shutdown UPS: UPS_1
     0.001230   exec:  /usr/local/libexec/nut/usbhid-ups -a UPS_1 -k
  


• ran upsmon -c fsd as suggested in [1]:
  OPNsense shutdown, UPS stayed on


• ran upsdrvctl shutdown (without -t):
  OPNsense did not shutdown but UPS switched off after some delay as expected.
  Note: Maybe I ran usbhid-ups -k instead. I can't check because I lost my history for obvious reasons :)
  

This makes me believe os-nut is missing step 8 in init scripts as described in [2]. At least, I couldn't find the necessary bits.
If someone confirms this behaviour, I would create a bug report for it.


[1] https://networkupstools.org/docs/user-manual.chunked/ar01s06.html#Testing_shutdowns
[2] https://networkupstools.org/docs/user-manual.chunked/ar01s06.html#Shutdown_design

Ich hab noch eine Seite gefunden mit der das gleiche Verhalten auftritt:
http://kamelopedia.net/ bzw. http://kamelopedia.net/wiki/Kamelopedia:Hauptseite, denn Ersteres bringt einen Redirect auf Letzteres und der Redirect funktioniert sowohl mit IPv6 als auch IPv4. Das Problem tritt erst danach auf:

Code Select Expand


curl -6 -v -o /dev/null  http://kamelopedia.net/wiki/Kamelopedia:Hauptseite
...
* TCP_NODELAY set
* Connected to kamelopedia.net (2a01:238:42ea:d900:e5d3:890d:85f6:9f7c) port 80 (#0)
> GET /wiki/Kamelopedia:Hauptseite HTTP/1.1
> Host: kamelopedia.net
> User-Agent: curl/7.53.1
> Accept: */*
>
> [hängt ewig]


IPv4 dagegen klappt:

Code Select Expand


curl -4 -v -o /dev/null  http://kamelopedia.net/wiki/Kamelopedia:Hauptseite
...
* TCP_NODELAY set
* Connected to kamelopedia.net (85.214.108.33) port 80 (#0)
> GET /wiki/Kamelopedia:Hauptseite HTTP/1.1
> Host: kamelopedia.net
> User-Agent: curl/7.53.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.26
< X-Content-Type-Options: nosniff
< Content-language: de
< Vary: Accept-Encoding,Cookie
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Date: Fri, 20 Oct 2017 19:27:30 GMT
< X-Varnish: 391412772 391407572
< Age: 4470
< Via: 1.1 varnish
< Connection: keep-alive
<
{ [955 bytes data]
...
* Connection #0 to host kamelopedia.net left intact


Vielleicht hilfts ja bei der Fehlersuche

Grüße
Woi

Bei mir lädt die Seite auch unendlich. Ich hab aber keine Zeit mir das jetzt näher anzugucken.

VDSL 100 mit Vectoring von DTAG, Dualstack mit IPv4 und IPv6 bis an die Clients, Modem ist ein Vigor 130, OPNsense ist aktuell. ICMPv6 hab ich händisch freigegeben. Bei deinem Test bekomme ich auch 10/10.  six.heise.de klappt auch.

To be honest, we do not wish to document this particular feature because it is a support nightmare.

Reading the code or searching the forum is ok to get the proper context here. :)

Code that does exist but is not documented could also be subject to change so documenting it "permanently" will let users thing we broke something if we want to change it / replace it.

We're working on another feature soon for "scheduled" updates which will be self-explanatory in the firmware settings section:

https://github.com/opnsense/core/issues/1798

Ok, that makes a lot of sense, at least for this particular feature.

That being said, documentation grows, we're likely going to release the sources for 18.1 if all goes well as well. Hopefully receive a bit of help from the community, too.

It would be great to allow for pull request for the documentation.  Indeed, that was something I planed  to create a feature request for  :)

That would be... awsome  8)

Oh my god. That was too obvious. Thanks for the quick reply.

But there is another thing in my mind: How do users, that do not follow the changelogs, get to know about this parameter?
Or more general: You're doing a great job and quick process with OPNsense, but I have the feeling documentation and help system are lagging behind.

@denn;s is this working for you?

@franco yesterday I set ALLOW_RISKY_MAJOR_UPGRADE as only parameter for the "Automatic firmware update" cron job. OPNsense is 17.1.11_1-amd64 and I was expecting an upgrade to 17.7.1 this night. But I'm still on 17.1.11_1. Did I missed something or did I found a bug? If so, do you like me to fill a prober bug report on github?

Additional info:

Code Select Expand


root@gw:~ # sudo --user=nobody  /usr/local/sbin/configctl firmware auto-update
OK


Code Select Expand


Sep 1 05:40:03 lighttpd[37099]: (log.c.217) server started
Sep 1 05:40:02 configd.py: generate template container OPNsense/WebGui
Sep 1 05:40:01 configd.py: [f15ebc76-1a80-4261-8cf8-dd59866b1adc] generate template OPNsense/WebGui
Sep 1 05:40:01 lighttpd[98929]: (server.c.1828) server stopped by UID = 0 PID = 36244
Sep 1 05:40:00 configd.py: [dbd634a1-c328-40c3-9ad0-e1b64b00eb3b] attempting automatic firmware update


Ich gebe Feedback direkt beim Patch: https://github.com/opnsense/core/commit/f31964a

Das scheint kein generelles Problem zu sein. Ich habe es jedenfalls auf meinem ALIX-Board mit CF-Karte in keiner 17.1.x gesehen.

Danke für die ausführliche Antwort , das war sehr aufschlussreich. Dein Fix erspart das DynDNS update ([1] Zwei Logeinträge weniger), aber behebt das Problem nicht grundsätzlich. Immerhin weiß ich jetzt wo ich gucken muss:
https://github.com/opnsense/core/pull/1524#issuecomment-296438567

[1]

Code Select Expand


Apr 23 14:32:57 configd.py: [4b16d7b3-62c6-44f3-9edc-e9c6bc7424ee] Reloading filter
Apr 23 14:32:56 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::105:105:3e9b:f014%pppoe0
Apr 23 14:32:56 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 62.155.240.20
Apr 23 14:32:56 UNKNOWN[11593]: resuming normal operation
Apr 23 14:32:56 UNKNOWN[11593]: can't join ipv6-allrouters on vr0
Apr 23 14:32:56 UNKNOWN[11593]: attempting to reread config file
Apr 23 14:32:55 UNKNOWN[11593]: sendmsg: Can't assign requested address
Apr 23 14:32:54 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::20d:b9ff:fe1c:cec0) (interface: wan) (real interface: pppoe0).
Apr 23 14:32:54 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.


FYI:
IPv6/Telekom Dualstack: Alle 15 min. rc.newwanipv6 und andere Logeinträge
https://forum.opnsense.org/index.php?topic=5037.0

Hallo zusammen,

ich betreibe meine OPNSense [1] an einem Telekom Vectoring-Anschluss und habe IPv6 wie unter [2] eingerichtet. Grundsätzlich funktioniert IPv6 auch (die Schildkröte auf kame.net tanzt, ein ping auf heise.de löst nach IPv6 auf, etc.)
Allerdings habe ich exakt alle 15 Minuten Meldungen im System Log [3], die mit Lags in Onlinespielen und Abbrüchen von VoIP-Telefonaten einhergehen. Außerdem ist mir aufgefallen das mein Rechner und die LAN-Schnittstelle der OPNSense zwar eine öffentliche IPv6-Adresse bekommen, die WAN-Schnittstelle jedoch nur eine Link-Local-Adresse.
Die einzige Beschreibung eines vergleichbaren Problems konnte ich hier finden: https://forum.opnsense.org/index.php?topic=4686.msg18186#msg18186
Ich frage mich nun ob hier ein Konfigurationsfehler auf meiner Seite vorliegt, ich auf einen Bug gestoßen bin den ich melden sollte oder das von mir beobachte Verhalten völlig normal ist? Leider ist dies bisher mein erster und einziger IPv6-Anschluß, so das ich keine Möglichkeiten zum vergleichen habe.  Es wäre daher  u.U. schon hilfreich zu wissen ob an anderen Telekom IPv6-Anschlüssen ebenfalls alle 15 Minuten Logeinträge zu beobachten sind und ob die WAN-Schnittstelle dort ebenfalls keine öffentliche IPv6-Adresse bekommt.

Besten Dank
Woi


[1]
Alix 2d13
Vigor 130
Telekom Vectoring mit 100/40 Mibit/s

OPNsense 17.1.4-i386
FreeBSD 11.0-RELEASE-p8
LibreSSL 2.4.5


[2]
* Firewall, Settings, Advanced:
     Allow IPv6 -> yes
* Interfaces, WAN
    General configuration:
       IPv6 Configuration Type ->  DHCPv6
    DHCPv6 client configuration
      Use IPv4 connectivity -> yes
      Request only a IPv6 prefix -> yes
      Directly send SOLICIT -> no
      DHCPv6 Prefix Delegation size -> 56
      Send IPv6 prefix hint -> yes
* Interfaces, LAN, General configuration
    IPv6 Configuration Type -> Tack Interface
    IPv6 Interface -> WAN
    IPv6 Prefix ID: -> 0
* Firewall, Rules, WAN:
     Action -> Pass
     Interface -> WAN
     TCP/IP Version -> IPv6
     Protocol -> IPV6-ICMP


[3]

Code Select Expand


Apr 21 14:19:59 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: (Success) IP Address Updated Successfully!
Apr 21 14:19:59 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wancustom'example.com'0.cache: 192.0.2.1
Apr 21 14:19:46 configd.py: [1b0b2fe9-8693-4f4c-a3b7-11e9dea0829b] Reloading filter
Apr 21 14:19:45 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::105:105:3e9b:f014%pppoe0
Apr 21 14:19:45 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 198.51.100.25
Apr 21 14:19:45 UNKNOWN[4485]: resuming normal operation
Apr 21 14:19:45 UNKNOWN[4485]: can't join ipv6-allrouters on vr0
Apr 21 14:19:45 UNKNOWN[4485]: attempting to reread config file
Apr 21 14:19:43 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::20d:b9ff:fe1c:cec0) (interface: wan) (real interface: pppoe0).
Apr 21 14:19:43 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.