1
votes

I'm working on an Linux application using PcapPlusPlus that will send a SIP packet to a port on the local host. Basically it is sending a UDP message:

Source:  127.0.0.1 port 5061 
Dest:    127.0.0.1 port 5060

My question is why doesn't port 5060 see the data.

Here is the section of C++ code:

    string localhost = "127.0.0.1";
    PcapLiveDevice *dev = pcpp::PcapLiveDeviceList::getInstance().getPcapLiveDeviceByIp(localhost.c_str());

    if (!dev->open())
            printf("open device failed\n");

    int res = dev->sendPacket(&packet);
    printf("%d return code\n", res);

sendPacket() returned 1 so the send looks good. The application is running as root so it shouldn't have permission issues with raw sockets.

Wireshark shows the data being sent but the server running on port 5060 never sees it. I also verified that netcat doesn't see it so it doesn't appear to be an issue with the server.

Here is the Wireshark trace:

Frame 415: 556 bytes on wire (4448 bits), 556 bytes captured (4448 bits) on interface 0
    Interface id: 0 (any)
        Interface name: any
    Encapsulation type: Linux cooked-mode capture (25)
    Arrival Time: Jan  2, 2020 15:15:44.960061179 CST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1577999744.960061179 seconds
    [Time delta from previous captured frame: 24.812597478 seconds]
    [Time delta from previous displayed frame: 24.812597478 seconds]
    [Time since reference or first frame: 1328.602949365 seconds]
    Frame Number: 415
    Frame Length: 556 bytes (4448 bits)
    Capture Length: 556 bytes (4448 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 772
    Link-layer address length: 6
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Unused: 0006
    Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 540
    Identification: 0x014d (333)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x3982 [validation disabled]
    [Header checksum status: Unverified]
    Source: 127.0.0.1
    Destination: 127.0.0.1
User Datagram Protocol, Src Port: 5061, Dst Port: 5060
    Source Port: 5061
    Destination Port: 5060
    Length: 520
    Checksum: 0xeedb [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
Session Initiation Protocol (INVITE)

I'm able to successfully send data to port 5060 using netcat (nc 127.0.0.1 5060 on the send side, nc -lv 127.0.0.1 5060 on the receive end) so there doesn't appear to be any firewall issues. I tried using an open source sipp client and messages from it were received by the server. I compared the Wireshark data from the sipp client and my application and they are identical (except for sequence numbers and checksums). Any ideas why my app would have a different result? Thanks!

EDIT - The same problem occurs when trying to connect to a server on a remote machine.

1
Does this answer your question? Wireshark localhost traffic captureRoss Jacobs
^ The answers in the linked question will generally answer yours. The short answer is don't use localhost/127.0.0.1/::1 if you want to capture your own traffic.Ross Jacobs
I tried the different test. I attempted to connect to a server on a remote machine and ran into the same issue. This rules out issues with localhost.jmq

1 Answers

2
votes

I found the issue. The src and dest MACs were not being set correctly in the outgoing packets.