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?