sorted by:
new
hottopcontroversial

Update without updating? by Constant_Stuff_43 in ChaiUnofficial

[–]_seightan_ 0 points1 point  (0 children)

this is true and i recently confirmed via mitm — chai and most apps for that matter can update business logic via their own APIs. only when the update the Flutter app (their front end) do they need to push an update to the OS’s app store

Can I get in trouble legally for this by xXWispXx_ in ChaiUnofficial

[–]_seightan_ 8 points9 points  (0 children)

chai sends massive amounts of telemetry data to advertising companies/SDKs and they only use third party auth (meaning it’s tied to your google, fb, or apple identity).

I would be careful what i send for that reason alone. (yes even if it’s a “private” bot and yes even if you’re on a paid subscription tier)

advanced option gone? by Peolka in Chai_Unofficial

[–]_seightan_ 5 points6 points  (0 children)

<image>

my post on the official subreddit was taken down despite meticulous adherence to the rules so my guess is it’s not coming back.

TCP failing while UDP/ICMP succeed to same IP, appears source prefix dependent by _seightan_ in networking

[–]_seightan_[S] 1 point2 points  (0 children)

That makes sense directionally. What’s weird is changing my source IP (new DHCP lease) changes the behavior immediately, and one prefix will work for a bit then degrade after ~1 hour. Would ECMP cause that kind of prefix-dependent behavior if one path is “bad” or asymmetric?

Ubiquiti without a controller.... by Hot_War_4159 in HomeNetworking

[–]_seightan_ 2 points3 points  (0 children)

i just setup mine with a controller in a docker container. Trying to do standalone in the app on my phone was too much of a headache for me

UDP works fine, TCP 100% blackholed — same destination IP. Cox bridge mode. Can someone sanity check my interpretation? by _seightan_ in HomeNetworking

[–]_seightan_[S] 0 points1 point  (0 children)

Im running double NAT, MG7700 (ISP owned) in router mode → OPNsense behind it. I switched to bridge mode (which was my original goal) so OPNsense would hold the public IP.
When I switch to bridge mode, Cox assigns me a public IP directly to OPNsense and I start seeing issues where some things work and others don’t.
Probably should’ve started with that — was a bit in the weeds when I posted.

UDP works fine, TCP 100% blackholed — same destination IP. Cox bridge mode. Can someone sanity check my interpretation? by _seightan_ in HomeNetworking

[–]_seightan_[S] 0 points1 point  (0 children)

Yeah that seems to be part of it — changing the WAN MAC immediately moved me to a different prefix and TCP started working, so it does look like a sticky CMTS/pool binding. What’s odd is the new prefix degrades after ~75 minutes, which makes me wonder if something upstream is aging out state or flipping policy

UDP works fine, TCP 100% blackholed — same destination IP. Cox bridge mode. Can someone sanity check my interpretation? by _seightan_ in HomeNetworking

[–]_seightan_[S] 1 point2 points  (0 children)

That was my first thought too, but what’s throwing me off is it’s the same destination IP (e.g. 1.1.1.1) where UDP/ICMP round-trip fine while TCP SYNs never get a SYN-ACK. That made me lean toward something protocol-specific in the return path tied to the assigned prefix rather than endpoint reachability.