512 entries in 0.724s
Framedragger: (ah. suresure. well if one plans to do that on millions of machines or more, better to use simple
tcp sockets hm. say that masscan for 1st phase uses its own
tcp stack to not exhaust kernel handles accidentally, etc...)
Framedragger: mircea_popescu: (syn flood suspicion because sockets don't respond with anything, even when possible to establish
tcp connection. and yes ping does seem to work.)
Framedragger: asciilifeform: seems that i can make it open 80/
tcp, but it won't give me any data
Framedragger: (ideally, i would guess, it'd munch datagrams, too, because gossipd is to have no stateful connections of the
tcp kind.)
Framedragger: aha, the way it'd work, it'd still scan only port 22 initially, because grabbing banners / doing stateful communication is much slower. doing the former is a matter of
TCP SYN/ACK, with embedded 'cookies', no need for state
Framedragger: the whole "patch a DNS server and run alternative root" effort sounds interesting and useful, but, as you said, eventually the underlying layer would need to swapped for gossipd anyway. in gossipd, UDP/
TCP as currently used by DNS may not even work. hence there may be a redundancy of effort;
Framedragger: imho one should not start prototyping gossipd on
tcp due to the whole stateful nature of
tcp. it would make things *appear* to be so much easier - implicit packet ordering and stream control, etc. - and when things eventually need changed it's gonna suck00r bigtime
mircea_popescu: as people (alf, mostly) pointed out in the intervening coupla years, there's absolutely no sane reason to marry gossipd to extant-internet, or
tcp/ip or etc, as the original draft was trying to
mircea_popescu: but in any case the same tongue that licked
tcp/ip also licked all of washington dc, not to mention etc.
Framedragger: [OT just for the record, it seems that rfc 7413 ("
tcp fast open") won't do any good because (lo and behold) not only would it not save against syn floods, it'd actually introduce new attacks (2.2 and beyond). and existing mitigation techniques may not work. gotta love those people. yeah, fuck
tcp.]
mircea_popescu: but all this stuff aside, back to the important point here : the "gossipd-like" thing contemplated for moving signed material (ie, v stuff) around is very much a different beast from the actual gossipd, which doesn't work on signed material ; presumably doesn't work on
tcp etc.
Framedragger: is rfc7413 even supported by any
tcp stack tho? (inb4 all
tcp stacks must die!1 [not disagreeing in principle])
trinque: you will not fix
TCP/IP with teh botz
phf: asciilifeform: going back to gossip conversation, my issue is that the gossip you talk about exists exclusively in your head, where's mp got a spec. there are aspects of gossip functionality that can be explored with current spec despite the underlying
tcp transport. and like i said broken transport doesn't invalidate the application functionality. it will leak in practice through
tcp shenanigans, but that's the nature of this
phf: so then it's not even about gossip, it's about "lets have a replacement for
tcp"
phf:
https://tools.ietf.org/html/rfc4880#page-13 (section 4.) over
tcp. i have an incremental packet parser that you can attach to
tcp stream and it'll give you packet-by-packet on the other end. that's probably not the right solution for going to war though
mircea_popescu: and while it would allow
tcp/ip, it wouldn't be limited to
tcp/ip
a111: Logged on 2016-07-06 00:14 shinohai: This is limitation of
tcp/ip unfortunately.
shinohai: This is limitation of
tcp/ip unfortunately.
☟︎ mircea_popescu: altogether the attempt to make a "web browser" work seems educational (read : selffuckstick) than anything. we don't even want
tcp to survive, let alone html, css or js.
Framedragger: yeah i'm not certain how representative that figure is of whatever, honestly. with all metaphor removed, it literally is "the number of ipv4 hosts which respond to a
TCP SYN to port 22 with
TCP ACK [packet with ACK flag set]". i'm fairly confident that i haven't missed many hosts of this kind, but too should be replicated and tested.
Framedragger: vc: just fyi, there appears to be a ~10k packets / second limit somewhere upstream, are you aware of anything of the kind? i'm just running some self-tests (using a program which has its own
TCP stack, i.e. no use of kernel networking / sockets). same tests produce at least 10 times as much elsewhere. cpu not the bottleneck. just wondering what it could be
trinque: Please do not abuse the ws->
tcp proxy. << what could go wrong
Framedragger: vc: re.
https://box.cock.li/ - do you tolerate responsible and low-bandwidth netscans (
TCP SYN and/or ssh-keyscan (which doesn't attempt any ssh auth)) perchance?
Framedragger: digital ocean e.g. - scanned more than querter of ipv4 space using
TCP SYN (masscan) - so just to see which :22 hosts are up - received numerous abuse complaints from all over the net, all forwarded to me
Framedragger: (..in other news hosters seem to cave in to the "we gun ban your ip cause we saw three
TCP SYN packets to :22 on our block" threats and do not allow any scanning whatsoever. online.net may be the exception and are cooperative, will see how they tolerate some scanz)
a111: Logged on 2016-05-23 02:23 Framedragger: asciilifeform et al.: a couple of representative ssh host key samples (e,N,ip_address) - two /8's - pipeline was masscan (sort of nmap+zmap with custom
tcp stack) -> ssh-keyscan (manually parallelized) -> custom conversion into CSV
Framedragger: asciilifeform et al.: a couple of representative ssh host key samples (e,N,ip_address) - two /8's - pipeline was masscan (sort of nmap+zmap with custom
tcp stack) -> ssh-keyscan (manually parallelized) -> custom conversion into CSV
☟︎ phf:
tcp had non-blocking mode for a very long time
trinque:
tcp 0 0 172.86.178.46:44113 185.30.166.37:7000 ESTABLISHED
assbot: Logged on 15-02-2016 18:37:44; jurov: and then it failed cuz must read /proc/net/
tcp ?!
jurov: and then it failed cuz must read /proc/net/
tcp ?!
☟︎ ascii_butugychag: but even then, a debugger that listens on
tcp is a dangerous thing to have around
phf: it sounds like ascii knows exactly what he's doing where's i'm struggling with simply getting all the required elements together. i've gotten as far as reliably reading gpg packets from a
tcp stream, but i still have too many open questions. i'm thinking that my attempt is entirely pointless, but i'll continue it as a learning exercise. i publish code in a week or two, so that all can learn how not to write c :)
ascii_field: whoever accepts
tcp connections is ddosable.
assbot: Logged on 28-11-2015 20:42:43; phf: ben_vulpes: sure, so you're going to cap the size of ciphertext of what you expect to be nonce, which is fine, but after that you rely on state outside of gossipd (
tcp packet from ip such and such) to drop all subsequent
phf: ben_vulpes: sure, so you're going to cap the size of ciphertext of what you expect to be nonce, which is fine, but after that you rely on state outside of gossipd (
tcp packet from ip such and such) to drop all subsequent
☟︎ ascii_field: i am deliberately not even mentioning gpu, because it is possible to have a useful computer with no vga board (e.g., you can speak x11 over
tcp)
mircea_popescu: <asciilifeform> adding
tcp would prolly double or triple the mass, though << the challenge would be to not write the worst piece of the completed assemblage.