log☇︎
512 entries in 0.645s
asciilifeform: !#s from:asciilifeform tcp
asciilifeform: mircea_popescu: the braindamage of tcp, iirc, is elaborated in buncha old threads
mircea_popescu: http://btcbase.org/log/2018-09-25#1854293 << tcp is truly a worthless piece of crap. the more one looks at it, the more one doesn't want anyone involved with it anywhere near his shit. ☝︎
asciilifeform: i picture the end product as something like tcp but without the retardations.
asciilifeform: ftr i never grasped why irc is a tcp item to begin with. it aint as if the messages outweigh the available bucket.
asciilifeform: imho tcp , if preserved anywhere, oughta live as a lowered-into-pederasty item-only-carried-over-better-protocols or strictly-on-lan, like telnet.
asciilifeform: tcp imho is fundamentally sad, not the least reason for which is that 'anybody' can break yer pipe
asciilifeform: 'g' , the tunnel-tcp-through-ciphered-udp thing
a111: Logged on 2018-09-18 18:03 ave1: I was working towards having different modules on top of a common base to support tcp / unix sockets etc. but I think your idea is way better, asciilifeform http://btcbase.org/log/2018-09-18#1851315
mircea_popescu: http://btcbase.org/log/2018-09-18#1851334 << i also can't think of a thing that would legitimately need/want to use both tcp and udp as a toplevel thing. ☝︎
a111: Logged on 2018-09-18 16:06 asciilifeform: as for tcp, unixsockets, etc. imho if we ever need these, they oughta live in own separate lib, given as they force somewhat different and gnarlier semantics, they do not belong in 1 gigantic 'kitchen sink' imho
ave1: I was working towards having different modules on top of a common base to support tcp / unix sockets etc. but I think your idea is way better, asciilifeform http://btcbase.org/log/2018-09-18#1851315 ☝︎☟︎
asciilifeform: as for tcp, unixsockets, etc. imho if we ever need these, they oughta live in own separate lib, given as they force somewhat different and gnarlier semantics, they do not belong in 1 gigantic 'kitchen sink' imho ☟︎
asciilifeform: incidentally, my lib can be asmed just as readily as ave1 asmed the classical 'all of tcp stack' glue. ( sadly i dun currently have the free hands to do this )
a111: Logged on 2018-09-17 08:00 ave1: I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done.
diana_coman: ave1> I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done. -> mind publishing somewhere this part then?
ave1: I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done. ☟︎
asciilifeform: ( a reply here, in turn, is not the idjit tcp 'ack', but a packet containing hash(currentsecretsalt + prevpacket) + cipherola-to-current-key , i.e. can only have been generated by the box on the other end, and can only be authenticated by yours
diana_coman: hm, so basically there might be something to "only tcp on gnat.sockets" after all since they baked this assumption in the...implementation of gnat.sockets themselves??
asciilifeform: tcp is very difficult to sanely work with without a stream abstraction, but udp -- trivial.
diana_coman: tcp good, udp bad!!
asciilifeform: diana_coman: that's pretty odd, i could not get it to tcp on 22
a111: Logged on 2013-03-11 07:17 mircea_popescu: actually the plan was to have tcp/ip reimpremented over pigeons
mircea_popescu: you don't really gain so much by having your special packets encapsulated in tcp
asciilifeform: and moreover, they are a problem with the basic design of (for the most part) tcp.
asciilifeform: it's convention, is all, the high ports were reserved for the local ends of tcp pipes
asciilifeform: mircea_popescu: perhaps he dun have a tcp pipe in the cokemachine chair.
phf: http://btcbase.org/log/2018-08-20#1843300 << little known fact: slime's architecture was originally implemented in a similar project for erlang called distel, by the same author luke gorrie. lukego also wrote an emacs clone in erlang and tcp/ip stack in cmucl. ☝︎☟︎
asciilifeform: mircea_popescu: the new biosen are lulzy also, often they have tcp stack nao, and read file system , and even show spam in the setup
a111: Logged on 2018-08-04 22:05 asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd. ☟︎☟︎
asciilifeform: i'm not objecting to the 'opens tcp to to usg server' part. but to the price signal.
spyked: hm. so trinque, OTPs don't have any sort of expiration? the scenario I'm thinking of is that eventually my (for example) home ISP would do some stupid thing that would lead to the TCP connection going down. but that could happen in a week, a month or six from now, so I'd want that OTP to be valid whenever that happens.
zx2c4: mircea_popescu: let's take a protocol that just encrypts ip packets and nothing more. traffic analysis of the size of packets gives you something, especially in the case of TCP where there are necessary types of responses at various points. but i suppose you want me to consider "general purpose cases". so im thinking about a raw UDP protocol. in this case, it might be that at the end of an exchange, one side has nothing more to say, and so it says
zx2c4: with many TCP protocols you can infer what's behind it based on the length
zx2c4: every time i send you something, i expect to hear back from you. if i dont hear back from you, then something bad has happened,and i should start over with a new handshake. my way of hearing back to you might be in the natural sense -- i send a TCP SYN, you send me back a TCP ACK -- or it might be the case that you actually just have nothing to send back to me. you got my message just fine, but really just cant think of anything to say back to me.
asciilifeform: i was convinced that mircea_popescu was picking at the tcp socket handoff !11 lol!!
asciilifeform: i dun think keepalive ( of the http variety , rather than tcp's ) comes into play at all when you aren't on a dialup modem or similar horror
mircea_popescu: (i don't mean it's the same thing ; i mean it's in the http because it was in the tcp.
asciilifeform: not tcp
mircea_popescu: cuz it's in the tcp standard.
asciilifeform: tcp gives every allcomer a quite-expensive 'something'
asciilifeform: mod6: not, sadly, practical with tcp at all
asciilifeform: this problem was a serious headache for the tcp/ip people, they solved it mircea_popescu-style, 'fuckyou and errything going over the wire is to be bigendian' (at the time, bigendianism dominated in 'serious' iron)
mircea_popescu: anyway, for the record : nothing in the world fucking easier than socat -u tcp-1:113,fork system:./say_mp.sh
asciilifeform: it's a resurrection of circa-2014 embraceandextendism -- 'let's impose prbtronic sslistic payment-via-tcp, and at the same time spam some moar spamola, make blox less breathable'
asciilifeform: prbism where you gotta tcp to somebody's box to pay him, or something of the kind
vlad56324: now with broadband it seems that everyone has the permission to grant the shit out of my pc in terms of TCP connections
asciilifeform: because we're doing arbitrary tcp to whole planet, presumably ? vs derping around inside one physical house
mircea_popescu: so basically they made a thread to "replace" the work the os does with the tcp stack, for instance.
asciilifeform: tcp'd to death, looks like.
a111: Logged on 2017-08-21 22:31 asciilifeform: i don't much like the phrase 'trusted nodes', when you connect to trb node, you get plaintext tcp, and 0 guarantees re who or what you're actually talking to.
asciilifeform: i don't much like the phrase 'trusted nodes', when you connect to trb node, you get plaintext tcp, and 0 guarantees re who or what you're actually talking to. ☟︎
ben_vulpes: "the greatest website to ever fit in a single TCP packet"
mircea_popescu: the equivalent of "no need for flow control" in tcp/ip say
a111: Logged on 2017-07-20 19:01 trinque: pf: pf_normalize_tcp_stateful failed on first pkt << deedbot departures appear to correspond with this.
asciilifeform: it can't really be vanished away without killing 'tcp to arsebook' etc also. as i currently understand it.
asciilifeform: ( and other tcp )
trinque: pf: pf_normalize_tcp_stateful failed on first pkt << deedbot departures appear to correspond with this. ☟︎
asciilifeform: and partly in that i find the 'prototype' that solves 0 of the difficult problems, simply not interesting. i can write a perlism that pushes shitrsa packets over tcp etc. in half hour. but why.
a111: Logged on 2017-06-30 07:41 sina: can change tcp for udp, can change sql for flatfile, can change python for syslang
sina: can change tcp for udp, can change sql for flatfile, can change python for syslang ☟︎
sina: I was thinking about the latest iteration which is much simpler, I think I might try and convert the TCP bit to UDP tomorrow
asciilifeform: in other, not wholly unrelated, lulz, '...out-of-bounds write in systemd-resolved in Ubuntu, which is possible to trigger with a specially crafted TCP payload. ... Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this... A malicious DNS server can exploit this by responding with a specially crafted TCP payload
sina: tmsr trigger warnings: it uses sqlite, TCP, OOP but I tried to make it modular enough that those things could easily be changed. It isn't the lighthouse or linespeed thing asciilifeform has mentioned, I just tried to follow the spec on trilema.com
trinque: what you've got there looks like a tcp-gpg-wad hucker
asciilifeform: hey i know a TCP jokehey i know a TCP jokehey i know a TCP jokehey i know a TCP jokehey i know a TCP jokehey i know a TCP jokehey i know a TCP joke[barf]
Framedragger: i guess no way to use luby code or equivalent on tcp huh
asciilifeform: in tcp
jurov: idea: what about providing fuckgoat output in realtime, as tcp stream. maybe i'll do when i get some
mircea_popescu: dude, what the fuck is with the bullshit. "we made a tcp on top of tcp because we're bored at "work" and hurr."
mircea_popescu: "Unlike TCP, the service mesh has a significant goal beyond “just make it work”: it provides a uniform, application-wide point for introducing visibility and control into the application runtime."
asciilifeform: now, not all of these invocations are of recv() for udp. most -- tcp.
Framedragger: that's why i preluded with "if backend connects over tcp"
Framedragger: huh, queries should be cancelled upon a failed http request.. if backend connects to db over tcp socket perhaps check https://www.postgresql.org/docs/current/static/runtime-config-connection.html#GUC-TCP-KEEPALIVES-IDLE
asciilifeform: 'February 16, 2017 ... Enphase Energy, Inc. (ENPH), a global energy technology company, today announced that it has refinanced and extended its term loan facility with certain funds managed by Tennenbaum Capital Partners ("TCP") from $25 million to $50 million.'
asciilifeform: attempts to secure tcp are duct tape.
a111: Logged on 2017-03-14 14:07 Framedragger: mircea_popescu: re. blackholing and to be alf-pessimistic for a second, node is exposed to risk of being blackholed as long as it uses TCP; because not only can enemy make it read packets (unavoidable in the end it seems), but there may be ways to making it send packets back.
asciilifeform: the important thing is to throw tcp straight into the shitcan where it belongs.
asciilifeform: Framedragger: the problem with tcp isn't simply that enemy can insert an RST packet and make you blame your peer. (and whitelists do 0 against this.) but that it is very expensive , computationally, long before you have any idea who you're talking to. ☟︎
Framedragger: (i guess "silently drop connections" (TCP DROP) from any non-whitelisted IP is one way around it, sorta.)
Framedragger: mircea_popescu: re. blackholing and to be alf-pessimistic for a second, node is exposed to risk of being blackholed as long as it uses TCP; because not only can enemy make it read packets (unavoidable in the end it seems), but there may be ways to making it send packets back. ☟︎
asciilifeform: that being said, you can use 'wire' with anything that can maintain a ciphered tcp pipe between two boxes. dun have to be ssh.
asciilifeform: 'IOC/ECG's Advanced Forensic Division (AFD) performed an analysis of Hive version 2.5 network communications to assess its likelihood of detection.The results of this analysis are found in document AFD-2012-0973-2. In summary, AFD was able to create signatures for DNS, ICMP, and TFTP triggers; found that the TCP and UDP triggers did not adhere to their respective protocol standards; and further found that the TCP and UDP triggers eac
asciilifeform: or any matches. If a match is found the packet is assumed to be a TCP replay and is dropped.'
asciilifeform: https://wikileaks.org/ciav7p1/cms/files/DevelopersGuide.pdf << for aficionados strictly -- details of implant protocol, where gibblets are disguised as tcp replay packets. apparently standardized across this particular directorate.
asciilifeform: which is why you'll often find trb-related tcp pipes randomly RST'd, and the like.
asciilifeform: my wired nodes still find each other via addr.dat and open ~second~, plaintext tcp pipe...
asciilifeform: srsly almost ANY protocol built on top of raw lossy packet, even with one hand tied behind your back, ends up beating the shit out of tcp.
asciilifeform: http://btcbase.org/log/2017-02-10#1613048 << you get ~all of this for free JUST BY DUMPING TCP ☝︎
asciilifeform: ben_vulpes: also subject to all classical tcp abuses (enemy can close connection for you without breaking a sweat or any cooperation from counterparty)
asciilifeform: tcp over dead monkey?
asciilifeform: with which to tcp
ben_vulpes: "tcp inject"!
asciilifeform: (specifically they did not permit chumps incoming tcp)
asciilifeform: mircea_popescu: the tcp stack per se does not offer any means whereby two proggies speak simultaneously through 1 socket
asciilifeform: this, incidentally, was a proggy that doesn't even use tcp.
asciilifeform: mircea_popescu: 'g' was result of my frustration with trb's plaintext tcp
Framedragger: mircea_popescu: the 20M or so servers which responded to TCP SYNs sent to port 22. however, out of those, about 5M (or however many) did not respond to ssh handshakes, hence the lower number in the banners and phuctor payloads.
Framedragger: (oh oh, and also trying out masscan (the first-stage scanner, i.e. the one which sends TCP SYNs) with maybe 30-100k packets per second stable))