On Tue, May 24, 2016 at 7:33 PM, Thadeu Lima de Souza Cascardo <
casca...@redhat.com> wrote:

> On Tue, May 24, 2016 at 07:14:11PM -0400, Flaviof wrote:
> > On Tue, May 24, 2016 at 7:06 PM, Thadeu Lima de Souza Cascardo <
> > casca...@redhat.com> wrote:
> >
> > > On Tue, May 24, 2016 at 06:24:21PM -0400, Flaviof wrote:
> > > > Hi folks,
> > > >
> > > > I'm trying to write a simple script to generate a packet into an
> existing
> > > > ovs interface (below). Instead of using "ovs-appctl ofproto/trace",
> I'm
> > > > attempting "ovs-appctl netdev-dummy/receive" so I can generate the
> raw
> > > > bytes, similar to what we have in the AT tests.
> > > >
> > > > Is "netdev-dummy/receive" something that did not exist in 2.0.2?
> > > > Any pointers on how one could use that functionality?
> > > > Maybe I could do this from an ovs sandbox?
> > >
> > > The dummy datapath is an OVS construct. You won't see dummy bridge and
> > > dummy
> > > ports as linux netdev interfaces. It is not at all related to the dummy
> > > linux
> > > driver.
> > >
> > >
> > heh, thanks for the clarification!
> >
> >
> > > If you want to inject packets using a different datapath, you can try
> > > OpenFlow
> > > packet out, using ovs-ofctl packet-out.
> > >
> > >
> > Ack! Will do!
> >
> > It seems that using "ovs-appctl ofproto/trace brtest in_port=${inport}
> > $packet" is working too.
> >
> > I was wrong to assume that "ofproto/trace" could not handle $packet as a
> > sring of hex values. Right now I'm having trouble seeing the packets in
> > wireshark (see below), but it is likely because I'm not setting the
> proper
> > checksum values. If so, that is 100% my fault. ;)
>
> The thing is that ofproto/trace will not execute the actions. It will
> process
> the packet in xlate_actions and then simply output which actions would
> have been
> executed. So, you won't see any real output. That explains why you don't
> see
> them in wireshark.
>
>
Make sense. I tried using the '-generate' flag to make it more 'real' but I
would not
accept that. Could be due to the 'old' ovs version I'm using (2.0.2).



> The thing about packet-out is that you need to provide an action. I am not
> sure
> if you can provide something like a resubmit(,0), but it's worth a try.
> Let me
> know if that trick works for you. Now, if all you have is a NORMAL action
> switch, just use NORMAL as your action and you should be good.
>
>
Heh, no dice. I tried the following variations w/out much luck:

in_port --> none, 1, 2, LOCAL
actions -->  'NORMAL', 'output:1', 'output:2', 'output:1,2', 'resubmit(,0)'

sudo ovs-ofctl -O OpenFlow13 packet-out brtest $in_port $actions
 
'0001020304050011223344550800450000540000400040010000c0a83221c0a837fe0035111100080000080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607'

I was looking to turn on some logs, but none of these seem to make a
difference:

for x in ofproto ofp_actions ofp_errors ofp_msgs vswitchd  pktbuf ovs_thread ;
do
  sudo ovs-appctl vlog/set ${x}:file:dbg
done

Would you know if there is a log that could give me some clues on what is
eating the packet?

-- flaviof



