[Feature]: Integrate parts of HokakuCafe for debugging purposes

[jonbarrow]

Checked Existing

• I have checked the repository for duplicate issues.

What feature do you want to see added?

(Using the new issue templates flow for this one)

Integrating at least some basic parts of HokakuCafe directly into Inkay. Specifically @ashquarky's fork, which supports dumping HTTPS traffic in a usable way. With the new Aroma update making it so plugins load earlier in the boot process, this should be theoretically doable (HokakuCafe is a setup module right now)?

We can leave HokakuCafe for more advanced users/detailed dumps, but for Inkay we could add 2 basic options:

• Dump HTTP Traffic which dumps HTTP/HTTPS traffic
• Dump Game Traffic which is functionally identical to HokakuCafe in UDP mode (the current PRUDP mode has bugs and only works on NEX servers, not Rendez-Vous servers like WATCH_DOGS)

Possibly even having them dump to separate pcaps, with an option to dump them into the same one? I can see how having them separate and having them together can be useful in different situations.

Why do you want to have this feature?

Since Quarky's fork supports dumping HTTPS traffic in a way that's actually usable to us, this would make debugging a lot easier when it comes to solving user problems. There are errors such as https://forum.pretendo.network/t/cant-access-servers-error-102-2402/307 which are very generic "a request went wrong" errors which don't give us any real details as to what went wrong and where. Being able to have the user enable this HTTP/HTTPS traffic dumping, then triggering the error, and giving us the dump would make it so that we can actually see what's going on on the users side.

Similarly enabling the Game Traffic option would make it easier for users to give us dumps of errors happening on the game servers. I know that they can just use HokakuCafe as-is for this, but it's one less thing for them to set up.

Being able to inspect the HTTP/HTTPS traffic in a usable way, without the need for a proxy server, would allow me to more accurately debug SSSL issues. Right now I'm having a hard time diagnosing the issue going on with Splatoon, as I can't replicate the issue when using a proxy server. But without a proxy server I can't see the traffic.

Any other details to share? (OPTIONAL)

No response

[TraceEntertains]

Would you be averse to the idea of implement hokakucafe (generally) as-is into Inkay? I feel like it would still be a fine option, because in the case of needing to get dumps through the plugin you need to tell the user what to do either way

Note: by (generally) as-is I mean having the core code be the same, just running through a plugin instead of a setup module, and having configs through the plugin menu instead of a file you have to manually edit

[jonbarrow]

Would you be averse to the idea of implement hokakucafe (generally) as-is into Inkay?

I would be, yes. I laid out this suggestion to be as simple as possible for the end user. We realistically only need 2 different kinds of traffic, so giving the full functionality of Hokaku is unnecessary here.

Making this a dumbed-down version of Hokaku is the point.

you need to tell the user what to do either way

There are users who do not know how to even login to accounts, needing to be told how to even get that far. I'm accounting for the lowest common denominator here, and giving them as few options as possible.

having configs through the plugin menu instead of a file you have to manually edit

The point is to make it simple for basic users. Hokaku is still there for if we really need something more detailed. This is meant to only get basic information from regular users, not act as a replacement for Hokaku for development purposes.

To reiterate: this is supposed to be a dumbed-down version of Hokaku. We have many users who struggle with even the most basic of tasks, needing constant hand holding. Giving them as few options as possible while getting as much information as we can is the point here.

[TraceEntertains]

Actually that's a fair point, nvm

[ashquarky]

Hokaku is notably pretty laggy when dumping TCP (there's just a lot of packets to flush, and Hokaku deliberately doesn't cache the file) so I'm a bit iffy about having it be a toggle in the plugin menu that a user might enable without understanding it.

[jonbarrow]

Hokaku is notably pretty laggy when dumping TCP (there's just a lot of packets to flush, and Hokaku deliberately doesn't cache the file)

Odd, I sometimes just used it in ALL mode and didn't notice any issues?

I'm a bit iffy about having it be a toggle in the plugin menu that a user might enable without understanding it

This is fair. How much can we control the plugin menu? I've never actually looked into its API before. We can do nested menus, maybe putting this under a Debug menu will a clear warning at the top would help here? We could probably move the BOSS task stuff there too tbh. Are we able to show notifications while the plugin menu is open? Either from Aroma's notifications API or from the consoles ErrEula? We could also show something when it's enabled on warning the user

[ashquarky]

Yeah, Debug or Advanced or whatever could work. I think I've already changed the labels for the next release, so I can just change it again ahead of it going out.
I mentioned this to Maschell due to some technical concerns I had, and while my concerns turned out to not be a big deal, he also had this to say:

I am more worried about the IOSU patch(es) itself. Before we have a nice solution for iosu "plugins" dealing with multiple iosu patches at the same time is always playing with the fire (e.g. what happens if do different modules/plugins are using the same area in the iosu), throwing us back to hbl-like issues
If it's only for debugging, i personally think I should be totally fine to expect a user to be able to copy a file to their sd card, shouldn't be much harder than accessing a debug option in the config menu imo
I don't know the details of it though

He's not wrong. Given a hypothetical "slim" version of Hokaku built into Inkay, If the user installs Inkay and Hokaku at the same time they'll step on each other's toes, if the user switches between multiple versions of Inkay (normal during development of Inkay itself) it'll crash, if the user runs the standalone Hokaku alongside Inkay it'll break, etc. etc.

