Does anyone else bump into the issue, that the fly.io website does not load if requested via IPv6 on Mac? I tried Safari, Chrome and curl and neither work:
Could easily be a path MTU issue? I don't currently have working IPv6, but on TCP/IPv4, the server->client handshake packets I get back from fly.io are full length packets. If your tcpv6 MSS is set incorrectly, and some other not great things are happening in the path, then you might not be able to receive large packets.
I'm not aware of a simple to use test site for this on IPv6 (I've got one for IPv4, but my server host doesn't do IPv6 either, and using a tunnel will limit the ranges I can test, etc)... so you'll need to test ye olde fashioned way.
I don't have a mac, but if the man page[1] is right, something like this should work to see how big of a packet you can successfully send and receive:
ping -6 -D -G 1500 -g 1400 fly.io
(you may need to run as root to set packet sizes). You should get back a list of replies with say 1408 bytes, then 1409, etc. The last number you get back is effectively the largest IPv6 payload you can receive (on this path, it could be different for other paths), and if you add the IPv6 header length of 40, that's your effective path MTU.
Use tcpdump to see what TCP MSS is being sent on your outgoing SYN packets, for IPv4, the MSS is MTU - 40 (20 for IPV4 header, 20 for TCP header), for IPv6, the MSS should be MTU - 60 (40 for IPv6 header, 20 for TCP header). If your TCP MSS is higher than the observed path MTU to fly.io, that's likely the immediate cause of your problem.
If you're using a router, make sure it knows the proper MTU for the IPv6 connection, and enable MSS clamping on IPv6, if possible --- or make sure the router advertisement daemon shares the correct MTU.
Just for reference, the ping command is a little different
sudo ping6 -D -G 1500,1400 fly.io
I set an MSS to 1492 which pfsense (my router) translates to an MSS clamp of 1492-60 for IPv6 and 1492-40 for IPv4. This is a German Deutsche Telekom Fiber connection. Now everything works fine, I can request fly.io (and also discovered that https://ipv6-test.com was not working before and now does with the MSS clamping)
Does MSS clamping have any disadvantages? Are there any alternatives in my case?
Excellent, happy to help, glad you figured out the right command!. 1492 MTU is consistent with PPPoE, or a network where they didn't want to run a separate MTU for PPPoE and straight ethernet.
The only downside to MSS clamping is the computational expense of inspecting and modifying the packets. On a residential connection, where you're running pfsense already, it's probably not even noticeable; but your ISP wouldn't be able to do clamping for you, because large scale routers don't have the processing budget to inspect packets at that level. I've seen some MSS clamping implementations that only clamp packets going out to the internet, and not the return packets... that can lead to problems sending large packets (which isn't always very noticeable, actually; a lot of basic browsing doesn't send packets large enough to hit this, unless you go to a site that sets huge cookies or do some real uploading)
The alternative would be to run a 1492 MTU on your LAN, but that has the marginal negative of reducing your maximum packet size for LAN to LAN transfers.
I tried to deploy an application I currently have running on Digital Ocean App Platform (their Heroku competitor) also on fly.io. The app is using Python/Django and Postgres, ideal to test.
I must say the deployment experience was great, stuff just worked, brilliant.
One question in case someone tried that: How can you customize the postgres config? I want to enable pg_stat_statements, and one needs to add `shared_preload_libraries = 'pg_stat_statements'` to the config for this. One could also make this the default maybe? It is the default on most cloud providers (AWS RDS, Digital Ocean).
> Fly Postgres clusters are just regular Fly applications. If you need to customize Postgres in any way, you may fork this repo and deploy using normal Fly deployment procedures. You won't be able to use fly postgres commands with custom clusters. But it's a great way to experiment and potentially contribute back useful features!
Just for reference: The latest release for Django Rest Framework is not compatible with Django 4.0 yet. At least my first attempts failed due to a missing `pytz` dependency. This is fixed in the `master` of DRF on Github. Installing `pytz` explicitly again to your project fixes DRF for now.
> The Python standard library’s zoneinfo is now the default timezone implementation in Django.
> This is the next step in the migration from using pytz to using zoneinfo. Django 3.2 allowed the use of non-pytz time zones. Django 4.0 makes zoneinfo the default implementation. Support for pytz is now deprecated and will be removed in Django 5.0.
> …
> To give time for such an audit, the transitional USE_DEPRECATED_PYTZ setting allows continued use of pytz during the 4.x release cycle. This setting will be removed in Django 5.0.
Vimcar | Berlin, Germany | Full-Time | Head of Engineering | https://vimcar.com
Vimcar is becoming the market leader for vehicle fleet management in the SMB market in Europe. We have 65k customers and 110k vehicles connected to our platform. We get live data from the vehicles (i.e. location) and try to add the most customer value based on this data. Tech stack is AWS, Python, TypeScript, React.
We are searching for a Head of Engineering who directly reports to the CTO. Responsibilities including growing the six teams and their team leads, iterating on our processes and keeping an overview on our architecture.
A perfect candidate would have experience as a leader of leaders and be willing to relocate to Berlin. We offer Visa sponsorships. Office language is English.
Vimcar provides vehicle fleet management for SMBs in Europe, thus helping small companies to keep track where their cars are and optimize how their are utilized.
We are well funded with more than 70k paying customers and more than 100k connected cars. Each of these cars is constantly transmitting live data to our servers (so it is IoT :-D). Our business is strong despite the current situation, so we want to grow our tech team.
Technologies include Python, Typescript, React, AWS (including AWS CDK for IaaC), Kotlin, (recent) Java, Docker, Jenkins.
Office in central Berlin, Germany, close to public transport. Office language is English.
Open Positions, with more details and application form:
MapOut is such a beautiful app, I'm using it very often. If you are doing any outdoor sports or even just wanting to get to know your surrounding, I heavily recommend MapOut on iOS. Worth every euro. The developers are also very responsive in case you have any questions.
