[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Issue with udp_input() and source ports
From: |
Brian Lam |
Subject: |
[lwip-users] Issue with udp_input() and source ports |
Date: |
Thu, 06 Aug 2009 15:36:15 -0700 |
User-agent: |
Thunderbird 2.0.0.22 (Windows/20090605) |
I am currently using lwIP 1.3.0, but this issue appears to remain in the
latest revision of udp.c.
Right now I am implementing PTPv2(IEEE 1588) using lwIP and it requires
that all its packets be broadcast to a specific port and address. This
restriction only applies to the destination port of the UDP header but
says nothing about the source port, which can be anything. What I tried
doing is to create a pcb and bind it to that port so it would receive
the messages on that port and then connect it to that port so it would
transmit to that port. The problem occurs when I get packets that have
correct destination port but a different source port. I never see those
messages.
I looked into udp.c and saw that udp_input() checks both the source and
destination port of connected pcbs before it considers it a match(line
195, rev 1.109). I think that this may be in violation of RFC 768 which
states that:
"Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted."
In my case, the PTPv2 standard is the "other information". In any case,
I think that source port filtering should occur above the UDP layer.
This is important even outside my case, because lwIP's implementation
appears to filter out packets with a source port of 0 as well, though I
have not tested that.
My current workaround is to create one unconnected pcb just for
receiving on all ports and another connected one for sending.
Thank you for making a great product,
Brian Lam
UC Berkeley
- [lwip-users] Issue with udp_input() and source ports,
Brian Lam <=