Ever wondered what a proper T.38 Fax over IP (FoIP) transmission looks like running through Wireshark? Maybe you’re troubleshooting a call flow, or never seen a T.38 capture. Below I’ll try to explain the call flow and steps to look out for when troubleshooting T.38 calls. Here’s an Outbound FAX call originating from a FXS port in a Cisco CUBE, and going towards Flowroute.

• Initial SIP INVITE and early media receipt (ringback). Note this is all RTP.
  
• SDP from the INVITE shows media offered is all voice (RTP)
  
• 183 Session in Progress, and we start sending media too (again, RTP). Later on comes the 200 OK, meaning the call was answered on the remote end.
  
• Things changing now… in-dialog (RE)INVITE from Cisco CUBE to SIP trunk… RTP and T.38 packets mixed because the remote end has not accepted our INVITE yet, but we start sending media either way.
  
• And the SDP of the new INVITE now shows all T.38 media now.
  
• Once we get the 200 OK from Flowroute, it’s all T.38 media both ways.
  
• Now the flow gets interesting, more Fax-ey. Wireshark will decode the HDLC data and show interesting bits here
  • TSI, is our Fax station number programmed in the machine.
    
  • DCS, our Fax machine communicates the capabilities, and starts training.
    
  • If we look inside the packet’s data, our DCS has a lot more information about our Fax machine’s settings and resolution
    
  • Then we get an FTT, means the remote end “Failed to Train”. Not usually a sign something is wrong, but more a capability mismatch. The remote fax may accept only lower baud rates, and will fail to train any higher. This is normal unless it’s the only response we get back from the remote end.
    
  • We see the same process of TSI, DCS and FTT until we hit the right baud rate… in our case it’s 9600… Once we get that, we receive a CFR.
    
  • Followed by a short training to sync-up and data (because we did long training before the CFR)
    
  • And our actual FAX data which will vary
    
  • At the end of the data, Wireshark reassembles the packets and tells us whether there was a loss or not. In our case, we’re good!
    
  • We send an EOP to signal the end of the transmission
    
  • The remote end does an MCF to acknowledge receipt (this is how your Fax machine knows the fax is “good” on the other end)
    
  • And then we send a DCN to logically hang up the HDLC stream, but we wait for the remote end…
    
  • Remote end hangs up the call… and we’re done…
    

And that was it. Many exchanges and training but in the end our page was sent over a SIP trunk, negotiating T.38, training with the remote fax machine at 9600 baud, and transmitting one page in about a minute.

Sophos UTM v9 comes with the tcpdump utility, which lets you run packet captures from the shell. This is great and all, but in order to look at those pcaps with Wireshark, you need to pipe to a file, copy the file, then run Wireshark against it. Annoying. All of it.

What if we could remotely capture packets over an SSH tunnel? YES… turns out it’s a bit tricky if you’re on Windows, and the authentication piece to get root access without having to do the loginuser first. How? Keep reading…

First, the necessary ingredients:

• Sophos UTM
• Wireshark (or your favorite pcap application)
• Putty suite (specifically Plink and PuttyGen)

To start, we’ll need to enable Shell Access, with public key authentication, and with Root access but only with SSH key.

We need to use PuttyGen to generate the key pair we’ll use for root authentication, so open it, Generate the key, then copy the Public Key into the Authorized Keys for root in the UTM, apply and save… and also Save private key to somewhere you’ll remember. We’ll need this for Plink.

There’s our new key…

Then run the actual magic using Plink. Take the following command as an example:

plink -ssh root@firewall.domain.com -i C:\ssh-priv.ppk “tcpdump -s 0 -U -n -w – not port 22 and not host 192.168.0.1” | “C:\Program Files\Wireshark\Wireshark.exe” -k -i –

Replace the SSH connection string for your actual firewall FQDN, the filename of ssh-priv.ppk for the location of your saved Private Key generated with PuttyGen, and the not host 192.168.0.1 with the IP address of the firewall from the interface you’re reaching it.

Wireshark will open and start showing packets. You can smile and jump now.

You can modify the tcpdump parameters to better match the capture, for example, using -i eth1 to capture a specific interface, or filter specific traffic… once you’re done, just close Wireshark and CTRL+C the command.

Note, if you’re doing this capture remotely over WAN or Internet, it will tunnel ALL packets over SSH, so it will take up a lot of bandwidth…

Have fun!!!