From baccenfutter at c-base.org  Sun Dec  4 17:32:25 2011
From: baccenfutter at c-base.org (Brian Wiborg)
Date: Sun, 4 Dec 2011 18:32:25 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
Message-ID: <20111204173225.GU637@shell.c-base.org>

On 25/11/11 09:15 +0100, Harald Welte wrote:
> If it is in Berlin, we might consider talking with c-base or
> Raumfahrtagentur as possible venues.
> 

c-base would be happy to host a OsmocomBB Hackathon. If you have no prefered
contact at c-base, you can very likely get in touch with me. Osmocom has a lot
of friends in near space orbit.

baccenfutter
o7



From laforge at gnumonks.org  Sun Dec  4 21:04:52 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 4 Dec 2011 22:04:52 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111204173225.GU637@shell.c-base.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
	<20111204173225.GU637@shell.c-base.org>
Message-ID: <20111204210452.GB28966@prithivi.gnumonks.org>

Hi Brian,

On Sun, Dec 04, 2011 at 06:32:25PM +0100, Brian Wiborg wrote:

> c-base would be happy to host a OsmocomBB Hackathon. If you have no prefered
> contact at c-base, you can very likely get in touch with me. Osmocom has a lot
> of friends in near space orbit.

thanks, I've already been in contact with the c-base "CultOrga".  Right
now we first need to settle on a date and then discuss our target date
with C-base.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sun Dec  4 21:14:04 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 4 Dec 2011 22:14:04 +0100
Subject: RFC: Osmocom developer workshop 2012
Message-ID: <20111204211404.GC28966@prithivi.gnumonks.org>

Hi!

Thinking a bit more about timing, it seems that the second half of March
is a good idea.

April is a bad idea, at least for the first two weeks, as this is easter
holiday time in a lot of German states.  This will cause lots of
tourists, as well as full hotels, trains, flights, etc.

So I'd propose something like four days in the second half of march.
Should we try to overlap/extend a weekend?  I guess this would help
people with e regular dayjob, as not as many holidays would be required.

If there are no objections in the next 48 hours, I will talk to C-Base
about availability during that timeframe.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From 246tnt at gmail.com  Sun Dec  4 21:47:41 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 4 Dec 2011 22:47:41 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111204211404.GC28966@prithivi.gnumonks.org>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
Message-ID: <CAHL+j09hcp3zeN_YfsKwkHTC0X0E29HWk7pmb-=kpsugTK25vg@mail.gmail.com>

Hi,

> So I'd propose something like four days in the second half of march.
> Should we try to overlap/extend a weekend? ?I guess this would help
> people with e regular dayjob, as not as many holidays would be required.

Yes, over the weekend would be nice I think.

So this makes it 18-21 March or 25-28 March.

> If there are no objections in the next 48 hours, I will talk to C-Base
> about availability during that timeframe.

Cheers,

    Sylvain



From 246tnt at gmail.com  Sun Dec  4 22:03:45 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 4 Dec 2011 23:03:45 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <CAHL+j09hcp3zeN_YfsKwkHTC0X0E29HWk7pmb-=kpsugTK25vg@mail.gmail.com>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
	<CAHL+j09hcp3zeN_YfsKwkHTC0X0E29HWk7pmb-=kpsugTK25vg@mail.gmail.com>
Message-ID: <CAHL+j09M8-oooxUknbjXZ7fHEGX+7QDekbYjzhnfDGmQvidzUw@mail.gmail.com>

> So this makes it 18-21 March or 25-28 March.

Well, as usual I didn't miss the opportunity of making a fool of
myself by using the 2011 calendar ... (thanks steve for pointing this
out)

So make this 16-19 | 23-26 then.

Cheers,

    Sylvain



From roh at hyte.de  Mon Dec  5 00:27:30 2011
From: roh at hyte.de (Joachim Steiger)
Date: Mon, 05 Dec 2011 01:27:30 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111204211404.GC28966@prithivi.gnumonks.org>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
Message-ID: <4EDC0FF2.5000506@hyte.de>

Harald Welte wrote:
> Hi!
> 
> Thinking a bit more about timing, it seems that the second half of March
> is a good idea.

> So I'd propose something like four days in the second half of march.
> Should we try to overlap/extend a weekend?  I guess this would help
> people with e regular dayjob, as not as many holidays would be required.
> 
> If there are no objections in the next 48 hours, I will talk to C-Base
> about availability during that timeframe.

since there are not that many participants listed in the wiki and after
talking to my fellow hackers here at raumfahrtagentur i can state that
we would be happy to host the developer meeting in our location.

we haven't yet planned any events in 2012, so there should be no other
event blocking certain dates.

greetings

--

roh




From laforge at gnumonks.org  Mon Dec  5 04:20:56 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 5 Dec 2011 05:20:56 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <4EDC0FF2.5000506@hyte.de>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
	<4EDC0FF2.5000506@hyte.de>
Message-ID: <20111205042056.GG28966@prithivi.gnumonks.org>

Hi roh,

On Mon, Dec 05, 2011 at 01:27:30AM +0100, Joachim Steiger wrote:
> Harald Welte wrote:
> > Hi!
> > 
> > Thinking a bit more about timing, it seems that the second half of March
> > is a good idea.
> 
> > So I'd propose something like four days in the second half of march.
> > Should we try to overlap/extend a weekend?  I guess this would help
> > people with e regular dayjob, as not as many holidays would be required.
> > 
> > If there are no objections in the next 48 hours, I will talk to C-Base
> > about availability during that timeframe.
> 
> since there are not that many participants listed in the wiki and after
> talking to my fellow hackers here at raumfahrtagentur i can state that
> we would be happy to host the developer meeting in our location.

thanks a lot for bringing this up.

However, I wouldn't use the wiki as a reference.  Given that we are > 10
people at 28C3, I would also suspect something like 10 to 15 (max)
people at the OsmoDevCon.

Without any offence, I also think that c-base is easier to reach, more
centrally located [some people may want to go out at night], and might
have better facilities in terms of a separate 'conference room' style
setup.

Having said that, I don't want to rule out Raumfahrtagentur yet.  Those
are just my initial thoughts.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Wed Dec 14 15:50:54 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2011 16:50:54 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
Message-ID: <20111214155054.GC27642@prithivi.gnumonks.org>

Hi all,

just a quick status update: I've spoken with the c-base event crew and
it is looking good.  Time-wise our intended schedule is not a problem on
the two proposed dates in late March.

I've also seen their meeting room, and it is more or less about the same
size as the room that we've had at 27C3 last year.  They have plenty of
tables, chairs, free wifi and a very decent projector + screen.

Anything else (power outlets, nanoBTS, phones, cables, measurement
equipment, etc) we'll bring ourselves.

The only remaining issue is that somebody of their 'core team' has to be
present all-day on Friday and Monday - which is not normally the case
on regular working days.

I'll be there again tonight to their internal meeting and see if we can
find some volunteer or convince them to entrust me with keys ;)

I'll report back once the date is finalized.  Please wait until then
before booking your travel and/or accomodation.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Wed Dec 14 21:52:03 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2011 22:52:03 +0100
Subject: UPDATE: Osmocom developer workshop 2012
In-Reply-To: <20111214155054.GC27642@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
	<20111214155054.GC27642@prithivi.gnumonks.org>
Message-ID: <20111214215203.GA4696@prithivi.gnumonks.org>

Hi all,

On Wed, Dec 14, 2011 at 04:50:54PM +0100, Harald Welte wrote:

> I'll be there again tonight to their internal meeting and see if we can
> find some volunteer or convince them to entrust me with keys ;)

the c-base "circle" has decided to endorse our workshop, with 5:0 votes
for it.

> I'll report back once the date is finalized.  Please wait until then
> before booking your travel and/or accomodation.

The date has been settled: March 23rd through 26th.  The room will be
available to us between 10am and 1am daily.

I've added some very basic information regarding the venue and travel to
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2012

I'll also added a section to the page where people intending to attend
should register themselves before December 24, 2011.  This way we can
review the applications and approve attendance for those registered.

I personally would be curious to hear about the following candidates:
 * Peter Stuge
 * Dieter Spaar
 * Christian Vogel
 * Steve-M
 * Marcin

Of course there are Berlin locals like Kevin, roh, Tobias Engel, dexter,
nico, etc.  who could join us at least partially for some hours in order
to discuss their respective "special interest" topics like SIMtrace v2,
OpenBSC API for external processes.

Also, getting Christian Daniel (of the upcoming OsmoSDR) here at least
over the weekend would be great.

If the list gets too long and the group gets too big, it might be
possible to at least temporarily occupy some other room at c-base, too -
or to split into working groups where one of them might e.g. do a TETRA
session at CCC Berlin, where the TETRA EBTS is located.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sat Dec 24 22:40:51 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 24 Dec 2011 23:40:51 +0100
Subject: UPDATE: Osmocom developer workshop 2012
In-Reply-To: <20111214215203.GA4696@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
	<20111214155054.GC27642@prithivi.gnumonks.org>
	<20111214215203.GA4696@prithivi.gnumonks.org>
Message-ID: <20111224224051.GF26984@prithivi.gnumonks.org>

Hi all,

On Wed, Dec 14, 2011 at 10:52:03PM +0100, Harald Welte wrote:

> I've added some very basic information regarding the venue and travel to
> http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2012
> 
> I'll also added a section to the page where people intending to attend
> should register themselves before December 24, 2011.  This way we can
> review the applications and approve attendance for those registered.

December 24 already arrived, and the list on the page is:

laforge zecke jolly tnt dieter? pablo ahuemer dburgess00 horizon khorben? vogelchr

This means there are 11 names, which is definitely ok given the amount
of space we have and the size of the event I had in mind.

I actually added Dieter with ? as I wasn't sure but was hoping he would
attend (and I think he mentioned that on the phone at some point).  What
about khorben?  You must have put that question mark there
delieberately..

As the benevolent Osmocom dictator, I am hereby accepting all those 11
registrations ;)   This means that those 11 people can start to make
travel arrangements.

I would still love to see Piotr participate, as I hope to get moving
forward regarding MTK in 2012.  But anyway, it's of course up to us to
finally start to use his code...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From peter at stuge.se  Sat Dec 24 22:54:00 2011
From: peter at stuge.se (Peter Stuge)
Date: Sat, 24 Dec 2011 23:54:00 +0100
Subject: UPDATE: Osmocom developer workshop 2012
In-Reply-To: <20111224224051.GF26984@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
	<20111214155054.GC27642@prithivi.gnumonks.org>
	<20111214215203.GA4696@prithivi.gnumonks.org>
	<20111224224051.GF26984@prithivi.gnumonks.org>
Message-ID: <20111224225400.29229.qmail@stuge.se>

Harald Welte wrote:
> > I'll also added a section to the page where people intending to attend
> > should register themselves before December 24, 2011.

Oops.


> December 24 already arrived, and the list on the page is:
> 
> laforge zecke jolly tnt dieter? pablo ahuemer dburgess00 horizon
> khorben? vogelchr

I'd like to be there too.


> Dieter with ?
> khorben?
> Piotr

I hope they can all be there.


//Peter



From alexander.chemeris at gmail.com  Mon Dec 26 04:28:37 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 26 Dec 2011 07:28:37 +0300
Subject: UPDATE: Osmocom developer workshop 2012
In-Reply-To: <20111214215203.GA4696@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
	<20111214155054.GC27642@prithivi.gnumonks.org>
	<20111214215203.GA4696@prithivi.gnumonks.org>
Message-ID: <CABmJbFXQkn08b0Wv_gVv8+hdqPwSjxdcgNh4E3GzXwWofKpw2A@mail.gmail.com>

Hi Harald,

On Thu, Dec 15, 2011 at 01:52, Harald Welte <laforge at gnumonks.org> wrote:
> I'll also added a section to the page where people intending to attend
> should register themselves before December 24, 2011. ?This way we can
> review the applications and approve attendance for those registered.

