test bacnet with vts - Githubissues

anzhen9 commented 5 years ago

When I test bacnet with VTS, it told me this: Decoding Error - PDU: <PDU None -> None : 0a.00.0c.01.20.ff.ff.00.ff.10.08> this is the data I send:

glaslos commented 5 years ago

The error seems to come from the bacpypes library we are using to parse the BACnet packets. Do you have time to investigate the issue? Here is the relevant code in Conpot: https://github.com/mushorg/conpot/blob/master/conpot/protocols/bacnet/bacnet_server.py#L72-L75

anzhen9 commented 5 years ago

invalid APDU type. It happended in https://github.com/JoelBender/bacpypes/blob/61dbd5237fe4406f64755c8cd7526ce28f5eb809/py34/bacpypes/apdu.py#L321. And I printed all the pduType and self.apduType, it liked this: ConfirmedRequestPDU.pduType 0 UnconfirmedRequestPDU.pduType 1 SimpleAckPDU.pduType 2 ComplexAckPDU.pduType 3 SegmentAckPDU.pduType 4 ErrorPDU.pduType 5 RejectPDU.pduType 6 AbortPDU.pduType 7 self.apduType 8 I got an 8 of apduType.

glaslos commented 5 years ago

So the solution would be to add the additional PDU type to bacpypes. Do you think this is something you can do?

anzhen9 commented 5 years ago

Thank you, I'm a novice and I will try it

PiyushDeshmukh commented 5 years ago

I am also facing the same issue.

I shall let you know to the point I have debugged this, but still no clue on how to resolve the issue.

According to Bacnet Wiki (and also I have seen in wireshark dissector as well), PDU types 1 through 7 are general ones and are supported by bacpypes.

I also received the self.apduType as 8. But this is not due to the client sending APDU type as 8, but the way how bacpypes is parsing the request stream.

I am using nmap script to send query 810a001101040005010c0c023fffff194b which is for Device Identifier(4b at the end). The query is for BACnet-Confirmed-Request PDU(type 0x0X)

    0x81, -- Type: BACnet/IP (Annex J)
    0x0a, -- Function: Original-Unicast-NPDU
    0x0011, -- BVLC-Length: 4 of 17 bytes
    -- BACnet NPDU
    0x01, -- Version: 0x01 (ASHRAE 135-1995)
    0x04, -- Control (expecting reply)
    -- BACnet APDU
    0x00, -- APDU Type: Confirmed-REQ, PDU flags: 0x0     <------ This is what should be decoded for APDU type
    0x05, -- Max response segments unspecified, Max APDU size: 1476 octets
    0x01, -- Invoke ID: 1
    0x0c, -- Service Choice: readProperty
    0x0c, -- Context-specific tag, number 0, Length Value Type 4
    0x023fffff, -- Object Type: device; instance number 4194303
    0x19, -- Context-specific tag, number 1, Length Value Type 1
    id)

However the library is trying to decode the first byte i.e. 0x81, which when decoded as (0x81 >> 4) & 0x0f gives 8 as APDU Type. This does not match any of the PDU types they have handled (0 through 7) and raises DecodingError.

It seems that Conpot's BACnet server is trying to decode the APDU header directly from the first byte, without parsing the previous bytes representing Bacnet VLC and NPDU headers.

Rajeswara-Muthyala commented 2 years ago

@PiyushDeshmukh were you able to fix this? I think conpot should check for 0x81 and decode BACnet vlc and NPDUs headers.

mushorg / conpot

test bacnet with vts #427