Le dimanche 14 novembre 2010 Ã 10:33 -0800, Kevin Cernekee a Ãcrit : > On Sun, Nov 14, 2010 at 12:59 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > > I would like to get an exact SIP exchange to make sure their is not > > another way to handle this without adding a "Cisco" string somewhere... > > > > Please provide a pcap or tcpdump -A > > Existing nf_nat_sip: phone sends unauthenticated REGISTER requests > over and over again, because it is not seeing the replies sent back to > port 50070: > > 10:05:53.496479 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723 > E`...[..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0 > Via: SIP/2.0/ > Hmm, partial tcpdump... you should use" tcpdump -s 1000 -A" We miss the Via: SIP/2.0/UDP 192.168.2.28:5060;branch=xxxxxxxx Maybe a fix would be to use this "5060" port, instead of hardcoding it like you did ? > > Patched nf_nat_sip: router sends the replies back to port 5060, so the > phone is now able to register itself and make calls: > > 10:09:46.221631 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 723 > E`...G..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0 > Via: SIP/2.0/ > > 10:09:46.253052 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491 > E....+..4..$C...............SIP/2.0 100 Trying > Via: SIP/2.0/UDP 192.168.2.28:5060 > > 10:09:46.253472 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 550 > E..B.,..4...C...............SIP/2.0 401 Unauthorized > Via: SIP/2.0/UDP 192.168.2.2 > > 10:09:46.261602 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 900 > E`...H..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0 > Via: SIP/2.0/ > > 10:09:46.290211 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491 > E....-..4.."C...............SIP/2.0 100 Trying > Via: SIP/2.0/UDP 192.168.2.28:5060 > > 10:09:46.295041 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 579 > E.._....4...C............K..SIP/2.0 200 OK > Via: SIP/2.0/UDP 192.168.2.28:5060;bra > > > BTW, I thought of two possible issues with the original patch: > > 1) Might need to call skb_make_writable() prior to modifying the > packet. Presumably the second invocation inside > nf_nat_mangle_udp_packet() will have no effect. > > (Is there a cleaner way to mangle just the port number? Most of the > utility functions only help with modifying the data area.) > > 2) I should probably be checking to make sure request == 0 before > mangling the packet. The current behavior is harmless if the SIP > proxy is on port 5060, but that might not always be the case. > > I can roll these, along with any other suggestions, into v2. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
