01:19:27  * Akagi201joined
01:35:21  * piernov__joined
01:36:43  * dobson`joined
01:38:45  * dobsonquit (Ping timeout: 250 seconds)
01:38:48  * creationixquit (Ping timeout: 250 seconds)
01:38:50  * piernovquit (Ping timeout: 250 seconds)
01:41:19  * creationixjoined
01:42:07  * DarkGodquit (Ping timeout: 240 seconds)
02:05:59  * dan336joined
02:29:16  * Akagi201quit
03:01:52  * dan336quit (Quit: Leaving.)
03:25:26  * dan336joined
03:45:25  * dan336quit (Quit: Leaving.)
04:51:03  * SkyRocknRolljoined
05:10:10  * SkyRocknRollquit (Ping timeout: 255 seconds)
05:26:59  * SkyRocknRolljoined
06:00:38  * SkyRocknRollquit (Ping timeout: 268 seconds)
06:16:16  * SkyRocknRolljoined
07:32:24  * DarkGodjoined
08:19:47  * squeeekjoined
08:21:24  * squeekquit (Ping timeout: 256 seconds)
13:29:09  * dan336joined
13:46:47  * DarkGodquit (Ping timeout: 272 seconds)
13:49:10  <rphillips>good morning
13:59:41  * DarkGodjoined
14:54:54  * SkyRocknRollquit (Remote host closed the connection)
15:41:56  * KennethWilkejoined
15:44:55  * KennethWilkequit (Remote host closed the connection)
15:45:38  * KennethWilkejoined
15:46:44  * DarkGodquit (Ping timeout: 246 seconds)
16:32:18  * creationixis still stumped as to why I can’t send a second ping request from the same process
16:33:17  <rphillips>hmm
16:33:19  <rphillips>link?
16:47:35  * SkyRocknRolljoined
17:01:54  <creationix>rphillips: I just pushed my code https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/feat/remote-checks/remote/test-ping.lua
17:01:57  <creationix>with test runner
17:02:12  <creationix>before I was creating a new socket for every ping, and now I’m reusing a socket
17:02:20  <creationix>same behavior in both though, only the first send works
17:02:43  <rphillips>hmm. on my machine I was getting request / responses back
17:03:04  <creationix>according to wireshark, all three pings send and receive
17:03:36  <creationix>https://gist.github.com/creationix/56dad9b46f89f14dc366
17:08:00  <rphillips>duplicated it
17:09:39  <creationix>I wonder if there is something manual I need to to do after reading a raw packet to continue getting events
17:10:30  <rphillips>remote/ping.lua:134 timer w/ a 2000ms timeout doesn't seem right
17:10:49  <creationix>why not?
17:11:05  <rphillips>shouldn't it be attributes.timeout?
17:11:17  <creationix>no, this is the delay between pings
17:11:22  <rphillips>ah k
17:11:41  <creationix>and if the response doesn’t come back in time, it emits ETIMEOUT
17:13:02  <creationix>hmm, ipv6 local ping works for me
17:13:07  <creationix>(just pushed update to code)
17:13:26  <creationix>but ipv4 is still getting back nil data events for on_recv
17:25:46  <rphillips>creationix: looks like rseq is always 0
17:27:01  <creationix>I’m probably parsing rseq wrong
17:27:17  <creationix>wireshark shows seq in the response matching the one I’m sending
17:27:37  <creationix>but is interesting that the first is seq 0/0, but the second is 1/256 and then 2/512
17:27:43  <creationix>I’m not sure what the second number is
17:29:10  <creationix>There is just “seq” in the ICMP header
17:29:23  <rphillips>creationix: sequence number (big endian), then seq num (little endian)
17:29:29  <creationix>right, I see that now
17:30:06  <creationix>network byte order is BE right?
17:30:11  <rphillips>right
17:30:19  <creationix>that’s what the checksum is sent in, and what wireshark displays for the id
17:34:25  <rphillips>remote/ping.lua:54 message = message:sub(21)
17:34:57  <rphillips>probably doesn't work with ipv6 though
17:35:42  <rphillips>creationix: ^
17:36:03  <rphillips>strips the ip address and IP header
17:37:27  * SkyRocknRollquit (Remote host closed the connection)
17:37:44  <creationix>yeah, that can be a problem
17:37:55  <creationix>but my issue is I’m never even getting the response data events
17:38:41  <rphillips>https://www.evernote.com/l/AAmZbt9QL-9Edqv37Bw67eJuEZ9jHYQ7dTg
17:39:00  <rphillips>probably because the seq number is always 0... i added that message:sub in and it fixed it
17:40:53  <creationix>interesting, I *am* getting the data event, it’s just not routing
17:41:47  <creationix>I see now why rseq is the problem, sorry for being dense
17:41:56  * creationixhas not been sleeping well
17:42:32  <rphillips>np :)
17:44:23  <rphillips>hmm. instead of skipping the 21 bytes... we can check the beginning of the message for the family
17:44:40  <rphillips>to know which IP protocol type it is
17:44:42  <creationix>right, just do better parsing
17:44:59  <creationix>I was posponing that work till I could figure out why my data events weren’t happening
17:44:59  <rphillips>+1
17:45:09  <creationix>self inflicted deadlock
17:52:10  <creationix>rphillips: what is libuv passing me, these bytes in the message don’t match what wireshark is capturing
17:52:23  <creationix>I see the icmp header about halfway through and my body after that
17:52:36  <creationix>but the bytes before don’t match the IP header bytes
17:52:48  <creationix>is the kernel rewriting the bytes or something?
17:53:54  <rphillips>hmm
17:55:06  <creationix>I’m getting looks like 28 bytes of strange data before the ICMP header starts
17:56:06  <creationix>hmm, no just 20
17:56:14  <creationix>that explains why your :sub(21) worked
17:59:00  <rphillips>https://www.evernote.com/l/AAnObIG-FA1M2a-wwhlmbt4rmDDRKXWMgSw
17:59:24  <rphillips>yeah, looks like the kernel is returning the start of the IP header
17:59:28  <rphillips>it strips the family
17:59:50  <rphillips>0x45 is the first byte of the message for ipv4
18:00:51  <creationix>well, if I can just read the ip header length and then skip that many bytes, that would be enough
18:00:57  <creationix>I only care about ICMP headers and the body
18:01:06  <rphillips>true
18:01:25  <creationix>so it looks like the lower 4 bits of the first byte is the ip header length
18:01:52  <rphillips>true
18:02:48  <rphillips>creationix: the top 4 bits tell you the IP protocol version
18:03:08  <creationix>right, but I don’t think I care about that do I?
18:03:36  <rphillips>0100 : version 4 0110 : version6
18:03:50  <rphillips>it doesn't look like the ipv6 header includes a length
18:10:34  <creationix>ok, got IPv4 length parsing working
20:55:57  * KennethWilkequit (Remote host closed the connection)
21:21:44  <creationix>rphillips: strange, on ipv6 responses, the ip header is not included
21:22:06  <rphillips>weird
21:22:22  <creationix>also I’m seeing the packet I send as well as the response
21:22:41  <creationix>too bad this raw socket over uv_udp_t isn’t documented
21:22:50  <creationix>might be undefined behavior even
22:23:15  * DarkGodjoined
22:42:44  <rphillips>creationix: figure that out?
22:43:05  <rphillips>i don't even see the first byte in the returned packet in wireshark
22:43:37  <creationix>sometimes it includes the ip header (but modified) sometimes it doesn’t
22:43:43  <creationix>the test seems to working though
22:45:40  <rphillips>it sure does... i was on a stale checkout
23:05:38  * dan336quit (Quit: Leaving.)
23:41:48  * DarkGodquit (Quit: Leaving)
23:42:41  * dan336joined
23:52:44  * dan336quit (Quit: Leaving.)