tmsr - Search: tcp

500+ entries in 0.707s

ossabot: Logged on 2019-12-18 18:44:31 jfw: "minimal possible bootable" seems a slippery goal, you could trim down to barely any OS at all. But then some pesky user comes along and wants graphics, and TCP, and to run on recent iron and then what.

jfw: "minimal possible bootable" seems a slippery goal, you could trim down to barely any OS at all. But then some pesky user comes along and wants graphics, and TCP, and to run on recent iron and then what.

trinque: I don't think you expect to actually be yourselves patching acpica autoconf automake bash bc bison bzip2 cl-hyperspec clisp dash db flex gales-util gcc64 git gnupg less libevent libressl libusb links m4 man-pages man-pages-posix mandoc ncurses nginx ocaml openssh patch pciutils perl php56 py-setuptools python python-docs qmail readline redis sbcl sqlite sqlite-doc tmux ucspi-tcp vim xz zlib

mp_en_viaje: in other sads, ~all of the czech republic has a massive connectivity issue ; no fucking internet in prague's worth the mention, my remote-over-telco links are just as bad because it's not tcp/ip level but actually telco level, and for some reason satcover here is shit right no

mp_en_viaje: even tcp'd have been ok by itself. the "pingpacket" thing is dumb.

asciilifeform: tcp 'ftw'

asciilifeform: mp_en_viaje: loox like hooligan might be sending forced tcp close in 'your' ip .

BingoBoingo: All of them doing TCP SYN without getting my dumps requested in person ours ago.

BingoBoingo: "Can I get a packet dump from at least one of the floods before sitting down and discussing options for moving forward. The graphs seem to show when activity is happening, but they lack information that could be used to put together a mitigation strategy. Is the incoming traffic UDP, TCP, ICMP, etc? Is there any information that suggests an origin or origins. Hay una falta de información forense que pueda ayudar a evaluar lo que est?

asciilifeform: ftr i did not put this in genesis because naively supposed that ordinary workings of tcp will in fact throw a connection if the pipe were to unplug. but apparently this aint so

spyked: http://logs.ossasepia.com/log/trilema/2019-10-03#1939920 <-- moreover, for some reason it seems that passive (i.e. listening) tcp socket much easier to keep open than active one; it's often happened to me to get to irc console in the morning and notice "ping timeout" from server for ??? reason.

trinque: tcp 0 0 45.32.123.240.31311 130.185.232.126.6666 ESTABLISHED

mircea_popescu: i mean, i see the merit, but isn't this rather tcp-style overloading of adhocisms ?

bvt: asciilifeform: today i had a quick look through stevens, apparently timeout for SO_KEEPALIVE is two hours (digging through linux source confirms), so i don't think this option is any useful as is; TCP_KEEPIDLE sets the keepalive timeout per-socket, but then there is a question to which extent to rely on all of these socket options.

snsabot: Logged on 2019-09-09 20:14:25 lobbes: http://logs.nosuchlabs.com/log/trilema/2019-09-09#1935281 << bvt, would you be able to produce the vpatch? I would, but a) my knowledge of tcp stack / kernels / etc. is pretty much nil and b) I'm gearing up to focus 100% on mircea_popescu's latest mp-wp bot ask if I end up winning this auction.

snsabot: Logged on 2019-09-09 17:22:25 asciilifeform: i still dun grasp why os's tcp stack doesn't liquidate a socket known to be stone dead. but this i suppose is a q for the original perpetrators , when they're connected to 220v

lobbes: http://logs.nosuchlabs.com/log/trilema/2019-09-09#1935281 << bvt, would you be able to produce the vpatch? I would, but a) my knowledge of tcp stack / kernels / etc. is pretty much nil and b) I'm gearing up to focus 100% on mircea_popescu's latest mp-wp bot ask if I end up winning this auction.

asciilifeform: i still dun grasp why os's tcp stack doesn't liquidate a socket known to be stone dead. but this i suppose is a q for the original perpetrators , when they're connected to 220v

asciilifeform: mircea_popescu: if the tcp stack per se is retarded in this way, i expect it is also in cobol , fortran, etc, how not.

asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-09-08#1935080 << seems like finally lobbes photographed that legendary ufo, the 'socket alive, but wedged tcp' state.

snsabot: Logged on 2019-09-06 06:50:37 mircea_popescu: (this, also, before we get into "Hunchentoot talks with its front-end or with the client over TCP/IP sockets and optionally uses multiprocessing to handle several requests at the same time. Therefore, it cannot be implemented completely in portable Common Lisp. It currently works with LispWorks and all Lisps which are supported by the compatibility layers usocket and Bordeaux Threads." discussions.)