I should read this mailing list more often then once in two months. :(
Is it still possible to sign for the participation? Probably Ivan with
his GPRS work will be interested as well.


-- 
Regards,
Alexander Chemeris.



From laforge at gnumonks.org  Wed Dec 14 21:53:54 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2011 22:53:54 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
Message-ID: <20111214215354.GB4696@prithivi.gnumonks.org>

Hi all,

following up my original mail:

On Fri, Nov 25, 2011 at 09:15:20AM +0100, Harald Welte wrote:
> 	I'd like to have a Osmocom developer workshop

I'd like to follow-up with one more posting to all our mailing lists:

The remaining discussion is happening at the openbsc at lists.osmocom.org
list, and it is not cross-posted to all other lists.

We've meanwhile settled on a date (March 23rd through 26th) and a venue
in Berlin.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Thu Dec  1 07:47:42 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 1 Dec 2011 08:47:42 +0100
Subject: Time in MM Info [patch]
In-Reply-To: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
References: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
Message-ID: <20111201074742.GY16931@prithivi.gnumonks.org>

Hi Gus,

On Wed, Nov 30, 2011 at 03:13:04PM -0800, Gus Bourg wrote:
> Attached is a patch to support sending time to the device.

thanks a lot for the patch.

however, some remarks:

1) We actually do support ranges with negative numbers in the syntax,
   after commit 33f0fc3c9565308044c934c9e0c1bb81c1a26311 in libosmocore
   you can do something like "timezone <-19-19> (0|15|30|45)"
   which I believe would be a more human-friendly way of entering it in
   hours and minutes.

2) the internal storage could thus also be a simple "int timezone",
   which gets filled from the hour and minute part of the abovementioned
   command syntax.

3) please make sure to use a default of "cur_time->tm_gmtoff" in case
   the config file doesn't use per-BTS timezones.  So another "int
   timezone_bts_specific" member might be applicable.

4) please make sure to use tab instead of "        " (sequence of 8
   whitespaces), or use a script that automatically takes care of that.

5) the "timezone" vty line should only be printed if the user actually
   configured it (i.e. timezone_bts_specific == 1).

6) there needs to be a way to completely remove the timezone statement,
   most likely a "no timezone" VTY command in the BTS node.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From gus at bourg.net  Thu Dec  1 20:25:39 2011
From: gus at bourg.net (Gus Bourg)
Date: Thu, 1 Dec 2011 12:25:39 -0800
Subject: Time in MM Info [patch]
In-Reply-To: <20111201074742.GY16931@prithivi.gnumonks.org>
References: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
	<20111201074742.GY16931@prithivi.gnumonks.org>
Message-ID: <CAKL=SEo2FJQcVZ+eGPHwKx0PO=6PhB9wWMyni2ELAcnMpKpsbQ@mail.gmail.com>

Hi Harald,

Thanks for the input.  Here's the updated patch.

Gus

On Wed, Nov 30, 2011 at 11:47 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Gus,
>
> On Wed, Nov 30, 2011 at 03:13:04PM -0800, Gus Bourg wrote:
>> Attached is a patch to support sending time to the device.
>
> thanks a lot for the patch.
>
> however, some remarks:
>
> 1) We actually do support ranges with negative numbers in the syntax,
> ? after commit 33f0fc3c9565308044c934c9e0c1bb81c1a26311 in libosmocore
> ? you can do something like "timezone <-19-19> (0|15|30|45)"
> ? which I believe would be a more human-friendly way of entering it in
> ? hours and minutes.
>
> 2) the internal storage could thus also be a simple "int timezone",
> ? which gets filled from the hour and minute part of the abovementioned
> ? command syntax.
>
> 3) please make sure to use a default of "cur_time->tm_gmtoff" in case
> ? the config file doesn't use per-BTS timezones. ?So another "int
> ? timezone_bts_specific" member might be applicable.
>
> 4) please make sure to use tab instead of " ? ? ? ?" (sequence of 8
> ? whitespaces), or use a script that automatically takes care of that.
>
> 5) the "timezone" vty line should only be printed if the user actually
> ? configured it (i.e. timezone_bts_specific == 1).
>
> 6) there needs to be a way to completely remove the timezone statement,
> ? most likely a "no timezone" VTY command in the BTS node.
>
> Regards,
> ? ? ? ?Harald
>
> --
> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time_happy_3.diff
Type: text/x-diff
Size: 5041 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111201/60c3ccd1/attachment.bin>

From gus at bourg.net  Thu Dec  1 23:25:06 2011
From: gus at bourg.net (Gus Bourg)
Date: Thu, 1 Dec 2011 15:25:06 -0800
Subject: Time in MM Info [patch]
In-Reply-To: <CAKL=SEo2FJQcVZ+eGPHwKx0PO=6PhB9wWMyni2ELAcnMpKpsbQ@mail.gmail.com>
References: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
	<20111201074742.GY16931@prithivi.gnumonks.org>
	<CAKL=SEo2FJQcVZ+eGPHwKx0PO=6PhB9wWMyni2ELAcnMpKpsbQ@mail.gmail.com>
Message-ID: <CAKL=SEp1+xC2p3dH7fdevdFjsT+ROr2fHqSsJS4uPNW-qtaC5Q@mail.gmail.com>

Apologize for so many replies.  Found another bug.  I think I have it
actually right this time.  Previously fractional hours were not set
right, and the calculation for the timezone offset was all wrong when
when the timezone wasn't set.

Thanks,
Gus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProperTime.diff
Type: text/x-diff
Size: 5340 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111201/5eec3199/attachment.bin>

From laforge at gnumonks.org  Fri Dec  2 09:19:13 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 2 Dec 2011 10:19:13 +0100
Subject: Time in MM Info [patch]
In-Reply-To: <CAKL=SEp1+xC2p3dH7fdevdFjsT+ROr2fHqSsJS4uPNW-qtaC5Q@mail.gmail.com>
References: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
	<20111201074742.GY16931@prithivi.gnumonks.org>
	<CAKL=SEo2FJQcVZ+eGPHwKx0PO=6PhB9wWMyni2ELAcnMpKpsbQ@mail.gmail.com>
	<CAKL=SEp1+xC2p3dH7fdevdFjsT+ROr2fHqSsJS4uPNW-qtaC5Q@mail.gmail.com>
Message-ID: <20111202091913.GJ1007@prithivi.gnumonks.org>

Hi Gus,

On Thu, Dec 01, 2011 at 03:25:06PM -0800, Gus Bourg wrote:

> Apologize for so many replies.  Found another bug.  I think I have it
> actually right this time.  Previously fractional hours were not set
> right, and the calculation for the timezone offset was all wrong when
> when the timezone wasn't set.

thanks, patch applied.

Please keep those patches coming, we appreciate all contributions...
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From jrees at arbor.net  Thu Dec  1 15:24:55 2011
From: jrees at arbor.net (Rees, Jim)
Date: Thu, 1 Dec 2011 15:24:55 +0000
Subject: Time in MM Info [patch]
In-Reply-To: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
References: <CAKL=SEr_dZXuhpUU10o6Fad5xd9rfekTOBTp0HDKrHDDi9RaXA@mail.gmail.com>
Message-ID: <17FE85C3-C5BE-4836-A788-7E1442A444FA@arbor.net>

Why not make tzunits a signed quantity and get rid of tzdir? And why 15 minute units? I realize this is how the bts wants them, but shouldn't the config file be a bit more user-friendly?

Also it looks like the indentation is a bit messed up.


From drwegaba at gmail.com  Fri Dec  2 06:41:29 2011
From: drwegaba at gmail.com (Dick Rwegaba)
Date: Fri, 2 Dec 2011 09:41:29 +0300
Subject: error at execution of autoreconf -i
Message-ID: <CAEO9OAfnoMUBCfUiJq-Q2GDzRVyn4SUKJ5FcmNsg3t4MkOp8pg@mail.gmail.com>

can some one help me with a work around?
root at debian:~/libosmocore# autoreconf -i
Can't exec "aclocal": No such file or directory at
/usr/share/autoconf/Autom4te/FileUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111202/34d0c7af/attachment.htm>

From alexander.huemer at xx.vu  Fri Dec  2 07:19:55 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Fri, 2 Dec 2011 08:19:55 +0100
Subject: error at execution of autoreconf -i
In-Reply-To: <CAEO9OAfnoMUBCfUiJq-Q2GDzRVyn4SUKJ5FcmNsg3t4MkOp8pg@mail.gmail.com>
References: <CAEO9OAfnoMUBCfUiJq-Q2GDzRVyn4SUKJ5FcmNsg3t4MkOp8pg@mail.gmail.com>
Message-ID: <20111202071955.GA3573@de.xx.vu>

On Fri, Dec 02, 2011 at 09:41:29AM +0300, Dick Rwegaba wrote:
> can some one help me with a work around?
> root at debian:~/libosmocore# autoreconf -i
> Can't exec "aclocal": No such file or directory at
> /usr/share/autoconf/Autom4te/FileUtils.pm line 326.
> autoreconf: failed to run aclocal: No such file or directory
Hi Dick,

install automake.
on debian/ubuntu with:
$ sudo apt-get install automake
that is missing in [1], I'll fix that.

Kind regards,
-Alexander Huemer

[1] http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC



From drwegaba at gmail.com  Sat Dec  3 07:18:35 2011
From: drwegaba at gmail.com (Dick Rwegaba)
Date: Sat, 3 Dec 2011 10:18:35 +0300
Subject: OpenBSC Digest, Vol 36, Issue 2
In-Reply-To: <mailman.1205.1322817566.1474.openbsc@lists.osmocom.org>
References: <mailman.1205.1322817566.1474.openbsc@lists.osmocom.org>
Message-ID: <CAEO9OAf87EC9dHvBWFMKLMRx+averzhhNxUKZcY1G9z=myZsSQ@mail.gmail.com>

thanks -Alexander Huemer
 but now i get a c compiler error yet i have installed
gcc-4.4_4.4.5-8_kfreebsd-i386(1).deb and
libc0.1_2.11.2-10+b1_kfreebsd-i386.deb

checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/root/libosmocore':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details
root at debian:~/libosmocore#


On Fri, Dec 2, 2011 at 12:19 PM, <openbsc-request at lists.osmocom.org> wrote:

