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