#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

eyedeekay zlatinb it should not be necessary, it works by combining the entries from the main news feed with the platform/channel specific news feed, then regenerating them in date-ordered fashion.

eyedeekay So if you don't need to add any more release notes specific to .dmg's, then you do not have to

eyedeekay I'm going to have at least some release notes every time because of base/included browser extension updates

zlatinb eyedeekay: idk_afk: data/mac/stable/releases.json updated, no changes to entries.html

zzz 0) Hi

zzz hi

zlatinb hi

eyedeekay Hi

zzz whats on your list for today?

orignal hi

zzz how about: 1) release status; 2) picking tunnels for netdb lookups; 3) peer test results and recommendations

eyedeekay I am still a little behind from last week and have been doing plugin stuff, I don't have anything to add for SSU2 right now

zzz did we want to talk about udp tunnels?

eyedeekay Yeah that's a good idea

zzz ok that's 4)

zzz that should be enough for today

zzz 1) release status

zzz about 18% have updated; no sign of bigly yet

zlatinb I just emailed parg on an urelated topic, will see if he gets back

zzz I usually don't bug him for at least a week or so

R4SAS hi

eyedeekay I've got to work with F-Droid to get their I2P auto-builds working this week, after that their section of the Android population should update

zlatinb I am noticing about 50% of my SSU1 links are <150ms RTT

zlatinb which is good

zzz yeah, we worked on that 3 months ago, forgot that we sped up SSU

orignal nice

zzz network seems ok even with the rekeying, doesn't seem to be a problem

zzz will keep an eye on things

zzz anything else on 1) ?

zlatinb yes releases.json is ready for mac

zlatinb and torrent is up on postman, so someone needs to flippa da switcha

eyedeekay I have to do Windows jpackage release this time, shouldn't take me long, will probably do it today

zlatinb eot

zzz ok

zzz 2) picking tunnels for netdb lookups

eyedeekay zlatinb sorry about the time it's taking to get it up on the mirrors, I'll flip it as soon as I can

zlatinb np

zzz orignal said last week he added connect-checking code and it seemed to help

zzz and I said I didn't know if we did that or not

zzz I researched it, and we don't

orignal and you do?

zzz orignal, do you have any test results on how much it helps?

orignal no

orignal didn't measure

zzz it just "feels" better?

orignal but no problems with lookup and publishing anymore

zzz ok. I added code to try it, haven't tested yet, probably need to record some baseline stats first

zzz what is the combination of routers that usually fails to connect? ipv4 only to ipv6 only? or ntcp only to ssu only? or what?

orignal ipv6

orignal of FF that firewalled

orignal also sometimes my tunnels far ends don't support ipv4

zzz ok

zzz I count 23 out of 3678 routers that are ipv6 only and firewalled... not too many

zzz but if they're ff they're more popular

zzz we won't auto-enable ff if firewalled

zzz or if ipv6 only

orignal as I said my problem is tunnel endpoints and gateways

zzz yup

orignal sometimes they have wrong transports

zzz I'll report back after my tests. May be next week, maybe longer, remind me if I forget

zzz anything else on 2) ?

orignal no

zzz 3) peer test results and recommendations

orignal ?

orignal what's with it?

zzz so a week or two ago I mentioned that it seems like my OB tunnels that were 'broken' had i2pd at the OBEP

zzz you said you were running some tunnel tests, so I enabled tunnel testing too and wrote down some results

orignal yes I remeber

orignal tunnel test not peer test

orignal peer test is SSU

zzz correct, my mistake

zzz when tunnel test is enabled, we fail a tunnel after 4 consecutive test fails

zzz 96-97% of individual tunnel tests pass

zzz when there are 4 consectutive fails, about 60% of the time it's an i2pd first hop

zzz about 60% of the time it's an i2pd OBEP

orignal first of IB

orignal ?

zzz first of OB

zzz I only looked closely at the OB

zzz about 40% of my fast peers that I pick client tunnels from are i2pd

orignal first hop or OBEP?

zzz for both, about 60% of the time it was i2pd

zzz so these results are inconclusive

zzz we didn't do that before

orignal interesting

orignal but I missed the point

zzz that's the one time you know for sure the tunnel is broken, and who to blame

orignal if you can't connect firts hop you can't build tunnel

zzz this is after the tunnel is successfully built, and the connection later disconnected

orignal any idea why?

zzz and the reconnect fails when trying to send something out the tunnel

orignal it's disconnected because idle

orignal no?

zzz yes, probably idle disconnect.

orignal did you investigate why recoonect fails?

orignal I don't see a reason

zzz can't tell from here, but either the peer went away, or conn. limits

orignal so is it connection failure or NTCP2 handshake failure?

zzz now maybe we should always allow a connection from a peer that's a previous hop, but that might be hard

orignal also have you checked geo locations?

zzz I don't know. We'll try both NTCP2 and SSU

orignal maybe that routers were in Russia?

zzz I'll look at the routers in question and report back if I see any patterns

orignal since they are blocking tor

orignal would be nice to see what else they are trying

zzz I'm failing about 50 tunnels a day with this, so it's definitely helping

orignal btw, how come?

orignal don't you pick the first hop from already connected peers?

orignal like str4d mentioned long time ago

zzz you don't need a fancy tunnel test to know the OB first hop is a problem...

zzz so that's one thing I've been working on

zzz anything else on 3) ?

zzz 4) udp tunnels

zzz no we don't necessarily prefer connected peers

zzz but in any case the idle timeout is much less than 10 minutes

