Hi Neels, Point codes in your packet appear at 2 different places: - in the M3UA header - the the SCCP header
Roch. Le sam. 27 août 2022 à 23:13, Neels Hofmeyr <[email protected]> a écrit : > I'm confused by what is happening in the pcap linked below: > According to wireshark, the SCCP message seems to come from *both* PC=4 > and PC=185. > > A column configured as sccp.calling.pc shows Point-Code 4. > A column configured as "Source Address" shows Point-Code 185. > > Is it even possible that the in-band Calling Address differs from whatever > wireshark detects as the SCCP Source Addres? Can anyone explain where the > 185 > is coming from? apparently not from sccp.calling.pc. > > The pcap and a screenshot showing the two point-codes and the column > config are > here: http://people.osmocom.org/neels/Eew7we0I/ > > Context: > The original RESET message (not part of the pcap) was sent to called.pc=4, > but > I have SCCP routing set up to forward PC=4 to the MSC that sees itself as > PC=185. > > I am expecting to see a RESET-ACK sent from PC=185. > IIUC The 4 should have evaporated when the MSC parsed the RESET message. > But > apparently when answering, it takes the "called.pc" and puts it in the > response > as "calling.pc" (4 is nowhere in the MSC's confguration, it MUST have > taken the > "4" from the received SCCP message). > > So what I am seeing in wireshark is eerily correct: it is the MSC that has > "185" in its cfg as local address sending the ACK, and it is responding to > a > request that was originally sent to "4", and which osmo-stp routed to > "185". > The response shows calling.pc=4. But how can wireshark know that it was > really > "185" sending, when no such information is in the SCCP layer of that > message? > What am I missing? > > if anyone knows, thanks in advance... > > ~N >
