go-tcap icon indicating copy to clipboard operation
go-tcap copied to clipboard

Failure on missing protocol version

Open aaronchar opened this issue 5 years ago • 13 comments

It looks like if no protocol version is defined this function will fail to correctly process the rest of the bytes

https://github.com/wmnsk/go-tcap/blob/08bd257a43a1f596e0f85f5a333c1402d0593918/dialogue-pdu.go#L438-L445

aaronchar avatar Nov 17 '20 18:11 aaronchar

I’m not sure that field is mandatory or optional, as it’s been so long since I worked on that implementation. Could you show the document to refer for that?

wmnsk avatar Nov 18 '20 16:11 wmnsk

@wmnsk I will try and find some time to dig through the spec, I was just basing this off a bunch of pcap's I was playing with trying to see how stable this was for parsing bytes off the wire.

Thanks

aaronchar avatar Nov 18 '20 16:11 aaronchar

OK I’ll check but give me some time to find it.

wmnsk avatar Nov 19 '20 12:11 wmnsk

No problem, I haven't had time to even pull up the spec files.

If you let me know which ones you used to write this I don't mind poking around as it seems like there might be something similar going on in ParseDialogue because i am seeing panic: runtime error: slice bounds out of range [143:109] after successfully decoding the ObjectIdentifier on a dialogueRequest

aaronchar avatar Nov 19 '20 12:11 aaronchar

The documents I refer are ITU-T's Q.771 - Q.775. I think it's described in Q.773, which defines the format of messages. By the way, I saw some samples that have no Protocol Version field. So, I'll fix the codes to check the presence of fields and accepts them even if some are absent, as I make it as kind to real-world users as possible.

wmnsk avatar Nov 29 '20 08:11 wmnsk

That would be fantastic, I'm not extremely familiar with the tcap protocol so I'm just stumbling my way through it.

But I have also noticed that the parseber function doesn't seem to work with continue segments. I can open another issue with that.

On Sun., Nov. 29, 2020, 02:24 Yoshiyuki Kurauchi [email protected] wrote:

The documents I refer are ITU-T's Q.771 - Q.775. I think it's described in Q.773, which defines the format of messages. By the way, I saw some samples that have no Protocol Version field. So, I'll fix the codes to check the presence of fields and accepts them even if some are absent, as I make it as kind to real-world users as possible.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wmnsk/go-tcap/issues/4#issuecomment-735360264, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBIMNZZANRGMTWOSY5YKSTSSIANXANCNFSM4TY6IAEQ .

aaronchar avatar Nov 29 '20 09:11 aaronchar

I might have misunderstood your case... I did not see any packets without Protocol Version, and I can't make it work without it easily. It'd be very helpful if you could provide the exact PCAP that caused the issue. Could you help with that?

wmnsk avatar Nov 30 '20 16:11 wmnsk

@wmnsk

I will see what i can do to grab a clean one , But here are a couple screen shots of a pcap i have open right now.

Screenshot from 2020-11-30 11-11-10

continue

aaronchar avatar Nov 30 '20 17:11 aaronchar

The problem with decoding Continue with ParseBER might have been fixed in the latest code. Could you give it a try? For the protocol version, give me some more time for investigation. It seems you have PCAPs with confidential information. I think copying the payload as a hex dump and masking fields with dummy values (like 11, ff, etc.) and pasting it here works. Make sure not to change the length of any value in that case.

wmnsk avatar Dec 02 '20 16:12 wmnsk

@wmnsk I just tried the latest version and it seems like it still fails to parse it correctly

([]*tcap.TCAP) (len=5 cap=5) {
 (*tcap.TCAP)(0xc0004941e0)({Transaction: {Type: 0x65, Length: 129, OrigTransactionID: <nil>, DestTransactionID: <nil>, PAbortCause: <nil>, Payload: }, Dialogue: <nil>, Components: <nil>}),
 (*tcap.TCAP)(0xc000494200)({Transaction: {Type: 0x64, Length: 0, OrigTransactionID: <nil>, DestTransactionID: <nil>, PAbortCause: <nil>, Payload: }, Dialogue: <nil>, Components: <nil>}),
 (*tcap.TCAP)(0xc000494220)({Transaction: {Type: 0x83, Length: 2, OrigTransactionID: <nil>, DestTransactionID: <nil>, PAbortCause: <nil>, Payload: }, Dialogue: <nil>, Components: <nil>}),
 (*tcap.TCAP)(0xc000494240)({Transaction: {Type: 0x30, Length: 49, OrigTransactionID: <nil>, DestTransactionID: <nil>, PAbortCause: <nil>, Payload: }, Dialogue: <nil>, Components: <nil>}),
 (*tcap.TCAP)(0xc000494260)({Transaction: {Type: 0x98, Length: 1, OrigTransactionID: <nil>, DestTransactionID: <nil>, PAbortCause: <nil>, Payload: }, Dialogue: <nil>, Components: <nil>})
}

continue_oid

as for the pcap you are on the money about private info, I was thinking about a hex dump with a mask. I will find time today or tomorrow morning to do that. Sorry it's taking me a bit

aaronchar avatar Dec 02 '20 19:12 aaronchar

@wmnsk

This should work for a hex dump, most things should be setup with dummy values where they matter (except the sizes). This is the tcap portion of the packet so it should just be able to get pushed through parseBER.

Just let me know when you grab it so i can wipe it. Thanks

aaronchar avatar Dec 03 '20 13:12 aaronchar

@wmnsk I'm guessing I pulled it off there before you grabbed it, I'll out it back today. I just didn't like the idea of leaving it up even if it did have altered hex values .

aaronchar avatar Dec 18 '20 09:12 aaronchar

I think I can find it in my email box, but unfortunately I don’t have time to work on this project these days. Give me some more time.

wmnsk avatar Dec 21 '20 06:12 wmnsk