Firefox toLocaleString displays wrong time on OpenBSD
I'm confused about Firefox's handling of Date objects on OpenBSD.
Why: Some Firefox browser extensions that display dates using
Date.toLocaleString or Date.toLocaleDateString can cause an incorrect
date to be displayed. For example, using a credit card expiration
displayed as "01/23" when it really expires in February 2023 will make
payments fail.
Synopsis: Calling toLocaleString without parameters on a date object
seems to yield the wrong time.
Description: Calling toLocaleString without parameters yields a
time that is one hour off for CST and two hours off for CDT. This
seems to happen only on Firefox with OpenBSD -- not on Chromium on
the same machine, nor on Firefox on other operating systems that
I've tried.
This problem will show up if you go to Web Developer -> Web Developer
Tools and try any dates in the console.
However, if you are in a Preferences tab and try it in the web
developer console, the error will NOT show up.
The error will also NOT show up if you use Date.toLocaleString
within a regular web page.
It only appears for me from the browser extension that uses
Date.toLocaleString, and in the developer console from a tab that
is not "Preferences."
I think this is a Firefox bug and have reported it to Mozilla.
I've reproduced the error on many OpenBSD machines for the last
several months all running -current, with various version of Firefox,
including 88.0.
(My first attempt to get the source from ports failed because of
an anemic machine, but I will try again with more memory.)
Sadly, I've been banging my head against this problem for a long
time. I initially and stupidly submitted to the wrong forum, and
compounded the problem with an ill-formatted date, although I had
tried valid dates as well. My example was unfortunate because, as
far as I can tell, any date will generate this problem.
My BIOS time is set to UTC and /etc/localtime points to US/Central.
I've also tried changing the BIOS time to my local time and setting
kern.utc_offset, but nothing changed.
I also tried the Firefox option to use the operating system's setting
to format dates just to see if that might affect anything, not
expecting it to change anything. Indeed, nothing changed.
As far as I can tell from reading developer.mozilla.org about
Date and Date.prototype.toLocalString and international formats, etc.,
calling toLocaleString without parameters might use an
unpredictable format, but the time displayed should be local time.
Some forum posts such as
https://stackoverflow.com/questions/33083936/
convert-date-to-local-time-zone-with-tolocalestring-method-firefox
say this is a bug in Firefox.
How-To-Repeat:
>From Web Developer -> Web Developer Tools in Firefox:
(with input and output marked, and comments starting with #)
# I've created the dates with new Date but
# new Date(Date.UTC(.)) doesn't change the results
# of the call to toLocaleString
# create date in Central Standard Time. so far so good
INPUT: event1 = new Date(2021, 0, 1, 12, 0, 0)
OUTPUT Date Fri Jan 01 2021 12:00:00 GMT-0600 (CST)
# output below of toLocaleString() is one hour before local
# time. Happens to match Canada/Mountain
INPUT: event1.toLocaleString()
OUTPUT: "1/1/2021, 11:00:00 AM"
INPUT: event1.toLocaleString('en-US', {timeZone: "Canada/Mountain"})
OUTPUT: "1/1/2021, 11:00:00 AM"
INPUT: event1.toLocaleString('en-US', {timeZone: "US/Central"})
OUTPUT: "1/1/2021, 12:00:00 PM"
# create date in Central Daylight Time. so far so good
INPUT: event2 = new Date(2021, 3, 29, 12, 0, 0);
OUTPUT: Date Thu Apr 29 2021 12:00:00 GMT-0500 (CDT)
# output below of toLocaleString()is two hours before local
# time. Happens to match Canada/Pacific
INPUT: event2.toLocaleString()
OUTPUT: "4/29/2021, 10:00:00 AM"
INPUT: event2.toLocaleString('en-US', {timeZone: "Canada/Pacific"})
OUTPUT: "4/29/2021, 10:00:00 AM"
INPUT: event2.toLocaleString('en-US', {timeZone: "US/Central"})
OUTPUT: "4/29/2021, 12:00:00 PM"
Fix: A workaround in the console: specify parameters to toLocaleString.
To workaround the display problem in the browser extension, set
privacy.resistfingerprinting to true. I think everything looks like
UTC, so any conversion problems seem to go away.
BGP circular routing
Hi, I guess this is not related to bgpd, but I hope there are skilled network admins here who can give me advice. I have a problem with circular routing on a site which talks BGP with two upstream providers, with traffic to site which has static default route over third ISP: --> ISP1 --> ISP3 --> SITEASITEB <-- ISP2 <-- ISP3 <-- I tried to prepend self / neighbor to ISP2 - no change (ISP1 has best routes for 99% of the prefixes, including to SITEB). I contacted ISP2, they said the problem is with ISP3. I contacted ISP3, they said ISP2 announces my prefix (they're my LIR) so the best route is over them. I contacted ISP2 again, they said they prepended my prefix to ISP3, but situation is the same. Is it OK for ISP2 (my LIR) to announce and prepend my prefix? I thought I should be in control of that. Is there anything I can do about the situation? Thank you in advance, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
aggr not load balancing
I switched from trunk to aggr on a "OpenBSD 6.8 GENERIC.MP#5 amd64" and it isn't load balancing across the two configured links. The remote side is a Cisco ASR9k with the same configuration. Is that expected? $ cat /etc/hostname.aggr0 trunkport bge0 trunkport bge1 description "BE2 to ASR9k" inet 192.168.200.12 255.255.255.240 up $ifconfig bge0: flags=8843 mtu 1500 lladdr fe:e1:ba:d0:54:6d index 1 priority 0 llprio 3 trunk: trunkdev aggr0 media: Ethernet autoselect (1000baseT full-duplex) status: active bge1: flags=8843 mtu 1500 lladdr fe:e1:ba:d0:54:6d index 2 priority 0 llprio 3 trunk: trunkdev aggr0 media: Ethernet autoselect (1000baseT full-duplex) status: active aggr0: flags=8843 mtu 1500 lladdr fe:e1:ba:d0:54:6d description: BE2 to ASR9k index 7 priority 0 llprio 7 trunk: trunkproto lacp trunk id: [(8000,fe:e1:ba:d0:54:6d,0007,,), (8000,70:e4:22:67:2a:1e,000C,,)] bge0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:54:6d, key 0x7, port pri 0x8000 number 0x1 bge0 lacp actor state activity,aggregation,sync,collecting,distributing bge0 lacp partner system pri 0x8000 mac 70:e4:22:67:2a:1e, key 0xc, port pri 0x8000 number 0x2 bge0 lacp partner state activity,aggregation,sync,collecting,distributing bge0 port active,collecting,distributing bge1 lacp actor system pri 0x8000 mac fe:e1:ba:d0:54:6d, key 0x7, port pri 0x8000 number 0x2 bge1 lacp actor state activity,aggregation,sync,collecting,distributing bge1 lacp partner system pri 0x8000 mac 70:e4:22:67:2a:1e, key 0xc, port pri 0x8000 number 0x1 bge1 lacp partner state activity,aggregation,sync,collecting,distributing bge1 port active,collecting,distributing groups: aggr egress media: Ethernet autoselect status: active inet 192.168.200.12 netmask 0xfff0 broadcast 192.168.200.15 inet6 fe80::fce1:baff:fed0:546d%aggr0 prefixlen 64 scopeid 0x7 $ netstat -in NameMtu Network Address Ipkts IfailOpkts Ofail Colls bge01500fe:e1:ba:d0:54:6d32188 0 368 0 0 bge11500fe:e1:ba:d0:54:6d 8266100 0 7852958 0 0 aggr0 1500fe:e1:ba:d0:54:6d 8297364 0 7852590 0 0 aggr0 1500 192.168.200. 192.168.200.128297364 0 7852590 0 0 aggr0 1500 fe80::%aggr fe80::fce1:baff:f 8297364 0 7852590 0 0
Re: BGP circular routing
On 2021-04-29, Marko Cupać wrote: > I guess this is not related to bgpd, but I hope there are skilled > network admins here who can give me advice. > > I have a problem with circular routing on a site which talks BGP with > two upstream providers, with traffic to site which has static default > route over third ISP: > > --> ISP1 --> ISP3 --> > SITEASITEB > <-- ISP2 <-- ISP3 <-- Asymmetric routing (circular suggest that it's looping so you have no working connecticity, which I tuink ks not what you're describing). > I tried to prepend self / neighbor to ISP2 - no change (ISP1 has best > routes for 99% of the prefixes, including to SITEB). I contacted ISP2, > they said the problem is with ISP3. I contacted ISP3, they said ISP2 > announces my prefix (they're my LIR) so the best route is over them. I > contacted ISP2 again, they said they prepended my prefix to ISP3, but > situation is the same. > > Is it OK for ISP2 (my LIR) to announce and prepend my prefix? I thought > I should be in control of that. > > Is there anything I can do about the situation? You can't do much to control incoming traffic though you can sometimes influence it. But you do control which routes you accept/prefer. If you want to avoid the assymetric path, you need to prefer ISP2's announcwments for SITEB, for example you could match and give it a higher localpref. Is it causing a problem though? This is completely normal and expected on the internet. > Thank you in advance, >
Lenovo Thinkstation Intel Xeon DDB upon boot
Good day, I'm trying to install OpenBSD on an old Inter Xeon Lenovo Thinkstation, but it will properly install, on reboot fails on PCI8 enumeration (or PCI6 when I enable only PCIE with the graphic card). I checked internally, nothing fancy seems installed, I disabled most bios features if not all, still the same error at the same point inside the kernel. DDB doesn't allow to do anything, the keyboard is non responsive. I'll try get more informations, meanwhile has some of you information on compatibility issue and how to deal with this for the Thinkstation or Xeon processors ? I installed the i386 OpenBSD 6.8. I can have a shell from finishing the install process, that works. Thanks Jean-François
