mercora

it will work as long as you are the one initiating the connection. if some peer suspects you have a wanted piece available i.e. from another peer in the swarm it can not communicate the intent to get that piece from you to your client directly. i think BitTorrent can relay messages through intermediate peers to make your client establish the connection to that other peer (reversing the initiator). Otherwise peers will exchange other peers that are visible to them so that your client might eventually learn how the other peer that wanted that piece is reachable and connects to it. So it actually will work without port forwarding but reaching your client will be harder and thus less peers inside the swarm will be available to you or them, likely making it slower.

P2P here means it will form a mesh network which itself means every node in the network (your clients) tries to connect to each other as "directly" as they determined possible by some routing algorithm. This is in contrast to a a hub and spoke model for example, where every node will connect to a central hub and communication between nodes need to pass through that hub.

> For example video streaming through it always causes hiccups.

This sounds weird to me. either there are enough resources available to sustain the bandwidth requirements or not. this changes with time and usage of the machine but just as it does without tinc. Depending on the hardware used it should not be too hard to stream common videos with something like 20mbit at max...

However, i just wanted to say; maybe you had MTU issues?

this assumes a bitflip would result in an immediate reboot which is not even that likely i think. detecting these failures probably requires redundant systems and luck i guess.

> If I were to guess, your network provider has your home address and used that?

they would have to know what access point is at my home too.

> but e911 is a USA thing, I don't know Germany's equivalent laws.

me neither. i know we have "eCall" for car emergencies but i am somewhat certain there are similar requirements here... the thing is i never seen this work without having a cellular connection too.

> I would assume the IPsec traffic is the WiFi Calling feature?

yes it is. i can see packets flowing when receiving a call for example... the destination/origin of these packets is into my providers network...

i am located in Germany and my phone indicates the WiFi calling feature in the status bar. I never signed up for this and thus never provided any address. I would guess my phone is still connected to the cell network in parallel and thus locateable anyhow. i can see IPsec traffic from my phone in traffic captures...

when reading about these considerations i always wonder if it really matters at which point i could discern single pixels from one another. i think there is more to it when we are talking about what we can see in the image. maybe we wont be able to benefit in the way that we see less of the pixel raster but i feel like having more details will benefit image clarity non the less. even if it is impossible to effectively discern the pixels the combination of them might still affect what i can see....

this[0] is likely slow because it will try to do reverse DNS lookups for each host which can be disabled, at least on linux, with "-n"

[0] https://gist.github.com/siraben/c3133b39e470d1aed16fd71f42b8...

i was less concerned about authentication issues and more about routing issues as ARP would lead to results depending on time and location inside the network topology...

> Apparently it took some creative techniques to figure out where the traffic was actually coming from.

probably they did lookup the MAC address on the switches and saw it on a port that did not match expectations. if you were using a wired connection this would trivially lead to you... on wireless you would have to narrow it down further by monitoring signal strength of the station :)

>Since it was an open network, it was simple scraping the network for other connected devices and spoofing one at random

you should probably know that using the same mac address in parallel will cause connectivity issues for both...

for virtual machines i tend to use names that belong to some other entity and call the hypervisor after that. for example Saturn and its moons, Africa and its countries or some authors and their works.

would that help them though? i mean it appears to me they are already as close as possible to avoid latency and use microwave links and stuff so that is pretty hard to beat i guess. the only thing i can easily imagine being beneficial is getting information across the globe faster but then i lack the skills to see how one profits from that, ie. being closer would still be better, no?

it is pretty trivial though and an obvious deficit easily visible by just looking at the "code" or nginx config in this case... it is even trivial to come up with this without knowing any of the setups details...

i don't think these permissions are enforced client side... I also think write and delete are separate permissions on windows and i am pretty sure i never lost a file on accidentally doing only the first halt of a cut and paste aka move... so i conclude this "someone" either had nothing to do with the incident or removed it by accident...

why wont you report them? is nobody interested in securing these?

that will just move the target of those attacks to these servers (or now yourself who stated to have access to these) with apparently a lot more rewarding outcomes too.

so i know some people around me who are using telegram and very likely most of them did not change anything about their privacy settings as usual. However, i do not see any of them in the list and it even shows me users some 10km away. When viewing this list on the top it has a button to make yourself visible so i assume if you don't do it voluntarily its not broadcasted at all which appears to be a non issue then, like he was already told.

spontaneously i came up with using a hardware based IP KVM device instead of moving the laptop physically.

i do not. i manually manage these routes all by myself using systemd-networkd... these routes are respected but the via address is ignored nonetheless. to repeat myself, the via part of the route is not considered; i even double checked this by reading the code and furthermore did a PoC if it could be done. as soon as the route hits the interface the packets get routed according to the AllowedIPs setting regardless of any via address set on that route. If you are inclined enough to do so you can try it yourself. set it to a non existing address and you will see it will be routed regardless... or even set it to the address of an existing peer that has it set in its AllowedIPs setting and you will notice the peer that has the packets destination set as AllowedIPs setting will get the packets. which makes some sense as return traffic would only be allowed to come from that peer anyhow. i.e. for incoming packets the routing table is not even considered at all (analog to reverse path filtering).

no, the via part is just not considered. it does not make much sense to try though as it is impossible to have multiple peers with the same AllowedIPs addresses set. if it would honor the via address and allow me to configure multiple peers with the same AllowedIPs setting some dynamic routing could be made possible but it is not. However, i do configure it like you described just for consistency reasons when looking at the routing tables.

i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.

not op but one issue i have with it is that it ignores the routing table as soon the packet hits the interface. what i mean is if i tell the linux network stack to route packets "via" some address (which normally would involve arp) this configuration is completely ignored and the packet gets routed to whatever endpoint has the destination address as (confusingly named) AllowedIP address set. I expected it to do the lookup based on that via address and was trying to figure out what went wrong way too long. I think it would be kinda trivial to do this as i expected it after some minor research but that also led me to think it is supposed to be this way for some reason or another.

my point is that i think there should be a soft limit on how long a single line of code should be because i feel like it becomes too hard to read if they get too long. that is an emotion as you said and it might be kinda arbitrary but i don't think there is something fundamentally wrong with it.

i like clear and concise naming and don't care too much about how long it is generally if it helps understand what it does without being extraneously verbose. However, i think there is an argument to be made about how long a single line of code should be before it becomes too hard to read. The example given would be too long for me and i would try to shorten it. In this case probably by implementing some abstraction ;)

maybe the algorithm wants to detect if you are as slow as a human would be solving those and you failed that ;D

not sure about any particulars of the issue you describe but it sounds like the terminal could not support something about your session to vi. maybe running GNU screen or tmux would make things work better?

sure, why should they escape user input when they can just ban various attempts as they notice them occurring...

it has nothing to do with IPv6 specifically but i mostly have a haproxy instance on every "edge" for public and private services. I also do TLS there. However, everything gets its own records in DNS too. I use dynamic updates from my DHCP server to a bind9 instance for that. This all works very well for IPv4 and IPv6 simultaneously... I admit its more complicated to set all of this up properly but maybe its just the way it is ;)

that is actually somewhat impressive performance in my books. i would guess 4G links are inherently unstable regarding prediction of connection characteristics for proper scheduling... thanks for sharing your experience with that :)

is that latency coming from routing to your upstream network or the packet scheduling itself?