Jump to content


Photo

CuWifi V 2.0 Mega


  • Please log in to reply
1 reply to this topic

#1 jim

jim

    Advanced Member

  • Administrators
  • 3,385 posts

Posted 24 February 2014 - 12:17 AM

I've been working on the CuWifi V 2.0 for the MEGA and generally it works great. I've run into a situation where the firmware in the wifi card will not pass the UDP broadcast packets from the router to my Arduino code. I'm a very experienced developer with 35+ yrs of programming and startup companies. Worked at MSFT, Electronic Arts, etc.. I'm using this wifi shield for a new startup of mine. I really need this to work.
I have tcpdump logs of the packets.. I will include one packet response from the router. This packet is not picked up by the WIFI card and passed to the CuMega driver code. I've put debug statements in the RX data hook and not a bit of data comes in. Even before the UDP packet is looked at by the tcp/udp stack. Most other networks work ok.. But this one is not. Is there a bug in the CuWifi firmware? An update?

15:49:11.670029 00:15:5d:01:0d:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 29431, offset 0, flags [none], proto UDP (17), length 328)
192.168.0.8.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xe12097d6, Flags [none] (0x0000)
Your-IP 192.168.0.116
Server-IP 192.168.0.8
Client-Ethernet-Address 00:1e:c0:04:cb:52
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Subnet-Mask Option 1, length 4: 255.255.255.0
RN Option 58, length 4: 216000
RB Option 59, length 4: 378000
Lease-Time Option 51, length 4: 432000
Server-ID Option 54, length 4: 192.168.0.8
Default-Gateway Option 3, length 4: 192.168.0.1
Domain-Name-Server Option 6, length 8: 192.168.0.8,8.8.8.8
0x0000: 4500 0148 72f7 0000 8011 05fe c0a8 0008 E..Hr...........
0x0010: ffff ffff 0043 0044 0134 a24c 0201 0600 .....C.D.4.L....
0x0020: e120 97d6 0000 0000 0000 0000 c0a8 0074 ...............t
0x0030: c0a8 0008 0000 0000 001e c004 cb52 0000 .............R..
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 6382 5363 3501 0201 ........c.Sc5...
0x0110: 04ff ffff 003a 0400 034b c03b 0400 05c4 .....:...K.;....
0x0120: 9033 0400 0697 8036 04c0 a800 0803 04c0 .3.....6........
0x0130: a800 0106 08c0 a800 0808 0808 08ff 0000 ................
0x0140: 0000 0000 0000 0000 ........



#2 jingjing

jingjing

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 05 March 2014 - 02:39 AM

It is unclear what the reasons are, you can try  the mac address of the module is set to FF: FF: FF: FF: FF that is broadcast address, I am convinced that this module can receive broadcast packets, but when we are there is no running TCP / UDP protocol, and the module is working in WIRELESS_MODE_ADHOC mode "the feasibility of your underlying code stickers that out? mainly the initial part of the module.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users