Recently I've started to migrate some of my VPS's to Netcup
+as I have found their offerings more performant, and less expensive, than other
+VPS providers.
+However, it seems due to the way Netup's IPv6 network is set up causes some issues
+with FreeBSD, and allegedly other BSDs leading to loss of connectivity via IPv6.
A simple, portable, wrapper for the borg backup and restic utilities written in Nim.
- -Recently I've started to migrate some of my VPS's to Netcup
+as I have found their offerings more performant, and less expensive, than other
+VPS providers.
+However, it seems due to the way Netup's IPv6 network is set up causes some issues
+with FreeBSD, and allegedly other BSDs leading to loss of connectivity via IPv6.
I recently had a issue logged by a client where a room calendar in Microsoft Exchange 365,
+when invited to a meeting, shows the organizer's name in the subject instead of the actual subject.
+This may well be a desirable feature, but in the case it isn't, this is how it can be resolved.
This is a story all about how
-Your query got twist-turned upside down
-And I'd like to show an answer just sit right there
-It might not be fully accurate but I don't care
Hello. How are you? I am fine.
-
-You may know me from a few places, but likely on the Fediverse as the person that
-maintains a BirdsiteLIVE instance with the url birdsite.wilde.cloud.
I recently had a issue logged by a client where a room calendar in Microsoft Exchange 365,
+when invited to a meeting, shows the organizer's name in the subject instead of the actual subject.
+This may well be a desirable feature, but in the case it isn't, this is how it can be resolved.
Room calendars are useful for booking meetings which will take place in a room in an office. Normally, the process would be for somebody to have delegate permissions on this calendar, allowing them to enter a calendar entry into this calendar and invite the required attendees. In this case, everything works well - the room shows the event, including subject and content and invited parties can accept to reject the event depending on their availability.
+However, sometimes somebody wishes to create an event in their own calendar, and invite the room calendar to that event. In this case, it appears the default option is for the event in the room calendar to have its subject and content replaced by the organisers details. I'm sure this makes sense in some cases, but my client in this case does not find this desirable. Luckily, there is a solution.
+A single Powershell command can be used to set some options on a calendar to change the way that calendars processing works.
+First, connect to Exchange Online:
Connect-ExchangeOnline
+Once connected, you can issue the following command to show the current options for a particular calendar's processing:
+Get-CalendarProcessing - Identity "{The Calendar Name}" | fl
+Which should show something like the below:
+AutomateProcessing : AutoAccept
+AllowConflicts : False
+AllowDistributionGroup : True
+AllowMultipleResources : True
+BookingType : Standard
+BookingWindowInDays : 180
+MaximumDurationInMinutes : 1440
+MinimumDurationInMinutes : 0
+AllowRecurringMeetings : True
+EnforceAdjacencyAsOverlap : False
+EnforceCapacity : False
+EnforceSchedulingHorizon : True
+ScheduleOnlyDuringWorkHours : False
+ConflictPercentageAllowed : 0
+MaximumConflictInstances : 0
+ForwardRequestsToDelegates : True
+DeleteAttachments : True
+DeleteComments : True
+RemovePrivateProperty : True
+DeleteSubject : True
+AddOrganizerToSubject : True
+DeleteNonCalendarItems : True
+TentativePendingApproval : True
+EnableResponseDetails : True
+OrganizerInfo : True
+ResourceDelegates : {**Names of delegates are here**}
+RequestOutOfPolicy : {}
+AllRequestOutOfPolicy : False
+BookInPolicy : {}
+AllBookInPolicy : False
+RequestInPolicy : {}
+AllRequestInPolicy : True
+AddAdditionalResponse : False
+AdditionalResponse :
+RemoveOldMeetingMessages : True
+AddNewRequestsTentatively : True
+ProcessExternalMeetingMessages : False
+RemoveForwardedMeetingNotifications : False
+AutoRSVPConfiguration : Microsoft.Exchange.Data.Storage.AutoRSVPConfiguration
+RemoveCanceledMeetings : False
+EnableAutoRelease : False
+PostReservationMaxClaimTimeInMinutes : 10
+MailboxOwnerId : Room Calendar Name
+Identity : Room Calendar Name
+IsValid : True
+ObjectState : Changed
+You'll see there are a few options set to "True" which could be toggled - Delete Subject, Delete Comments and Delete Attachments - they should be fairly self explanitory.
+You can toggle these options by issuing the following command:
Set-CalendarProcessing -Identity "Room Calendar Name" -DeleteComments $false -DeleteSubject $false -DeleteAttachments $false
+This simply disables those options, so now the subject, comments and attachments will not be deleted when the calendar processes the event.
+There is one further options which may, or may not, be helpful to disable - AddOrganizerToSubject. This option adds the organizer's name to the start of the Subject. This may be useful, but my client also wanted this switched off which can be done with the following command (or, indeed, adding the flag to the previous command).
Set-CalendarProcessing -Identity "Room Calendar Name" -AddOrganizerToSubject $false
+And there we are, new events now will appear in the calendar as desired - with full Subject, Comments and Attachments.
+Previous entries will not update automatically, the organizer must go into each one and re-send it (no need to change anything, just re-send it and press "Send Anyway") which will update the event in the room calendar as desired.
Recently I've started to migrate some of my VPS's to Netcup
+as I have found their offerings more performant, and less expensive, than other
+VPS providers.
+However, it seems due to the way Netup's IPv6 network is set up causes some issues
+with FreeBSD, and allegedly other BSDs leading to loss of connectivity via IPv6.
I have moved to Netcup for a few reasons: 1. expense, 2. experienced better performance than my previous provider, and 3. ability to provide my own ISOs for OS install.
+Netcup in my experience are great, I have a few Debian systems with them that have been super reliable.
+But, I want to use FreeBSD for my projects, so my new VPSs run FreeBSD.
All is well on the IPv4 front, the DHCP client picks up my provided IPv4 address and connectivity is there, great. I still manually set it statically for consistency, but either way it works great.
+IPv6 however, different story. FreeBSD doesn't seem to get it's provided IPv6 address via
+SLAAC, so no address gets associated. That's OK though, I can set it statically in
+rc.conf. Netcup provide a /64 IPv6 subnet for each VPS, so I can pick any IPv6 in the range
+they have provided, but they also sent one via email, so I'll just use that for now.
...
+ifconfig_vtnet0_ipv6="inet6 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff/64"
+...
+2a03:4000 is Netcup's network I believe with AAAA defining a certain part of that network.
+BBBB is the subnet provided to me with cccc:dddd:eeee:ffff being the range of address I can use in that subnet.
Netcup's IPv6 network is switched, not routed, I'm sure there's a reason for this, and I'm sure it's sensible, but for now the important bit is that the IPv6 gateway should always be fe80::1%vtnet0 (where vtnet0 is the external interface name) rather than another 2a03:4000::AAAA:BBBB IPv6 address. I pop that into my rc.conf as well.
...
+ipv6_defaultrouter="fe80::1%vtnet0"
+...
+Reboot the VPS, and all works well. ping6s work, curls to IPv6 addresses work, incoming IPv6 connections work. Great! Done...
Not Done.
+After about 10 minutes of connectivity, IPv6 just drops out. ping6s fail, curls fail, no connectivity on IPv6 from the outside world. Drat.
+Reboot the VPS again... oh, it's back. Great. Wait a few minutes, it goes again. Reboot, back, wait, gone. And so on.
Obviously the first thing I'm thinking is firewall. So I disable pf and reboot and wait again - no difference, IPv6 just stops working after a few minutes.
In my fairly inexperienced IPv6 knowledge (it's not big in the UK... yet), using fe80::1 as a gateway feels weird, so I try a traceroute6 anyaddress.com to see what the first hope on the route is (it must be my actual gateway, right?) and pop that address into my ipv6_defaultrouter= config in rc.conf.
+Reboot... no joy, no IPv6 connectivity at all. OK, I set that back.
I browse the netcup forums a bit, find a handful of posts of people experiencing the same issue. Some refer to people leasing an additional IPv6 lease from Netcup and using that instead which allegedly works for them. I did this, it did not work for me - the IPv6 worked, for about 10 minutes again, then dropped off as before.
+FreeBSD forums is the same sort of thing, articles from a few years ago.
Both forums seem to have posts saying the issue lies in the fact the IPv6 address and [actual] gateway exist in different subnets.
+My simple understanding of this is: the gateway may have address 2a03:4000:AAAA::2 which is in a /48 subnet, and my VPS may have IPv6 address 2a03:4000:AAAA:BBBB::1234 which is a /64 subnet. Because they do not exist on the same subnet, something happens at some point to stop them being able to communicate. I believe this "something" is to do with Netcup's switching (rather than routing).
Of the people experiencing this, some have had the IPv6 Connectivity come back and drop off again on its own. I haven't experienced this, but perhaps I'm just impatient.
+So, I write a post on the FreeBSD forums with a bit of information of things I've tried asking for help. I like this to a Fediverse post and wait for responses. It doesn't take long.
+@fab responds with the idea of using a /48 prefix instead of /64.
+Given what I have learned up to this point, this could make sense - the gateway is in a /48 of the same first 48 bits of my /64 subnet (2a03:4000:AAAA)
+after all, so why not put my IPv6 in that same subnet. It could cause issues with communication with other servers in different /64 subnets within the same /48 subnet, but let's risk it for now.
Unfortunately, I experience the same issues again here. After about 10 minutes the connectivity drops off. Reboot, OK, wait, gone.
+Maybe it's because I'm a native English speaker that I didn't do this before, but I
+thought I'd look more in depth at the Netcup forums and found this thread by a German speaker having the same issues. Fortunately, in browser translate was able to translate it for me and I was able to get the gist of what was going on.
+This post in particular was interesting, along with this post by the same author - they suggest two things I've tried before - using a /48 prefix instead of /64, and setting a route for the actual gateway address (not the fe80::1 address), but I didn't try them both at the same time!
I'll get my default gateway via traceroute6 again
> traceroute6 netcup.de
+traceroute6 to netcup.de (2a03:4000::e01e) from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff, 64 hops max, 28 byte packets
+ 1 2a03:4000:AAAA::2 0.472 ms 1.058 ms 0.604 ms
+Pop that in my rc.conf and also change my prefix to /48 while I'm there.
...
+ifconfig_vtnet0_ipv6="inet6 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff/64"
+ipv6_defaultrouter="2a03:4000:AAAA::2"
+...
+Reboot. It's working. Wait. It's still working! Wait a little longer. Still working!
+This is progress! ping6s and curls are working great!
+Oh, incoming connections aren't so good...
# From another host
+> ping6 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff
+...
+From 2a00:11c0:AA:B::fff icmp_seq=4 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=5 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=6 Destination unreachable: Address unreachable
+So ping6s go out OK, but nothing is coming in.
As previously mentioned, Netcup switches their IPv6 addresses, they don't route them.
+I'm not going to pretend I know exactly what this means, but it feels to me that it's
+likely the gateway could "switch" periodically, and in normal circumstances the fe80::1 can be aware of this and cater for it, just not for the BSDs.
Maybe... I could try switching my default route to another gateway IP? This Post on the Netcup thread seems to suggest there could be a number of 2a03:4000:AAAA::X gateways that could be routers...
route -6 add default 2a03:4000:AAAA::3
+Meanwhile on another host...
+...
+From 2a00:11c0:AA:B::fff icmp_seq=4 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=5 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=6 Destination unreachable: Address unreachable
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=1308 ttl=48 time=5.62 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=1309 ttl=48 time=4.81 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=1310 ttl=48 time=5.04 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=1311 ttl=48 time=4.80 ms
+...
+PROGRESS!
+At this point I'm excited. I switch my rc.conf to use that different gateway. I haven't rebooted yet but I see no reason to just yet. Right now I'm at about icmp_seq=5000 on my outgoing ping6s and incoming are still successful. But... on my remote server...
64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=4504 ttl=48 time=4.86 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=4505 ttl=48 time=4.93 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=4506 ttl=48 time=4.81 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=4507 ttl=48 time=4.87 ms
+From 2a00:11c0:AA:B::fff icmp_seq=508 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=509 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=510 Destination unreachable: Address unreachable
+Drat!
+Outgoing ping6s still seem OK though... let's switch that default route again
route -6 add default 2a03:4000:AAAA::2
+and on the other server:
+...
+From 2a00:11c0:AA:B::fff icmp_seq=4 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=5 Destination unreachable: Address unreachable
+From 2a00:11c0:AA:B::fff icmp_seq=6 Destination unreachable: Address unreachable
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=6323 ttl=48 time=5.42 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=6324 ttl=48 time=4.72 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=6325 ttl=48 time=5.14 ms
+64 bytes from 2a03:4000:AAAA:BBBB:cccc:dddd:eeee:ffff: icmp_seq=6326 ttl=48 time=4.94 ms
+...
+OK, so I can dynamically bring connectivity back if/when it drops. I can probably script this in some way to happen automatically too. Is it perfect? No, but it's something.
+This is where I am right now. I have a sort-of almost stable IPv6 connection that works most of the time, but it's nowhere near ideal. I am continuing my research and I will update this post if/when I discover anything that stablises it completely.
+In the meantime, I welcome any comments about things that I could do further to help, or, indeed, comments for reasons why I should not have done any of the above. I'm familiar with networks, but with IPv6 being ignored in the UK my knowledge of it is a little lacking.
If you want to send any comments, please do so either on this FreeBSD Forum thread or on this Fediverse thread.
+ +This is a story all about how
+Your query got twist-turned upside down
+And I'd like to show an answer just sit right there
+It might not be fully accurate but I don't care
Hello. How are you? I am fine.
+
+You may know me from a few places, but likely on the Fediverse as the person that
+maintains a BirdsiteLIVE instance with the url birdsite.wilde.cloud.
Rate Stuff with Ross, quite simple.
- -If you have a bread maker:
-Without a bread maker:
-After a few hours of rising time (longer if you're using sourdough starter) -your dough will, hopefully, have risen enormously. You can now use it. -I'll be adding recipes for pizzas, naans and other -things that use this dough here, eventually.
-Rate Stuff with Ross, quite simple.
+ +If you have a bread maker:
+Without a bread maker:
+After a few hours of rising time (longer if you're using sourdough starter) +your dough will, hopefully, have risen enormously. You can now use it. +I'll be adding recipes for pizzas, naans and other +things that use this dough here, eventually.
+ +