You are not logged in.
Hello,
I have put xil_printf("abc") in dataFromNetworkLayer_callback and it gets printed out constantly even though i'm not transmitting (No iperf or ping). I tried with CSMA.mac and its the same thing. Is this normal?
Offline
Does the node itself show any Tx activity (i.e. is the green LED near the antenna connector blinking)?
The OFDM Reference Design implements a feature we called 'dummy packet mode', where the MAC code periodically transmits packets with random payload. If your code is enabling this mode you would expect to see transmit activity even if no Ethernet traffic is present.
Offline
I''ll see tomorrow about Tx activity but dummy packet mode isn't activated. For that i would need to call warpmac_setDummyPacketMode(1).
Offline
murphpo wrote:
Does the node itself show any Tx activity (i.e. is the green LED near the antenna connector blinking)?
The OFDM Reference Design implements a feature we called 'dummy packet mode', where the MAC code periodically transmits packets with random payload. If your code is enabling this mode you would expect to see transmit activity even if no Ethernet traffic is present.
I still have the same problem. D23 Led near ethernet is red D21 is blinking. LED near antenna connector is red and it's not blinking. All LEDs near hexadecimal displays are turned off.
Offline
If you look in warpmac.c, you can see that the usr_dataFromNetworkLayer callback (ie the callback that is assigned to dataFromNetworkLayer_callback in csmaMac.c) is used twice:
1) In the warpmac_pollDataSource() function, which is here. This is the 'dummy packet mode', which Patrick mentioned above.
2) In the emacRx_handler() function, which is here.
As you can see from the second use, if the received Ethernet packet is not a management frame (ie not a WARPNet management packet) and you are not in 'dummy packet mode' and skipDataCallback== 0 then the dataFromNetworkLayer_callback() is called with the contents of the Ethernet packet. Now, if you look back at the warpmac_pollDataSource() function, you can see that if there is any data in the Ethernet FIFO, then you are going to call the emacRx_handler(); This means that any non-WARPNet management packets that the node sees on the network are going to result in the dataFromNetworkLayer_callback() function being called.
Unfortunately, on many hosts, there is a lot of default network traffic (eg. Dropbox does LAN discovery, etc). The best way to understand what is going on would be to use Wireshark to sniff your Ethernet traffic on the switch the node / host is attached so that you can understand all of the Ethernet traffic that the node is seeing. You can always implement additional filtering on the Ethernet packets so that you only pass the packets you really want up to the dataFromNetworkLayer_callback.
Offline
Ok. Thank you.
How can i implement such filtering? I have no idea how to do that. I want to allow only iperf udp traffic
Offline
Basically, you have to check the various headers within the Ethernet packet data to filter the traffic:
1) The Ethernet header is 14 bytes; You need to check that the EtherType is IPv4.
2) The IP header is generally 20 byes; You need to check that the protocol is User Datagram Protocol.
3) The UDP header is 8 bytes; You can check the destination port and that should give you a pretty good filter for UDP traffic to a given port.
You can implement other checks against fields in the headers if you need to filter traffic more. Just remember that the data coming in over Ethernet is big endian, so you will need to byte swap any field greater than a byte or make the comparison value big endian. You can see some of this implemented in the WARPxilnet Library.
Offline
I have never done any kind of programming using these xilinx functions. I looked into emaRx_handler(). Can you tell me what is this XLLF_RLF_OFFSET constant. and how is XIo_In32(EMAC_FIFO_BaseAddr+XLLF_RLF_OFFSET) length of packet. Does this mean that XIo_In32(EMAC_FIFO_BaseAddr+XLLF_RLF_OFFSET+2bytes) gives ip version field?
Offline
Within the Xilinx SDK, if you right click on any function, constant, or variable, you can choose "Open Declaration" (ie F3) and it will take you to the definition of the item.
For example, for XLLF_RLF_OFFSET, it takes you to xllfifo_hw.h and says:
#define XLLF_RLF_OFFSET 0x00000024 /**< Receive Length */
Similarly, you can find the definition of XIo_In32(), which is just a macro that wraps a hardware register read. You can always find documentation for the Xilinx peripherals on-line. Just make sure you use the correct version of the documentation (ie the version that is in the XPS hardware project). For example, the Ethernet FIFO is a xps_ll_fifo version 1.02.a, which you can find the documentation here.
If you read through the emacRx_handler(), you can see that it gets the packet length and then transfer the contents of the packet from the FIFO to the packet buffer pointed to by pktBufPtr. The packet buffer is just an array of bytes in memory and you can treat it as such. For example, if you cast the packet buffer pointer to an "unsigned char *", then pktBufPtr[0] is the most significant byte of the destination address of the Ethernet header.
Offline