lwip-users
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]