On Tue, Feb 19, 2019 at 12:43:08PM +0800, Krish wrote:
> Hi Flavio,
> 
> I think I got tcp_src and tcp_dst values, I can also successfully print
> them.
> Here is what I did:
> for(numb=0;numb<cnt; numb++)
> {
> 
>         uint8_t nw_proto = 0;
> packet=packets->packets[numb];
> size_t size = dp_packet_size(packet);
> const void *data = dp_packet_data(packet);
> const char *frame = (const char *)data;
> dp_packet_reset_offsets(packet);
> *data_pull(&data, &size, ETH_ADDR_LEN * 2);*
> //dl_type = parse_ether(&data, &size);
> //VLOG_DBG("parse ether type DL TYPE: 0x%4x", dl_type);
> packet->l3_ofs = (char *)data - frame;
> const struct ip_header *ip = dp_packet_l3(packet);
> nw_proto = ip->ip_proto;
> VLOG_DBG("IP proto---> %d ", nw_proto);
> int ip_len;
> ip_len = IP_IHL(ip->ip_ihl_ver) * 4;
> 
>                 *data_pull(&data, &size, ip_len);*
> packet->l4_ofs = (char *)data - frame;
>                 if(nw_proto == 6)
> {
> struct tcp_header *th = dp_packet_l4(packet);
> VLOG_DBG( "tcp_src ---> %d", ntohs(th->tcp_src));
> VLOG_DBG( "tcp_dst ---> %d", ntohs(th->tcp_dst));
>               }
> }
> 
> 
> Can you please confirm, if this is the right approach I have used and not
> seeing the old values like before?

It's hard to read code using html (bold, etc), could you please use
text only and indent the code properly? It makes our life a lot easier.

When you pull ETH_ADDR_LEN*2, the offset now points to ethernet_type
which is not the l3_ofs as you set next. I don't think the above code
works unless you uncomment parse_ethertype() which pulls more 4 bytes.

fbl



