Bad line packet received - hex dump

[alanz]

Here is some hex logging of the bad line packet

The first one is the wire packet, the second is immediately after delineize, and logs the line id followd by packet length and hex dump of packet. It is obvious that the length is wrong

07:57:38:>>>>:recvTelex:208.68.164.253:42424 (460) 00013a6fb5bc1b0312e8d8715f3959720b68efd941ec5f9d8e1090f775ebd4c4d9804d4f648ac46ecbb8605a020a250ebd38275fe9c31f6498d1cdd349ebf9c932af6b993ab852b453b8174eb552fea3e2505b2f4f619a37db796695ca22d802a3e978b0e02d811a1c9fd5483f343b7cb0b8e0ff06d72f84039384b66c4b680aba6992dca6834a6db688c882f0c830c6ee1c1838b4407eadb5631cb239ff93d282e3ba099396ea657f519b2ef103dd7d647fcc72b548f9af27f4dd029b0553e140d6a44db8a63e3e422a6c0e72b37886b896326611a050a7a8fbed607fae16595705be849e28966f6672130308a7452b312ed01e08de7cca710cfb23dc6bf04babab15170941383f412bc432b463204be8eaeff2d0dfa85c4149888692425504515629c7ed95901d07d8edba0cbe1d6789f6a060731502ff8f557c878fe9e8d0086fc813ed5188321fc16051fde50bc6645d091332f33efb828960d476f02987dca6ff1410ae821f3fba939b70521bc324abd89945efb9003cd7283bda1535472a92ebc7f458ad5e4a0e839768e98ac1212ca0e4db6453279001e4ff713964f4b64f69938c5236f11cd76bd3475eda215c2fba1077a1ca85c71a803e9f322766159274e06b9d7c6aba545971
07:57:38:>>>>:crypt_deopenize_1a:inner 31e463916f3012a0a5016a2bc6f2c391 (413) 6c3258f8cc77b7f6e7eaf963b02b2121fb9a7eec724160b3a20450c90b4bd195742bc892b6793876583b0ee51a254f7955eebd14180f44290700ae5cdec67626931c8c947d252e627ce84a130adf753cabcb33f05a72e43b26930a960a47fcc9adea862a5af26bd2f15c81e4a3c33b910dd15b2435d6c14bfdfe42c72e93078b78a2386cd61414744a8a3264b4aacea222af54d698b5e5f7e74c2c0476882f30173103fcbd2817467ddbdc7f20ae1f40b91c949a19f036d6135f4f1b4ccaf73c54de5c329510df2034a1a8b02b904f0ba8672fd8ef2024b2e6083e37821075d16371fe02622405e382352e9167c81ffcbaba2586b83006dba9a8f8aec8c660ca194c1976613c6565248bac3b3c41df2e3ed2e2715faa4f901514bf92bf2d314bedd1abfb41ed46b5f4891dd0a7ee22892b55337ac6d5d6eee4883a4cbb258924399683cbb0e7e6a7bdf18bd70f50748994b6db0f52ba1b25328e2faa5c7db7c080124dd9dc4e0831c6574ede3bc9971557ff0b4bc1daa421b7d5d0c64579e2951c541934363c60e32ab0462e30de4d396ea6f01a62686e1c5307e7feb2
*** Exception: Data.Binary.Get.runGet at position 413: demandInput: not enough bytes

[quartzjer]

That's a cs3a open packet, 0001 is 1-byte header (open) and the next byte is the CSID (3a)... are you supporting bridging, or if not then somehow the node seed got that network path associated with some other hashname (bad info in a see or paths maybe?).

[alanz]

I am working in test configuration with a local node instance, and
connecting via it and the normal seed. Sometimes the initial connection
happens via a bridge through the local node one.

I will put in a check for this case and simply discard it.

On Fri, Jun 6, 2014 at 8:43 PM, Jeremie Miller notifications@github.com
wrote:

That's a cs3a open packet, 0001 is 1-byte header (open) and the next byte
is the CSID (3a)... are you supporting bridging, or if not then somehow the
node seed got that network path associated with some other hashname (bad
info in a see or paths maybe?).

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[alanz]

Just checked my code, I was ignoring that byte in the open and always forcing a 1a open, will correct it

[alanz]

New one, of 1a. My interpretation of the length is 0x208 or 520 decimal, packet is only 401 bytes

15:09:57:>>>>:recvTelex:208.68.164.253:42424 (2) 0000
15:09:57:>>>>:recvTelex:208.68.164.253:42424 (448) 00011a503281fa2ed3b286d8f0d932540b1452d17c537f4f4b1d897f8fbc73b52b86f8006d10272ce1f36fed83b0b72675a17895918a3313d6c14d2eb7aaee5f44e218e59eab91b5abe543f1a6cb99dcb620711a992ccfd8af91f2e60e9557a58f72e90879a6a9c751c3a8974f1e7133118585867541fc1d44acfc40672c7bf1b0e9f5caace08da29eb4c8ed764640718c77a4ef14d96bd16ccb40cc061395fb599a40960c2b460a2351871702e8ebb6286d97dad6ee3e5500ccb59a35e60d9589d08a83cc5f83891db18f82f39a1965d6078ed54cef05417f95d3a1e38f611535c7708d4d29c15e6b410b96763d2f53b4a07f4f52fd60e3723c9c8fc3004da98dd6aadd63e2a653e7e86e8a51a7bfc8ec7c4ab53a33ee89b05eefcd07cbb6ab4dcc7ccd157d52da97801c71884acd10382cbeb1f578e34abc49f8f4d076440dc45209202ba4d5302ffb21bf324886038d7431d29b26ba833f534ec1811c050875c145ac4c8047a66e77ae75f89c1fa990ac119f8ceb0ae2e39937fa1d8269d8352e0732073aeefad41a4e9b83206e5e5f7a8939423abf677d7cb8da92d3d74a092842364241f23712c92b879946979d4cb4d4a356e75c697d90ab562302a365
15:09:57:>>>>:crypt_deopenize_1a:inner d4b2ae82e73fa95968048f645051e776 (401) 0208b6d2ea2e7f81ddcbd196decd080f0903b727aec7edc7073e5c70b559fabf48fa2edec45f9c783276f4c80510de181748487fde0d8e4c23145147a9425d721b8d9522dfd71d1f33d9d558de8c72566b557b0e7869dcf36a7125260175dc5c9f7d48a17292630fe02843b460e2dbf42723eaa50dbbce03afcbf67f19f4e7af0e692778199d744eed7bf4b94220100374fb0ed270e450ac9815ed2b9ca160bb184d6914c28b0f5b3675482f27c13dea1591d0f8ba623264acad6dbda5207274da181be104182fa0cfd49525373bab4e57d7fc10dfa518a18d3ef7b2f308715107f5c78365a8103b7b45bc586eab67a4c14ef9ed1a4890f068a64f88b6081a6a77b1bd3a7f74c31c618273afaed958ffbe8c8f7ba309af245fc63ebd4260ae96730affcdc2184aaa26af63c391065c0249c51fd6e2a6b877008e8532d4fe7beff135619559ef2936213541f545ead91dbd822845904521c5f27892d785ef1444a60099d1743451ef3d277676a9a1c41173e2122c959a591e43f32c46abcb1167c8cb76f47803d62ce344d2d05151215024