log☇︎
512 entries in 0.92s
mircea_popescu: why would you imagine THAT particular aspect of the charade is in so much better shape than all the others ? can'\t fucking compile, right ? why would you be able to tcp/ip ?
punkman: but there are other tools that can pipe the graphics over tcp, no?
punkman: why should I want pipe x11 over tcp?
ascii_field: FUCK this-replaces-x11-but-won't-pipe-over-tcp
assbot: Logged on 26-02-2015 21:09:34; asciilifeform: PeterL: most 'alternatives for x11' dispense with the everything-can-be-piped-over-tcp
assbot: How both TCP and Ethernet checksums fail (evanjones.ca) ... ( http://bit.ly/1G34kXn )
punkman: http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html
trinque: and yet... tcp 0 0 172.30.0.227:56649 94.125.182.252:7000 ESTABLISHED
ascii_field: http://log.bitcoin-assets.com/?date=08-09-2015#1266672 << mongolia has what, tcp-over-dead-goat modem ? ☝︎
mircea_popescu: atm the explanations are, bad tcp/ip implementation on the machine running it in a very subtle way, or some issue in the firewalls downstream
ascii_field: this drew my attention to the asinine tcp socket handling in therealbitcoin
asciilifeform: mircea_popescu: gotta have at least a minimal scheduler for tcp/ip
trinque: and the qemu commands is... qemu-system-x86_64 -hda root.img -vnc :0 -redir tcp:2222::22
mircea_popescu: and tcp with 2nd chan did not catch on precisely because added complexity.
asciilifeform: iirc tcp as originally proposed had a second channel for virtual 'out of band' ! but was never used.
mircea_popescu: or must have tcp packets and udp checksums separate ?
asciilifeform: i have a box where some sniveling fucker has been lifting payloads out of tcp, for ~9+ hours now.
trinque: decimation: I believe /dev/udp and /dev/tcp are bashisms which do not actually exist as a device node
ascii_field: now we also need a tcp crud pipe for every access to the blockchain ????!!
asciilifeform: after which we get to write gossipd with tcp syn instead of udp
decimation: at any rate, the problem isn't udp or tcp, it's the fact that ip packets route without any signature
asciilifeform: mircea_popescu: if it's tcp, you are serving jam to folks for showing up
jurov: then you'll just enable the reflection attacks right to your tcp port 80.. indeed fun to watch
mircea_popescu: let them run on tcp/ip, should be fun to watch.
mircea_popescu: asciilifeform ftr, i am noit proposing orphan-block TCP is any better. shouldreally be TCP/OB
asciilifeform: to filter tcp syn vs empty udp
asciilifeform: mircea_popescu: so then you get flooded with TCP SYNs. same difference.
asciilifeform: it is relevant to having created this bizarre situation where mircea_popescu thinks that tcp somehow solves ANY of the problems discussed earlier
asciilifeform: as tcp forces.
decimation: and it's not exactly like it is hard to game the tcp state machine
asciilifeform: it is tcp which is the ultimate braindamage.
asciilifeform: routing tcp no-questions-asked while filtering packets that could be signature-authed without storing state is braindamaged.
asciilifeform: mircea_popescu prefers to be ddosed with tcp ?
Azelphur: Also, if anything UDP is lighter on the infrastructure than TCP
Azelphur: mircea_popescu: you realise UDP is essential for a number of services and that they wouldn't function using TCP, right?
punkman: "For TCP/IP, the tool fingerprints the client-originating SYN packet and the first SYN+ACK response from the server, paying attention to factors such as the ordering of TCP options, the relation between maximum segment size and window size, the progression of TCP timestamps, and the state of about a dozen possible implementation quirks (e.g. non-zero values in "must be zero" fields)."
asciilifeform: as for that one, you could, conceivably, look at sequence numbers and learn when a severely broken tcp/ip stack is in use
mircea_popescu: asciilifeform the part where they make wildly improbable claims (ex : purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications (often as little as a single normal SYN) without interfering in any way.) but then mishmashingly backtrack on it (this release candidate still has a relatively small database of fingerprints) and so on
trinque: in this case it'd be as BingoBoingo said, don't have fucking dumb hosts that can't TCP
BingoBoingo: <trinque> mod6: BingoBoingo: what are your opinions on using random-id and reassemble tcp in incoming traffic through pf? << Haven't used either of those yet. Pretty much use block, pass, and queue
mod6: im not positive (i don't have access to my pf.conf atm) that i've ever used random-id. i think that's for a very specific problem. but yeah you probably /do/ want scrub all reassemble tcp
trinque: mod6: BingoBoingo: what are your opinions on using random-id and reassemble tcp in incoming traffic through pf?
mircea_popescu: i dun see how they do anything. either they maintain compliance with tcp/ip spec as is, in which case they do nothing
ascii_field: 'Trend Micro Threat Intelligence Manager installs a secure web interface (httpd.exe, tcp port 443/https) which listens for incoming requests. Several vulnerabilities have been found in the product that would allow a remote attacker to cause the product to execute arbitrary code.'
assbot: Logged on 02-02-2015 23:03:08; mircea_popescu: "I've noticed certain repeating characteristic in the writing of many members of this forum: they construct grammatically correct sentences but absolutely disregard the underlying semantics: incoming vs. outgoing, local vs. remote, source vs. destination, etc. Here in regards to TCP/IP ports, but I observed that in regards to pretty much any technical issue."
decimation: even microsoft needs a tcp/ip stack - reminds me of your blog post on 'the burden of supporting all the world'
assbot: Logged on 03-07-2015 01:39:38; asciilifeform: or does it open ordinary sockets and expect a tcp stack
decimation: it uses a tcp connection with a special block server I think
asciilifeform: or does it open ordinary sockets and expect a tcp stack ☟︎
ascii_field: there are ~working~ tcp stacks for 'bare bios'
ascii_field: and not, as naive might suppose, the tcp/ip !
decimation: if you are using a standard linux distro, it's well known that older kernels had buffer bloat/tcp tuning issues
assbot: Netcat: the TCP/IP swiss army ... ( http://bit.ly/1GIo4t0 )
assbot: nc(1): arbitrary TCP/UDP connections/listens - Linux man page ... ( http://bit.ly/1GIo0tn )
asciilifeform: tcp without threads?
asciilifeform sends warm hello to the nice folks at ft meade sending us tcp FIN's
mircea_popescu: iptables -I INPUT -p tcp ! -s <permittedIP> -j DROP << is that it ?
ascii_field: until you want to do something like tcp
mircea_popescu: i am inclined to believe this is more likely the result of original author having nfi how tcp works rathger than having an idea about some obscure weakness he's deliberately mitigating
asciilifeform: once a tcp socket is opened, there is two-way communication.
assbot: Logged on 06-05-2015 17:21:23; mircea_popescu: http://log.bitcoin-assets.com/?date=06-05-2015#1122612 << it's actually a fine entry point to explain to anyone why exactly tcp/ip is so broken. because this IS NOT a trivial task. the price for ipv4 and it's undocumented, buggy, slow and haphazardously ad-hoc nat-routing model is that you can't find out by inspecting yourself. the half-assed, quarter-baked lazy slothful and aol-windowesque implement
asciilifeform: (how tcp? over slip/rs232, of course)
trinque: I used /dev/tcp magic making that gentoo image for mod6 the other day
asciilifeform: tor is this thing where tcp is bounced via three machines, selected by shitgnomiferous mega-turd of a client, over ssl (ditto)
jurov: williamdunne: it could accept perfectly ordinary tcp packet
decimation: asciilifeform: why do the sks keyservers take the position that all crypto checks are 'up to the user'? would you expect your router to check ip/tcp headers?
decimation: http://www.reed.com/blog-dpr/?page_id=6 < "One project where my friend and officemate Steven T. Kent (now chief scientist and vice president at BBN, and a chief advisor to NSA) and I lost was our strong argument to put mandatory end-to-end encryption into TCP (and adaptations of the ideas to UDP-based protocols, such as RTP, hich I worked out but abandoned). "
decimation: mircea_popescu: nfs is a method of exporting a filesystem over tcp
mircea_popescu: and this is also a fine entry point for explaining to management noobs the meta point of why exactly a theoretical approach doesn't ever work. yes, you could read the tcp/ip spec and look for holes. those are the holes in the tcp/ip spec, not the holes in tcp/ip.
mircea_popescu: http://log.bitcoin-assets.com/?date=06-05-2015#1122612 << it's actually a fine entry point to explain to anyone why exactly tcp/ip is so broken. because this IS NOT a trivial task. the price for ipv4 and it's undocumented, buggy, slow and haphazardously ad-hoc nat-routing model is that you can't find out by inspecting yourself. the half-assed, quarter-baked lazy slothful and aol-windowesque implementation means that yo ☝︎☟︎
decimation: lol some guy was reading #b-a and has an anti-tcp agenda http://notcp.io/
assbot: Logged on 29-04-2015 07:33:47; gabriel_laddel: I'll note that I wrote a prototype for the RPC described above - ran into an issue with TCP or the library I was using it from. Messages were disappearing in flight.
gabriel_laddel: I'll note that I wrote a prototype for the RPC described above - ran into an issue with TCP or the library I was using it from. Messages were disappearing in flight. ☟︎
ascii_field: 'When we tried wget, it detected errors, retried, and finally succeeded. It said the error was a bad length field in a TLS packet. That didn't make sense at first because we thought TLS packets were error corrected by TCP.' << incidentally, i am not certain that i agree with the author's conclusion ('reverse heartbleed'.) it may very well be an attempt to exploit other braindamage in http stack
asciilifeform: ~50MHz 32-bit (oddball architecture) cpu, tcp/ip implemented in hardware, can address via spi (as in sd card) external eeprom.
Chillum: asciilifeform: tcp/ip layer or application layer?
mircea_popescu: but i wouldn't sign off on him being beaten because tcp/ip sucks.
asciilifeform: i humbly request a copy of r. stevens's 'tcp/ip' bound in his skin.
Chillum: sockets vs tcp, should be secure both ways
mod6: tcp 0 0 0.0.0.0:8333 0.0.0.0:* LISTEN
asciilifeform: decimation: almost certainly the cheapest crystal (if any! might well have rc oscillator!) - given as the thing only works with iPnohe, which has always-on tcp
assbot: Logged on 26-02-2015 21:09:34; asciilifeform: PeterL: most 'alternatives for x11' dispense with the everything-can-be-piped-over-tcp
asciilifeform: it should ask for only a tcp stack and a place to park bytes in some nonvolatile way
asciilifeform: PeterL: most 'alternatives for x11' dispense with the everything-can-be-piped-over-tcp ☟︎☟︎
asciilifeform: may as well also be said about tcp over lan, where no packet ought to ever drop unless the place is on fire...
asciilifeform: and tcp/ip stack...
asciilifeform: the_scourge: the 'open' in 'opengenera' is an archaic 1980s usg-ism. it simply refers to the fact that a product features industry-standard protocols like tcp/ip and does not require you to buy the entire universe you live in from one particular vendor.
asciilifeform: the telco drops anything at all coming your way that isn't part of a tcp connection you established earlier
asciilifeform: or are we to believe that a protocol carried 100% in cleartext, on unique tcp port - is not being molested ?
asciilifeform: (it uses custom tcp stack)
mircea_popescu: "I've noticed certain repeating characteristic in the writing of many members of this forum: they construct grammatically correct sentences but absolutely disregard the underlying semantics: incoming vs. outgoing, local vs. remote, source vs. destination, etc. Here in regards to TCP/IP ports, but I observed that in regards to pretty much any technical issue." ☟︎
mircea_popescu: ip addresses seems to be the manner to connect via tcp/ip neh ?
mats: y'all give TCP a bad rap. it works exceedingly well for the goals, which is automagical conservative scaling of speed to dynamically changing throughput over opaque paths, which makes it reliable. reliable is good.
Adlai: (this was in a comparison of bitcoin to tcp/ip or smtp... "you can't short SMTP when your inbox takes forever to load"
asciilifeform: interestingly, there is, afaik, no support for any of the spiffy bells & whistles (hardware tcp/ip, queueing, packet inspection, etc.) in any civilized os.
mod6: it came back with windows TCP Socket Errors. I was like ... WTF?! RAGE!
assbot: cl-async/tcp.lisp at master · orthecreedence/cl-async · GitHub ... ( http://bit.ly/1CcX6cI )
punkman: adlai: lol https://github.com/orthecreedence/cl-async/blob/master/src/ssl/tcp.lisp#L321 << win!
assbot: cl-async/tcp.lisp at master · orthecreedence/cl-async · GitHub ... ( http://bit.ly/1CcX6cI )
adlai: lol https://github.com/orthecreedence/cl-async/blob/master/src/ssl/tcp.lisp#L321