> 
> Thank you so much,
> Krish
> 
> On Tue, Feb 19, 2019 at 11:25 AM Krish <attkillro...@gmail.com> wrote:
> 
> > Flavio,
> >
> > Thank you for the clarification. You explained it very well.
> >
> > I don't want to wait for the miniflow_extraction, so I am left with
> > parsing packet myself.
> >
> > Here is what I am doing now:
> >
> > for(numb=0;numb<cnt; numb++)
> > {
> >
> >         uint8_t nw_proto;
> > const char *frame;
> > packet=packets->packets[numb];
> > const void *data = dp_packet_data(packet);
> > frame = data;
> > *dp_packet_reset_offsets(packet);*
> > * packet->l3_ofs = (char *)data - frame;*
> > * const struct ip_header *ip = dp_packet_l3(packet);*
> > nw_proto = ip->ip_proto;
> > VLOG_DBG("IP proto---> %d ", nw_proto); // This is 0
> >
> > }
> >
> > I followed almost the same approach of what is going in miniflow_extract.
> > nw_proto(ip protocol) is printing out to be 0.
> > I am using this code just before emc_processing and inside
> > dp_netdev_input__.
> > Can you please help me here?
> >
> > Thanks
> > Krish
> >
> >
> > On Mon, Feb 18, 2019 at 8:11 PM Flavio Leitner <f...@sysclose.org> wrote:
> >
> >> On Mon, Feb 18, 2019 at 11:05:53AM +0800, Krish wrote:
> >> > Thanks for reply Ben.
> >> > Does it mean that *miniflow_extract* will also initialize the L3 header
> >> > pointer?
> >>
> >> If you look at the miniflow_extract(), you  will see that it calls
> >> dp_packet_reset_offsets(packet) which will set all the header pointers
> >> to their defaults meaning that they are not pointing to anything real.
> >>
> >> These pointers are used by dp_packet_l3 (or 4) functions to locate
> >> the header.
> >>
> >> Then if you continue following the function, you will notice that
> >> the code parses the packet from the outer header to the inner header
> >> and as the parser goes, it updates the header offsets, like this line:
> >>
> >> packet->l3_ofs = (char *)data - frame;
> >>
> >> At this point, you have the pointer to the l3 header and you could use
> >> dp_packet_l3().
> >>
> >>
> >> > But I am getting the correct values for *nw_proto* from the L3 header.
> >> > struct ip_header *ip = dp_packet_l3(packet);
> >> > nw_proto = ip->ip_proto;
> >> >
> >> > Any comments on this? Whether its right or wrong?
> >>
> >> When using DPDK, the packet is represented by two parts. One if the
> >> rte buffer (packet data) that comes from DPDK library and the second
> >> part is the packet's metadata (the offsets you need). This offsets
> >> are allocated in the stack at dp_netdev_process_rxq_port(), so most
> >> probably you are seeing old values from previous packets which
> >> happens to work, but they are not correct.
> >>
> >> As I said above miniflow_extract() initializes those offsets to a
> >> known state and then parse the packet to update with the correct
> >> values.
> >>
> >> In summary, you will need to either wait for miniflow_extract() or
> >> parse the packet yourself if you need the tcp port.
> >>
> >> HTH,
> >> fbl
> >>
> >>
> >>
> >> >
> >> > Thanks a lot for your patience and response.
> >> >
> >> > Regards
> >> >
> >> > Krish
> >> >
> >> > On Sat, Feb 16, 2019 at 10:09 AM Ben Pfaff <b...@ovn.org> wrote:
> >> >
> >> > > You are almost certainly dereferencing a null pointer.
> >> > >
> >> > > On Sat, Feb 16, 2019 at 09:02:17AM +0800, Krish wrote:
> >> > > > That code I showed before. It is working fine and crashing only
> >> when I
> >> > > > enable debugging.
> >> > > >
> >> > > > As *sruct tcp_header's tcp_src* has ovs_be16 type. How to store and
> >> print
> >> > > > this value ?
> >> > > >
> >> > > > Thanks
> >> > > >
> >> > > > On Sat, Feb 16, 2019, 08:43 Ben Pfaff <b...@ovn.org> wrote:
> >> > > >
> >> > > > > Then you're going to have to work harder since miniflow_extract()
> >> is
> >> > > > > what initializes the L4 header pointer.
> >> > > > >
> >> > > > > On Sat, Feb 16, 2019 at 08:39:08AM +0800, Krish wrote:
> >> > > > > > I am sorry, but I am trying not to use extracted flow.  I want
> >> to use
> >> > > > > this
> >> > > > > > information before it goes to EMC.
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Sat, Feb 16, 2019, 03:44 Ben Pfaff <b...@ovn.org> wrote:
> >> > > > > >
> >> > > > > > > On Fri, Feb 15, 2019 at 03:48:22PM +0800, Krish wrote:
> >> > > > > > > > Hi
> >> > > > > > > >
> >> > > > > > > > I want to store tcp_src, dst port in a variable.
> >> > > > > > > > This is what I am doing:
> >> > > > > > > > 1. Retrieve packet from dp_packet_batch one by one.
> >> > > > > > > > 2. Retrieving field values by extracting packets headers:
> >> > > > > > > >
> >> > > > > > > > struct ip_header *ip = dp_packet_l3(packet);
> >> > > > > > > > nw_proto = ip->ip_proto;
> >> > > > > > > > if(nw_proto == 6)
> >> > > > > > > > {
> >> > > > > > > > struct tcp_header *th = dp_packet_l4(packet);
> >> > > > > > > > // The following are the 2 different ways I am trying to
> >> print
> >> > > the
> >> > > > > > > tcp_src.
> >> > > > > > > > I have tried it 1 and 2 separately not at the same time.
> >> > > > > > > >                 //1 . Ovs crash at the below statement
> >> > > > > > > >                 uint16_t src = (uint16_t)
> >> ntohs(th->tcp_src);
> >> > > > > > > >                 VLOG_DBG( "tcp_src ---> %d", src );
> >> > > > > > > >                 //2. When I enable logging ovs crashes at
> >> this
> >> > > point
> >> > > > > > > >                 VLOG_DBG( "tcp_src ---> %d",
> >> ntohs(th->tcp_src)
> >> > > );
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >                  }
> >> > > > > > > >
> >> > > > > > > > Can anyone please help how to store tcp_src port value in a
> >> > > variable
> >> > > > > and
> >> > > > > > > > print it in vlogs?
> >> > > > > > > > Statement 2 is working fine if vlogs are disabled, but I
> >> want the
> >> > > > > port
> >> > > > > > > > value to be stored in a variable and then print.
> >> > > > > > >
> >> > > > > > > I'd just get it from the extracted flow instead of inventing
> >> new
> >> > > code
> >> > > > > to
> >> > > > > > > extract it.
> >> > > > > > >
> >> > > > >
> >> > >
> >>
> >> > _______________________________________________
> >> > discuss mailing list
> >> > disc...@openvswitch.org
> >> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >>
> >>
> >>

> _______________________________________________
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to