Thank you for your help and sorry for my english. I have a problem with mipv6 and a server SIP, SER (SIP Express Router). The mipv6 path is "mipv6-2.0.2" in kernel 2.6.16.24-Ubuntu.
The problem occurs when a packet is too big (it must be fragmented), and go to the node what makes function of P-CSCF (Proxy in SIP) and Correspondent Node. If the P-CSCF is not a CN, all is OK. But if the node is CN, then i have the problem. The SER logs are:
................ Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: SER: new INVITE Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: parse_headers: flags=-1 Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: check_via_address(2001:720:1500:1B:FCFD:FF:FE0C:103, [2001:720:1500:1B:FCFD:FF:FE0C:103], 3) Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: ERROR: warning_builder: buffer size exceeded Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: WARNING: warning skipped -- too big Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: WARNING:vqm_resize: resize(0) called Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: DEBUG: reply sent out. buf=0x8106270: SIP/2.0 1..., shmem=0xb5e8b330: SIP/2.0 1 Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: DEBUG: _reply_light: finished Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: DEBUG: mk_proxy: doing DNS lookup... Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: check_via_address(2001:720:1500:1B:FCFD:FF:FE0C:103, [2001:720:1500:1B:FCFD:FF:FE0C:103], 3) Nov 20 18:28:25 pcscfD /usr/sbin/ser[8068]: DBG: tcp_main_loop: dead child 2 (shutting down?) Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: child process 8051 exited by a signal 11 Nov 20 18:28:25 pcscfD kernel: [4296472.851000] <0>skb_under_panic: text:c02d2aad len:321 put:14 head:d62cfc00 data:d62cfbea tail:d62cfd2b end:d62cfd80 dev:eth0 Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: core was not generated Nov 20 18:28:25 pcscfD kernel: [4297162.639000] ------------[ cut here ]------------ Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: INFO: terminating due to SIGCHLD Nov 20 18:28:25 pcscfD kernel: [4297162.639000] kernel BUG at net/core/skbuff.c:112! Nov 20 18:28:25 pcscfD /usr/sbin/ser[8059]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8052]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8053]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8054]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8055]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8056]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8057]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8058]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8060]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8061]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8062]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8063]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8064]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8065]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8066]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8067]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8068]: INFO: signal 15 received Nov 20 18:28:25 pcscfD /usr/sbin/ser[8050]: INFO: signal 15 received Nov 20 18:28:25 pcscfD kernel: [4297162.639000] invalid opcode: 0000 [#3] Nov 20 18:28:25 pcscfD /usr/sbin/ser[8059]: Memory status (pkg): Nov 20 18:28:25 pcscfD /usr/sbin/ser[8052]: Memory status (pkg): Nov 20 18:28:25 pcscfD /usr/sbin/ser[8053]: Memory status (pkg): Nov 20 18:28:25 pcscfD /usr/sbin/ser[8054]: Memory status (pkg): Nov 20 18:28:25 pcscfD /usr/sbin/ser[8055]: Memory status (pkg): Nov 20 18:28:25 pcscfD /usr/sbin/ser[8056]: Memory status (pkg): ....................... Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: hash = 2055 fragments no.: 1, unused: 0 ^I^I bucket size: 1048576 - 2097152 (first 1572864) Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: hash = 2059 fragments no.: 1, unused: 0 ^I^I bucket size: 16777216 - 33554432 (first 31934160) Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: TOTAL: 26 free fragments = 33537656 free bytes Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: ----------------------------- Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: shm_mem_destroy Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: destroying the shared memory lock Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: terminating due to SIGCHLD ############################################################## The problem is in the MTU size, because if the packet is not fragmented, there is not a problem. But the INVITE packet needs to fragment, what it means, i always have the same problem.
My questions are:
- Have anybody the same o similar problem? - The MTU size is a problem in SER? - Have anybody sent fragmented packets with SER?
Thanks for your help.
______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
On Nov 23, 2006 at 10:11, Jose Angel Calvo jacc15dkz@yahoo.es wrote:
Thank you for your help and sorry for my english. I have a problem with mipv6 and a server SIP, SER (SIP Express Router). The mipv6 path is "mipv6-2.0.2" in kernel 2.6.16.24-Ubuntu.
The problem occurs when a packet is too big (it must be fragmented), and go to the node what makes function of P-CSCF (Proxy in SIP) and Correspondent Node. If the P-CSCF is not a CN, all is OK. But if the node is CN, then i have the problem. The SER logs are:
[...]
The problem is in the MTU size, because if the packet is not fragmented, there is not a problem. But the INVITE packet needs to fragment, what it means, i always have the same problem.
My questions are:
- Have anybody the same o similar problem?
Nobody that I know of :-)
- The MTU size is a problem in SER?
No, there shouldn't be (there is no place where we look at the MTU).
- Have anybody sent fragmented packets with SER?
Yes, and it works.
Could you give more details? - what version of ser are you running (ser -V)? - is it vanilla ser or a modified version? - the packet is sent over TCP? UDP? - a coredump backtrace? (for this you'll have to start ser with -w directory_where_core_can_be_written, e.g. ser -f ser.cfg -w /tmp/) After the crash, run gdb path_to_ser/ser /tmp/core, type bt and send me the output. Note: the core file might have another name (e.g. core.3456). Just look for core.* .
Andrei