> Send OpenBSC mailing list submissions to
>        openbsc at lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>        openbsc-request at lists.osmocom.org
>
> You can reach the person managing the list at
>        openbsc-owner at lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
>   1. Re: Time in MM Info [patch] (Rees, Jim)
>   2. Re: Time in MM Info [patch] (Gus Bourg)
>   3. Re: Time in MM Info [patch] (Gus Bourg)
>   4. error at execution of autoreconf -i (Dick Rwegaba)
>   5. Re: error at execution of autoreconf -i (Alexander Huemer)
>   6. Re: Time in MM Info [patch] (Harald Welte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 1 Dec 2011 15:24:55 +0000
> From: "Rees, Jim" <jrees at arbor.net>
> To: Gus Bourg <gus at bourg.net>
> Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: Time in MM Info [patch]
> Message-ID: <17FE85C3-C5BE-4836-A788-7E1442A444FA at arbor.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Why not make tzunits a signed quantity and get rid of tzdir? And why 15
> minute units? I realize this is how the bts wants them, but shouldn't the
> config file be a bit more user-friendly?
>
> Also it looks like the indentation is a bit messed up.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 1 Dec 2011 12:25:39 -0800
> From: Gus Bourg <gus at bourg.net>
> To: Harald Welte <laforge at gnumonks.org>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: Time in MM Info [patch]
> Message-ID:
>        <CAKL=SEo2FJQcVZ+eGPHwKx0PO=6PhB9wWMyni2ELAcnMpKpsbQ at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Harald,
>
> Thanks for the input.  Here's the updated patch.
>
> Gus
>
> On Wed, Nov 30, 2011 at 11:47 PM, Harald Welte <laforge at gnumonks.org>
> wrote:
> > Hi Gus,
> >
> > On Wed, Nov 30, 2011 at 03:13:04PM -0800, Gus Bourg wrote:
> >> Attached is a patch to support sending time to the device.
> >
> > thanks a lot for the patch.
> >
> > however, some remarks:
> >
> > 1) We actually do support ranges with negative numbers in the syntax,
> > ? after commit 33f0fc3c9565308044c934c9e0c1bb81c1a26311 in libosmocore
> > ? you can do something like "timezone <-19-19> (0|15|30|45)"
> > ? which I believe would be a more human-friendly way of entering it in
> > ? hours and minutes.
> >
> > 2) the internal storage could thus also be a simple "int timezone",
> > ? which gets filled from the hour and minute part of the abovementioned
> > ? command syntax.
> >
> > 3) please make sure to use a default of "cur_time->tm_gmtoff" in case
> > ? the config file doesn't use per-BTS timezones. ?So another "int
> > ? timezone_bts_specific" member might be applicable.
> >
> > 4) please make sure to use tab instead of " ? ? ? ?" (sequence of 8
> > ? whitespaces), or use a script that automatically takes care of that.
> >
> > 5) the "timezone" vty line should only be printed if the user actually
> > ? configured it (i.e. timezone_bts_specific == 1).
> >
> > 6) there needs to be a way to completely remove the timezone statement,
> > ? most likely a "no timezone" VTY command in the BTS node.
> >
> > Regards,
> > ? ? ? ?Harald
> >
> > --
> > - Harald Welte <laforge at gnumonks.org> ? ? ? ? ?
> http://laforge.gnumonks.org/
> >
> ============================================================================
> > "Privacy in residential applications is a desirable marketing option."
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch.
> A6)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: time_happy_3.diff
> Type: text/x-diff
> Size: 5040 bytes
> Desc: not available
> URL: <
> http://lists.osmocom.org/pipermail/openbsc/attachments/20111201/60c3ccd1/attachment-0001.diff
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 1 Dec 2011 15:25:06 -0800
> From: Gus Bourg <gus at bourg.net>
> To: Harald Welte <laforge at gnumonks.org>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: Time in MM Info [patch]
> Message-ID:
>        <CAKL=SEp1+xC2p3dH7fdevdFjsT+ROr2fHqSsJS4uPNW-qtaC5Q at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Apologize for so many replies.  Found another bug.  I think I have it
> actually right this time.  Previously fractional hours were not set
> right, and the calculation for the timezone offset was all wrong when
> when the timezone wasn't set.
>
> Thanks,
> Gus
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ProperTime.diff
> Type: text/x-diff
> Size: 5339 bytes
> Desc: not available
> URL: <
> http://lists.osmocom.org/pipermail/openbsc/attachments/20111201/5eec3199/attachment-0001.diff
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 2 Dec 2011 09:41:29 +0300
> From: Dick Rwegaba <drwegaba at gmail.com>
> To: openbsc at lists.osmocom.org
> Subject: error at execution of autoreconf -i
> Message-ID:
>        <CAEO9OAfnoMUBCfUiJq-Q2GDzRVyn4SUKJ5FcmNsg3t4MkOp8pg at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> can some one help me with a work around?
> root at debian:~/libosmocore# autoreconf -i
> Can't exec "aclocal": No such file or directory at
> /usr/share/autoconf/Autom4te/FileUtils.pm line 326.
> autoreconf: failed to run aclocal: No such file or directory
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osmocom.org/pipermail/openbsc/attachments/20111202/34d0c7af/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Fri, 2 Dec 2011 08:19:55 +0100
> From: Alexander Huemer <alexander.huemer at xx.vu>
> To: Dick Rwegaba <drwegaba at gmail.com>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: error at execution of autoreconf -i
> Message-ID: <20111202071955.GA3573 at de.xx.vu>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Dec 02, 2011 at 09:41:29AM +0300, Dick Rwegaba wrote:
> > can some one help me with a work around?
> > root at debian:~/libosmocore# autoreconf -i
> > Can't exec "aclocal": No such file or directory at
> > /usr/share/autoconf/Autom4te/FileUtils.pm line 326.
> > autoreconf: failed to run aclocal: No such file or directory
> Hi Dick,
>
> install automake.
> on debian/ubuntu with:
> $ sudo apt-get install automake
> that is missing in [1], I'll fix that.
>
> Kind regards,
> -Alexander Huemer
>
> [1] http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 2 Dec 2011 10:19:13 +0100
> From: Harald Welte <laforge at gnumonks.org>
> To: Gus Bourg <gus at bourg.net>
> Cc: openbsc at lists.osmocom.org
> Subject: Re: Time in MM Info [patch]
> Message-ID: <20111202091913.GJ1007 at prithivi.gnumonks.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Gus,
>
> On Thu, Dec 01, 2011 at 03:25:06PM -0800, Gus Bourg wrote:
>
> > Apologize for so many replies.  Found another bug.  I think I have it
> > actually right this time.  Previously fractional hours were not set
> > right, and the calculation for the timezone offset was all wrong when
> > when the timezone wasn't set.
>
> thanks, patch applied.
>
> Please keep those patches coming, we appreciate all contributions...
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> End of OpenBSC Digest, Vol 36, Issue 2
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111203/a411bb8d/attachment.htm>

From laforge at gnumonks.org  Sat Dec  3 08:29:09 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 3 Dec 2011 09:29:09 +0100
Subject: OpenBSC Digest, Vol 36, Issue 2
In-Reply-To: <CAEO9OAf87EC9dHvBWFMKLMRx+averzhhNxUKZcY1G9z=myZsSQ@mail.gmail.com>
References: <mailman.1205.1322817566.1474.openbsc@lists.osmocom.org>
	<CAEO9OAf87EC9dHvBWFMKLMRx+averzhhNxUKZcY1G9z=myZsSQ@mail.gmail.com>
Message-ID: <20111203082909.GX1007@prithivi.gnumonks.org>

Hi Dick,

first of all, please refrain from quoting an entire list digest at the
end of your message.

And as the cofnigure script itself states:

On Sat, Dec 03, 2011 at 10:18:35AM +0300, Dick Rwegaba wrote:

