I'm trying to send data from my PC to FPGA with ethernet cable.
I used this code for receiving packet's that send from my PC to FPGA (through Ethernet cable). I capture received packets on FPGA with ila(integrated logic debugger).
After programming FPGA when i used ifconfig on my linux pc, i see below: (I hidden my MAC Address)
enp7s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1490
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1427 bytes 199195 (199.1 KB)
TX errors 1071 dropped 0 overruns 0 carrier 0 collisions 0
As i knew from this similar question, My FPGA don't have any specific ip address and even port number. it's listen on every packets that sent on RXD (ethernet mii) according to it's MAC Address.
How i can send packets to FPGA when even i haven't any specific IP and Port?
I think i should set port and IP for my FPGA in my PC(no need to change hardware) but i don't know how do it?
there are few options.
if the FPGA is directly connected to your interface, then it will receive anything you send, so no worry about the network config
if you have a switch between, you could send a broadcast message, that would be forwarded to all device in the network (assuming you don't have a complex config in your switch like vlan or similar) .
about broadcast: https://en.wikipedia.org/wiki/Broadcasting_(networking)
it is simply a dest mac with FFs
as for the actual sending, you could be using python to generate and send your packet.
scapy is a very simple package that should help you for that
doc: https://scapy.readthedocs.io/en/latest/usage.html
look at this particular example:
sendp(Ether()/IP(dst="1.2.3.4",ttl=(1,4)), iface="eth1")
Related
I'm a newbie in the Linux network drivers. I'm trying to enable offload features in an ethernet IP.
This ethernet IP supports TX checksum offloading for only 2 Tx HW queues among the total 8 Tx HW queues. Whether the Linux network stack supports offloading Tx checksum only for a few queues(0 and 1 in this case).
Following is my understanding: The Linux driver declares the offload capabilities in netdev->hw_features, NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM in the case of TXCOE. If the device is enabled for TX checksum offloading, the stack doesn’t perform any checksum calculation or insertion and this is offloaded to the HW for the transmit packets irrespective of the HW queue.
Also what I can see is that tools like ethtool only support Tx/Rx checksum offloading for the whole device. Not on a per queue basis.
So can anyone confirm whether this ethernet IP(with 2 among 8 Tx HW queues alone supporting Tx COE) can handle Tx Checksum offloading properly in Linux with all 8 Tx HW queues enabled?
We have recently upgraded to DPDK 18.08 version.
After upgrading to the latest version observing issue with UDP packets transmission error for few packets.
No issue observed while transferring UDP packets with size 28 bytes and 48 bytes.
I tried to print the packet length calculation in my program just before sending it out to the Kernel using rte_kni_tx_burst.
The packet length calculation seems correct to me.
1.)
size_udp:48
sizeof(struct udp_hdr):8
size_ApplMsg:40
udphdr->dgram_len:12288
m->data_len:82
size_ip:68
l2_data_shift:14
2.)
size_udp:28
sizeof(struct udp_hdr):8
size_ApplMsg:20
udphdr->dgram_len:7168
m->data_len:62
ip->total_length:12288
size_ip:48
l2_data_shift:14
Packets with UDP size 736 are not getting transmitted to the receiving end and getting dropped.
3.)
size_udp:736
sizeof(struct udp_hdr):8
size_ApplMsg:728
udphdr->dgram_len:57346
m->data_len:770
size_ip:756
l2_data_shift:14
Also MTU is set to 1500 in my program. So it shouldn't be an issue to transfer 736 bytes UDP data which is less than 1500 bytes MTU.
I tried to increase the kernel buffer size but that didn't help.
netstat -su -> output shows 0 send/receive buffer errors.
What has changed in DPDK 18.08 with respect to UDP packets?
Please suggest if I need to consider tuning udp, offloading udp traffic to resolve this issue.
Thanks,
I am checking the MTU size of a USB tethering connection, but I got different results with different commands...
By using "netsh interface ip show subinterfaces" I get the following results (Local Area Connection 8 is the tethering connection):
C:\Users\Chris>netsh interface ip show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
4294967295 1 0 1350760 Loopback Pseudo-Interface 1
1500 2 3756376356 10363121083 Wireless Network Connection
1500 5 0 0 Local Area Connection
1500 1 178477 238360 Local Area Connection 8
But by using "ping google.com -l 1472 -f" I got the following results:
C:\Users\Chris>ping google.com -l 1472 -f
Pinging google.com [216.58.220.142] with 1472 bytes of data:
Reply from 192.168.42.129: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
The tethering connection is the only working connection when I check. If the MTU size is 1500 the ping method should work... I am a little bit confused here. Could anyone tell me what's the difference between the 2 method?
netsh shows the MTU of the interface itself. But your ping command sends packets through your interface into the wider world of the Internet. Somewhere along the path between your interface and google.com there is a router with a smaller MTU than 1472 bytes. This is called Path MTU.
I have an RFID receiver that constantly sends UDP packets to port 5757. When connected over ethernet to my desktop, all packets are received and valid (confirmed with Wireshark), and there is no issue. When I connect the receiver via ethernet to my laptop, not one UDP packet is received.
Things I have tried:
I have connected the laptop to the desktop over ethernet, and have sent UDP packets via netcat in both directions. Netcat has no issues with sending/receiving the data.
I've also captured and saved the RFID UDP packets on the desktop, and played them back using bittwist, first on the desktop, and had no issues capturing them in Wireshark(desktop). Then I copied the saved packets over to the laptop, played them back using bittwist, and had zero UDP packets captured in Wireshark(laptop).
Finally, I updated the ethernet driver and had the same results.
Any help would be greatly appreciated.
When send a UDP datagram larger than the MTU size, only the last fragment of the UDP datagram is putted out to the destination. The rest of fragments are silently discarded. Sendto() return the sendlength (no error).
Envirenment:
OS: vxWorks6.8
CPU: ARM9
MTU: 1500
The vxWorks board is direct connected via ethernet cable to the Win7 PC (with wireshark).
The DF flag isn't set.
Example 1:
sendto with 1400 Bytes
wireshark shows: udp with 1400 Databytes4
Example 2:
sendto with 1800 Bytes
wireshark shows: Fragmented IP protocol (proto=udp 0x11, off=1496, id0a00) -> Data (312 bytes)
Example 3:
sendto with 4000 Bytes
wireshark shows: Fragmented IP protocol (proto=udp 0x11, off=1496, id0a00) -> Data (1016 bytes)
Example 4:
sendto with 7800 Bytes
wireshark shows: Fragmented IP protocol (proto=udp 0x11, off=1496, id0a00) -> Data (328 bytes)
I use the same test on a second vxworks board with CPU PPC and this work fine and the ip-fragmentation work properly.
Why the first fregments of the udp packet are always discarded?
Many Thanks