No probs! On Mon, 5 Sep 2016 at 11:27 Kaustubh Rajwade <rkaustub...@gmail.com> wrote:
> Hi Jack, > > Thanks for pointing me in the right direction! > > Cheers, > Kaustubh > > On Mon, Sep 5, 2016 at 8:14 PM, Jack Hickish <jackhick...@gmail.com> > wrote: > >> Hi Kaustubh, >> >> I think you missed out on a fix by just a couple of weeks -- see >> https://github.com/casper-astro/mlib_devel/commit/129937f7dba65f53db39b3fc0a0c968d2cacf9f6 >> >> Cheers >> Jack >> >> On Mon, 5 Sep 2016 at 10:00 Kaustubh Rajwade <rkaustub...@gmail.com> >> wrote: >> >>> Hi Jack, >>> >>> >>> Here are commits that I am using: >>> >>> Old library: commit a88c343 (16 Nov 2010) >>> >>> New library: commit ecab6f (2 Jan 2015) >>> >>> Cheers, >>> Kaustubh >>> >>> On Mon, Sep 5, 2016 at 6:07 PM, Jack Hickish <jackhick...@gmail.com> >>> wrote: >>> >>>> Hi Kaustubh, >>>> >>>> What version of the mlib_devel libraries are you using? >>>> >>>> Cheers, >>>> >>>> Jack >>>> >>>> On Mon, 5 Sep 2016 at 08:11 Kaustubh Rajwade <rkaustub...@gmail.com> >>>> wrote: >>>> >>>>> Hi Casperites, >>>>> >>>>> I have a simple ROACH 1 design streaming packets via two 10GbE ports >>>>> (clock:160 MHz). When I compile the design using old libraries (XSG: 11.4, >>>>> Matlab 2009), I have no issues in receiving packets via sockets. When I >>>>> compile the same design using newer libraries (XSG:14.7, Matlab2013a), I >>>>> can receive packets via tcpdump but I get bad checksum and I cannot >>>>> capture >>>>> the packets using standard methods (e.g. recvfrom()). An example of the >>>>> checksum error is shown below: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size >>>>> 262144 bytes16:04:58.998384 02:02:0a:00:00:1f > 00:25:90:63:13:ac, >>>>> ethertype IPv4 (0x0800), length 8242: (tos 0x0, ttl 255, id 0, offset 0, >>>>> flags [DF], proto UDP (17), length 8228, bad cksum 63a8 (->47a0)!) >>>>> 10.0.0.31.48400 > 10.0.0.10.48500: [no cksum] UDP, length 8200 >>>>> 0x0000: 0025 9063 13ac 0202 0a00 001f 0800 4500 0x0010: 2024 0000 >>>>> 4000 ff11 63a8 0a00 001f 0a00 0x0020: 000a bd10 bd74 2010 0000 >>>>> 0000 >>>>> 0027 8734* >>>>> I validated the payload in the udp packets by sending counter values. >>>>> >>>>> Has anyone experienced this issue before? >>>>> >>>>> Cheers, >>>>> Kaustubh >>>>> >>>> >>> >
