Tuesday, January 06, 2015
… and this bug exists because of a work-around for that bug …
Sigh.
The last day at work in 2014 (Debtember 18th), I spent it
running yet another IOT, which involves running
tcpdump to capture the network traffic on our end to verify
that we receive and send the data properly. After running a test, I would
load the resulting capture into wireshark, filter for the
SIP protocol only to
find—
Nothing.
“Project: Sippy-Cup” was
getting the packets and responding correctly—well, as “correctly” as these things go, but I was not
seeing any packets under wireshark, no matter what I did. But
the whole test setup is so jury-rigged that it wouldn't surprise me at all
if we were, in fact, doing NAT over avian
carriers that it seemed rather pointless to spend the next few hours
trouble shooting my inability to do network captures when the other
participants were able to capture enough of the transaction to let us
continue running the test.
Especially as I was one day from retirement a few hours
away from a two-week Christmas vacation.
And then today, I learned that we were, in fact, capturing data.
Why was wireshark not showing the packets?
Because I was telling wireshark to filter on SIP, which defaults to port
5060. We were running our SIP component on port 5061, because of some odd-ball
router on our network that oh-so-helpfully looks for SIP traffic and attempts to proxy it
anywhere else than our SIP component.
And because we were running on a non-standard port,
wireshark wasn't showing us the proper packets as it was
looking only for packets on port 5060.
I swear, I think IP-over-avaian-carriers would be easier to deal with.
