Displaying 7 results from an estimated 7 matches for "6e65".
Did you mean:
665
2019 Apr 15
1
No CRLF in Pigeonhole's header?
...0x0010:? 7f00 0001 6ea2 0019 8982 e279 d090 b820? ....n......y....
? 0x0020:? 8018 021e 0749 0000 0101 080a c345 2b51? .....I.......E+Q
? 0x0030:? b382 853c 4d41 494c 2046 524f 4d3a 3c72 ...<MAIL.FROM:<r
? 0x0040:? 4073 3066 2e6d 642e 6465 7664 6576 6465? @sxf.md.devdevde
? 0x0050:? 762e 6e65 743e 0d0a 5243 5054 2054 4f3a v.net>..RCPT.TO:
? 0x0060:? 3c63 6f6e 7461 6374 4072 6567 6973 2e74 <contact at regis.t
? 0x0070:? 6563 683e 0d0a 4244 4154 2032 3235 3420 ech>..BDAT.2254.
? 0x0080:? 4c41 5354 0d0a 582d 5369 6576 653a 2050? LAST..X-Sieve:.P
? 0x0090:? 6967 656f 6e68 6f6c...
2004 Dec 08
0
dovecot 1.0-test-56 mail doesn't show up with Mac Entourage clients
...6976 uston.State.Univ
0x0480: 6572 7369 7479 0d0a 582d 5348 5355 2d4d ersity..X-SHSU-M
0x0490: 6169 6c53 6361 6e6e 6572 3a20 466f 756e ailScanner:.Foun
0x04a0: 6420 746f 2062 6520 636c 6561 6e0d 0a58 d.to.be.clean..X
0x04b0: 2d53 4853 552d 4d61 696c 5363 616e 6e65 -SHSU-MailScanne
0x04c0: 722d 5370 616d 4368 6563 6b3a 206e 6f74 r-SpamCheck:.not
0x04d0: 2073 7061 6d2c 2053 7061 6d41 7373 6173 .spam,.SpamAssas
0x04e0: 7369 6e20 2873 636f 7265 3d2d 302e 3030 sin.(score=-0.00
0x04f0: 312c 0d0a 0972 6571 7569 7265 6420 352e...
2016 Nov 21
2
Winbind traffic not encrypted
...e 0606 2b06 0105 0502 a054 ...``^..+......T
0x0050: 3052 a024 3022 0609 2a86 4882 f712 0102 0R.$0"..*.H.....
0x0060: 0206 092a 8648 86f7 1201 0202 060a 2b06 ...*.H........+.
0x0070: 0104 0182 3702 020a a32a 3028 a026 1b24 ....7....*0(.&.$
0x0080: 6e6f 745f 6465 6669 6e65 645f 696e 5f52 not_defined_in_R
0x0090: 4643 3431 3738 4070 6c65 6173 655f 6967 FC4178 at please_ig
0x00a0: 6e6f 7265 nore
16:37:05.496321 IP 192.168.56.33.49418 > 192.168.56.32.389: Flags [.],
ack 254, win 229, options [nop,nop,TS val 5433966 ecr 5433956], length 0
0x0000: 4...
2013 Jan 05
1
imap: Error: net_connect_unix(/.../auth-master) failed: Invalid argument
...(0x12,0x8062a23,0x1dd)
365 log RET read -1 errno 35 Resource temporarily unavailable
365 log CALL kevent(0x1e,0,0,0x805f000,0x18,0xbfbfec80)
1012 imap CALL write(0x2,0x8069160,0x9f)
1012 imap GIO fd 2 wrote 159 bytes
0x0000 0104 3130 3132 206e 6574 5f63 6f6e 6e65 |..1012 net_conne|
0x0010 6374 5f75 6e69 7828 2f66 732f 7061 636b |ct_unix(/fs/pack|
0x0020 6167 652f 6d6f 756e 742f 7061 636b 6167 |age/mount/packag|
0x0030 652f 686f 7374 2f73 7066 2e62 6961 6978 |e/host/spf.biaix|
0x0040 2e6f 7267 2f66 6f72 6569 676e 2f64 6f76 |....
2006 Mar 21
0
wine and Mankind (the one from www.mankind.net) - possible networking or file creation problem
...kind.net. (32)
0x0000: 00a0 cc5c 2a75 0011 6b30 74e6 0800 4500 ...\*u..k0t...E.
0x0010: 003c 96bf 4000 4011 2071 c0a8 012f c0a8 .<..@.@..q.../..
0x0020: 0101 805c 0035 0028 f37e 08f0 0100 0001 ...\.5.(.~......
0x0030: 0000 0000 0000 026e 7007 6d61 6e6b 696e .......np.mankin
0x0040: 6403 6e65 7400 0001 0001 d.net.....
That's ok. The server that distributes the updates is np.mankind. But I
don't capture any other packets. I would expect an attempt to connect to
it or any other of Mankind's servers.
This may also be related to some other thing I have noticed...
2008 Jul 14
5
EOL in stderr of ssh - Linux
Hello everyone,
recently I've found something I consider a bug.
Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
Imagine my surprise when I saw that all messages that are being output
on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
terminated with 0x0D, 0x0A.
Maybe that's standard behaviour of all stderr messages in all Linux
2010 Jun 03
2
mangled user_attrs from LDAP
...0404 3230 3030 3010 0403 7569 er1...20000...ui
0x0070: 6431 0904 0767 7368 626f 626d 3014 0409 d1...xxxbobx0...
0x0080: 7569 644e 756d 6265 7231 0704 0533 3835 uidNumber1...385
0x0090: 3338 301f 040d 686f 6d65 4469 7265 6374 380...homeDirect
0x00a0: 6f72 7931 0e04 0c2f 6e6f 6e65 7869 7374 ory1.../nonexist
0x00b0: 656e 74 ent
I will spare you the packet dump, but in the cases where the login works
correctly, LDAP returns the values in the same order that they are
requested in. This behaviour has been found with both OpenLDAP: slapd...