the controller has no eeprom, so it has no subvendor/subdevice id. try
this: (drivers/isdn/hardware/mISDN/hfcmulti.c)
{ PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFCE1, PCI_ANY_ID,
PCI_ANY_ID,
- 0, 0, 0},
+ 0, 0, H(19)},
the driver should now handle this card. try it.
what vendor is this? maybe they should register at cologne chip for
subvendor IDs.
> [ 796.302786] Unknown HFC multiport controller (vendor:1397
device:30b1
> subvendor:ffffffff subdevice:ffffffff)
> [ 796.302891] Please contact the driver maintainer for support
this must be the case.
-----Ursprüngliche Nachricht-----
The vendor is junghanns.net I got the card directly from them.
You said that the controller has no eeprom. Or do you mean that it has
an eeprom that is not programmed? (FFFFFFFF). If this is the case,
someone at junghanns.net might have forgotten to program the eeprom?
regards.
Philipp
The attached message was received as a bounce, but either the bounce
format was not recognized, or no member addresses could be extracted
from it. This mailing list has been configured to send all
unrecognized bounce messages to the list administrator(s).
For more information see:
https://lists.gnumonks.org/mailman/admin/openbsc/bounce
JFYI:
http://mobile.slashdot.org/story/09/08/17/0014235/Open-Source-GSM-Network-A…
I'll be writing a report on our test network as soon as I find time for it.
This list will obviously be notified once it is finished.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello WoMax,
On Mon, 17 Aug 2009 18:10:26 +0200, "WoMax" <womax(a)gmx.ch> wrote:
>
> I got the bs11_config and the bsc_hack compiled,
>
> yes I use cygwin ..
>
>
> but ipaccess-find and the other programs won't compiled.
Cygwin does not seem to support SO_BINDTODEVICE. The line which
uses it was introduced with one the recent updates, as far as I
understand it, you can now optionally specify the network
interface for ipaccess-find (Harald might correct me if I am
wrong).
As long as you only have one network card, you most certainly
don't need this option and so for now just comment the line or
put it inside "#if !defined(__CYGWIN__)" "#endif" and it will
compile with Cygwin and should still work.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I got the bs11_config and the bsc_hack compiled,
yes I use cygwin ..
but ipaccess-find and the other programs won't compiled.
Can somebody bring me on the right lane?
Tom@HAL2008 ~
$ cd openbsc/openbsc
Tom@HAL2008 ~/openbsc/openbsc
$ make
make all-recursive
make[1]: Entering directory `/home/Tom/openbsc/openbsc'
Making all in include
make[2]: Entering directory `/home/Tom/openbsc/openbsc/include'
Making all in openbsc
make[3]: Entering directory `/home/Tom/openbsc/openbsc/include/openbsc'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/Tom/openbsc/openbsc/include/openbsc'
Making all in vty
make[3]: Entering directory `/home/Tom/openbsc/openbsc/include/vty'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/Tom/openbsc/openbsc/include/vty'
make[3]: Entering directory `/home/Tom/openbsc/openbsc/include'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/Tom/openbsc/openbsc/include'
make[2]: Leaving directory `/home/Tom/openbsc/openbsc/include'
Making all in src
make[2]: Entering directory `/home/Tom/openbsc/openbsc/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -Wall -g -O2 -MT
ipaccess-find.o -MD -MP -MF ".deps/ipaccess-find.Tpo" -c -o ipaccess-find.o
ipaccess-find.c; \
then mv -f ".deps/ipaccess-find.Tpo" ".deps/ipaccess-find.Po"; else
rm -f ".deps/ipaccess-find.Tpo"; exit 1; fi
In file included from ipaccess-find.c:13:
../include/openbsc/ipaccess.h:37: warning: "struct e1inp_line" declared
inside parameter list
../include/openbsc/ipaccess.h:37: warning: its scope is only this definition
or declaration, which is probably not what you want
ipaccess-find.c: In function `udp_sock':
ipaccess-find.c:46: error: `SO_BINDTODEVICE' undeclared (first use in this
function)
ipaccess-find.c:46: error: (Each undeclared identifier is reported only once
ipaccess-find.c:46: error: for each function it appears in.)
make[2]: *** [ipaccess-find.o] Error 1
make[2]: Leaving directory `/home/Tom/openbsc/openbsc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Tom/openbsc/openbsc'
make: *** [all] Error 2
Tom@HAL2008 ~/openbsc/openbsc
$
Hello WoMax,
On Fri, 14 Aug 2009 13:17:01 +0200, "WoMax" <womax(a)gmx.ch> wrote:
> ... here are some (interesting) pics about nanoBTS:
>
> http://www.umts.zerber.us
>
> more to come ...
Great :-). You noticed that there are a few pictures from another
nanoBTS model at the following location ?
http://bs11-abis.gnumonks.org/trac/wiki/nanoBTS_Internals
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Nordin,
On Fri, 14 Aug 2009 12:54:19 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> Well it should at least know it is dealing with the nanobts, which is
> not the case.
> In function bootstrap_network() of bsc_hack.c the function
> vty_read_config_file() is called, and that's it. So bsc_hack.c does
> nothing with the config file. Furthermore, I can't seem to find where
> the bts->type is filled. So my conclusion is this part is not finished yet.
Sorry, wrong. The type is set, your configuration file is wrong.
If you use "nanobts1800" instead of "nanoBTS", add
"ip.access unit_id 1800 0" (you might have to ajust the numbers)
everything will work (at least the nanoBTS is configured). I
just tried it with the version from the GIT. Why do I have to
try it, instead that you look carefully ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de