This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Q.931 - Does anyone know what might generate this traffic?

0

alt text

asked 26 Jun '12, 12:44

someitguy2012's gravatar image

someitguy2012
1111
accept rate: 0%


4 Answers:

1

Maybe it's just the Cisco RLM dissector getting a "false positive"; almost all the packets appear not to be LAPD-over-UDP, even if the dissector is treating them as such, given all the errors in the dissection. To quote a comment in that dissector:

/*
 * RLM is a proprietary Cisco protocol used for centralling managing
 * many redundant NASes.  I don't know much about the format, but you
 * can read about the feature here:
 *
 * http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/rlm_123.html
 *
 * RLM runs on a UDP port (default 3000) between the MGC and the NAS.
 * On port N+1 (default 3001), a Q.931/LAPD/UDP connection is maintained.
 * Both sides use the same local port number for the connection, so source
 * and dest port are always the same.
 *
 * In large networks, the links are typically split onto higher ports,
 * so anything up to 3015 (or higher) could either be RLM or Q.931 traffic,
 * although always the RLM has the one lower port number for that RLM group.
 *
 * Multiple RLM groups are possible on a single NAS.
 *
 * I haven't been able to find the protocol documented, so I've
 * guessed some of the fields based on the output of debug commands on
 * cisco NASes.
 *
 */

The heuristic dissector's check is pretty weak - it just checks whether what would be the control field if the packet were LAPD-over-UDP looks "good enough", which could just mean that the first byte of the payload doesn't happen to have both bits set. That extremely weak check isn't done for arbitrary UDP traffic, but it is done where the source and destination port numbers are the same and are between 3001 and 3015.

Unfortunately, there's no way to disable that dissector. Perhaps we should add a way to disable it and should also attempt to strengthen the heuristic.

answered 26 Jun '12, 14:56

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

0

Could be some kind of VoIP solution. See here: http://wiki.wireshark.org/Q.931

Can you identify the device that used IP 192.168.0.254? Based on that information you might get an idea what generates Q.931 traffic (like a PBX with IP interface).

Regards
Kurt

answered 26 Jun '12, 12:51

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks for your info Kurt. I am trying to track the source device down. The 192.168.0.254 and 192.168.0.255 IPs don't make any sense, wondering if they are spoofed somehow. Is that a possibility?

(26 Jun '12, 12:57) someitguy2012

Address spoofing. Well.... possible, but I don't believe that. Why do you think those addresses don't make any sense? Don't you know them, or what is the reason?

BTW: The MAC addresses are both Cisco. Maybe one of them is a Cisco Call Manager? At least it supports Q.931 signaling. However, as I'm not a Cisco guru, I'm just guessing!

(26 Jun '12, 13:01) Kurt Knochner ♦

0

Q.931 is typically one layer below H.225 (H.323 VoIP signalling), unless you have some TDM traffic captured from a specialist TDM (ISDN) analyser, such as MtyEye.

The .255 address will be the broadcast address assuming the mask is 255.255.255.0 and .254 may well be the default gateway (hence Cisco MAC).

However, I cannot see why Q.931 traffic would be targetting the broadcast address.

What is the subnet mask?

answered 26 Jun '12, 14:32

KeithFrench's gravatar image

KeithFrench
121115
accept rate: 0%

0

Are you running Wireshark V1.8.0, if so, could it be worth checking the ISDN preference to ensure it is set to LAPD. There were some changes made by Guy in this area?

answered 27 Jun '12, 06:16

KeithFrench's gravatar image

KeithFrench
121115
accept rate: 0%

That's probably not it - that preference for "ISDN" in the sense of a direct capture from an ISDN line, but what he's seeing is being dissected as LAPD over UDP when it is, I suspect, not LAPD over UDP, so either the purported LAPD frames are reported by the LAPD dissector as bad (that's what the "I, N(R)=X, N(S)=X [Malformed packet]" probably are) or they manage to get through the LAPD dissector but they get reported by the Q.931 dissector as bad (the others).

(27 Jun '12, 09:53) Guy Harris ♦♦