hi,
1) thanx for that info. i can see that you tried running it...
2) i have not checked it. i hope that msg->l3h points to l2 pseudo header.
3) before fixing that, i need to have an issue solved:
two approaches to free a message, if it passes a layer border?
a) the sending layer frees the message after calling the other layer. b) the receiving layer frees the message.
i prefer the second approach, because the message can be queued by the receiving layer without duplicating it. but if i read lapdm.c, i cannot figure out what approach is ment to be used:
- rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll(). - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown.
this issue must be solved soon, i think.
thanx for looking at it,
andreas
-----Ursprüngliche Nachricht----- Von: Sylvain Munaut [mailto:246tnt@gmail.com] Gesendet: Montag, 26. April 2010 15:22 An: Andreas.Eversberg Cc: baseband-devel@lists.osmocom.org Betreff: Re: Layer 3 status
Hi,
i will start testing it tonight and hope to get results soon.
Here's a few bug reports
Sorry, there are no 'proper' fix or patches for them, I just worked around them with ugly hacks see if I could get up to LOCATION UPDATE REQUEST, then it was kinda late ... I hope just pointing them out will help you a bit anyway.
1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn
/* if no PLMN in list */ - if (plmn_first) { + if (!plmn_first) {
2) BCCH message don't have the same header.
See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind
struct gsm48_hdr *gh = msgb_l3(msg);
But in BCCH some message don't have this header and have a 'L2 pseudo length' field ...
3) You do a msgb_free on messages in , but the layer 1 will actually have freed those message already.
See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd)
l1ctl_recv((struct osmocom_ms *) fd->data, msg); msgb_free(msg); // <======
Sylvain