packetdrill usage documentation

[ciernab...@gmail.com]

Hello! I'd like to use this tool for network testing with two physical machines however I could not find any documentation about this usage. Do you have any docs no packetdrill parameters and usage scenarios. This would help a lot!

Thanks,
Jan

[Neal Cardwell]

Hi,

We will be adding more documentation as time allows, but here's a
quick example/summary...

On the machine under test, run:

host1# ./packetdrill --wire_client --wire_server_ip=<ip2> foo.pkt

On another machine on the same L2 domain (same hub/switch) run the
following to have a packetdrill process act as a "wire server" to
inject and sniff packets:

host2# ./packetdrill --wire_server

Hope that helps,

neal

> --
> You received this message because you are subscribed to the Google Groups
> "packetdrill" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to packetdrill...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[ciernab...@gmail.com]

Thanks for the quick reply. I think this will help me for the start. Looking forward to see the documentation!

-Jan

[yoshi nishida]

Hi, thanks for providing an interesting tool.

This seems that we need to install packetdrill on both server and client side.
But, is there any usage that we can use packatdrill from just one side?

Thanks,
--
Yoshi

[Neal Cardwell]

On Mon, Jul 8, 2013 at 10:24 PM, yoshi nishida <nsd...@gmail.com> wrote:
> Hi, thanks for providing an interesting tool.
>
> This seems that we need to install packetdrill on both server and client
> side.
> But, is there any usage that we can use packatdrill from just one side?

Yes, you can use it oin a single machine. Just provide the script
name, without any options. For an example, please see the README in
the source distribution, or:

https://code.google.com/p/packetdrill/wiki/README

neal

[yoshi nishida]

Hi Neal,

Thanks for the response.

Well, yes. These examples use local connection through tunneling device.

I'm wondering if there's a way to send traffic from packetdrill to remote hosts (which doesn't have packetdrill) to investigate their behavior.

Sorry if I miss something.

Thanks,

--

Yoshi

[Neal Cardwell]

I see. Sorry I misunderstood your question. No, there is not yet
support for testing a remote host that doesn't have packetdrill
running. This would be straightforward to add, I think. I think it
would be a new mode, a lot like the wire_server.c code, with an event
loop like wire_server_run_script(), except that instead of getting
command line arguments and the script over a TCP connection, it would
get them directly. I would be happy to apply a patch like that if
someone cooks up a good one (and tests it).

neal

[smallboy li]

Oho, can.t wait~~

在 2013年7月11日星期四UTC+8上午8时56分45秒，Neal Cardwell写道：

[anil Kainikara]

HI,

Has anything been done in this regard ( "send traffic from packetdrill to remote hosts (which doesn't have packetdrill) to investigate their behavior" )?

--Anil

[Neal Cardwell]

On Thu, Oct 29, 2015 at 12:28 AM, anil Kainikara <anilku...@gmail.com> wrote:
> HI,
>
> Has anything been done in this regard ( "send traffic from packetdrill to
> remote hosts (which doesn't have packetdrill) to investigate their behavior"
> )?

As far as I know, nobody has implemented this.

neal

[Yoshifumi Nishida]

I see some packets are going out by doing this sort of things? Can't we utilize this?

sudo packetdrill --local_ip=MY_IP --wire_client --wire_server_ip=SERVER_IP --wire_server_port=SERVER_PORT --wire_client_dev=NIC_NAME --ip_version=ipv4 SCRIPT_NAME

--

Yoshi

[Neal Cardwell]

On Thu, Oct 29, 2015 at 11:30 AM, Yoshifumi Nishida <nsd...@gmail.com> wrote:
> I see some packets are going out by doing this sort of things? Can't we
> utilize this?
>
> sudo packetdrill --local_ip=MY_IP --wire_client --wire_server_ip=SERVER_IP
> --wire_server_port=SERVER_PORT --wire_client_dev=NIC_NAME --ip_version=ipv4
> SCRIPT_NAME

When it comes to the question of sending traffic from packetdrill to remote
hosts not running packetdrill, my sense is that most of what would be required
is already in the code base: parsing scripts, injecting packets, sniffing
packets. But currently the "wire" mode requires a client running
packetdrill (which makes system calls on the machine under test)
and the server running packetdrill (which injects packets on the LAN),
and the two machines must be on the same LAN.

My sense is that an interested party could write a new packetdrill mode that
was closely based on wire_server.c but removed the logic to handshake
with the client, and simply injected packets and waited for inbound packets,
according to the script.

neal