IP Fragmented IP protocol (proto=UDP 0x11, off=0) insecure

Asterisk Asterisk Support
1

We are experiencing problem about a sip trunk.

Infact when we receive a call from the trunk we get this log:.
9119.901426 195.60.190.51 -> 93.88.110.8 IP Fragmented IP protocol (proto=UDP 0x11, off=0)
9119.946352 93.88.110.8 -> 195.60.190.51 SIP Status: 407 Proxy Authentication Required
9119.946413 195.60.190.51 -> 93.88.110.8 SIP Request: ACK sip:08281962108@93.88.110.8

of course we use “insecure = invite” inside the sip trunk configuratio.
But seems that the fragmented invite is not well recognized and so it is not allowed.

The other invite (not fragmented) from other trunk are allowed.

How can i workourd this?

regards
Rosario

2

Fragmentation is an OS issue, and you haven’t told us what that is.

The OS should re-assemble the fragments, and Asterisk should not know they were ever fragmented.

Incidentally, your trace is incomplete, as it is only showing the first fragment. The packet should not be delivered to the application if a fragment is missing.

3

the os is this:

Linux asterisk1 2.6.18 #1 PREEMPT Mon Aug 4 14:26:18 GMT 2008 i586

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

\ / /___ __ __ ___ ___ ___ Useful Commands:
\ // _ \ / /,-_ |/ _ |/ -_) remountrw - mount disk as read-write
/ _/ \ / _,_ |___| remountro - mount disk as read-only
// '| remove.docs - remove all docs and manpages
{ V o y a g e } - L i n u x
< linux.voyage.hk > Version: 0.5 (Build Date 20080629)

the log is from tethereal.
without any packet missing.

regards
Rosario

4

If there is no packet missing, the sender’s IP stack is broken. If you have a fragmented packet, there should be multiple packets. A low level packet sniffer will see the individual fragments, and typically won’t be able to reassemble them itself.

5

i think it is not any misisng, because anything else is working fine,
may be only the short reprot from tethereal is mising the entire packet flow.

What can i do to let asterisk accept every packet from this trunk, and not only invite?

regards

6

this is the log from asterik.
It is getting a correct INVIte, so the OS is repackging the packets correctly.
But asterisk fails to trust the invite.

Any help is welcome…

IP Debugging enabled
asterisk1*CLI>
<— SIP read from PROXYIP:5060 —>
INVITE sip:08281962108@ASTERISKIP SIP/2.0
Record-Route: sip:08281962108@DOMAIN.IT:5060;ftag=482ca6774420ddeo0;lr=on
Via: SIP/2.0/UDP PROXYIP;branch=z9hG4bKf5d6.c898cc04.0
Via: SIP/2.0/UDP PHOINEIP:5060;rport=5060;branch=z9hG4bK-648148c2
From: 08281962102 sip:08281962102@DOMAIN.IT;tag=482ca6774420ddeo0
To: sip:08281962108@DOMAIN.IT
Remote-Party-ID: 08281962102 sip:08281962102@DOMAIN.IT;screen=yes;party=calling
Call-ID: 5410112b-d34c82ba@PHOINEIP
CSeq: 102 INVITE
Max-Forwards: 69
Proxy-Authorization: Digest username=“08281962102”,realm=“DOMAIN.IT”,nonce=“49bfafdb1514a4009c13be2ab85b46e6d641516b”,uri="sip:08281962108@DOMAIN.IT",algorithm=MD5,response="bce5965eb9808a40d9c808b3b1249b6f"
Contact: 08281962102 sip:08281962102@PHOINEIP:5060
Expires: 240
User-Agent: Linksys/SPA2102-5.2.5
Content-Length: 443
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp

v=0
o=- 28157802 28157802 IN IP4 PHOINEIP
s=-
c=IN IP4 PHOINEIP
t=0 0
m=audio 19536 RTP/AVP 8 18 0 2 4 96 97 98 100 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
<------------->
— (18 headers 20 lines) —
Sending to PROXYIP : 5060 (no NAT)
Using INVITE request as basis request - 5410112b-d34c82ba@PHOINEIP

<— Reliably Transmitting (no NAT) to PROXYIP:5060 —>
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP PROXYIP;branch=z9hG4bKf5d6.c898cc04.0;received=PROXYIP
Via: SIP/2.0/UDP PHOINEIP:5060;rport=5060;branch=z9hG4bK-648148c2
From: 08281962102 sip:08281962102@DOMAIN.IT;tag=482ca6774420ddeo0
To: sip:08281962108@DOMAIN.IT;tag=as109df772
Call-ID: 5410112b-d34c82ba@PHOINEIP
CSeq: 102 INVITE
User-Agent: ConvAsterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm=“convasterisk”, nonce="787e7744"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘5410112b-d34c82ba@PHOINEIP’ in 32000 ms (Method: INVITE)
Found user ‘08281962102’

<— SIP read from PROXYIP:5060 —>
ACK sip:08281962108@ASTERISKIP SIP/2.0
Via: SIP/2.0/UDP PROXYIP;branch=z9hG4bKf5d6.c898cc04.0
From: 08281962102 sip:08281962102@DOMAIN.IT;tag=482ca6774420ddeo0
Call-ID: 5410112b-d34c82ba@PHOINEIP
To: sip:08281962108@DOMAIN.IT;tag=as109df772
CSeq: 102 ACK
User-Agent: OpenSER (1.2.3-notls (i386/linux))
Content-Length: 0

<------------->
— (8 headers 0 lines) —

7

Asterisk has told the proxy that its authentication credentials are not valid and is asking it to supply correct ones. The proxy should have retried, but maybe gave up because it was sure they were right first time (but as this is Digest authentication, I don’t think that would be a safe assumption).

Either the packet wasn’t really fragmented, or it has been reassembled, but the network trace tool has only shown the initial fragment.

8

the trnunk has:
insecure=invite

so asterisk should not check any credentials like it does with all other invite that are not fragmented.

regards

9

Asterisk doesn’t know there is fragmentation.

It is conceivable that it has been confused because the INVITE has attempted to authenticate. If so that might be a bug. See if you can get another vote for a bug, then raise it on bugs.digium.com. (I haven’t looked closely at authentication, it is possible that it is not possible to distinguish between invalid credentials and credentials for another proxy, in which case you would have to disable authentication for the register.)

Again, I believe the fragmentation is a red herring.

10

I had a quick look at the code and insecure=invite will turn off authentication even if authorization data is in the request, so either the insecure=invite has been entered wrongly, or the incoming packet is not selecting the right user entry.

11

Actually, I should have asked you which version you are using. 1.6 and trunk use 401 rather than 407, but I only checked the SVN tip version of 1.4 (which uses 407), with a quick scan of the change history. If you are using 1.2 or an early 1.4, please retry on a recent 1.4 or 1.6 version.

Unfortunately, the UserAgent header has been over-ridden.