Hi
until here everything is OK, except that the send-function should
return the
number of bytes which are sent, but the value is always too large
for three.
so it returns less than what we wrote?
No msg->len and ret are equal. I think it was my fault. I had count the bytes manually. For example:
<001b> ipaccess.c:512 TX 2: 03 01 01 28 02 03 0b 00 02 49 04 <001b> ipaccess.c:514 msg->len 14 <001b> ipaccess.c:520 bfd->fd: 12 <001b> ipaccess.c:521 ret: 14
On line 512 i count manually 15 bytes, but the msg->len and ret value is 18. I think this is OK, than the bytes on line 512 doesn't contain the IPA protocol bytes. I could verify this on wireshark. There are 3 bytes more for the IPA header (00 0b 00). So i would say that i've misinterpreted that. On line 510 the function ipaccess_prepend_header is called and therefore i thought that the bytes for the header is included at the output. I didn't concerned that only the msg->l2h is printed.
You can set a delay timer to not things as fast as possible and
probably get IPA packets into different IP packets.
Unfortunately this doesn't solve the problem.
this is valid behavior (and you see it during RSL/OML bring up), one
thing how
Ok. If this is a valid behavior, maybe i'm on the wrong track. Therefore i don't know how to investigate the problem further.
this can break (and would break OpenBSC/libosmo-abis) is that we do:
1.) ipa_header = recv(3 bytes) 2.) data = recv(ipa_header->len)
this would fail in case header and data do not appear on the same
frame. So
the esoteric question is do you have MTU changes in your network
(this assumes
that the ipaccess would have similar broken code we have)?
No the standard MTU (1500 Bytes) is set. Even if i connect it directly on my pc via a switch the problem occurs. My abis pcap file was created this way.
Best regards Dennis Wehrle