If the user is going to have to pull the pcaps off their SD card anyway, wouldn't it be better to improve the Hokaku experience a bit? Maybe have it default to ALL mode, put everything in a zip or a pcapng, then just say "ok run this rpx/wuhb then cause the error".

[jonbarrow]

I agree he's not wrong, and I agree with his expectations. But I've begun to learn to try and account for the "weakest link" these days. There are people who absolutely will get tripped up with even just having to edit the config file. I agree that this sounds absurd, but I've had to help people recently who didn't know common sense things like "you can't link the same username to a platform twice" or "friends made when using your NNID don't show up when not using your NNID, and vice versa" after being told multiple times.

I now picture "the user" as a 5 year old who knows nothing, limiting the number of steps they have to take and making things as idiot proof as possible. People do fuck up using Hokaku as-is, we have plenty of network dumps from our crowdsourcing effort that are useless because they either contain no data, or they didn't swap the capture mode so part of it is missing (despite our guide clearly state to switch the mode, and telling them what to swap it to). I've even seen people on Twitter asking for help because they thought they could run Inkay on Tiramisu "because it's just homebrew". These are the people I'm accounting for here, not the typical user and definitely not us.

shouldn't be much harder than accessing a debug option in the config menu imo

For the "weakest link", it definitely will be. For these people it's the difference between:

• Update Inkay (something they already have)
• Flip an option in the friendly menu

Vs:

• Download new homebrew
• Place it in a new folder
  • Not the same folder as Inkay, which may trip people
  • Some users may not have even used setup modules before
• Modify the ini config (which may be something users have never done)

then just say "ok run this rpx/wuhb then cause the error".

Some of this stuff would need to be captured earlier in the boot process, like when debugging SSSL since the console requests the policylist pretty early. Though I guess that's mostly an us thing, I doubt many people using SSSL will always have homebrew anyway.

Before we have a nice solution for iosu "plugins" dealing with multiple iosu patches at the same time is always playing with the fire (e.g. what happens if do different modules/plugins are using the same area in the iosu), throwing us back to hbl-like issues
...
If the user installs Inkay and Hokaku at the same time they'll step on each other's toes, if the user switches between multiple versions of Inkay (normal during development of Inkay itself) it'll crash, if the user runs the standalone Hokaku alongside Inkay it'll break, etc. etc.

These are valid concerns. I don't have answers for them all unfortunately. The best I could suggest is something like "see if Hokaku is installed before enabling anything in Inkay and warn the user" but that only fixes some of those concerns (doesn't address having multiple Inkay versions at the same time), and wouldn't work for Hokaku installations with different names.

Maybe we can compromise here? For example, maybe Inkay itself does not integrate Hokaku's features but could act as a user friendly frontend for it, giving users limited access to its settings? And if the user doesn't have Hokaku installed, download it for them? Unsure how viable that is. Something like that might be the best of both worlds, hand-holding the "weakest link" while still keeping the functionality in Hokaku itself (which helps centralize changes and stuff too)

[ashquarky]

Download new homebrew
Place it in a new folder
Not the same folder as Inkay, which may trip people
Some users may not have even used setup modules before
Modify the ini config (which may be something users have never done)

If we made some changes to the default settings of Hokaku, or had a special build for this purpose, this could also look like:

• Download a new homebrew (possibly from the homebrew appstore, thus sidestepping the "folder" issue)
• Open it from the home menu
• Make the error occur
• Pull the .pcaps off, with FTP or by reading the SD card

Remember, HokakuCafe has a standalone/non-setup-module build already. If that build also defaulted to ALL mode, there's no need to edit the config. The bonus of the standalone version is that the user can't accidentally forget to remove it, which would be quite nasty if they left it running for like, a year or something.

I'm not strictly opposed to tightening up Inkay's integration with Hokaku, I'd just like to explore this as a possibly better solution first. I know users can be silly but they've also, by definition, managed to at least get through the Aroma setup guide, so we can expect some things like "ability to read/write to the SD card". If they can't get the right folder that's an issue with unclear documentation/tutorials.

[ItzSwirlz]

If HokakuCafe is implemented into Inkay, there should probably be an option to enable or disable its features if it could cause performance issues with logging

[jonbarrow]

If that build also defaulted to ALL mode, there's no need to edit the config

Sure, but that's not what this suggestion was about. Defaulting to ALL mode would dump everything all the time. The point of this feature request is to make it easier for users to provide us with information about their traffic for our debugging purposes, and having people always (because it's unlikely they'd change the config on their own) submit dumps from ALL mode would be cluttered and waste space/time.

That's why I proposed separate options for dumping UDP and HTTP traffic, going to 2 different pcaps, with an option to have them go in the same pcap. Having that clear separation of just the data we need (while still having the ability to have all the data in one place if we need to) would help a lot imo. This was already shown when trying to help Imora last night.

I'm not strictly opposed to tightening up Inkay's integration with Hokaku

Given the potential issues that you and Maschell brought up regarding multiple instances of Hokaku having conflicts, I am honestly against a direct integration now. Those are very valid points. I think the better way forward now is to improve Hokaku itself, adding in these options there, and having Inkay act as a front end for Hokaku instead of directly integrating it.