> Cascardo.
>
> >
> > Thanks, Cascardo!!!
> >
> > -- flaviof
> >
> >
> >
> > [dell:ovsScripts.git] (master)$ ./sendIcmp.sh
> >
> > + test_ipv4_icmp_request dummy0 001122334455 000102030405 c0a83221
> c0a837fe
> >
> > + local invif=dummy0 eth_src=001122334455 eth_dst=000102030405
> > ipv4_src=c0a83221 ipv4_dst=c0a837fe icmpv4_code=
> >
> > + local hdrchksum=0000
> >
> > + local icmp_seq=0001
> >
> > + local icmp_ts=02bb445700000000
> >
> > + local
> >
> icmp_data=000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> >
> > + local
> >
> icmp_payload=080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> >
> > + local
> >
> packet=0001020304050011223344550800450000540000400040010000c0a83221c0a837fe0035111100080000080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> >
> > + inport=1
> >
> > + sudo ovs-appctl ofproto/trace brtest in_port=1
> >
> 0001020304050011223344550800450000540000400040010000c0a83221c0a837fe0035111100080000080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> >
> > Packet:
> >
> icmp,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=00:11:22:33:44:55,dl_dst=00:01:02:03:04:05,nw_src=192.168.50.33,nw_dst=192.168.55.254,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=0,icmp_code=53
> >
> > Flow:
> >
> icmp,metadata=0,in_port=1,vlan_tci=0x0000,dl_src=00:11:22:33:44:55,dl_dst=00:01:02:03:04:05,nw_src=192.168.50.33,nw_dst=192.168.55.254,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=0,icmp_code=53
> >
> > Rule: table=0 cookie=0 priority=0
> >
> > OpenFlow actions=NORMAL
> >
> > no learned MAC for destination, flooding
> >
> >
> > Final flow: unchanged
> >
> > Relevant fields:
> >
> skb_priority=0,ip,in_port=1,vlan_tci=0x0000/0x1fff,dl_src=00:11:22:33:44:55,dl_dst=00:01:02:03:04:05,nw_frag=no
> >
> > Datapath actions: 3,5
> >
> > + echo ok
> >
> > ok
> >
> >
> >
> >
> > > Regards.
> > > Cascardo.
> > >
> > > >
> > > > Thanks,
> > > >
> > > > -- flaviof
> > > >
> > > > ---
> > > >
> > > > [dell:ovsScripts.git] (master)$ lsmod | grep dummy
> > > >
> > > > dummy                  16384  0
> > > >
> > > > [dell:ovsScripts.git] (master)$
> > > >
> > > > [dell:ovsScripts.git] (master)$ sudo ovs-vsctl show
> > > >
> > > > c0006a18-e32c-44aa-9985-7641d61a74fc
> > > >
> > > >     Bridge brtest
> > > >
> > > >         Port brtest
> > > >
> > > >             Interface brtest
> > > >
> > > >                 type: internal
> > > >
> > > >         Port "dummy0"
> > > >
> > > >             Interface "dummy0"
> > > >
> > > >     ovs_version: "2.0.2"
> > > >
> > > > [dell:ovsScripts.git] (master)$
> > > >
> > > > [dell:ovsScripts.git] (master)$ ip a s dev dummy0
> > > >
> > > > 13: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
> master
> > > > ovs-system state UNKNOWN group default
> > > >
> > > >     link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
> > > >
> > > >     inet 192.168.55.254/24 scope global dummy0
> > > >
> > > >        valid_lft forever preferred_lft forever
> > > >
> > > >     inet6 fe80::d074:13ff:fe2f:26d3/64 scope link
> > > >
> > > >        valid_lft forever preferred_lft forever
> > > >
> > > > [dell:ovsScripts.git] (master)$
> > > >
> > > > [dell:ovsScripts.git] (master)$
> > > >
> > > > [dell:ovsScripts.git] (master)$ cat sendIcmp.sh
> > > >
> > > > #!/bin/bash
> > > >
> > > >
> > > > ip_to_hex() {
> > > >
> > > >     printf "%02x%02x%02x%02x" "$@"
> > > >
> > > > }
> > > >
> > > >
> > > > test_ipv4_icmp_request() {
> > > >
> > > >     local invif=$1 eth_src=$2 eth_dst=$3 ipv4_src=$4 ipv4_dst=$5
> > > > icmpv4_code=$6
> > > >
> > > >     shift; shift; shift; shift; shift; shift
> > > >
> > > >     # This packet has bad checksums but logical L3 routing doesn't
> check.
> > > >
> > > >     local hdrchksum=0000
> > > >
> > > >     local icmp_seq=0001
> > > >
> > > >     local icmp_ts=02bb445700000000  ; # May/24/16 16:35:14 EDT
> > > >
> > > >     local
> > > >
> > >
> icmp_data=000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> > > >  ; # 48 bytes
> > > >
> > > >     local
> > > icmp_payload=0800${hdrchksum}5fbf${icmp_seq}${icmp_ts}${icmp_data}
> > > >
> > > >     local
> > > >
> > >
> packet=${eth_dst}${eth_src}080045000054000040004001${hdrchksum}${ipv4_src}${ipv4_dst}0035111100080000${icmp_payload}
> > > >
> > > >     sudo ovs-appctl netdev-dummy/receive $invif $packet
> > > >
> > > >
> > > >
> > > > }
> > > >
> > > >
> > > > eth_dst=000102030405
> > > > eth_src=001122334455
> > > > ip_src=$(ip_to_hex 192 168 50 33)
> > > > ip_dst=$(ip_to_hex 192 168 55 254)
> > > >
> > > > set -x
> > > >
> > > > test_ipv4_icmp_request dummy0 $eth_src $eth_dst $ip_src $ip_dst
> > > >
> > > > echo ok
> > > >
> > > >
> > > > [dell:ovsScripts.git] (master)$
> > > >
> > > > [dell:ovsScripts.git] (master)$ ./sendIcmp.sh
> > > >
> > > > + test_ipv4_icmp_request dummy0 001122334455 000102030405 c0a83221
> > > c0a837fe
> > > >
> > > > + local invif=dummy0 eth_src=001122334455 eth_dst=000102030405
> > > > ipv4_src=c0a83221 ipv4_dst=c0a837fe icmpv4_code=
> > > >
> > > > + local hdrchksum=0000
> > > >
> > > > + local icmp_seq=0001
> > > >
> > > > + local icmp_ts=02bb445700000000
> > > >
> > > > + local
> > > >
> > >
> icmp_data=000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> > > >
> > > > + local
> > > >
> > >
> icmp_payload=080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> > > >
> > > > + local
> > > >
> > >
> packet=0001020304050011223344550800450000540000400040010000c0a83221c0a837fe0035111100080000080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> > > >
> > > > + sudo ovs-appctl netdev-dummy/receive dummy0
> > > >
> > >
> 0001020304050011223344550800450000540000400040010000c0a83221c0a837fe0035111100080000080000005fbf000102bb445700000000000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607
> > > >
> > > > "netdev-dummy/receive" is not a valid command
> > > >
> > > > ovs-appctl: ovs-vswitchd: server returned an error
> > > >
> > > > + echo ok
> > > >
> > > > ok
> > > >
> > > > [dell:ovsScripts.git] (master)$
> > >
> > > > _______________________________________________
> > > > discuss mailing list
> > > > discuss@openvswitch.org
> > > > http://openvswitch.org/mailman/listinfo/discuss
> > >
> > >
>
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to