In case anyone's interested, here's what seems
to be the packet at the top of the page. I've
got the checksum to add up correctly, so its likely correct, except that even though the
checksum is correct, the ip dst addresses don't
match up with the one he claims...
1: 4500 2: 001c 3: 0000 4: 0000 5: 8001 6: c16d 7: cf47
8: 5cdb 9: d02f 10: 7d21 11: 0800 12: f7ff 13: 0000
Total bytes read: 26
in_cksum: sum 0 len 20
in_cksum: iter 1 case 10
10: 0045 0000
9: 1c00 0045
8: 0000 1c45
7: 0000 1c45
6: 0180 1c45
5: 6dc1 1dc5
4: 47cf 8b86
3: db5c d355
2: 2fd0 1aeb1
1: 217d 1de81
1fffe
ip len: 28 header length: 20 ip tcpLen 8 checksum: ffff (0)
ip src 207.71.92.219
ip dst 208.47.125.33
ip packet extends beyond end of data
i'm trying to read those packets... why in
the world is he coding left-to-right-top-to-bottom
nibbles...
anyone got some hex from those packets?
(only one reason i can think of that he's coding
them that way)
Slashdot Mirror
In case anyone's interested, here's what seems to be the packet at the top of the page. I've got the checksum to add up correctly, so its likely correct, except that even though the checksum is correct, the ip dst addresses don't match up with the one he claims... 1: 4500 2: 001c 3: 0000 4: 0000 5: 8001 6: c16d 7: cf47 8: 5cdb 9: d02f 10: 7d21 11: 0800 12: f7ff 13: 0000 Total bytes read: 26 in_cksum: sum 0 len 20 in_cksum: iter 1 case 10 10: 0045 0000 9: 1c00 0045 8: 0000 1c45 7: 0000 1c45 6: 0180 1c45 5: 6dc1 1dc5 4: 47cf 8b86 3: db5c d355 2: 2fd0 1aeb1 1: 217d 1de81 1fffe ip len: 28 header length: 20 ip tcpLen 8 checksum: ffff (0) ip src 207.71.92.219 ip dst 208.47.125.33 ip packet extends beyond end of data
i'm trying to read those packets... why in the world is he coding left-to-right-top-to-bottom nibbles... anyone got some hex from those packets? (only one reason i can think of that he's coding them that way)