[Planetlab-devel] tcp raw socket problem on new planetlab system

Sat Jan 17 21:33:54 EST 2009

Hi Harsha,

You need to prove that the returning ICMP packet belongs to you, so at
the time that it returns, you should be bound to the local UDP port
that  it is associated with. If you use a UDP socket, it should
autobind to a local port and things should work out. If not, then
you'll have to somehow bind explicitly.

Sapan

On Sat, Jan 17, 2009 at 9:22 PM, Harsha V. Madhyastha
<harsha at cs.washington.edu> wrote:
> Hi Sapan,
>
> Yes, our tool uses raw sockets for sending the UDP probes (because we need
> to receive the ICMP PORT-UNREACHABLE error messages received in response).
>
> Thanks!
> Harsha
>
> On Jan 17, 2009, at 5:29 PM, Sapan Bhatia wrote:
>
>> Hi Harsha,
>>
>> Are you using RAW sockets to send the UDP pings?
>>
>> Sapan
>>
>> On Sat, Jan 17, 2009 at 8:14 PM, Harsha V. Madhyastha
>> <harsha at cs.washington.edu> wrote:
>> Hi Sapan,
>>
>> We are seeing a similar problem now with UDP probes.
>>
>> We have a tool that sends UDP pings with the destination port range
>> similar to what traceroute uses. I ran the following experiment with it.
>>
>> >From several PlanetLab nodes, I sent probes to a host at UW using our UDP
>> ping tool and using traceroute, with both sending probes to the same
>> destination port. tcpdump on the destination host at UW shows that probes
>> from both tools are received and ICMP PORT-UNREACHABLE error messages are
>> sent back in response to both. However, on the PL node, I only see the ICMP
>> errors when using traceroute but not when using our UDP ping tool.
>>
>> Our UDP ping tool had been working fine since the beginning of 2006. But,
>> we haven't used it of late and given the similar problem with TCP reported
>> below, I guess propagation to the right slice of ICMP errors elicited by UDP
>> probes was also broken by the upgrade. Would be great if you could please
>> look into this issue.
>>
>> BTW, the svn ticket from your system when the TCP-related problem was
>> reported previously is here: https://svn.planet-lab.org/ticket/347
>>
>> Thanks!
>> Harsha
>>
>>
>> On Jul 8, 2008, at 8:12 PM, Sapan Bhatia wrote:
>>
>> Hi Ying and Maoke,
>>
>> You're right in your thinking, that slivers are isolated also with
>> respect to network packets. But this restriction does not prevent them
>> from reading packets (via raw sockets or otherwise) that belong to
>> them. A packet ``belongs to a sliver'' if it is associated with a
>> connection initiated or handled by a the sliver.
>>
>> The definition of 'being associated with a connection' comes from the
>> Netfilter subsystem of Linux, which we use to classify packets. For
>> instance, all TCP packets following the initial handshake are
>> associated with the resulting connection. All ICMP packets received
>> because of errors are also associated with that connection.
>>
>> The problem here is not that such ICMP packets are *not* getting
>> associated with the right sliver. It is that they are not appearing in
>> the network stack in the first place. So I can't see them via TCPDUMP
>> even when I log into the system as root. I'm going to try to regress
>> some patches that affect the network stack to see if it solves the
>> problem, and debug it from there on.
>>
>> It might also be that there's a configuration parameter somewhere that
>> causes ICMP errors related to TCP to be suppressed.
>>
>> Sapan
>>
>>
>>
>> On Tue, Jul 8, 2008 at 10:17 PM, Maoke <mk at cernet.edu.cn> wrote:
>> I also wonder to have an explanation on this issue. Is this related to the
>> architecture of PlanetLab node where the slivers are isolated only over
>> the
>> network layer, and the pcap facilities are forbidden in slivers due to
>> security and privacy considerations? We expect the developers giving a
>> comprehensive comment on this. Thanks!
>>
>> Best,
>> Maoke
>>
>> --
>> mk at cernet.edu.cn
>> Room 227 Main Building, Tsinghua University, Beijing 100084 P R China
>> --
>>
>> -----Original Message-----
>> From: devel-bounces at planet-lab.org [mailto:devel-bounces at planet-lab.org]
>> On Behalf Of Ying Zhang
>> Sent: Tuesday, July 08, 2008 3:19 PM
>> To: devel at lists.planet-lab.org
>> Cc: zmao at eecs.umich.edu
>> Subject: [Planetlab-devel] tcp raw socket problem on new planetlab system
>>
>> Hi, I have problem with TCP raw socket on the new system. Can
>> anyone help me on this?
>> For example, the TCP traceroute does not work. TCP packets are sent out,
>> but no packets are received. Even if I use tcpdump
>> on the planetlab node, I didn't see any received packets. But if I use UDP
>> traceroute, it works fine. I am certain that packets are sent out because
>> I've tested in by doing tcpdump on the destination.
>>
>> For example,
>> if you use
>> [michigan_exp at planetlab2 ~]$ sudo traceroute -P tcp 128.112.139.221
>> traceroute to 128.112.139.221 (128.112.139.221), 30 hops max, 40 byte
>> packets
>>  1  * * *
>>  2  * * *
>>  3  * * *
>>  4  * * *
>>
>>
>> But without specifying protocol, it works fine:
>> [michigan_exp at planetlab2 ~]$ sudo traceroute 128.112.139.221
>> traceroute to 128.112.139.221 (128.112.139.221), 30 hops max, 40 byte
>> packets
>>  1  eecscomp2-4.eecs.umich.edu (141.213.4.1)  0.386 ms  0.353 ms
>> 0.377 ms
>>  2  ge-caen-bin-arb.r-bin-arb.umnet.umich.edu (192.122.183.41)  0.562 ms
>> 0.523 ms  0.564 ms
>>  3  l3-barb-bseb-1.r-bin-seb.umnet.umich.edu (192.12.80.9)  0.629 ms
>> 0.619 ms  0.673 ms
>>  4  v-bin-seb-i2-aa.merit-aa2.umnet.umich.edu (192.12.80.33)  6.427 ms
>> 6.399 ms  6.396 ms
>>  5  192.122.183.30 (192.122.183.30)  7.011 ms  6.998 ms  6.958 ms
>>
>>
>> Does anyone have had this problem before? The problem occurred after the
>> system upgrade. Is it a problem with the new kernel?
>>
>> thanks!
>> Ying
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
>