SMB-over-QUIC File Sharing on older Windows
Posted by Eion Robb in Uncategorized on 2026-07-21
So something new that came out with Windows Server 2025 is the option for hosting Windows File Sharing shares (aka Samba or SMB) over a UDP protocol, QUIC. Funnily enough, this has been named SMB over QUIC. The benefits being that it uses a newer TLS 1.3 connection and is a lot easier to secure, and so works really well as an alternative for normal Windows File Sharing over the older TCP connections and having to mess around with VPNs or other things to be able to get a secure connection. Also pretty cool is that SMB-over-QUIC is available in Samba server on Linux as of version 4.23.0.
OK Yes, I know the rest of the world has moved on with web access for file shares, eg through Sharepoint or Nextcloud or something else, but humour me here!
So I got thinking, is this really the bog-standard SMB protocol over a QUIC connection, or is it all marketing? The idea that it took a while to come out on Samba made me think there was some magic voodoo going on here. I mean, sure I probably could have just looked at the Samba source code and figured it out, but I’m a coder! I don’t have time to read other peoples code!
I couldn’t easily test out the new Samba because my Linux machine didn’t have the quic.ko kernel module, but coincidentally I had an old Windows Server 2012 server that I was decommissioning and a terrible nagging thought that wouldn’t leave me alone. Yes, it was: "could I make this new fangled silliness work with a 14 year old server?" It was as if all the dark evils of the world possessed me for a brief moment, and the madness seemed to make sense.
So out I jumped out and slapped QUIC on top of my server with what was effectively a QUIC proxy: GOST, a Golang project that routes traffic between different protocols and it had support for QUIC. I redirected QUIC UDP port 443 to my TCP 445 Windows File Server then connected through from my Win11 client using net use Z: \\server.example.com\share /TRANSPORT:QUIC /SKIPCERTCHECK aaand it didn’t work. Darn. So, I fired up Wireshark and found that the Windows client would try to set up the TLS1.3 connection with a unique ALPN of "smb" but my GOST instance wasn’t configured with that. Tweaking the GOST config file still didn’t work, and it turned out to have a hard-coded ALPN of "h3, quic/v1" baked into the source.
I spun off a GitHub ticket, but didn’t let the thought go.
Instead, I vibed up a little wrapper utility that would provide the same, and it sorta kinda mostly worked!… but only on my Linux box. Turns out the C# libs for QUIC need OpenSSL but that’s only used on the Linux builds and there were lots of hoops to jump through to get that building on Windows. I could run the relay on my Linux box and point it at the old Windows Server, but: Blegh. No one really wants to have to run a whole extra server just to do a nasty hack, right? Just imagine the carbon-miles on that extra server hop!
But then the GOST devs changed up their code pretty quick, and spinning up a GOST server (with a free wildcard cert from LetsEncrypt) it worked! The net use works great!
The downside was that throughput was a lot slower. Likely because the protocol relaying was happening in software using CPU rather than any direct low-level kernel/service, but it did prove that yes, it was actually just the old SMB protocol running over QUIC and not some magic new protocol with a fancy marketing term. Huzzah!
(Yes, this is a terrible idea, no you shouldn’t use it in production. grim just negged me into writing a blog post after pointing out the last one was a million years ago or something.)
Four more prpls
It suddenly occurred to me that I never posted about the new prpls that I’ve written since the Hangouts prpl. Today we shall fix that.
Read the rest of this entry »
Building for iOS5 with XCode 8
Posted by Eion Robb in Uncategorized on 2016-11-18
Part of my day job is creating a mobile app, of which one of the platforms we deploy to is iOS. We still have some users out there on iPad 1’s and the latest version of iOS that’s available for them is 5.1.1, which the latest version of XCode (version 8.1 at time of writing) doesn’t support.
Up to and including XCode 8.0 we’ve been able to build for iOS5 without trouble just by changing the “Development Target” setting to 5.1.1, however XCode 8.1 complains with an error “ld: library not found for -lcrt1.3.1.o”. Turns out that the iOS10 SDK doesn’t ship with this file any more, effectively dropping support for iPad1’s.
Fortunately the solution is simple, to take a copy of crt1.3.1.o from an older copy of XCode and put it into the /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/ folder, and just like that it’s possible to build for iOS5 again.
A Hangouts Prpl
So Pidgin has fairly alrightish support for Hangouts through the XMPP server that Google provides. Unfortunately it’s missing a whole bunch of stuff – like group chats, self-sent messages et. al. – that make it just that little bit annoying to use.
So we had a Summer of Code 2015 student start work on a new protocol plugin (prpl) for Pidgin. Unfortunately due to a few roadblocks (mostly around new stuff in libpurple3) it didn’t get completed, so I’ve spent the last too-many weeks implementing the pblite/protobuf-json/jsprotobuf protocol (TODO find a link for this one) that Google uses, in C using the amazing protobuf-c library (in combination with the always awesome json-glib), to begin work on a new Hangouts prpl for Pidgin.
After the pblite-madness set in (seriously, that stuff will give you nightmares), Maiku came on board to help, and now we have a plugin that’s at a ‘good enough’ state right now that people can start using it.
We’ve taken inspiration from the Python-based Hangups library, and used the authentication code that Nakul wrote as part of GSoC2015 to come up with some moderately-sane code that works for both Pidgin 2.x and those foolish enough to be using Pidgin 3. There’s still a lot of pieces of the puzzle missing (you’ll see what I mean when you try it), but I think it’s good enough now that I’ve ditched my XMPP account in favour of it.
Please give it a go and tell us what you think. Just to be different, it’s over on BitBucket instead of GitHub.
Summer Status S’chwupdate
Posted by Eion Robb in Uncategorized on 2016-01-06
So I was allowed to have a few days break from my day-job over the xmas break, and in between making desserts and back-breaking work in the garden, I managed to do a few Pidgin related things 🙂
Retiring the MightyText plugin
So unfortunately I’ve had to discontinue work on the MightyText plugin for Pidgin.
Semi-recently, Google changed their authentication process to no longer allow an old type of auth. Unfortunately, the new system (OAuth) relies on the user having a web browser to login with, which isn’t something we can assume with libpurple (have you tried using a text-based web browser with Finch?!). Although I managed to find a way around this, to connect back from OAuth into the MightyText server requires a great deal of effort that ended up going nowhere.
So, regretfully I’ve had to stop.
Using the new “Skype for Web”
So, Skype have recently announced a new, web-accessible version of Skype. Currently it’s invite-only, closed beta but I’ve managed to have a look around to see what it’s capable of and how it works. They’ve talked about making it work with WebRTC but at the moment it needs a separate download to get a browser plugin. Thus, a lot of the peer-to-peer features (such as file transfers or audio/video calls) don’t work. The major benefit of the new system is that it complements existing Desktop API or SkypeKit messaging by providing access to the server-stored “thread” chats. It’s also interesting to see that the ‘endpoint’ information for users, including what platform they’re using the Skype client on, is being provided. The downside is that it’s still beta, that it destroyed my buddy list and can’t handle talking to older, pre-microsoft Skype clients or in the older type of multi-user chats — I guess that’s why they’ve been so desperate to block older clients and get everyone moved onto a new version of the client.
Everything (other than login) is mostly JSON message sending/receiving with an HTTP-long polling connection for events. You’ll also need to do a bit of XML parsing for some of the messages, particularly for some metadata about chat rooms (adding/removing users). The ‘protocol’ also can’t make up it’s mind about whether it wants to identify a user or conversation by a URL or a id. Probably the worst part about it is how very sensitive it is to be 100% exact.
Ah well. I’ve been working on a new plugin for the last week, if anyone else is interested in testing it out. It’s got a few bugs, a few segfaults but the hard part is out of the way. Please grab it from svn on googlecode, the skypeweb subfolder of trunk, give it a compile and email me when you find all the fun bugs 🙂
Facebook to shut down their XMPP service
Posted by Eion Robb in Uncategorized on 2014-05-14
So it’s been recently announced that Facebook are planning on turning off their XMPP gateway for Facebook Messaging. Their announcement says that it’ll be completely turned off for good as of April 2015, but that it’s just deprecated for now.
This is kind of a bittersweet announcement. The XMPP gateway was never really as feature-complete as any of the other messaging options provided by Facebook (by this, I mean the mobile Messenger client and the Firefox-powered Desktop Messenger), but it’s rise to prominence was the main reason I gave up on the old HTTP-based Facebook Plugin for Pidgin, which pretended to be a mobile browser.
So, now it looks like it might be time to dust the cobwebs off the old FB plugin and give it another crack. The other option is starting again, but reverse-engineering how the mobile Messenger clients work (might have something to do with MQTT?).
So that’s another big service dumping XMPP – we’ve already had MSN, AIM and Google deprecate their XMPP gateways. Who’s next? Does this make XMPP dead? What’s going to be the ‘next big thing’ in messengers? I guess that’s half the reason I like working with libpurple/Pidgin is that it’s an ever changing landscape with new things to learn from bigger companies.
Win8 JS Privacy Policy Settings
As part of the Windows 8 App Store requirements, if your app has internet/network connectivity then you’re required to not only have a privacy policy in your app store description, but also as a Charms menu item. Unfortunately all the docs suck for how to add a simple charms menu item to open the privacy policy in a new window using JavaScript 🙂
After lots of digging, I’ve come up with a simple bit of JavaScript code, that should also let you add other Charms Settings menu settings without tearing your eyes out trying to read the docs.
var settingsPane = Windows.UI.ApplicationSettings.SettingsPane.getForCurrentView();
function commandsRequested(eventArgs) {
var applicationCommands = eventArgs.request.applicationCommands;
var privacyCommand = new Windows.UI.ApplicationSettings.SettingsCommand('privacy', 'Privacy Policy', function() {
window.open('www.link.to.your/privacy_policy.html');
});
applicationCommands.append(privacyCommand);
}
settingsPane.addEventListener("commandsrequested", commandsRequested);
Setting up the MSN-XMPP plugin in Pidgin
Fun conversation in the #pidgin IRC channel this morning about the latest news about Microsoft shutting down the MSN servers later this year. As part of it, a few people wanted to start using MSN-over-XMPP using the msn-xmpp plugin for Pidgin. I have some uncommitted (and unfinished) code on my computer to convert the plugin from just an authorising mechanism to a proper protocol plugin but in its presently available state, it’s a fairly manual process. Just to make people’s lives easier I’m documenting here the setup process (might even put some info on the Google code page 🙂 )
First of all, grab the plugin, install it and enable it through Tools->Plugins
Then create a new XMPP account in your Pidgin Accounts page. You’ll want to use your MSN/Live/WLM email address with the ‘@’ characters replaced with ‘%40’ for the username, and messenger.live.com as the domain
Save and enable the account and follow all the popup prompts and login pages in your browser. You’ll also want to open the debug log in Pidgin through Help->Debug Window. You’re watching for a message saying ‘see-other-host’ (you can filter by it if you want). You want to then take that value and cram it into the ‘Connect Server’ setting in the Advanced tab.