> See `config.log' for more details

Have you checked config.log?  What does it say?  It would be great if
you had attached that to your message, or at least something like the
last 50 lines of config.log.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From dburgess at jcis.net  Mon Dec  5 17:27:49 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Mon, 5 Dec 2011 09:27:49 -0800
Subject: GPRS/RLC in Wireshark?
Message-ID: <CB1FEF5E-5446-4FF9-9FA3-886A9295B80D@jcis.net>

Hello -

[My apologies if this message has appeared more than once; I accidentally mailed it previously from the wrong address.]

Is there any easy way to analyze Um GPRS/RLC, encapsulated in GSMTAP at the L1/L2 boundary, in Wireshark?  I tried just putting the frames coming into L1 into GSMTAP packets, but Wireshark tries to analyze them as LAPDm.  There was nothing obvious in the GSMTAP_TYPE_* values to correspond to Um GPRS/RLC, though I admit that I have not tried other values yet.

-- David




From 246tnt at gmail.com  Mon Dec  5 18:40:23 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 5 Dec 2011 19:40:23 +0100
Subject: GPRS/RLC in Wireshark?
In-Reply-To: <CB1FEF5E-5446-4FF9-9FA3-886A9295B80D@jcis.net>
References: <CB1FEF5E-5446-4FF9-9FA3-886A9295B80D@jcis.net>
Message-ID: <CAHL+j0-ppPW4sjtJDRoDN1985Z2e62_60V0tTRVapzBU131V0g@mail.gmail.com>

> Is there any easy way to analyze Um GPRS/RLC, encapsulated in GSMTAP at the L1/L2 boundary, in Wireshark? ?I tried just putting the frames coming into L1 into GSMTAP packets, but Wireshark tries to analyze them as LAPDm. ?There was nothing obvious in the GSMTAP_TYPE_* values to correspond to Um GPRS/RLC, though I admit that I have not tried other values yet.

type = GSMTAP_TYPE_UM
sub_type = GSMTAP_CHANNEL_PACCH

Cheers,

    Sylvain



From dburgess at jcis.net  Mon Dec  5 18:45:25 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Mon, 5 Dec 2011 10:45:25 -0800
Subject: GPRS/RLC in Wireshark?
In-Reply-To: <CAHL+j0-ppPW4sjtJDRoDN1985Z2e62_60V0tTRVapzBU131V0g@mail.gmail.com>
References: <CB1FEF5E-5446-4FF9-9FA3-886A9295B80D@jcis.net>
	<CAHL+j0-ppPW4sjtJDRoDN1985Z2e62_60V0tTRVapzBU131V0g@mail.gmail.com>
Message-ID: <EB2EC4E0-62B8-4C81-86D0-2726437189A5@jcis.net>

Sylvan -

Doh!  I'll try it ASAP.  Thanks.

-- David


On Dec 5, 2011, at 10:40 AM, Sylvain Munaut wrote:

>> Is there any easy way to analyze Um GPRS/RLC, encapsulated in GSMTAP at the L1/L2 boundary, in Wireshark?  I tried just putting the frames coming into L1 into GSMTAP packets, but Wireshark tries to analyze them as LAPDm.  There was nothing obvious in the GSMTAP_TYPE_* values to correspond to Um GPRS/RLC, though I admit that I have not tried other values yet.
> 
> type = GSMTAP_TYPE_UM
> sub_type = GSMTAP_CHANNEL_PACCH
> 
> Cheers,
> 
>    Sylvain




From t-openbsc at tobias.org  Tue Dec  6 07:57:58 2011
From: t-openbsc at tobias.org (Tobias Engel)
Date: Tue, 06 Dec 2011 08:57:58 +0100
Subject: Slightly OT: NanoBTS / OpenBSC question
Message-ID: <4EDDCB06.2050406@tobias.org>

Hi,

does anybody know when the exact moment in a call is, when the NanoBTS
starts forwarding audio from a MS to OpenBSC?

Is it always when the "Create Connection" RSL message is sent and the
TCP connection was established? (Assuming the channel was set up as
traffic channel)

Or could it be that the BTS waits for the "Connect" message from the MS?

I started thinking about that when I saw that the NanoBTS _never_ sets
the "transparent to the BTS" bit in the first byte of RSL messages...

Regards,
-Tobias



From laforge at gnumonks.org  Tue Dec  6 09:43:43 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 6 Dec 2011 10:43:43 +0100
Subject: Slightly OT: NanoBTS / OpenBSC question
In-Reply-To: <4EDDCB06.2050406@tobias.org>
References: <4EDDCB06.2050406@tobias.org>
Message-ID: <20111206094343.GB28966@prithivi.gnumonks.org>

On Tue, Dec 06, 2011 at 08:57:58AM +0100, Tobias Engel wrote:
> Hi,
> 
> does anybody know when the exact moment in a call is, when the NanoBTS
> starts forwarding audio from a MS to OpenBSC?

I guess as soon as
1) a RTP stream is configured, and
2) there are actual audio speech frames received from the phone

Each frame on the TCH can be either audio or FACCH, this is
differentiated in L1 by the use of the stealing flags.  So as long as
the phone is sending FACCH frames, they go to the LAPDm implementation
in the BTS.  Once it sends voice frames, they go to the RTP socket.

The RSL CHANNEL MODE (speech) might also have an influence on it.

> Or could it be that the BTS waits for the "Connect" message from the MS?

The BTS doesn't have anythin to do with call control.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From t-openbsc at tobias.org  Tue Dec  6 10:22:41 2011
From: t-openbsc at tobias.org (Tobias Engel)
Date: Tue, 06 Dec 2011 11:22:41 +0100
Subject: Slightly OT: NanoBTS / OpenBSC question
In-Reply-To: <20111206094343.GB28966@prithivi.gnumonks.org>
References: <4EDDCB06.2050406@tobias.org>
	<20111206094343.GB28966@prithivi.gnumonks.org>
Message-ID: <4EDDECF1.1030409@tobias.org>

> I guess as soon as
> 1) a RTP stream is configured, and
> 2) there are actual audio speech frames received from the phone

Ok, thanks.

>> Or could it be that the BTS waits for the "Connect" message from the MS?
> 
> The BTS doesn't have anythin to do with call control.

Do you know why the BTS then never sets the "T"-Bit in RSL messages? Is
it just a bug in their implementation?

Regards,
-Tobias



From laforge at gnumonks.org  Tue Dec  6 11:47:59 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 6 Dec 2011 12:47:59 +0100
Subject: Slightly OT: NanoBTS / OpenBSC question
In-Reply-To: <4EDDECF1.1030409@tobias.org>
References: <4EDDCB06.2050406@tobias.org>
	<20111206094343.GB28966@prithivi.gnumonks.org>
	<4EDDECF1.1030409@tobias.org>
Message-ID: <20111206114759.GK28966@prithivi.gnumonks.org>

On Tue, Dec 06, 2011 at 11:22:41AM +0100, Tobias Engel wrote:

> Do you know why the BTS then never sets the "T"-Bit in RSL messages? Is
> it just a bug in their implementation?

I guess so.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From dburgess at jcis.net  Tue Dec  6 18:02:20 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Tue, 6 Dec 2011 10:02:20 -0800
Subject: Slightly OT: NanoBTS / OpenBSC question
In-Reply-To: <20111206094343.GB28966@prithivi.gnumonks.org>
References: <4EDDCB06.2050406@tobias.org>
	<20111206094343.GB28966@prithivi.gnumonks.org>
Message-ID: <71F4B348-A7C6-4C2E-8E08-376287BB14BA@jcis.net>


And in the general case (beyond the specific OpenBSC implementation) it's even more complicated than that, depending on the assignment type (early, late, very early) and whether or not the network uses early media for in-patterns.  (In other words, the sound of the phone ringing at the other end might come over the speech channel before the call is actually connected.)  For most purposes, the receipt of Connect Acknowledge is considered to be the start of the call, but as Harald points out, that does not happen in the BTS, which is mostly a layer-2 device.  (Unless you are using OpenBTS, which is a different matter altogether.)

On Dec 6, 2011, at 1:43 AM, Harald Welte wrote:

> On Tue, Dec 06, 2011 at 08:57:58AM +0100, Tobias Engel wrote:
>> Hi,
>> 
>> does anybody know when the exact moment in a call is, when the NanoBTS
>> starts forwarding audio from a MS to OpenBSC?
> 
> I guess as soon as
> 1) a RTP stream is configured, and
> 2) there are actual audio speech frames received from the phone
> 
> Each frame on the TCH can be either audio or FACCH, this is
> differentiated in L1 by the use of the stealing flags.  So as long as
> the phone is sending FACCH frames, they go to the LAPDm implementation
> in the BTS.  Once it sends voice frames, they go to the RTP socket.
> 
> The RSL CHANNEL MODE (speech) might also have an influence on it.
> 
>> Or could it be that the BTS waits for the "Connect" message from the MS?
> 
> The BTS doesn't have anythin to do with call control.
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)




From holger at freyther.de  Tue Dec  6 20:32:28 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 06 Dec 2011 21:32:28 +0100
Subject: RFC for VTY documentation
Message-ID: <4EDE7BDC.4050200@freyther.de>

Hi,

my goal is to generate documentation for the VTY, I had a look at quagga but
they have a manual process. Right now I have pushed zecke/vty-doc (code + xsd)
to libosmocore and a hack to osmo-bsc to invoke it...

My plan is to to merge the doc with xslt... and generate some html out of
it... For generation I can imagine a new VTY command to dump it to a file or a
cli option...

comments? feedback? volunteers to make it work and take it from here?

holger



From laforge at gnumonks.org  Wed Dec  7 01:47:29 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 7 Dec 2011 02:47:29 +0100
Subject: New tools for (U)SIM authentication
Message-ID: <20111207014729.GZ28966@prithivi.gnumonks.org>

Hi!

I've committed the following bits and pieces regarding authentication:

1) libosmocore now has a generic core for authentication algorithm
   implementations.  Using this API, even external plugins can register
   algorithms which are not available in libosmocore itself.

   libosmocore includes COMP128v1 and (now) MILENAGE

2) a small command-line program "osmo-auc-gen", which can be used to
   generate authentication vectors from the command line.  You hav to
   specify all the required parameters.  For GSM, this is only ki, but
   for 3G, you also have to specify at least OPC and SQN.

   osmo-auc-gen is part of libosmocore.git

3) a small pythong script called "osmo-sim-auth.py", available from a
   new git repository (http://cgit.osmocom.org/cgit/osmo-sim-auth,
   git://git.osmocom.org/osmo-sim-auth)

   It is the counterpart for the MS side.  It can execute authentication
   on both SIM and USIM.

I've tested the tools with a COMP128v1 SIM and a MILENAGE USIM,
it seems to be working fine.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From holger at freyther.de  Wed Dec  7 08:26:30 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 07 Dec 2011 09:26:30 +0100
Subject: New tools for (U)SIM authentication
In-Reply-To: <20111207014729.GZ28966@prithivi.gnumonks.org>
References: <20111207014729.GZ28966@prithivi.gnumonks.org>
Message-ID: <4EDF2336.1050600@freyther.de>

On 12/07/2011 02:47 AM, Harald Welte wrote:
> Hi!
> 
> I've committed the following bits and pieces regarding authentication:
> 
> 1) libosmocore now has a generic core for authentication algorithm
>    implementations.  Using this API, even external plugins can register
>    algorithms which are not available in libosmocore itself.

Morning,

this broke the build on GCC 4.2.2 (FreeBSD) and GCC 4.4.5 (Debian Stable).
Both compiler versions do not like to initialize an anonymous union with .umts
= {}. I propose to give the the union a name.

holger




From 246tnt at gmail.com  Wed Dec  7 09:10:13 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 7 Dec 2011 10:10:13 +0100
Subject: New tools for (U)SIM authentication
In-Reply-To: <20111207014729.GZ28966@prithivi.gnumonks.org>
References: <20111207014729.GZ28966@prithivi.gnumonks.org>
Message-ID: <CAHL+j09Sj8v8pMF-MyQuCad3dBLV7yey+j6LfmqKRK5dAMc7xQ@mail.gmail.com>

Hi,

> 1) libosmocore now has a generic core for authentication algorithm
> ? implementations. ?Using this API, even external plugins can register
> ? algorithms which are not available in libosmocore itself.
>
> ? libosmocore includes COMP128v1 and (now) MILENAGE

Nice !

> 3) a small pythong script called "osmo-sim-auth.py", available from a
> ? new git repository (http://cgit.osmocom.org/cgit/osmo-sim-auth,
> ? git://git.osmocom.org/osmo-sim-auth)
>
> ? It is the counterpart for the MS side. ?It can execute authentication
> ? on both SIM and USIM.

Do you really use all the card stuff you imported for something ?

I actually would have tought basing it on the sim abstraction layer of
pysim would have been simpler and would support cheap serial adapters
as well and not just pcsc ones. The api already has a run_gsm algo and
so only adding the umts one and a command line tool to call it would
have been needed.

Cheers,

    Sylvain



From laforge at gnumonks.org  Wed Dec  7 10:28:26 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 7 Dec 2011 11:28:26 +0100
Subject: New tools for (U)SIM authentication
In-Reply-To: <CAHL+j09Sj8v8pMF-MyQuCad3dBLV7yey+j6LfmqKRK5dAMc7xQ@mail.gmail.com>
References: <20111207014729.GZ28966@prithivi.gnumonks.org>
	<CAHL+j09Sj8v8pMF-MyQuCad3dBLV7yey+j6LfmqKRK5dAMc7xQ@mail.gmail.com>
Message-ID: <20111207102826.GE28966@prithivi.gnumonks.org>

Hi Sylvain,

On Wed, Dec 07, 2011 at 10:10:13AM +0100, Sylvain Munaut wrote:

> > 3) a small pythong script called "osmo-sim-auth.py", available from a
> > ? new git repository (http://cgit.osmocom.org/cgit/osmo-sim-auth,
> > ? git://git.osmocom.org/osmo-sim-auth)
> >
> > ? It is the counterpart for the MS side. ?It can execute authentication
> > ? on both SIM and USIM.
> 
> Do you really use all the card stuff you imported for something ?
> 
> I actually would have tought basing it on the sim abstraction layer of
> pysim would have been simpler and would support cheap serial adapters
> as well and not just pcsc ones. The api already has a run_gsm algo and
> so only adding the umts one and a command line tool to call it would
> have been needed.

I thoguht it was easier for me to go the other way.  No doubt
integration with pysim would have been cleaner.  The problem is that
there are too many tools.  For most of my manual/interactive work with
SIM cards and other smart cards I use cyberflex-shell from
git://github.com/henryk/cyberflex-shell.git which allows you to enter
raw APDUs on a command line and have modules for various card types that
implement card-specific features.  So the 'cleanest' implementation
would probably have been to merge all of them, but that requires time...

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From akibsayyed at gmail.com  Mon Dec 12 04:58:24 2011
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Mon, 12 Dec 2011 10:28:24 +0530
Subject: slightly off the topic
Message-ID: <CAMG-S91QY0FLChBfiG3g3n6w_WLinW9VQXsxbLqNra12VXk0ZQ@mail.gmail.com>

guys i wanted to know what gnuradio version is needed for airprobe.
i tried asking on airprobe list but dint got any repsonse.

also i tried to compile gnuradio 3.1.2 but dint worked for me.
can any one please
explain??


thanks in advance

-- 
Akib Sayyed
Matrix-Shell
akibsayyed at gmail.com
akibsayyed at matrixshell.com
Mob:- +91-966-514-2243
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111212/615a2767/attachment.htm>

From dburgess at jcis.net  Wed Dec 14 05:37:19 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Tue, 13 Dec 2011 21:37:19 -0800
Subject: omsosgsn test phone recommendation?
Message-ID: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>

Hi -

Can someone recommend a good smartphone for testing with OsmoSGSN?  We are having trouble getting our GPRS modem to recognize a ACTIVATE PDP CONTEXT ACK message and are trying to determine if the error is in the modem, in OmsoSGSN or somewhere in between.

Better yet, is there anything out there that can generate an L2 or L3 trace, like the Nokia 3310, but for GPRS as well as GSM?

-- David





From laforge at gnumonks.org  Wed Dec 14 09:36:37 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2011 10:36:37 +0100
Subject: omsosgsn test phone recommendation?
In-Reply-To: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
References: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
Message-ID: <20111214093637.GQ10252@prithivi.gnumonks.org>

Hi David,

On Tue, Dec 13, 2011 at 09:37:19PM -0800, David A. Burgess wrote:

> Can someone recommend a good smartphone for testing with OsmoSGSN?  We
> are having trouble getting our GPRS modem to recognize a ACTIVATE PDP
> CONTEXT ACK message and are trying to determine if the error is in the
> modem, in OmsoSGSN or somewhere in between.

I've successfully used at least SE K800i, Google Nexus S, Dell Streak,
HTC Hermes II, Motorola A780 here on my side.  I know some other people
have been using OsmoSGSN/OpenGGSN for iPhone related work, though I
don't know which particular model they've used.

> Better yet, is there anything out there that can generate an L2 or L3
> trace, like the Nokia 3310, but for GPRS as well as GSM?

The only ones that come to my mind are the TEMS variants of the K800i,
but those are of course hard to come by and/or expensive :/

Have you considered using Luca's work on gprsdecode?  This way you could
do an air interface trace of what's happening between BTS and MS.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From dburgess at jcis.net  Wed Dec 14 18:05:31 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Wed, 14 Dec 2011 10:05:31 -0800
Subject: omsosgsn test phone recommendation?
In-Reply-To: <20111214093637.GQ10252@prithivi.gnumonks.org>
References: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
	<20111214093637.GQ10252@prithivi.gnumonks.org>
Message-ID: <5B5B8F7E-52F7-4CE7-85D6-EA0DE7FD2F7D@jcis.net>

Harald -

Thanks for the list.  We'll try to find one of these.  I have a few iPhones sitting in front of me, but unfortunately they are all 850/1900 and my available hardware is 900. :(

Does you have an example GSMTAP/PCAP trace of a successful PDP context activation using OmsoSGSN?  That would be useful for comparison.  (And do you find the GPRS L3 & SNDCP decoding in the current Wireshark 1.7 to be reliable?)

-- David



On Dec 14, 2011, at 1:36 AM, Harald Welte wrote:

> Hi David,
> 
> On Tue, Dec 13, 2011 at 09:37:19PM -0800, David A. Burgess wrote:
> 
>> Can someone recommend a good smartphone for testing with OsmoSGSN?  We
>> are having trouble getting our GPRS modem to recognize a ACTIVATE PDP
>> CONTEXT ACK message and are trying to determine if the error is in the
>> modem, in OmsoSGSN or somewhere in between.
> 
> I've successfully used at least SE K800i, Google Nexus S, Dell Streak,
> HTC Hermes II, Motorola A780 here on my side.  I know some other people
> have been using OsmoSGSN/OpenGGSN for iPhone related work, though I
> don't know which particular model they've used.
> 
>> Better yet, is there anything out there that can generate an L2 or L3
>> trace, like the Nokia 3310, but for GPRS as well as GSM?
> 
> The only ones that come to my mind are the TEMS variants of the K800i,
> but those are of course hard to come by and/or expensive :/
> 
> Have you considered using Luca's work on gprsdecode?  This way you could
> do an air interface trace of what's happening between BTS and MS.
> 
> Regards,
> 	Harald
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)




From t-openbsc at tobias.org  Wed Dec 14 19:35:22 2011
From: t-openbsc at tobias.org (Tobias Engel)
Date: Wed, 14 Dec 2011 20:35:22 +0100
Subject: omsosgsn test phone recommendation?
In-Reply-To: <5B5B8F7E-52F7-4CE7-85D6-EA0DE7FD2F7D@jcis.net>
References: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
	<20111214093637.GQ10252@prithivi.gnumonks.org>
	<5B5B8F7E-52F7-4CE7-85D6-EA0DE7FD2F7D@jcis.net>
Message-ID: <4EE8FA7A.3030405@tobias.org>

Hi David,

adding to Haralds list, I can confirm that the Nokia E71 also works.

-Tobias

On 14.12.2011 19:05, David A. Burgess wrote:
> Harald -
> 
> Thanks for the list.  We'll try to find one of these.  I have a few iPhones sitting in front of me, but unfortunately they are all 850/1900 and my available hardware is 900. :(
> 
> Does you have an example GSMTAP/PCAP trace of a successful PDP context activation using OmsoSGSN?  That would be useful for comparison.  (And do you find the GPRS L3 & SNDCP decoding in the current Wireshark 1.7 to be reliable?)
> 
> -- David
> 
> 
> 
> On Dec 14, 2011, at 1:36 AM, Harald Welte wrote:
> 
>> Hi David,
>>
>> On Tue, Dec 13, 2011 at 09:37:19PM -0800, David A. Burgess wrote:
>>
>>> Can someone recommend a good smartphone for testing with OsmoSGSN?  We
>>> are having trouble getting our GPRS modem to recognize a ACTIVATE PDP
>>> CONTEXT ACK message and are trying to determine if the error is in the
>>> modem, in OmsoSGSN or somewhere in between.
>>
>> I've successfully used at least SE K800i, Google Nexus S, Dell Streak,
>> HTC Hermes II, Motorola A780 here on my side.  I know some other people
>> have been using OsmoSGSN/OpenGGSN for iPhone related work, though I
>> don't know which particular model they've used.
>>
>>> Better yet, is there anything out there that can generate an L2 or L3
>>> trace, like the Nokia 3310, but for GPRS as well as GSM?
>>
>> The only ones that come to my mind are the TEMS variants of the K800i,
>> but those are of course hard to come by and/or expensive :/
>>
>> Have you considered using Luca's work on gprsdecode?  This way you could
>> do an air interface trace of what's happening between BTS and MS.
>>
>> Regards,
>> 	Harald
>> -- 
>> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
>> ============================================================================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                  (ETSI EN 300 175-7 Ch. A6)
> 
> 
> 




From admin at manateeshome.com  Thu Dec 15 09:43:42 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Thu, 15 Dec 2011 18:43:42 +0900
Subject: omsosgsn test phone recommendation?
In-Reply-To: <4EE8FA7A.3030405@tobias.org>
References: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
	<20111214093637.GQ10252@prithivi.gnumonks.org>
	<5B5B8F7E-52F7-4CE7-85D6-EA0DE7FD2F7D@jcis.net>
	<4EE8FA7A.3030405@tobias.org>
Message-ID: <3AF5AEBE-3698-4D73-918D-7246253DF11F@manateeshome.com>

I can add the following phones to the list

Apple iPhone 4
Apple iPhone 3GS

Samsung Omnia II
Samsung Galaxy S II
Samsung SGH-i780

HTC touch Diamond


Envoy? de mon iPhone

Le Dec 15, 2011 ? 4:35 AM, Tobias Engel <t-openbsc at tobias.org> a ?crit :

> Hi David,
> 
> adding to Haralds list, I can confirm that the Nokia E71 also works.
> 
> -Tobias
> 
> On 14.12.2011 19:05, David A. Burgess wrote:
>> Harald -
>> 
>> Thanks for the list.  We'll try to find one of these.  I have a few iPhones sitting in front of me, but unfortunately they are all 850/1900 and my available hardware is 900. :(
>> 
>> Does you have an example GSMTAP/PCAP trace of a successful PDP context activation using OmsoSGSN?  That would be useful for comparison.  (And do you find the GPRS L3 & SNDCP decoding in the current Wireshark 1.7 to be reliable?)
>> 
>> -- David
>> 
>> 
>> 
>> On Dec 14, 2011, at 1:36 AM, Harald Welte wrote:
>> 
>>> Hi David,
>>> 
>>> On Tue, Dec 13, 2011 at 09:37:19PM -0800, David A. Burgess wrote:
>>> 
>>>> Can someone recommend a good smartphone for testing with OsmoSGSN?  We
>>>> are having trouble getting our GPRS modem to recognize a ACTIVATE PDP
>>>> CONTEXT ACK message and are trying to determine if the error is in the
>>>> modem, in OmsoSGSN or somewhere in between.
>>> 
>>> I've successfully used at least SE K800i, Google Nexus S, Dell Streak,
>>> HTC Hermes II, Motorola A780 here on my side.  I know some other people
>>> have been using OsmoSGSN/OpenGGSN for iPhone related work, though I
>>> don't know which particular model they've used.
>>> 
>>>> Better yet, is there anything out there that can generate an L2 or L3
>>>> trace, like the Nokia 3310, but for GPRS as well as GSM?
>>> 
>>> The only ones that come to my mind are the TEMS variants of the K800i,
>>> but those are of course hard to come by and/or expensive :/
>>> 
>>> Have you considered using Luca's work on gprsdecode?  This way you could
>>> do an air interface trace of what's happening between BTS and MS.
>>> 
>>> Regards,
>>>    Harald
>>> -- 
>>> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
>>> ============================================================================
>>> "Privacy in residential applications is a desirable marketing option."
>>>                                                 (ETSI EN 300 175-7 Ch. A6)
>> 
>> 
>> 
> 
> 




From laforge at gnumonks.org  Wed Dec 14 22:41:52 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2011 23:41:52 +0100
Subject: omsosgsn test phone recommendation?
In-Reply-To: <5B5B8F7E-52F7-4CE7-85D6-EA0DE7FD2F7D@jcis.net>
References: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
	<20111214093637.GQ10252@prithivi.gnumonks.org>
	<5B5B8F7E-52F7-4CE7-85D6-EA0DE7FD2F7D@jcis.net>
Message-ID: <20111214224152.GH4696@prithivi.gnumonks.org>

Hi David,

On Wed, Dec 14, 2011 at 10:05:31AM -0800, David A. Burgess wrote:

> Does you have an example GSMTAP/PCAP trace of a successful PDP context
> activation using OmsoSGSN?  That would be useful for comparison.  (And
> do you find the GPRS L3 & SNDCP decoding in the current Wireshark 1.7
> to be reliable?)

I currently don't think I have any traces ready that I could share with
you, but there might be some other people on this list who have.

In any case, if you are already getting beyound the GMM procedures (RA
UPDATE / GPRS ATTACH) in bi-directional communication between the MS and
the SGSN, then I think your L1 and RLC/MAC are working.

I guess the problem might really be the PDP CONTEXT ACTIVATE then.

I would look in the PCAP files for
 * issues with using the wrong TLLI, especially during/after P-TMSI
   reallocation (maybe patch out the code from OsmoSGSN)
 * sequence numbering issues on the LLC layer sequence numbers

And yes, so far I havent' had much complaints about the GMM/SM/SNDCP/LLC
decoding of wireshark.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From krkos at phd.feec.vutbr.cz  Wed Dec 14 15:44:34 2011
From: krkos at phd.feec.vutbr.cz (=?iso-8859-2?Q?Radko_Krko=B9?=)
Date: Wed, 14 Dec 2011 16:44:34 +0100
Subject: omsosgsn test phone recommendation?
In-Reply-To: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
References: <31143EA4-665B-4845-A7D5-36DF02DFF7EB@jcis.net>
Message-ID: <001701ccba77$481aeb20$d850c160$@phd.feec.vutbr.cz>

Hello

> We are having trouble getting our GPRS modem to recognize a ACTIVATE
> PDP CONTEXT ACK message and are trying to determine if the error is in the
> modem, in OmsoSGSN or somewhere in between.

Probably in OsmoSGSN as I have exactly the same problem with several phones.
Those that work more often than others are Nokia 6230i (not a smartphone)
and HTC TyTN (smartphone, but an older one).

Regards,
Radko Krko?





From drwegaba at gmail.com  Thu Dec 15 05:41:43 2011
From: drwegaba at gmail.com (Dick Rwegaba)
Date: Thu, 15 Dec 2011 08:41:43 +0300
Subject: OpenBSC Digest, Vol 36, Issue 8
In-Reply-To: <mailman.1.1323687602.15440.openbsc@lists.osmocom.org>
References: <mailman.1.1323687602.15440.openbsc@lists.osmocom.org>
Message-ID: <CAEO9OAfHFBDUdNJR+2rouyryzr3TeJcVLXCE7uNcKgErPYAA1Q@mail.gmail.com>

dear pals please help with this error for gnuradio build

checking for boost >= 1.35... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether the boost::thread includes are available... yes
checking for exit in -lboost_thread-mt... yes
checking whether the boost::date_time includes are available... yes
checking for exit in -lboost_date_time-mt... yes
checking whether the boost::system includes are available... yes
configure: error: Could not link against libboost_system!
root at debian:~/gnuradio# ^C


On Mon, Dec 12, 2011 at 2:00 PM, <openbsc-request at lists.osmocom.org> wrote:

> Send OpenBSC mailing list submissions to
>        openbsc at lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>        openbsc-request at lists.osmocom.org
>
> You can reach the person managing the list at
>        openbsc-owner at lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
>   1. slightly off the topic (Akib Sayyed)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 12 Dec 2011 10:28:24 +0530
> From: Akib Sayyed <akibsayyed at gmail.com>
> To: "openbts-discuss at lists.sourceforge.net List"
>        <openbts-discuss at lists.sourceforge.net>, openbsc at lists.osmocom.org
> Subject: slightly off the topic
> Message-ID:
>        <CAMG-S91QY0FLChBfiG3g3n6w_WLinW9VQXsxbLqNra12VXk0ZQ at mail.gmail.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> guys i wanted to know what gnuradio version is needed for airprobe.
> i tried asking on airprobe list but dint got any repsonse.
>
> also i tried to compile gnuradio 3.1.2 but dint worked for me.
> can any one please
> explain??
>
>
> thanks in advance
>
> --
> Akib Sayyed
> Matrix-Shell
> akibsayyed at gmail.com
> akibsayyed at matrixshell.com
> Mob:- +91-966-514-2243
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osmocom.org/pipermail/openbsc/attachments/20111212/615a2767/attachment-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> End of OpenBSC Digest, Vol 36, Issue 8
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111215/58bda9bc/attachment.htm>

From holger at freyther.de  Thu Dec 15 08:26:33 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 15 Dec 2011 09:26:33 +0100
Subject: OpenBSC Digest, Vol 36, Issue 8
In-Reply-To: <CAEO9OAfHFBDUdNJR+2rouyryzr3TeJcVLXCE7uNcKgErPYAA1Q@mail.gmail.com>
References: <mailman.1.1323687602.15440.openbsc@lists.osmocom.org>
	<CAEO9OAfHFBDUdNJR+2rouyryzr3TeJcVLXCE7uNcKgErPYAA1Q@mail.gmail.com>
Message-ID: <4EE9AF39.6060105@freyther.de>

On 12/15/2011 06:41 AM, Dick Rwegaba wrote:
> dear pals please help with this error for gnuradio build

Hi Dick,

do not top post. You can use a service like gmane.org to post to this
mailinglist without being subscribed and following the netiquette. If  you
include the output of a program, include the full output (e.g. autoconf
pointed you to config.log).

Let me try to explain autoconf's error output, maybe it is helpful.

"configure: error: Could not link against libboost_system!"

configure: The configure program you invoked.
error: This means an error has occured.
"Could not link against libboost_system": Is the error that happened.

"Could not link": It means no binary could be linked together (config.log will
have the output of linking process.

"against libboost_system": Take a look at config.log, you might find a line
with -lboost_system and the output of the linker, the most likely source is
that you don't have 'libboost-system' installed.

And most interestingly, do you feel like introducing yourself, what you do,
what you will work on?

holger



From drwegaba at gmail.com  Fri Dec 16 07:18:49 2011
From: drwegaba at gmail.com (Dick Rwegaba)
Date: Fri, 16 Dec 2011 10:18:49 +0300
Subject: OpenBSC Digest, Vol 36, Issue 11
In-Reply-To: <mailman.1.1323946801.19193.openbsc@lists.osmocom.org>
References: <mailman.1.1323946801.19193.openbsc@lists.osmocom.org>
Message-ID: <CAEO9OAd=dawUgusGg-UVyVe-nR8Kx46k5_avaxGU7PCcue5jDg@mail.gmail.com>

Hi This is the libboost version that i have but still get the same error.
root at debian:~/gnuradio# apt-cache search libboost-system
libboost-system1.42.0 - Operating system (e.g. diagnostics support) library

and this is the boost tree
root at debian:~# apt-cache search boost
libboost-date-time1.42.0 - set of date-time libraries based on generic
programming concepts
libboost-thread1.42.0 - portable C++ multi-threading
libboost-iostreams1.42.0 - Boost.Iostreams Library
libboost-serialization1.42-dev - serialization library for C++
libboost-program-options1.42.0 - program options library for C++
libboost-dev - Boost C++ Libraries development files (default version)
libboost-thread1.42-dev - portable C++ multi-threading
libboost-system1.42.0 - Operating system (e.g. diagnostics support) library
libboost-thread-dev - portable C++ multi-threading (default version)
libboost-signals1.42.0 - managed signals and slots library for C++
libboost1.42-dev - Boost C++ Libraries development files
libboost-date-time1.42-dev - set of date-time libraries based on generic
programming concepts
libboost-serialization1.42.0 - serialization library for C++
libboost-filesystem1.42.0 - filesystem operations (portable paths,
iteration over directories, etc) in C++
root at debian:~#



On Thu, Dec 15, 2011 at 2:00 PM, <openbsc-request at lists.osmocom.org> wrote:

> Send OpenBSC mailing list submissions to
>        openbsc at lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>        openbsc-request at lists.osmocom.org
>
> You can reach the person managing the list at
>        openbsc-owner at lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
>   1. Re: OpenBSC Digest, Vol 36, Issue 8 (Holger Hans Peter Freyther)
>   2. Re: omsosgsn test phone recommendation? (Seungju Kim)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Dec 2011 09:26:33 +0100
> From: Holger Hans Peter Freyther <holger at freyther.de>
> To: openbsc at lists.osmocom.org
> Subject: Re: OpenBSC Digest, Vol 36, Issue 8
> Message-ID: <4EE9AF39.6060105 at freyther.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 12/15/2011 06:41 AM, Dick Rwegaba wrote:
> > dear pals please help with this error for gnuradio build
>
> Hi Dick,
>
> do not top post. You can use a service like gmane.org to post to this
> mailinglist without being subscribed and following the netiquette. If  you
> include the output of a program, include the full output (e.g. autoconf
> pointed you to config.log).
>
> Let me try to explain autoconf's error output, maybe it is helpful.
>
> "configure: error: Could not link against libboost_system!"
>
> configure: The configure program you invoked.
> error: This means an error has occured.
> "Could not link against libboost_system": Is the error that happened.
>
> "Could not link": It means no binary could be linked together (config.log
> will
> have the output of linking process.
>
> "against libboost_system": Take a look at config.log, you might find a line
> with -lboost_system and the output of the linker, the most likely source is
> that you don't have 'libboost-system' installed.
>
> And most interestingly, do you feel like introducing yourself, what you do,
> what you will work on?
>
> holger
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 15 Dec 2011 18:43:42 +0900
> From: Seungju Kim <admin at manateeshome.com>
> Cc: "openbsc at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: omsosgsn test phone recommendation?
> Message-ID: <3AF5AEBE-3698-4D73-918D-7246253DF11F at manateeshome.com>
> Content-Type: text/plain;       charset=utf-8
>
> I can add the following phones to the list
>
> Apple iPhone 4
> Apple iPhone 3GS
>
> Samsung Omnia II
> Samsung Galaxy S II
> Samsung SGH-i780
>
> HTC touch Diamond
>
>
> Envoy? de mon iPhone
>
> Le Dec 15, 2011 ? 4:35 AM, Tobias Engel <t-openbsc at tobias.org> a ?crit :
>
> > Hi David,
> >
> > adding to Haralds list, I can confirm that the Nokia E71 also works.
> >
> > -Tobias
> >
> > On 14.12.2011 19:05, David A. Burgess wrote:
> >> Harald -
> >>
> >> Thanks for the list.  We'll try to find one of these.  I have a few
> iPhones sitting in front of me, but unfortunately they are all 850/1900 and
> my available hardware is 900. :(
> >>
> >> Does you have an example GSMTAP/PCAP trace of a successful PDP context
> activation using OmsoSGSN?  That would be useful for comparison.  (And do
> you find the GPRS L3 & SNDCP decoding in the current Wireshark 1.7 to be
> reliable?)
> >>
> >> -- David
> >>
> >>
> >>
> >> On Dec 14, 2011, at 1:36 AM, Harald Welte wrote:
> >>
> >>> Hi David,
> >>>
> >>> On Tue, Dec 13, 2011 at 09:37:19PM -0800, David A. Burgess wrote:
> >>>
> >>>> Can someone recommend a good smartphone for testing with OsmoSGSN?  We
> >>>> are having trouble getting our GPRS modem to recognize a ACTIVATE PDP
> >>>> CONTEXT ACK message and are trying to determine if the error is in the
> >>>> modem, in OmsoSGSN or somewhere in between.
> >>>
> >>> I've successfully used at least SE K800i, Google Nexus S, Dell Streak,
> >>> HTC Hermes II, Motorola A780 here on my side.  I know some other people
> >>> have been using OsmoSGSN/OpenGGSN for iPhone related work, though I
> >>> don't know which particular model they've used.
> >>>
> >>>> Better yet, is there anything out there that can generate an L2 or L3
> >>>> trace, like the Nokia 3310, but for GPRS as well as GSM?
> >>>
> >>> The only ones that come to my mind are the TEMS variants of the K800i,
> >>> but those are of course hard to come by and/or expensive :/
> >>>
> >>> Have you considered using Luca's work on gprsdecode?  This way you
> could
> >>> do an air interface trace of what's happening between BTS and MS.
> >>>
> >>> Regards,
> >>>    Harald
> >>> --
> >>> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> >>>
> ============================================================================
> >>> "Privacy in residential applications is a desirable marketing option."
> >>>                                                 (ETSI EN 300 175-7 Ch.
> A6)
> >>
> >>
> >>
> >
> >
>
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> End of OpenBSC Digest, Vol 36, Issue 11
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111216/4c56a2ae/attachment.htm>

From laforge at gnumonks.org  Fri Dec 16 08:16:17 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Dec 2011 09:16:17 +0100
Subject: OT: gnuradio compilation problems (Re: OpenBSC Digest, Vol 36, Issue
	11)
In-Reply-To: <CAEO9OAd=dawUgusGg-UVyVe-nR8Kx46k5_avaxGU7PCcue5jDg@mail.gmail.com>
References: <mailman.1.1323946801.19193.openbsc@lists.osmocom.org>
	<CAEO9OAd=dawUgusGg-UVyVe-nR8Kx46k5_avaxGU7PCcue5jDg@mail.gmail.com>
Message-ID: <20111216081617.GA17847@prithivi.gnumonks.org>

Hi Dick,

On Fri, Dec 16, 2011 at 10:18:49AM +0300, Dick Rwegaba wrote:

> Hi This is the libboost version that i have but still get the same error.
> root at debian:~/gnuradio# apt-cache search libboost-system
> libboost-system1.42.0 - Operating system (e.g. diagnostics support) library

Pleaes refrain from top-posting as well as full-quoting from a
mailinglist digest in all your mails.  I consider reading a document
like http://www.river.com/users/share/etiquette/#quotes

Using a _meaningful_ subject would also be considered a polite gesture
towards the people you expect to read your list postings.

Furthermore, I don't really understand why you are sending us your
gnuradio compilation issues.  This is not a gnuradio mailing list, it is
about OsmocomBB.

OsmocomBB does not - to the best of my knowledge - use gnuradio in any
way.  So your inquiries regarding gnuradio are off-topic.

Also, to say the least, projects like OsmocomBB, airprobe, OpenBSC and
others are made by developers for developers.  It is not our task to
teach people how to generally compile/build/install Free Software
packages on GNU/Linux.  There are plenty of other groups and forums
available for that.

Let me also add that some people could consider your behaviour quite
rude.  You never have contributed to the discussions on this list in
any way.  You simply top-post (with digest full-quote) error messages
from your console, without much comment.  You don't even take the time
to describe what you are trying to achieve, and what you have tried so
far in order to resolve the problem.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Fri Dec 16 17:44:28 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Dec 2011 18:44:28 +0100
Subject: Building an E1/T1/J1 line interface
Message-ID: <20111216174428.GQ17847@prithivi.gnumonks.org>

Hi all,

Dieter and I have been thinking about building a simple/basic E1 line
interface.  The idea is to simply put trnasformers + LIU + crystal on a
small PCB, which then exposes the Rx and Tx signals at stanard 3.3V CMOS
levels which can be fed in your favourite FPGA or even directly into a
microcontroller.

The first interesting LIU that's available in single quantity is the
Dallas/Maxim DS21348:
http://www.maxim-ic.com/datasheet/index.mvp/id/2848

It can be operated in "software mode" where all configuration (E1/T1/J1,
attenuation, amplification, termination, ...) is set via SPI from a
microcontroller.

However, it expose "Rx Positive" and "Rx Negative" and does not have the
HDB3/AMI/B8ZS encoder internally.  This means there would be two synchronous
serial streams going into the FPGA or microcontroller.  This is probably
ok for an FPGA - but it is a problem for most microcontrollers that only
have one sync serial interface like the sam3s/sam7s SSC.

The other option seems to be the IDT 82V2081
(http://www.idt.com/?genId=82V2041E&cid=58553), which as internal
HDB3/AMI/B8ZS encoders and decoders (so-called "single rail mode").  It
is a bit more expensive (USD 20 in single qty), but this would enable us
to hook it up directly at a sam3s / sam7s.

As jolly points out, there is still a lot of work required like
framing, s-bits, multiplexing, hdlc, etc. in order to turn it into a
full E1 interface.

But then, maybe there are some applications that don't even require all
those features, such as building a sniffer-only device, or something
that "simply" tries to forward E1 over IP based transports without
parsing too much of the contents.

Open questions:
* stay with 1port design or immediately do a 4port unit? (for
  bidirectional sniffing you already need two)
* how do we achieve synchronization between Rx and Tx data path?

Looking forward to your comments, feedback.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From lars at ibp.de  Fri Dec 16 20:42:40 2011
From: lars at ibp.de (Lars Immisch)
Date: Fri, 16 Dec 2011 21:42:40 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111216174428.GQ17847@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
Message-ID: <C9728389-F301-4239-A61E-D82C535091E4@ibp.de>

Hi,

> Dieter and I have been thinking about building a simple/basic E1 line
> interface.  The idea is to simply put trnasformers + LIU + crystal on a
> small PCB, which then exposes the Rx and Tx signals at stanard 3.3V CMOS
> levels which can be fed in your favourite FPGA or even directly into a
> microcontroller.
> 
> The first interesting LIU that's available in single quantity is the
> Dallas/Maxim DS21348:
> http://www.maxim-ic.com/datasheet/index.mvp/id/2848
> 
> It can be operated in "software mode" where all configuration (E1/T1/J1,
> attenuation, amplification, termination, ...) is set via SPI from a
> microcontroller.
> 
> However, it expose "Rx Positive" and "Rx Negative" and does not have the
> HDB3/AMI/B8ZS encoder internally.  This means there would be two synchronous
> serial streams going into the FPGA or microcontroller.  This is probably
> ok for an FPGA - but it is a problem for most microcontrollers that only
> have one sync serial interface like the sam3s/sam7s SSC.

I haven't studied the datasheets in detail yet, but I was immediately thinking of the Xmos chips (basically multi-threaded 400MHz 32bit DSPs available with a number of different cores). Several people in the forums claim they have reached clock SPI clock speeds of 50MHz and they are easy to use (source #paloaltona).

A single chip with one core (xs1-l1) costs USD 8 at Sparkfun, a dual core (xs1-l2) about USD 15.

> The other option seems to be the IDT 82V2081
> (http://www.idt.com/?genId=82V2041E&cid=58553), which as internal
> HDB3/AMI/B8ZS encoders and decoders (so-called "single rail mode").  It
> is a bit more expensive (USD 20 in single qty), but this would enable us
> to hook it up directly at a sam3s / sam7s.
> 
> As jolly points out, there is still a lot of work required like
> framing, s-bits, multiplexing, hdlc, etc. in order to turn it into a
> full E1 interface.
> 
> But then, maybe there are some applications that don't even require all
> those features, such as building a sniffer-only device, or something
> that "simply" tries to forward E1 over IP based transports without
> parsing too much of the contents.
> 
> Open questions:
> * stay with 1port design or immediately do a 4port unit? (for
>  bidirectional sniffing you already need two)

FWIW, I'd do 4 ports.

- Lars


From laforge at gnumonks.org  Fri Dec 23 20:08:47 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 23 Dec 2011 21:08:47 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111216174428.GQ17847@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
Message-ID: <20111223200847.GL12250@prithivi.gnumonks.org>

Hi all,

the first draft revision of the schematics and PCB design can be found
at http://cgit.osmocom.org/cgit/osmo-e1-xcvr/
(or "git clone git://git.osmocom.org/osmo-e1-xcvr.git")

The design has the following features:
 * the 4x3 and 2x3 jumpers like on the HFC-E1 eval board to set TE mode
   and NT mode as well as two possible configurations of the pairs
 * jumper to select between 1.544 MHz and 2.048 MHz oscillator clock
   i.e. E1/T1
 * jumper to decide whether TCLK should be sourced from MCLK or if it is
   provided externally by the transmitter
 * 10pin header for SPI control interface
 * 10pin header for TDM interface
 * 5x5cm size for cheapest pcb prototyping ;)

Comments or feedback is welcome.  I decided to use this project to try
current EAGLE (I last used it when there was a DOS version, IIRC).  So
I'm sorry it's not KiCAD / gEDA, but I needed a pet project to evaluate
it...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From vogelchr at vogel.cx  Sat Dec 24 12:59:36 2011
From: vogelchr at vogel.cx (Christian Vogel)
Date: Sat, 24 Dec 2011 13:59:36 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111223200847.GL12250@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
Message-ID: <20111224125935.GA1984@vogel.cx>

Hi Harald,

I cannot say anything competent about the IDT82v2081, but I have a few
general remarks.

Is it on purpose that you can open the Tx-Line by removing R4/R5 (0 Ohm),
or is it planned to maybe add a RC-Filter there? (why?)

> The design has the following features:
>  * the 4x3 and 2x3 jumpers like on the HFC-E1 eval board to set TE mode
>    and NT mode as well as two possible configurations of the pairs

As you are trying to conserve space, have you thought about using
2x2 jumpers for TE/NT selection, such as:

         jumpers                   jumpers
 Rx+---- o    o ----RJ4    Rx+---- o -- o ----RJ4
         |    |
 RJ13--- o    o ----Tx+    RJ13--- o -- o ----Tx+ ?

It might be useful to have pads for the RTIP/RRING TTIP/TRING signals + GND
accessible for debugging (maybe as unpopulated jumpers), those signals should
be cleaner than what's accessible on the jumpers/RJ45.

On Ethernet cards, the unused pairs are normally terminated in something ~100 Ohm,
and the central tap of the transformers and the unused pairs connected to system
ground via a few 100pF capacitor, I don't have any E1/T1 equipment here
to compare, but maybe one could consider doing this?

>  * jumper to decide whether TCLK should be sourced from MCLK or if it is
>    provided externally by the transmitter

>  * 10pin header for SPI control interface
>  * 10pin header for TDM interface

Is there an established standard for these interfaces, or a "most popular
eval board" in use? On the TDM-Interface TDN/TDP and RDN/RDP don't run
on adjacent pairs if a press-on flat-cable connector is used, if this
is a established standard, please ignore this comment, otherwise I'd propose

	\RST	1   2	\LOS	<- control signals
	GND	3   4	TCLK	<- gnd+tx clock
	TDP	5   6	TDN	<- transmit pair
	GND	7   8	RCLK	<- tnd+rx clock
	RDP	9  10	RDN	<- receive pair

When testing the chip on a bench, maybe with only a oscilloscope connected
to the TDM-pins, it might be useful if \RST is pulled high on the board.

For the SPI interface my suggestion would be to use something compatible
to the most prevalent JTAG pinout (SDO=TDO, \CS=TMS, SCLK=TCK), that way
one can easily talk to the 82V2081 from the PC using a common (dumb) USB
JTAG cable and custom software, and please include Vcc on SPI.

I don't know about the intended cable lengths, but maybe a few series resistors
for dampening the signal wouldn't hurt.

>  * 5x5cm size for cheapest pcb prototyping ;)

For the board, can you please move all external connectors to the side
opposing the RJ45?

All but one diode have the same orientation, that's unnecessarily confusing
during population of the board. To conserve space, a quad diode array (first
google hit: BAV99DW has one pair with common cathode, one pair with common
anode) could be useful.

Include a LED for loss-of-signal and power?

Include pads for a 3.3V linear low-dropout regulator,
normally bridged by a 0 Ohm resistor?

  The datasheets lists all I/O to be 5V compatible, and
  someone might want to use the transceiver with a 5V-only
  FPGA/Microcontroller board? Or someone might want to power
  the FPGA/Microcontroller via the LDO on the transceiver board?

Hmm... ok, this has become more than I intended, but maybe
the comments are useful? ;-)

Happy Christmas,

	Chris





From laforge at gnumonks.org  Sat Dec 24 14:43:36 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 24 Dec 2011 15:43:36 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111224125935.GA1984@vogel.cx>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20111224125935.GA1984@vogel.cx>
Message-ID: <20111224144336.GA26984@prithivi.gnumonks.org>

Hi Christian,

thanks a lot for your review!

On Sat, Dec 24, 2011 at 01:59:36PM +0100, Christian Vogel wrote:

> Is it on purpose that you can open the Tx-Line by removing R4/R5 (0 Ohm),
> or is it planned to maybe add a RC-Filter there? (why?)

This is in order to put non-0-ohm resistors into the lines (as required
for hardware termination).  It's not reall required, but I thought it
might be a nice option to have, as there is no cost associated with
it...

> > The design has the following features:
> >  * the 4x3 and 2x3 jumpers like on the HFC-E1 eval board to set TE mode
> >    and NT mode as well as two possible configurations of the pairs
> 
> As you are trying to conserve space, have you thought about using
> 2x2 jumpers for TE/NT selection, such as:

No, I didn't think about that.  But I've meanwhile updated the design
(last night) to actually place two RJ45 sockets, one in TE and one in NT
mode.

The second jumper for determining 1-2 / 3-6 has been removed completely.
I guess if you want to use a less common configuration, you just have to
crimp your own adapter cable.  That's not hard to do.

So now there are much less jumpers, especially no invalid
combinations...

> It might be useful to have pads for the RTIP/RRING TTIP/TRING signals + GND
> accessible for debugging (maybe as unpopulated jumpers), those signals should
> be cleaner than what's accessible on the jumpers/RJ45.

good point. I'll add that.

> On Ethernet cards, the unused pairs are normally terminated in something ~100 Ohm,
> and the central tap of the transformers and the unused pairs connected to system
> ground via a few 100pF capacitor, I don't have any E1/T1 equipment here
> to compare, but maybe one could consider doing this?

The HFC-E1 evaluation board (of which you get the schematics if you buy
one) has the center tap left open.  I don't think I have other
schematics, but I will try to check what Digium is doing.  The unused
pairs are left open as a standard, I'm quite sure.

> >  * jumper to decide whether TCLK should be sourced from MCLK or if it is
> >    provided externally by the transmitter
> 
> >  * 10pin header for SPI control interface
> >  * 10pin header for TDM interface
> 
> Is there an established standard for these interfaces, or a "most popular
> eval board" in use? 

I don't think so.

> On the TDM-Interface TDN/TDP and RDN/RDP don't run on adjacent pairs
> if a press-on flat-cable connector is used, 

The TDN / RDN are not differential signals, if that's what you're
thinking of.  They just indicate if the ternary encoding had a positive
or negative symbol.  In fact, I anticipate RDN and TDN to not be used
much at all, as the benefit of using this specific IDT chip is that it
can do the HDB3/B8ZS/AMI coding completely itself, i.e. only TDP and RDP
will be used for an un-coded bitstream.  I think the data sheet calls
this single-ended mode.

I just put the signals on the connector anyway, as the pins were free
and somebody might want to use that other mode one day.

> if this is a established
> standard, please ignore this comment, otherwise I'd propose
> 
> 	\RST	1   2	\LOS	<- control signals
> 	GND	3   4	TCLK	<- gnd+tx clock
> 	TDP	5   6	TDN	<- transmit pair
> 	GND	7   8	RCLK	<- tnd+rx clock
> 	RDP	9  10	RDN	<- receive pair
> 
> When testing the chip on a bench, maybe with only a oscilloscope connected
> to the TDM-pins, it might be useful if \RST is pulled high on the board.

this was also already done by my revision last night.  but thanks :)

> For the SPI interface my suggestion would be to use something compatible
> to the most prevalent JTAG pinout (SDO=TDO, \CS=TMS, SCLK=TCK), that way
> one can easily talk to the 82V2081 from the PC using a common (dumb) USB
> JTAG cable and custom software, and please include Vcc on SPI.

Mh, now thinking more about it, I'll primarily use the board with Olimex
development boards, and the typically have this UEXT connector for
UART/SPI/I at C.  I will align the pin-out to make sure this works 1:1.

this means:

1	3V3
2	GND
6	MISO
8	MOSI
9	CLK
10	nPCS1

> I don't know about the intended cable lengths, but maybe a few series resistors
> for dampening the signal wouldn't hurt.

You're referring to which signals?  Where do you want to have them?

> >  * 5x5cm size for cheapest pcb prototyping ;)
> 
> For the board, can you please move all external connectors to the side
> opposing the RJ45?

I'm not sure how easy that is, I've already spent a lot of time with the
layout to make sure the autorouter doesn't produce complete crap.   So
in order to conserve time, I may not be doing that.

> All but one diode have the same orientation, that's unnecessarily confusing
> during population of the board.

I actually only rotated them based on layout requirements.  But yes,
will try to rotate that one diode.

> To conserve space, a quad diode array (first google hit: BAV99DW has
> one pair with common cathode, one pair with common anode) could be
> useful.

I was thinking about a BAV99 (it's used on HFC-E1),  but the IDT data
sheet specifically specifies one diode type, and it has very different
characteristics (200mV less forward voltage, ...) than the BAV99.   So I
decided to play safe and use the recommended component at least in the
first generation.

> Include a LED for loss-of-signal and power?

Good idea.  Will do that.

> Include pads for a 3.3V linear low-dropout regulator,
> normally bridged by a 0 Ohm resistor?

I've placed a LDO now in last nights' version, but it's unconditional.
But yes, a 0 ohm resistor placement option might be a good idea.

> Hmm... ok, this has become more than I intended, but maybe
> the comments are useful? ;-)

definitely, thanks again.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sat Dec 24 16:06:08 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 24 Dec 2011 17:06:08 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111224144336.GA26984@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20111224125935.GA1984@vogel.cx>
	<20111224144336.GA26984@prithivi.gnumonks.org>
Message-ID: <20111224160608.GC26984@prithivi.gnumonks.org>

Hi Christan and others,

I've updated the schematics and PCB layout, please see below.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: e1_xcvr_sch.pdf
Type: application/pdf
Size: 33094 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111224/b6297c0b/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: e1_xcvr_pcb.pdf
Type: application/pdf
Size: 71367 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111224/b6297c0b/attachment-0001.pdf>

From vogelchr at vogel.cx  Sat Dec 24 21:47:09 2011
From: vogelchr at vogel.cx (Christian Vogel)
Date: Sat, 24 Dec 2011 22:47:09 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111224144336.GA26984@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20111224125935.GA1984@vogel.cx>
	<20111224144336.GA26984@prithivi.gnumonks.org>
Message-ID: <op.v60j4vk8unbdei@desolation.dillberg.com>

Hi Harald,

I've not yet looked at your updated design, just finished the Christmas
celebrations with relatives and so on ;-)...

> I've meanwhile updated the design
> (last night) to actually place two RJ45 sockets, one in TE and one in NT
> mode.

I would go with the jumper-selectable method, but that's maybe just
personal preferance.

> The TDN / RDN are not differential signals, if that's what you're
> thinking of.

Indeed, that's what I thought of, nevertheless I'd try to have at least
the clock lines somewhere adjecent to ground, even if it's only based on
my gut feeling.

>> I don't know about the intended cable lengths, but maybe a few series  
>> resistors for dampening the signal wouldn't hurt.

> You're referring to which signals?

SPI and TMS, if you have fast outputs on either the E1 transceiver or the
microcontroller/fpga, series resistors (say... 68 Ohm) might dampen the
ringing on the edges.

> I'm not sure how easy that is, I've already spent a lot of time with the
> layout to make sure the autorouter doesn't produce complete crap.   So
> in order to conserve time, I may not be doing that.

I never used the eagle autorouter, because I think it doesn't produce
elegant routing, or sometimes no routing at all. Fortunately all my boards
were of comparably low complexity (one microcontroller, maybe one or two  
small
additional ICs, everything low pin-count). I'll try my luck on manually
routing the new board tomorrow in the morning or so...

> I was thinking about a BAV99 (it's used on HFC-E1),  but the IDT data
> sheet specifically specifies one diode type, and it has very different
> characteristics (200mV less forward voltage, ...) than the BAV99.

I checked the datasheet and they use rather strong (500mA and up) schottky
diodes (hence the lower forward drop compared to the BAV99).

Possibly they are considering their product being connected in a commercial
telco-equipment with a few kilometres of cable connected to it, and the
diodes are for protecting the inputs from overvoltage.

Personally, I'd say that for the current design you can easily go with
a little weaker diodes, such as the BAT54s (dual in SOT23 smd) which
can take up to 200mA (avg).

Greetings from bavaria,


	Chris



From laforge at gnumonks.org  Sat Dec 24 22:12:08 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 24 Dec 2011 23:12:08 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <op.v60j4vk8unbdei@desolation.dillberg.com>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20111224125935.GA1984@vogel.cx>
	<20111224144336.GA26984@prithivi.gnumonks.org>
	<op.v60j4vk8unbdei@desolation.dillberg.com>
Message-ID: <20111224221208.GE26984@prithivi.gnumonks.org>

Hi Christian,

On Sat, Dec 24, 2011 at 10:47:09PM +0100, Christian Vogel wrote:
> >I've meanwhile updated the design
> >(last night) to actually place two RJ45 sockets, one in TE and one in NT
> >mode.
> 
> I would go with the jumper-selectable method, but that's maybe just
> personal preferance.

Sorry, I'm not going to change back now ;)

> Indeed, that's what I thought of, nevertheless I'd try to have at least
> the clock lines somewhere adjecent to ground, even if it's only based on
> my gut feeling.

ok, I'll look at that.  The pin-configuratoin of the TDM connector is
definitely not

> SPI and TMS, if you have fast outputs on either the E1 transceiver or the
> microcontroller/fpga, series resistors (say... 68 Ohm) might dampen the
> ringing on the edges.

Well, I think for SPI there is no speed requirement anyway (it's just
configuring the transceiver and maybe reading an error status back), so
if there are problems, we can simply reduce the clock rate.

For the TDM signals, they are 2MBits/s and there is nothing we can
change about that ;)

I'll see if I can squeeze in some resistor footprints there.

> >I'm not sure how easy that is, I've already spent a lot of time with the
> >layout to make sure the autorouter doesn't produce complete crap.   So
> >in order to conserve time, I may not be doing that.
> 
> I never used the eagle autorouter, because I think it doesn't produce
> elegant routing, or sometimes no routing at all. 

If it wasn't for the router, I could have done the project in KiCAD,
where from my experience routing is really bad and/or takes ages.

> I'll try my luck on manually > routing the new board tomorrow in the
> morning or so...

Don't bother, it's a waste of time.  Really.  I've already spent way too
much time on this and would say it's about time to order some actual
PCBs (seeedstudio.com 9.99 for 10 units and cheapest shipping option)
and play with it.

I'll probably render some GErber output, look at it in a gerber viewer
and order tomorrow or on the 26th.

> I checked the datasheet and they use rather strong (500mA and up) schottky
> diodes (hence the lower forward drop compared to the BAV99).
> 
> Possibly they are considering their product being connected in a commercial
> telco-equipment with a few kilometres of cable connected to it, and the
> diodes are for protecting the inputs from overvoltage.

I think E1 is not specified over that distance anyway.  Last time I
checked, it was in the low hundreds of meters.

> Personally, I'd say that for the current design you can easily go with
> a little weaker diodes, such as the BAT54s (dual in SOT23 smd) which
> can take up to 200mA (avg).

Yes, you're probably right.  But let's try not to over-optimize this.
We're talking about a development board which will probably be produced
and used in a quantity of one or two dozen.

If later somebody emerges with a microcontroller/fpga/cpld design that
does something useful with the transceiver (i.e. implement an actual
functional E1 interface with HDLC, etc.), it would make a lot of sense
to make a custom board with this external logic and the transceiver on
one board.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From holger at freyther.de  Tue Dec 27 12:22:00 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 27 Dec 2011 13:22:00 +0100
Subject: MNCC and MNCC_LCHAN_MODIFY (and ack/nack)
Message-ID: <4EF9B868.4040400@freyther.de>

Hi Andreas, all,

right now there is no ack/nack for the MNCC_LCHAN_MODIFY and I would like to
introduce _ACK/_NACK for it.

The MNCC_LCHAN_MODIFY message will end up calling the
gsm0808_assignment_request of the BSC API and in case the call is not on a TCH
it will assign a new TCH. Things will go wrong from here. osmo-nitb does not
implement the assign_compl/assign_fail callbacks and in case of an assignment
failure we crash right now (master has dummy callbacks).

I would like to introduce MNCC_LCHAN_MODIFY_ACK/MNCC_LCHAN_MODIFY_NACK, change
the mncc_sock.c:mncc_setup_ind and handling of MNCC_CALL_CONF_IND.

what do you think?

	holger




From holger at freyther.de  Thu Dec 29 21:42:28 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 29 Dec 2011 22:42:28 +0100
Subject: Quick Recap of running the 28C3 network
Message-ID: <4EFCDEC4.5010706@freyther.de>

Hi all,

just a quick review of things we saw/learned during the congress

* OsmocomBB LAPDm and nanoBTS LAPDm appear to have some communication issues
leading to timeouts (nanoBTS resends a message with N(R) not incremented as a
response to our I frame with Identity Response (or timeout) but with the old
data). We don't have a fix/clear understanding of this yet... looks a bit like
a bug in the nanoBTS firmware (but then other phones appear to work just fine)

* CHANNEL ACTIVATION NACK on a TS. No idea why (maybe we closed a channel with
our auto-timer but the nanoBTS thinks it is open). IIRC the nanoBTS sends us a
report about open channels, we should cross-check every n-th report with our
view of the channels... on top of that we should block failed channels
(configurable, still to do).

* Open channels... E.g. with a nanoBTS reboot or "drop bts connection ", there
was a bug in libosmo-abis that the e1inp_event was not sent as the link was
already taken out of the list of sign links when close is called (fixed in
libosmo-abis and sharing code between rsl.c and ipaccess.c)

* one OML NACK drops all BTS.. The code is there to deal with a crashed BTS to
not have it connected in a bad state... (fixed in zecke/28c3)

* subscriber queue, thanks to jolly's SMS setup we increased the amount of SMS
and there still appear to be paths in the code that do not properly release
the transaction/subscr_put and the queue got stuck. We should start by merging
jolly's sms rework.. and see how we can move the queue out of process...

* Local End Release for SAPI > 0 should be done in the channel release code,
we need to implement T3109... thanks to jolly reading GSM 08.58/04.08 with me
and discussing the normal/abnormal case. I have some work in progress (only
tested the success case) patches in the zecke/28c3 branch.


* I uploaded our scripts but somehow the core dumping does not work correctly
(core_pattern appears to be right though) for running the network

* Purging subscribers from the VLR, we do it too aggressively (on failed
paging), it should take the periodic updating timer into account.

* Sometimes i miss dates.. e.g. when was the channel opened

probably some more things I forgot now, would be a great opportunity if
someone gives a hand in cleaning things up.

holger

PS: jenkins will be back in january, ZFS crashed, the secret key was on the
ZFS, grep didn't find the backup script...





From holger at freyther.de  Thu Dec 29 21:42:28 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 29 Dec 2011 22:42:28 +0100
Subject: Quick Recap of running the 28C3 network
Message-ID: <4EFCDEC4.5010706@freyther.de>

Hi all,

just a quick review of things we saw/learned during the congress

* OsmocomBB LAPDm and nanoBTS LAPDm appear to have some communication issues
leading to timeouts (nanoBTS resends a message with N(R) not incremented as a
response to our I frame with Identity Response (or timeout) but with the old
data). We don't have a fix/clear understanding of this yet... looks a bit like
a bug in the nanoBTS firmware (but then other phones appear to work just fine)

* CHANNEL ACTIVATION NACK on a TS. No idea why (maybe we closed a channel with
our auto-timer but the nanoBTS thinks it is open). IIRC the nanoBTS sends us a
report about open channels, we should cross-check every n-th report with our
view of the channels... on top of that we should block failed channels
(configurable, still to do).

* Open channels... E.g. with a nanoBTS reboot or "drop bts connection ", there
was a bug in libosmo-abis that the e1inp_event was not sent as the link was
already taken out of the list of sign links when close is called (fixed in
libosmo-abis and sharing code between rsl.c and ipaccess.c)

* one OML NACK drops all BTS.. The code is there to deal with a crashed BTS to
not have it connected in a bad state... (fixed in zecke/28c3)

* subscriber queue, thanks to jolly's SMS setup we increased the amount of SMS
and there still appear to be paths in the code that do not properly release
the transaction/subscr_put and the queue got stuck. We should start by merging
jolly's sms rework.. and see how we can move the queue out of process...

* Local End Release for SAPI > 0 should be done in the channel release code,
we need to implement T3109... thanks to jolly reading GSM 08.58/04.08 with me
and discussing the normal/abnormal case. I have some work in progress (only
tested the success case) patches in the zecke/28c3 branch.


* I uploaded our scripts but somehow the core dumping does not work correctly
(core_pattern appears to be right though) for running the network

* Purging subscribers from the VLR, we do it too aggressively (on failed
paging), it should take the periodic updating timer into account.

* Sometimes i miss dates.. e.g. when was the channel opened

probably some more things I forgot now, would be a great opportunity if
someone gives a hand in cleaning things up.

holger

PS: jenkins will be back in january, ZFS crashed, the secret key was on the
ZFS, grep didn't find the backup script...