All,
Thanks for you help I have sort of resolved this issue:
UmTRX now hanging off TP-Link TL-SG1005D Gigabit switch and Shuttle XS35-703 V2 running OpenBTS hanging off Netgear FS605 10/100Mbps switch.Root cause: JMicron JMC250 connecting to a Gigabit switch and the link partner enabled the IEEE 802.3az Energy Efficient Ethernet feature
War and peace can be found here:
http://genesysguru.com/blog/blog/2013/03/16/umtrx-networking-issues/
Regards
CraigOn 16 March 2013 12:33, Alexander Chemeris <alexander.chemeris@gmail.com> wrote:
We temporarily solved issues with this JMC chip by putting a switch
between it and UmTRX, but not all models of switches worked and even
after that stability was not perfect.
Looking forward to know more about your experience.
--
On Sat, Mar 16, 2013 at 1:39 AM, Craig Reading <craig.reading1@gmail.com> wrote:
> Yes - shuttle with JMicron JMC250 (off top of my head). Depends on chip
> revision - complete pain!
>
> I'll post my experiences - basically no joy on Pre revision 4 chips.
>
> Regards
> Craig
> On 15 Mar 2013, at 21:24, Alexander Chemeris <alexander.chemeris@gmail.com>
> wrote:
>
> Craig,
>
> Which NIC is that? We had the same experience (no Gbit connection) on
> Shuttle computers. I don't have this information near my hands, but IIRC
> they had JMicron NICs. We never had issues with Intel motherboards.
>
> Please excuse typos. Written with a touchscreen keyboard.
>
> --
> Regards,
> Alexander Chemeris
> CEO/Founder Fairwaves LLC
> http://fairwaves.ru
>
> On Mar 15, 2013 11:26 PM, "Craig Reading" <craig.reading1@gmail.com> wrote:
>>
>> 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@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@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.
>>>
>
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ïïï õÍòÁÄÉÏ
http://fairwaves.ru