15 Mar
2013
15 Mar
'13
3:29 p.m.
Hi Alexander
I'll email the wireshark trace to you shortly. Yes I have been playing with network
setup but can't remember the configuration when successful!
The openBTS server has a 1Gbit NIC but can't get it to negotiate anything other than
100Mbit even after updating drivers and much other 'playing' with cables hubs and
switches!
Mr Amazon is bringing some new network components tomorrow which should help further my
investigations.
This might well be one of these weird network issues you have seen that we might get to
the bottom off.
Regards
Craig
On 15 Mar 2013, at 19:04, Alexander Chemeris <alexander.chemeris(a)gmail.com> wrote:
Craig,
Could you please send a Wireshark capture of the start attempt? Send it to me directly if
it's more then 100k.
This looks very much like a networking issue. Have you changed your network setup since
it was working? May be connected it through a different switch? We found that some models
of switches does not work well and introduce weird issues.
Is your network card 100Mbit or 1Gbit?
If it's an UmTRX issue indeed, we'll replace it. Our beta testers is our most
precious asset.
Please excuse typos. Written with a touchscreen keyboard.
--
Regards,
Alexander Chemeris
CEO/Founder Fairwaves LLC
http://fairwaves.ru
On Mar 15, 2013 10:07 PM, "Craig Reading" <craig.reading1(a)gmail.com>
wrote:
> Hi All,
>
> After my initial success early in the week things seems to have gone pear shaped!
>
> I cannot get OpenBTS to start reliably as per traces below. After a power cycle of
the UmTRX I can normally get OpenBTS to start for a few seconds before the transceiver
terminates again. ./transceiver starts and runs on its own OK but there is a lot less
traffic in a wireshark trace compared to being started from OpenBTS.
>
> When the transceiver starts from OpenBTS a Wireshark trace shows a lot of UDP
packets.
>
> Approx 460 x 36 byte UDP packets for the first 0.5 seconds
> Then some variable length UDP packets all ACKed back with 36 bytes
> After 0.8 from startup the UmTRX sends a 28 byte message:
>
> 14d0000700000005000000140000000000a6d5180000000000100100
>
> After approx 1.0s from startup I then only get a few packets back from UmTRX
> After 5s I get nothing back from UmTRX
> After 6s I get an ICMP Port Unreachable
>
> If I had more time I would look into the transceiver source code to figure out where
things are stopping.
>
> I suspect this might be a networking issue and have tried changing some Linux kernel
buffer settings without success. I have also reset my OpenBTS database just in case I had
an option in there causing this. I'll carry on checking out the network side of things
but I am starting so suspect there might be an issue with the UmTRX.
>
> Help!
>
> Regards
> Craig
>
> >> Traces
>
> ALERT 46937531359488 TRXManager.cpp:408:powerOn: POWERON failed with status -1
> transceiver: no process killed
> linux; GNU C++ version 4.1.2 20080704 (Red Hat 4.1.2-52); Boost_104100; UHD_003.
> 004.000-93a49d0
>
> terminate called after throwing an instance of 'uhd::runtime_error'
> what(): RuntimeError: no control response
> EMERG 1101519168 OpenBTS.cpp:134:startTransceiver: Transceiver quit with status
> 6. Exiting.
>
> or:
>
> ALERT 47613775102208 TRXManager.cpp:408:powerOn: POWERON failed with status -1
> transceiver: no process killed
> linux; GNU C++ version 4.1.2 20080704 (Red Hat 4.1.2-52); Boost_104100; UHD_003.
> 004.000-93a49d0
>
> ALERT 47832442212256 UHDDevice.cpp:469:open: UHD make failed, device type=umtrx,
> addr=192.168.1.10,name=UmTRX,serial=13
> ALERT 47832442212256 runTransceiver.cpp:95:main: Transceiver exiting...
>
> EMERG 1104513344 OpenBTS.cpp:134:startTransceiver: Transceiver quit with status
> 256. Exiting.