3

I have to work with an FPGA module already running a code written by someone else. I have no access to the FPGA code.

Now the setup is something like this:-

  • FPGA is connected to the pc via ethernet cable.
  • PC is also connected to the internet via ethernet cable on a different interface card. (there are 2 NIC installed on the pc)

As soon as the FPGA module is turned ON, it establishes the connection with the pc and starts sending the readings/data as UDP datagrams. I am interested in the data.

So, to understand the frame structure of the UDP packets, I ran Wireshark. The output of all the received packets on that specific ethernet card is shown below.

enter image description here

hfmajestrix.local is my pc and it has a static IP.

Can someone explain me whats happening after that ARP request from my pc in the fourth packet?

PC sends an ARP request to know which node has IP 169.254.37.110. Where is the ARP response?

Also, Where does IP 192.168.10.150 come from when there is NO router attached to the pc and when pc is asking for IP 169.254.37.110?

Details of ARP packet :- enter image description here

Details fo IGMP membership report :- enter image description here

3

I have to work with an FPGA module already running a code written by someone else.

The first 8 messages are not related to the FPGA; all of them seem to be transmitted by the PC and the PC always transmits these message whenever the network card detects that there is any connection.

hfmajestrix.local is my pc and it has a static IP.

The existence of the ARP packet you are interested in as well of the second packet (DHCP) makes me doubt. These packets are typical if a network card does not have a fixed IP address.

You have two network cards in the PC. Note that each network card has its own IP address if there are multiple network cards in one PC!

Are you sure the network card you use to connect to the FPGA has a fixed IP address?

when pc is asking for IP 169.254.37.110?

What you see here is "APIPA" (see the link in Ron Maupin's answer) which is used if a network card has no fixed IP address and DHCP also failed:

The PC takes a random IP address in the range 169.254.xx.xx and sends an ARP packet simply to check if this address is already in use ...

Where is the ARP response?

... if there is no ARP response the PC knows that the address is not in use and it uses this address.

Also, Where does IP 192.168.10.150 come from ...?

Obviously the code on your FPGA is compiled to use the fixed IP address 192.168.10.150. It broadcasts UDP packets to all computers in the network 192.168.10.xx.

If you want to communicate with the FPGA you have to give the network card the FPGA is connected to a fixed IP address in the range 192.168.10.xx (but not 192.168.10.150, of course).

However not knowing the protocol used by the FPGA this will be hard...

  • Now I get it, I have two NIC's and the NIC connected to FPGA doesn't have a static IP. It uses DHCP to get the dynamic IP. The other NIC might have the static IP but that doesn't affect this NIC. But ONE more question, every time I disconnect and reconnect the FPGA from/to PC, the pc always take the same IP in the 169.254.xx.xx range which is "169.254.37.110". Shouldn't It be random every time? Also, I didn't get what you mean by this? > However not knowing the protocol used by the FPGA this will be hard... – simarmannsingh Jul 9 '18 at 9:07
  • @simar1992 I'm not sure how your operating system chooses the "random address". Some operating systems use a pseudo-random number based on the MAC address for example (which is static). Some operating systems might save the value last used and re-try it the next time... – Martin Rosenau Jul 9 '18 at 18:49
4

Can someone explain me whats happening after that ARP request from my pc in the fourth packet?

That is a multicast IGMP join for the registered mDNS multicast group (224.0.0.251), see the IANA IPv4 Multicast Address Space Registry).

The pink (magenta?) highlighted packets are IPv6 multicast packets for neighbor discovery. See RFC 4861, Neighbor Discovery for IP version 6 (IPv6).

PC sends an ARP request to know which node has IP 169.254.37.110. Where is the ARP response?

It looks like it is configuring itself with link-local addressing (169.254.0.0/16), and it is performing duplicate address detection per RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses. No response means that there is not a duplicate address, and the host is free to use that address.

Where does IP 192.168.10.150 come from when there is NO router attached to the pc and when pc is asking for IP 169.254.37.110?

That is the source address on those packets, which are sent to what appears to be the broadcast address of the 192.168.10.0/24 network. We don't have enough information to tell you from where those packets are sourced, other than the source address.


By the way, you cannot route packets to/from a link-local address. That is expressly forbidden by the RFC, so if you need to do that, then you need to configure proper addressing.

An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header.

  • I intended to post a comment, but edited your post mistakenly. [SORRY, I am a newbie here.] How can I revert that ? :p So that anyone facing the same problem can see your response too. :/ – simarmannsingh Jul 9 '18 at 9:15
  • @simar1992, I rejected the edit. You do not have enough reputation to actually make the edit without approval, but I could still roll it back even if you did. Simply make your comment or post an answer. – Ron Maupin Jul 9 '18 at 10:46
2

Also, Where does IP 192.168.10.150 come from when there is NO router attached to the pc and when pc is asking for IP 169.254.37.110?

If the NIC is directly connected to the FPGA or through a (simple) switch with no other nodes attached, the origin must be the FPGA.

However, UDP port 5050 multimedia conference control might indicate a stray node on that link - or the FPGA simply using this unregistered port number. Check the source MAC address for details on the source. If a managed switch connects that segment you can examine its MAC table for the source port.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.