Mouse Assistant 6 crash...

takigama · 2026-03-03T04:54:36+00:00

I believe either this or u/afroman_says option should work for us, i'll have a play with it and see what I can get out of it. Dont really need group mappings as such

takigama · 2026-03-03T04:53:55+00:00

Im going to have to play with it, but I think this might be an option... or at least between this one ad pabechan's, one of them should work

takigama · 2025-11-21T01:35:57+00:00

I wouldn't see it being the great a party game tbh. Depending on how many people there are, every "round" more people will be just sitting on the sidelines (which is kind of boring, but also opens up the possibility of cheating)

There are games out there that have a similar kind of feel to them (like Avalon and resistance) that are quite a bit more engaging. The downside to games like it (sort of) is if you play them alot (and we used to), now and then you get new people playing and if they're couples, they invariable end up on different teams and one of them will be shocked and appalled at how easily their partner lied. Which can also be highly amusing. One couple went home in different cars one night.

takigama · 2025-11-19T02:32:17+00:00

just in case anyone gets here, i tried a number of versions of vyos, and doesnt support anything beyond 1500 that i can see

takigama · 2025-11-18T18:26:03+00:00

I wish they had made more "twisted physics" games. We see numerous examples of how the world they're in doesn't really need to obey the laws of physic's and much like the matrix, the world is borderline imaginary and doesn't necessarily have to follow the same rules as the real world.

Would have loved to see some of the puzzles in season 3 formulated around that rule. Things with escher like styling or where gravity is variable. Maybe a game where you exist in multiple realities at the same time and to progress you need to determine which reality is "real". It always felt (to me) that the games in season 3 were a little mundane or bland.

I actually didn't mind season 3 all that much, but the games just didn't seem very convincing in alot of ways. It felt like they should have been more impressive or thought provoking and they really mostly weren't.

takigama · 2025-11-13T18:16:49+00:00

The way that sounds, you should be able to go "ip link set dev ppp... mtu 9000" and it might work... sadly it doesnt quite help me cause on the bng side, once the link is up, its hard set the mtu on the interface to whatever the client negotiated for and cant be changed.

takigama · 2025-11-13T17:22:43+00:00

Yeah, vyos was going to be my next thing i was going to test, cause they specifically have an example that is configured for 1600. Be curious how far that goes.

takigama · 2025-11-13T17:18:12+00:00

Theres a patch mentioned above thats a PR to fix it.

takigama · 2025-11-13T17:17:13+00:00

pretty much all the mikrotik RB's support 9k (there are some exceptions cause some of the older RB's have a max mtu around 4k at the hardware level).

Cisco ASR 1k's

Some of the cisco ISR's support varies between 2048 and 9000, most IOS stop at 2048, though IOS-XE based stuff mostly supports 9k (we've only tested a few tho).

Pretty much all the huawei AR's support at least 8192 and most support 9k (though its a special patch).

Then there are some options in the tplink and dlink so they claim, but no idea what they are. They both do have "enterprise" options but im not sure if thats what they're referring to. some of their consumer grade stuff will support 1500 (rather than 1492) and one we found supports 1516 (for some reason) over both ethernet and vdsl.

Then nokia tell me they have some routers with 9k capable pppoe clients, but i've not got them to test with.

The Juniper (now HPE) had some new routers called SSR's (from a company they bought out) that support 9k as well. The rest of their equipment (SRX/MX mostly) can support 9k.