orignal why? it's a big advantage

orignal because it makes profiling of your trafiic harder

orignal e.g. if few tunnels go through the same connection it harder to recognize your real traffic

zzz in general, we're probably connected (for client tunnels anyway) if we have a lot of client tunnels

zzz not for exploratory

orignal yes, I mean cient tunnels

zzz anything else on 3) ?

orignal no

zzz 4) udp tunnels

zzz I spent most of the last week on a big refactor of our incomplete udp tunnel support

zzz fixing things and adding i2cp from/to port support

zzz in the zzz.i2p thread we said we need documentation on how your udp tunnels work

orignal very easy

zzz we can't evaluate them and either implement the same thing or something better without some docs

orignal I read incoming UDP buffer

orignal I send first packet as repliable datagram

orignal and others as raw

zzz and the replies?

orignal if I receive repliable datagram

orignal I send reply back if I have something to send

orignal either data or technical block for ratchets

orignal so if trafiic if low I always send repliable datagrams and replies

zzz are replies repliable or raw?

orignal and bunch of raw on spikes

orignal repliable

zzz ok

orignal I can't reply to raw

zzz two questions

orignal yes?

zzz 1) can the server handle multiple clients at once?

zzz and know what responses go where?

orignal yes

orignal I maintain "sessions"

zzz ok

orignal once I receive repliable datagram it created a "session"

orignal every session has a queue

orignal of data to send

orignal either it goes with reply

orignal of by timeout

zzz 2) on the client side, if there are UDP DNS queries coming from multiple programs on different localhost ports, can you handle that and send the UDP replies to the right port?

orignal 10 millisecond if I remember

orignal on client I also remeber port where request came from and send back

orignal e.g. another "session"

zzz I don't see how you track sessions if you're using raw though

eyedeekay So is there any point where the repliable datagram from the first packet gets re-sent?

zzz is it by i2cp from/to ports?

orignal but I don't use raw

orignal they are only folllow-on packets

zzz you said "the first is repliable and the others raw"

orignal yes, from the buffer

orignal ofc I meant if they came from the same endpoint

zzz so you track a session by i2cp from/to port pairs?

orignal I don't use i2cp

orignal if you mean gzip header

orignal yes I pass ports there

zzz I don't mean i2cp the protocol, just the port numbers in the gzip header

orignal yes

zzz ok I think that answers my questions, thanks

zzz eyedeekay, did you get your question answered or do you have more?

eyedeekay I am not sure that I did

orignal then ask

eyedeekay I think the place where I'm confused is when you say "First repliable, then raw" first in what? Seems like there must be an interval here, if so, how is that defined?

eyedeekay Is it the whole lifetime of the tunnel, or is a timeout, or is it something else?

dr|z3d repliable sets up the connection it sounds like. handshake?

orignal let me clarify

orignal your UDP socket always has a buffer

orignal and you can set it's size

orignal when new packet arrives it's get placed to that buffer

orignal and then you take it usign read_from

orignal if traffic if heavy ususally you have bunch of packets it it

orignal if this case I send first packet as repliable and others as raw

orignal no I don't set an interval

zzz and the first packet starts the "session", all using the same fromPort, right?

orignal I read first packet then check if more paxckets are in the buffer

zzz assuming they all had the same UDP source IP/port

orignal usually I stop on 25-th of so and give control to the kernel

orignal by calling read_from

orignal yes, right

orignal usually that's most common case

zzz ok, so once you find a UDP packet with a different source IP/port, you have to create a 2nd session with a differet fromPort

zzz and send the first datagram as repliable for the 2nd session

zzz right?

orignal yes

idk_afk I got disconnected mid-answer but caught it over here on my scrollback account

orignal and start as it was new

zzz I understand

idk_afk OK that answers my question, thanks

zzz super

zzz anything else on 4) ?

zzz thanks orignal for the explanation

idk_afk I think I have all the info I need for now, thanks orignal

orignal no

zzz anything else for the meeting?

idk_afk no

zzz also for those that missed it, with my approval acetone is now logging this channel with the 'major' bot and logs are at major.acetone.i2p

dr|z3d (subject to stability)

orignal no

R4SAS btw, can somebody contact with postman? Since previous release connection stucks sometimes for irc

R4SAS so that can happen twice in a day

dr|z3d Is that ongoing, R4SAS? ie has it happened today?

dr|z3d and is there anything log-wise in your client I can forward to postman?

albat it happens for me too 1 or 2 times a day

albat (hi)

dr|z3d connection stuck doesn't help much. more info needed.

R4SAS dr|z3d: I can only say when that happend, no more info

R4SAS because connection made via znc

dr|z3d so the connection gets stuck.. you're just left in a connecting phase?

dr|z3d no timeout, just a perpetual state of "connecting..." ?

R4SAS no, I got timed out like everyone here, in 15 seconds znc reconnects and continue work

zzz you can try asking in #irc2p

R4SAS i haven't heard that postman updated his i2p

R4SAS not now, nor previous release

dr|z3d so you're just getting timed out by the server, is that essentially the issue?

dr|z3d server and/or tunnel lag..

dr|z3d zzz mentioned some possible issue with i2pd 0.9.51 that was causing leaseset issues, dunno is this is related. or what the issue is, exactly.#

albat maybe you should increase timeout to 320

albat it works a lot better now since i did this

dr|z3d I don't think postman broadcasts his router updates, R4SAS :)

dr|z3d you've been busy lately on git, zzz, anything in the pipes?