#ls2 (irc2p) | #ls2 proposal review channel

dr|z3d anyways, there are plenty of routers with good bandwidth that aren't making excessive requests to a single router. this one's an outlier which is why it's turning up in logs. just suspicious.

orignal I can tell you something why it might happen

orignal retroshare

orignal they have implemented Bob wrong

orignal look at the thread at 333.i2p about it

dr|z3d oh, interesting, if it's non-malicious and just a coding fuckup. either way, I'm tempted to add that id to the blocklist.

orignal 333.i2p/topics/201-client-tunnels-limits

dr|z3d thanks

R4SAS that's when I added some checks and fixes?

orignal but in trunk

orignal I guess people still use release version

obscuratus dr|z3d: I noticed that router also.

dr|z3d obscuratus: oh, you too? making a huge amount of part tunnel requests in short order?

obscuratus I see a pretty consistent high amount of tunnel requests.

zzz orignal, R4SAS, last 4 hours and 10 minutes, since R4SAS said "updated" :

zzz 10 YXEAXl

zzz 9 BpATV4

zzz 6 CEFnjX

zzz 4 bAU~6X

zzz 3 k8vhnd

zzz 2 Qreu1M

zzz 2 p~8-FO

zzz 2 ~GIB3b

zzz 1 kyY2Tx

zzz 1 2RRYXk

orignal let me check 2RRY

orignal I don't see AEAD errors

orignal or unexpected messages from you

orignal SSU2: Unexpected message type 183 from [2a02:180:2:92:92:92:11:15]:16799

orignal I see only one

orignal and it means I don't have a session on my side anymore

orignal and it doesn't seem it's about SessionConfirmed

orignal but SessionRequest

zzz nope. 9:26:31 our time, got session created, send session confirmed, sent 3x more times, sent at least 4x data packet, expired 9:26:42

zzz same failure as reported for many days

orignal sec

orignal yes I see it, but it's much before

orignal SSU2: Unexpected message type 229 instead 2

orignal that's what it is

orignal I expect SessionConrimed but got some crap

orignal and terminate the session on my side now

zzz the "crap" is my big RI. Did you test your changes yesterday? because I see no improvement

orignal yes I did

orignal do you know if you sent two sessionconfirmed

orignal I see improvement

orignal because yeasterday I couldn't handle your RI at all

orignal today I see incoming connections from you all the time

orignal -Akx: [2a02:180:2:92:92:92:11:15] => [65380:315756] [itag:2249102499]

orignal even right now. how can you explain it?

zzz I can't, you'll have to investigate on your side

orignal yes, I know. That's what I'm going to do

zzz :)

orignal I only mean ivprovement you don't see

orignal you are definitly able to connect now

zzz yeah but about the same with YXEAX, for example, yesterday 25 failures in 12 hours; today 10 failures in 4 hours

orignal let's concentrate on 2RRY

orignal are you sure hat YXEA is ours?

zzz that's what my notes say, along with BpAT and kyY2, but of course my notes could be wrong

zzz in last ~10 hours I see 11 success and 1 failure to 2RRY

orignal BpAT yes

orignal so let's inverstigate this failure to 2RRA

R4SAS YXEA as I said is mine

R4SAS 14:12:58 <+R4SAS> YXEA - 1561

zzz ok let me look for any difference between the 11 that worked and the one that didnt

orignal <orignal> R4SAS can you check your log?

orignal <orignal_> you should see error from zzz's IP

zzz don't see anything different on the one that failed. wasn't the biggest RI, wasn't the smallest

zzz pkt sizes: 1452, 293

orignal I don't think it's related to fragments

zzz R4SAS, are all your interfaces on all your routers 1500 MTU?

orignal but let me check how I handle is second fragment comes from first

orignal zzz it doesn't matter now

orignal becuase const size_t SSU2_MTU = 1440;

orignal so we never send 1500

zzz I'm sending a 1500 byte ipv6 pkt to you. so if you can't handle it, it's a problem

orignal maybe

orignal let me check mine

orignal mtu 1420

orignal voila )))

zzz because you're not publishing MTU in SSU2 address so I'm assuming 1500

orignal mtu 1480 for HE tunnel

orignal btw, do you know if this failure is about ipv6 only?

zzz i already looked. It's almost all ipv6, but I prefer ipv6, so that doesn't mean much

orignal how about xZ9N?

orignal it's ipv4 only

zzz how big were the crap packets you got from me?

orignal and as you can guess 2RRY is 1500

orignal I didn't print size

orignal but again 2RRY is 1500

orignal it means it's something else

orignal and I will add mtu shortly

orignal as you see 1420 in one router

orignal that less than my packet side

orignal *size

zzz no xZ9n failures since yesterday

zzz R4SAS, please report your MTUs

orignal let me start publishing it

zzz BpAT and YXEA both reporting 1472 for ipv6 SSU address

zzz well, that was one time in 12. I'm logging the session confirmed and data packet sizes, so whenever you have the logging to tell me what you got, we can chase that one further

orignal let me implement mtu first

zzz yup

orignal also I have that issue with 1420

orignal meaning it's not only publishing

zzz don't see any 1420 mtu routers right now

orignal because it's ipv6 only )))

orignal MNcW

orignal do we publish mtu without address?

orignal please remind me

orignal I mean without host

orignal also do you know where this code comes from?

orignal if (mtu > 1472) { // TODO: magic constant

orignal mtu = 1472;

orignal hence you don't know what is his real MTU

zzz yes

zzz originally the default and max mtu was 1484

orignal do you thinl I should change it to 1500 ?

zzz so then ipv6 had to be lower, or 1472

zzz later, we did a proposal I think, and said ipv6 could be 1488

orignal what's you suggestion ?

orignal for this code

orignal that's where I set mtu for publushed address

orignal and again do I publish mtu without host?

zzz SSU 1 IPv6 must be mod 16 == 0, so the max is 1488, as of Proposal 127, 0.9.28, 2016-12-02

zzz yes you must publish MTU if it is not the default, whether you have a host or not

orignal then where 1500 come from?

orignal I can change to 1488, not a problem

zzz 1500 is the max and default for SSU2, as specified in proposal 159

orignal fine 1488 for SSU1 and 1500 for SSU2

zzz because no mod 16 required

orignal right?

zzz max is 1484/1488 for v4/v6 SSU 1. default is 1484 for SSU 1. max and default are 1500 for SSU2, both v4/v6

orignal I publish mtu for ipv6 only

zzz when published as "SSU", you must use the SSU 1 default for SSU2. As specified in prop. 159.

orignal I don't publish SSU2 as SSU

zzz right, but those are the rules for getting the MTU from addresses published as SSU

orignal R4SAS netsplit

zzz you must, of course, publish non-default MTU for ipv4 also

orignal I doubt we have a code for ipv4 mtu

orignal but that's another task

orignal you should see mtu=1420 for MNcW

R4SAS zzz: ipv4 - yes

R4SAS 1480 for ipv6 because I use HE.net tunnels

zzz ok, so that's probably the issue

orignal please take last commit and re-create router.info

R4SAS kk

R4SAS also one router crashed, but I didn't built binary with symbols

orignal it's possible

R4SAS that's first time

R4SAS updated