mircea_popescu: (this, also, before we get into "Hunchentoot talks with its front-end or with the client over TCP/IP sockets and optionally uses multiprocessing to handle several requests at the same time. Therefore, it cannot be implemented completely in portable Common Lisp. It currently works with LispWorks and all Lisps which are supported by the compatibility layers usocket and Bordeaux Threads." discussions.)

snsabot: Logged on 2019-08-22 12:35:01 asciilifeform: spyked: mine disconnects strictly when a send() or recv() actually return eggog (i.e. indicating dead tcp pipe)

asciilifeform: diana_coman: if it runs, will run, all that's asked of it is to forward a tcp pipe to port x (whichever yer py is on)

asciilifeform: worse, not even certain that it is possible to write a clean/light www shitter , considering what http , tcp , are like to begin with

asciilifeform: mircea_popescu: i can think of a few riotously braindamaged proggies atm (e.g. 'sshd', where author somehow thought it acceptable to generate host key at boot ; and tcp stack, where seq #'s )

snsabot: Logged on 2019-08-22 21:48:34 trinque: the thing's literally built atop tcp which supposedly has "connections" and it wants this ping/pong mechanism atop. ask me how many more hours of my life I wish to dedicate to this duck cunt that just wants a bit more.

trinque: the thing's literally built atop tcp which supposedly has "connections" and it wants this ping/pong mechanism atop. ask me how many more hours of my life I wish to dedicate to this duck cunt that just wants a bit more.

asciilifeform: spyked: mine disconnects strictly when a send() or recv() actually return eggog (i.e. indicating dead tcp pipe)

asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930066 << ftr i've yet to observe this 'silent wedge' effect in my bot (i.e. where the tcp pipe is 'alive' but not doing anyffin useful). tbf it is, what, only 3rd week of this bot.

snsabot: Logged on 2019-08-20 15:01:22 asciilifeform: atm i vaguely suspect that tcp on piz is slowed by an inept wiretap somewhere.

asciilifeform: ( and, interestingly, specifically fucked re tcp. )

snsabot: Logged on 2019-08-20 07:47:16 mp_en_viaje: would like to take the time to point this out re ye olde discussion of "is something to learn / is nothing to learn", coming up oft re gosspid but generally always there. "to learn" is insanely vague an operator. just because you don't learn anything useful [about programming] while doing, say, python, it still dun mean you don't learn anything useful about your girflriend, or the tcp infrastructure, or router har

mp_en_viaje would like to take the time to point this out re ye olde discussion of "is something to learn / is nothing to learn", coming up oft re gosspid but generally always there. "to learn" is insanely vague an operator. just because you don't learn anything useful [about programming] while doing, say, python, it still dun mean you don't learn anything useful about your girflriend, or the tcp infrastructure, or router hardware, or the difference be

asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-19#1929694 << this is worth expanding on. asciilifeform also gets very fast pings ( never moar than 200msec, to date ) and fast udp. what i suspect is, usg's snoop gear that sits as parasitic toad on south amer's pipe, specifically slows down tcp.

asciilifeform: pipe delay ( piz <-> asciilifeform's chair , cannot be generalized to entire planet ) varies from 0.2-0.4s (for revvup of tcp pipe, that is)

asciilifeform: mp_en_viaje: thinking about it, it's outgrowth of tcp retardation, where having the client alive costs the server at all times

asciilifeform: in trad irc, server periodically asks 'PING blah' and client expected to 'PONG blah' back (why? if it's a tcp pipe? what's the whole point of tcp, orig, if not to avoid this? dun ask me)

bvt: asciilifeform: until the day for tcp to die arrives, you'd still have to interact with tcp warts in that or other form

asciilifeform: my 'udp' lib was orig. gonna be a 'udp and tcp' lib. but very quickly realized...

asciilifeform: could try to use ada's 'streams' model. but then must decide, how to represent ~all~ of the possible tcp hiccups.

asciilifeform: aand that's just pg. now consider how to deal with tcp.

bvt: true, but i don't find '80% of cl argument' too convincing; if want comfort, sure, use cl/python; want hard memory limits and gcc performance, can use ada, it won't be fundamentally dirtier (due to tcp and db stuff), just more boilerplate code

asciilifeform: ( tcp?! )

asciilifeform: bvt: how do i throw into a tcp socket a formatted fetch of log, consisting of unknown length of "<a ... " + blah + "</a>" etc, w/out string munging ?

asciilifeform: currently there aint a 'tmsr lang' in which can readily write wwwisms. (i dun even have a tcp end for gnat atm)

asciilifeform: what does, is to prevent eternal hang on silent (ask the tcp committee why this is physically possible, not me) deaths

asciilifeform: reason why 3 decade of 'apache' is same as why erryone (incl. microshit) is using that SAME tcp stack from berkeley '80s. cuz protocol was deliberately made so braindamaged, with literally 10,000+ moving parts, that ~impossible to correctly reimplement if demanding compat with 'everyone'

asciilifeform: point is , tho, that it is barfalicious ~because tcp~, not because author as such was tard

asciilifeform: 'Now, as if this wasn't enough, TCP also has a (transport layer) segment size, which must fit into a so-called "Maximum Segment Size" (MSS), which must be smaller than the MTU, because we also need to fit lower-layer headers and all that. Otherwise TCP isn't concerned too much with this, but misconfiguration can cause problems with congestion windows and whatnot, and we sure as hell don't want this shit to blow up. Finally, as if the

asciilifeform: as if the ludicrous cpu & bw waste of tcp weren't enuff, it also conveniently groups (with said grouping being entirely plaintext) 'sessions' for hitler to moar conveniently store & read.

asciilifeform: tcp was a 'gift' of profound retardation that 'keeps on giving', even to moar obvious extent than e.g. unix. it is single-handedly responsible for ~100% of the backbreaking complexicrud of apache, ssh, ftp, etc

asciilifeform: not to mention, gotta establish process re tcp ddosen. tomorrow could be e.g. qntra instead.

asciilifeform: re upstack >> anyone using one of asciilifeform's kernels can use simple cure : echo 0 > /proc/sys/net/ipv4/tcp_sack ☝︎

a111: Logged on 2018-08-21 17:36 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.

a111: Logged on 2019-05-29 08:51 spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place.

a111: Logged on 2019-05-29 15:27 asciilifeform: tcp shows erry possible sign of having been designed, from the start, to extend the ease of snoopage from traditional circuit-switched telco grid, to the packet world. consider e.g. the 'helpfully' plaintext sequence numbers.

asciilifeform: tcp shows erry possible sign of having been designed, from the start, to extend the ease of snoopage from traditional circuit-switched telco grid, to the packet world. consider e.g. the 'helpfully' plaintext sequence numbers. ☟︎

a111: Logged on 2017-03-14 14:31 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.

a111: Logged on 2016-08-26 13:34 asciilifeform: tcp is evil, fundamentally because it violates the 'NEVER something-for-nothing-to-all-comers-FUCKOFFRANDOS' principle.

asciilifeform: spyked: not only is the implementation what it is, but tcp per se is massive pile o'shit, where it aint even possible to implement it w/out 9000 tonnes of state machine gnarl

a111: Logged on 2019-05-29 09:06 spyked: the weird part is that the linux tcp stack ~works~ for the most part. I imagine the maintainer of that particular subsystem must be a neckbeard with 20+y experience in tcp (because sure, it's not only the implementation, the protocol itself is a mountain of complexity)

spyked: and then looking at e.g. https://elixir.bootlin.com/linux/v3.10/source/Documentation/CodingStyle , one can readily notice that half or maybe more of the tcp code doesn't meet that minimum set of criteria. and yet... it's there. so, I guess re. http://btcbase.org/log/2019-03-15#1902966 he was prolly dumb from the very beginning ☝︎

spyked: the weird part is that the linux tcp stack ~works~ for the most part. I imagine the maintainer of that particular subsystem must be a neckbeard with 20+y experience in tcp (because sure, it's not only the implementation, the protocol itself is a mountain of complexity) ☟︎

spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place. ☝︎☟︎☟︎

Mocky: and i can also expand later on what's with the 'connecting', tcp? and what's with the directories, protocol on top of tcp? I'm hoping that its figurative and you don't literally want to build gns on tcp and http

asciilifeform: tcp over slightly bent rudder.

mp_en_viaje: but the point here was, that as long as what you're implemeting is, say, tcp, or dram, what you will get is not in fact a safely auditable object.

mp_en_viaje: now imagine a fpga, surrounded by 725 islands, leveraging each one thing, this is net-a that is tcp-ip-b, that'

mp_en_viaje: so : suppose a) tcp/ip is intrinsically, by its very [deliberate, and previously uknown-ly so] design vulnerable to "blowhammer", which is a class of yet undescribed attacks ; suppose your fpga includes an electrically-isolated leverage for a.

mp_en_viaje: http://btcbase.org/log/2019-04-06#1907145 << this is a more doubtful claim. what patterns, tcp/ip ? ☝︎

a111: Logged on 2019-03-26 21:31 asciilifeform: i'll add that even a tcp skin wouldn't be entirely useless ( right nao the only way to write a wwwistic proggy in ada is to use adacorpse's 'gnatsockets' crock of shit )

asciilifeform: asciilifeform sees tcp as a legacy tech, really

mircea_popescu: might tbe a better route, esp if it delivers a cheap way to a tcp-based republican web, to replace the www.

asciilifeform: i'll add that even a tcp skin wouldn't be entirely useless ( right nao the only way to write a wwwistic proggy in ada is to use adacorpse's 'gnatsockets' crock of shit ) ☟︎

asciilifeform: or , say, take tcp. mircea_popescu aint even a programmer, and is just about as 'clean' as a fella can get in re programming radiation damage and still have worked with comp. but it took asciilifeform 3+yrs to get him to see that tcp is -- by design -- garbage

BingoBoingo: There's likely logistics lessons to be learned. Timings necessary to keep conenctions open and other tcp weird.

asciilifeform: ( e.g. the problems of mitigating tcp ddos are irrelevant to proper udpistic gossipd. and ditto authentication of handles. )

asciilifeform: diana_coman: i'll admit that it isn't clear to me how effort put into baking glue for oddball nonstandard ircisms helps in re gossipd . irc as i see it is an entirely dead-end tech ( rides on tcp, and 0 notion of crypto , and cannot be retrofitted really )

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.

mircea_popescu: tcp, prospect of "wtf, mysql, postgres", prospect of wtf we do with xml, prospect of cl-php-replacement, prospects galore.

asciilifeform: defo premature, esp. in light of prospect of e.g. ditching tcp

a111: Logged on 2019-01-22 07:16 mircea_popescu: and yes, obviously, the problem is tcp connection is stateful, which means memory allocation, and SUCH THINGS (if not necessarily just that thing).

mircea_popescu: and yes, obviously, the problem is tcp connection is stateful, which means memory allocation, and SUCH THINGS (if not necessarily just that thing). ☟︎

asciilifeform: fwiw simply rejecting tcp won't do the trick, you also gotta not allocate state for udp ( all extant routers, afaik, do.. but e.g. s.mg protocol and similar, will operate entirely correctly without this, as i understand it )

asciilifeform: ( and also happen to know why : they 'give to allcomers' in the sense of allocating memory for state of tcp connection. therefore it stands to reason that if one built router that doesn't tcp at all -- it will not fall. )

asciilifeform: mircea_popescu: i have plain old tcp with 'pehbot' ( via trinque's cl proggy )

mircea_popescu: no, what i'm saying is that with udp it is ~never worth "Retrying" in the tcp sense.

asciilifeform: ( unlike e.g. tcp, where pipe can die )

asciilifeform: the mechanics of use is actually 'easy part' -- they take x11 pipe over tcp, and are pretty light on graphics (1bit raster)

asciilifeform: i for instance am sitting here and tryin', not always successfully, to cure folx of delusions that linux instilled in'em, e.g. 'tcp gives cheap an' reliable pipes' ( cured mircea_popescu after , what, 3y ) and nao 'udp packets can be anyffing, not merely 1472' (not cured yet..)

mircea_popescu: 6. if you pertmit this 16kb item be chunked, you basically rebuild the tcp ddos bs long discussed here. if it has to be in 1 piece, you can always use or discard on sight.

mircea_popescu: but, yes, alf has a point : meanwhile read up ~on tcp~. despaired.

BingoBoingo: End then we'd have to strip down tcp over carrier pigeon to get UDP over carrier pigeon

mircea_popescu: i'm currently connected through the internet through sheer force of will, and there's a tcp thing trying to rape this.

asciilifeform: wouldn't go this far; dunno about mircea_popescu , but i'm presently connected to fleanode, trb, etc via tcp

mircea_popescu: im not fucking writing that. i don't like tcp enough.

asciilifeform: mircea_popescu: 'catalogue of tcp braindamage' is prolly ripe for an article. ( sadly asciilifeform is mired in liquishit and prolly will not write it this wk )

a111: 158 results for "from:asciilifeform tcp", http://btcbase.org/log-search?q=from%3Aasciilifeform%20tcp