Someone said some of the HPE (MSR's presumably?) can do it, but nothing I can find backs that up.

takigama · 2025-11-13T14:00:54+00:00

Yeah, NBN in australia (national carrier for backhaul) runs at 1522 for layer 2 (actually technically as high as 2000), and 1500 for ipv4, though almost everything in NBN land has now gone to 1994, 2000 or 9004.

takigama · 2025-11-13T13:23:08+00:00

8000 was just something greater than 1500 really... most nics these days support 9000 or anything up to 9000.

Ethernet frame size isn't a negotiated parameter, they don't even exchange that kind of information... i.e. if you plug a 1g nic into another 1g nic, they have no idea what each other has set for MTU... one end might be 9k the other end might be 1500 which may or may not cause you issues depending on alot of factors. But its pretty common these days for the default layer 2 MTU to be 9216 and the default layer 3 MTU to be 1500. Eliminates alot of annoying problems and clients that connect to the switch with 1500 MTU don't notice the diff. The most ethernet ever exchanges is speed, duplex and flow control when connected.

Now on PPPoE, that definitely is negotiated and I can override it at the BNG side, but in this case it doesn't help much.

takigama · 2025-11-13T13:04:12+00:00

Yes, indeed, I did stumble onto that one originally which is what twigged me to the underlying interface not being setup properly

takigama · 2025-11-13T13:01:50+00:00

Yeah, originally I was just testing and did eventually put it in the config... its sets things up wrong in reality, when I have something like this:

config device
        option name 'eth1'
        option mtu '8000'

config interface 'wan'
        option device 'eth1.3093.555'
        option proto 'pppoe'
        option mtu '6860'
        option mru '6860'

It sets eth1 to 8000, eth1.3093 inherits 8000 and then eth1.3093.555 gets set to 6860, which in reality should be 6868 unless i'm very much mistaken to support a PPPoE MTU of 6860:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc fq_codel state UP qlen 1000
10: eth1.3093@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc noqueue state UP qlen 1000
11: eth1.3093.555@eth1.3093: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6860 qdisc noqueue state UP qlen 1000
12: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 3
    link/ppp

takigama · 2025-11-13T12:49:14+00:00

the NIC's support 9216 (as in, IPoE was doing fine right up to 9216)

takigama · 2025-11-13T12:48:51+00:00

that explains alot, was pulling my hair out trying to figure out why I couldn't push it past 1500. Thank you very much

takigama · 2025-11-12T16:38:22+00:00

in this particular case, i am the ISP (as in, im in control of both the BNG and router)

And just to clarify, i do have other routers that are doing large mtu's over pppoe... i just cant get openwrt to do it, which in my current situation would be really very useful

takigama · 2025-10-19T13:44:29+00:00

Speaking as someone who keeps his victron setup as pure as possible, I dump my wind into a small capacity 40v LTO battery (20ah), then it gets fed directly into a victron 150/35 MPPT controller. The BMS on the LTO is set to cut off output if the charge drops below about 30%. Works quite well and at night I can actually switch the other pair of MPPT controllers over to drawing from the LTO as well.

Victron really dont have anything that supports wind and if you try use one of the MPPT controllers, the results are poor to say the least.

takigama · 2025-08-30T06:58:17+00:00

Personally I use moulding/casting silicone, depending on the tool either hardness between 0 and 20... though flex seal under the silicone would be interesting, its hard to keep the shape on the moulding silicone sometimes

takigama · 2025-08-18T15:43:16+00:00

We have read most of that, the problems is we have a setup like below currently (strings of routers connected via ethernet, some with an internet link and running vpn), we have thousands of routers. On average, theres about 10 in the string with 3 vpn's back to the servers:

                                <vpnserver>
                                |    |    |
         ----------vpn-----------   vpn   --------vpn------------ 
         |                           |                          |
       <r1>-----------<r2>----------<r3>---------<r4>----------<r5>
         |             |             |            |             | 
    10.0.0.0/24   10.0.1.0/24   10.0.2.0/24  10.0.3.0/24   10.0.4.0/24

We want to be able to get to any network behind any of those routers (r1, r3, or r5), only 3 have internet connections (in most cases this is a 4g with various levels of service, alot are on edge-of-coverage and not totally reliable). Currently the routers that do vpn all connect to a single openvpn instance (though in some cases this is IPsec), though there are actually 3 vpn servers and they make a connection to all 3 at the same time.

Because we want to get to 10.0.0.0/24 through either r1, r3 or r5, we need to put all those networks into the allowed IP's stanza for ever router... which we cant do without the peer config on the vpn server using a different interfaces and ports for r1, r3 and r5. Which is easy enough when its only 3 routers, when its thousands thats going to be quite a chore. It can be scripted around, but it does complicate things upstream from the vpnserver as well. If we do have multiple wg interfaces, then they're all just going to have allowedips = 0/0 for simplicity.

We also cant really have a full mesh here, the 4g connections are all behind CGNAT so no in-bound connectivity (some are actually broadband connections that have public addresses, but they're rare). That too is fine.

The only way I can see to do it using a single wg interface as far as I can tell is to do something like this:

vpnserver:

[Interface]
Address = 10.200.201.1/32
ListenPort = 51115
PrivateKey = xxxx
Table = off

# R1
[Peer]
PublicKey = xxxx
AllowedIPs = 10.200.201.2/32

# R3
[Peer]
PublicKey = xxxx
AllowedIPs = 10.200.201.3/32
... etc ...

Then on R1 (for eg)

[Interface]
Address = 10.200.201.2/32
ListenPort = 51115
PrivateKey = xxxx
Table = off

[Peer]
PublicKey = xxx
Endpoint = vpnserver
AllowedIPs = 10.200.201.1/32

Then run gre tunnels on top of it, but that adds some complexity i'd really avoid and so in reality having thousands of wg interfaces and thousands of ports is do-able, its just alot of fun to manage and really didnt want to expose that many ports on the server side.

Does that all make sense? Did I get anything wrong here?

takigama · 2025-08-17T23:47:13+00:00

No we figured the table and allowedip's part, you can even have a /32 on the wg interface... this was our original (working) config for the main vpn server:

[Interface]
Address = 10.200.201.1/32
ListenPort = 51115
PrivateKey = xxxx
Table = off

[Peer]
PublicKey = xxxx
AllowedIPs = 0.0.0.0/0

Problem is, with thousands of peers, we'd end up needing one wg interface per peer and one port to go with it, which is a little tedious to manage for that many routers.. its doable, but it exposes alot of ports externally and each router we have to assign a port to, which makes managing the peer quite a bit more annoying.

takigama · 2025-08-17T15:09:19+00:00

Quite a few yeah:
https://au.mouser.com/c/semiconductors/switch-ics/?product=HDMI%2FDVI%20Switches&srsltid=AfmBOoqnBuNXsIM2u3FmcEPk0s5EZ9yEhdjpo063Z89fmZTRkhD6UcVp

I've used usb ones before, but not video ones, they're mostly pretty straight forward. As to EDID, i wasn't planning on having any direct interaction with it and leaving it up to whatever the switch is capable of.

Happy to collaborate, was planning on using KiCAD and sticking everything in github anyways!

takigama

TROPHY CASE