RN2483 can't join to Conduit

Home › Forums › Conduit: AEP Model › RN2483 can't join to Conduit

Tagged: ,

Viewing 30 posts - 1 through 30 (of 51 total)
1 2
  • Author
    Posts
  • February 9, 2017 at 4:38 am #16849
    Yuqian Li
    Participant

    I am running AEP1.3.3 of Conduit, I had set the Conduit:
    DR is 2
    SF is 12
    ADR is on
    RN2483 same to Conduit.

    Now when the RN2483 trying to join the Conduit, the Conduit thinking it is joined like below
    ————
    before RN2483 try to join
    admin@mtcdt:~# lora-query -n
    Net Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg

    no node joined

    after RN2483 try to join

    lora-query -n
    Net Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg
    00:00:00:01 00-04-a3-0b-00-1c-01-xx A 2017-02-09T09:58:08Z 0 0 0 0 0 0 0 0 0 0 0 0
    ———–

    Conduit said node was joined, but RN2483 keeping tell denied. also, when the RN2483 tried 3 times to join, then the RN2483 keeping tell no free-channel.

    Here is the details join log from Conduit, please take a look on that, and welcome any suggestions 🙂

    admin@mtcdt:~# 9:57:55:637|TRACE| Parse upstream message 244 bytes
    9:57:55:638|TRACE| Gateway 00:80:00:00:00:00:c4:eb seen
    9:57:55:639|INFO| Parsing 1 rx packets
    9:57:55:640|DEBUG| Received packet
    ================================
    000 00 ff ff 00 fa 47 c7 41
    008 db 21 01 1c 00 0b a3 04
    010 00 11 69 48 4b 12 be

    9:57:55:640|DEBUG| Rx on 868300000, rssi: -47 snr: 85
    9:57:55:641|DEBUG| Received frame: type: Join Request
    9:57:55:641|INFO| Received join request
    9:57:55:641|DEBUG| BUFFER: 00ffff00fa47c741db21011c000ba304001169
    9:57:55:642|DEBUG| App EUI: db-41-c7-47-fa-00-ff-ff
    9:57:55:642|DEBUG| Dev EUI: 00-04-a3-0b-00-1c-01-21
    9:57:55:642|DEBUG| Nonce: 00006911
    9:57:55:643|DEBUG| MIC is valid
    9:57:55:644|DEBUG| Got appkey: a0.2d.fe.b4.af.7b.52.cb.fd.e0.ae.ce.5c.a6.7e.f2
    9:57:55:644|DEBUG| DEV NONCE: 6911
    9:57:55:644|DEBUG| APP NONCE: 7e179d
    9:57:55:645|DEBUG| session keys: 1068d5b7c377d12234c8d833b412fe20 9a364ee690542623bb898bf87523c321
    9:57:55:645|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “0004a30b001c0121”;
    9:57:55:646|INFO| Device not found in DB
    9:57:55:647|INFO| assigning address: 1
    9:57:55:648|TRACE| SQL query = SELECT address FROM nodes where deveui = “0004a30b001c0121”;
    9:57:55:650|TRACE| SQL query = INSERT INTO nodes (address, appeui, deveui, authenticationkey, encryptionkey, lastdownmsgseqno, class) VALUES (“00000001”, “db41c747fa00ffff”, “0004a30b001c0121”, “2b7e151628aed2a6abf7158809cf4f3c”, “2b7e151628aed2a6abf7158809cf4f3c”, 0, “A”)
    9:57:55:654|TRACE| SQL query = INSERT INTO packets (node, gateway, seqno, data) VALUES (“00000001”, “”, 0, “”);
    9:57:55:659|TRACE| SQL query = INSERT INTO appkeys (appeui, deveui, appkey) VALUES (“db41c747fa00ffff”, “0004a30b001c0121”, “a02dfeb4af7b52cbfde0aece5ca67ef2”);
    9:57:55:663|DEBUG| Update session keys
    9:57:55:663|TRACE| SQL query = UPDATE nodes SET authenticationkey = “1068d5b7c377d12234c8d833b412fe20”, encryptionkey = “9a364ee690542623bb898bf87523c321” WHERE address = “00000001”
    9:57:55:667|DEBUG| Freq 0: 8691000
    9:57:55:668|DEBUG| Freq 1: 8693000
    9:57:55:668|DEBUG| Freq 2: 8695000
    9:57:55:668|DEBUG| Freq 3: 8697000
    9:57:55:673|DEBUG| Freq 4: 8699000
    9:57:55:673|DEBUG| GenerateJoinRequestIntegrityCode
    9:57:55:675|DEBUG| node is active
    9:57:55:675|DEBUG| app data size 0
    9:57:55:676|INFO| Queue join response 33 bytes
    9:57:55:676|DEBUG| Update stats
    9:57:55:676|DEBUG| Join packet received
    9:57:55:677|DEBUG| transmitController.ReceivedFrame
    9:57:55:677|DEBUG| update bestGateway
    9:57:55:677|DEBUG| Time: 3844941188
    9:57:55:678|DEBUG| App Queue Length: 1
    9:57:55:678|DEBUG| NewFrame
    9:57:55:678|DEBUG| 0 : 00:80:00:00:00:00:c4:eb == 00:80:00:00:00:00:c4:eb 1
    9:57:55:679|DEBUG| update gateway 0
    9:57:55:679|DEBUG| DR Index sf: 10 bw: 125 index: 2
    9:57:55:679|DEBUG| Rx Frame SEQ 16839 SNR 85 SF 2
    9:57:55:680|DEBUG| ADR FindDR : snr : 85 step : 30
    9:57:55:680|DEBUG| ADR PRE MIN/MAX DR: 9
    9:57:55:681|DEBUG| ADR NEW DR: 5 MIN: 0 MAX: 5 STEP: 30
    9:57:55:681|DEBUG| ADR update avgSnr store size: 0 snr: 85 avg: 0
    9:57:55:681|DEBUG| ADR update avgSnr store size: 0 snr: 85 avg: 85
    9:57:55:682|DEBUG| ReceiveOption : db
    9:57:55:682|TRACE| SQL query = UPDATE nodes SET lastdownmsgseqno = 0 WHERE address = “00000001”;
    9:57:55:683|DEBUG| Send MQTT message 229 bytes
    9:57:55:684|DEBUG| UDP message: lora/00-04-a3-0b-00-1c-01-21/packet_recv {“chan”:1,”codr”:”4/5″,”data”:”AP//APpHx0HbIQEcAAujBAARaUhLEr4=”,”datr”:”SF10BW125″,”freq”:868.29999999999995,”lsnr”:8.5,”modu”:”LORA”,”rfch”:0,”rssi”:-47,”size”:23,”stat”:1,”time”:”2017-02-09T09:57:55.637126Z”,”tmst”:3844941188}
    9:57:55:684|DEBUG| UDP port: 1784
    9:57:55:687|TRACE| Published message: 124
    9:57:55:688|TRACE| MQTT message: lora/00-04-a3-0b-00-1c-01-21/packet_recv
    9:57:55:691|TRACE| SQL query = UPDATE nodes SET jointime = “2017-02-09T09:57:55Z” WHERE address = “00000001”
    9:57:55:695|TRACE| SQL query = UPDATE packets SET port = 4, seqno = 0, gateway = “008000000000c4eb”, time = “2017-02-09T09:57:55Z”, microseconds = 637126, rssi = -47, channel = 1, lsnr_cB = 85, spread = 10, modulationbandwidth = 125, data = “001169” WHERE node = “00000001”
    9:57:55:700|TRACE| SQL query = UPDATE nodes SET lastuppacketid = 1, lastmessagems = 52 WHERE address = “00000001”;
    9:57:55:703|TRACE| SQL query = UPDATE gateways SET lastuppacketid = 1 WHERE address = “008000000000c4eb”;
    9:57:55:707|DEBUG| getTimeOnAirMs dr: 10 bw: 0 pl: 8 sz: 32 toa: 452
    9:57:55:708|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “0004a30b001c0121”;
    9:57:55:709|DEBUG| Mosquitto command received ‘packet_recv’
    9:57:55:709|TRACE| Unknown command ‘packet_recv
    9:57:55:710|INFO| Send Join Accept – EUI: 00-04-a3-0b-00-1c-01-21 ADDR: 00000001
    9:57:55:711|INFO| Schedule TX Time on air: 462 ms
    9:57:55:711|DEBUG| BestGatewayChannel::scheduleAt seq: 0 tm:21092532 dur:462 freq:868300000
    9:57:55:712|DEBUG| BestGatewayChannel::scheduleAt gw_seq: 16839 seq: 0
    9:57:55:712|DEBUG| BestGatewayChannel 0 : 00:80:00:00:00:00:c4:eb
    9:57:55:712|TRACE| Schedule DC band: 1 available: 36000 duration: 462 freq: 868300000
    9:57:55:713|DEBUG| returning 00:80:00:00:00:00:c4:eb
    9:57:55:717|DEBUG| Send MQTT message 0 bytes
    9:57:55:729|TRACE| Published message: 125
    9:57:55:730|DEBUG| UDP message: lora/00-04-a3-0b-00-1c-01-21/joined
    9:57:55:730|DEBUG| UDP port: 1784
    9:57:55:768|TRACE| MQTT message: lora/00-04-a3-0b-00-1c-01-21/joined
    9:57:55:768|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “0004a30b001c0121”;
    9:57:55:770|DEBUG| Mosquitto command received ‘joined’
    9:57:55:770|TRACE| Unknown command ‘joined

    lora-query -n
    Net Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg
    00:00:00:01 00-04-a3-0b-00-1c-01-21 A 2017-02-09T09:58:08Z 0 0 0 0 0 0 0 0 0 0 0 0

    February 9, 2017 at 4:46 am #16850
    Yuqian Li
    Participant

    also, I tried to change Conduit “Disable Duty Cycle” “Disable Join Rx1” “Disable Join Rx2″as somebody said that maybe can help, but nothing was help as well 🙁

    February 9, 2017 at 9:41 am #16853
    Peter Ferland
    Blocked

    Is the RN2483 configured for OTAA or ABP joins?

    February 9, 2017 at 11:25 am #16867
    wojtek t
    Participant

    I can respond on Yuqian’s behave… he is testing it in OTAA mode…

    February 9, 2017 at 10:01 pm #16957
    Yuqian Li
    Participant

    thank you, Wojtek, yes, I am running OTAA mode.
    Does anyone who has same issue as I think this is must be a common issue for RN2483 and Conduit.

    February 10, 2017 at 4:22 am #16961
    lorawan2016
    Participant

    Hi Yuqian,

    Yes I have seen this behavior previously and I think this is related to radio channels configurations since the LoRaWAN module RN2483 is trying to send in a pre-configured frequency in the activated channel normally ch0 and ch1 as the default settings of the MultiTech conduit gateway require but it fails when there is no enough time during the pre-configured duty cycle for each radio channel especially when there’s interference “causing the return status no_free_channel” as I remember it between LoRaWAN end-device and the gateway.

    In my point of view, I recommend to re-configure the radio channels according to your region available legal frequency bands and set on each channel not just the frequency band but also, the duty cycle, data rate and set the channel to on. Don’t forget to save your configuration after setting the new configuration. Try to adjust the frequency until you find the suitable band to communicate to the gateway. The bandwidth in each channel is 125 KHz.

    In Europe the activated frequencies in RN2483 are 868.1, 868.3 and 868.5.

    Kindly share your findings if you would try this approach and this is would be helpful for others as well.

    February 10, 2017 at 4:42 am #16962
    Yuqian Li
    Participant

    Hi Loranwan2016,
    Thanks for your suggestions.
    The RN2483 actually is enabled three mandatory channels, check this link out http://www.microchip.com/forums/m947922.aspx#947922

    Now the problem is the Conduit can see the RN2483 sending join required used one of those 3 channels and replied to RN2483, but the RN2483 can’t receive that in consistently, we are tried to increase the Rx1 window time from 1000ms to 5000ms for RN2483, just get a little bit improves :(.

    We still working on that to try find the real reason, and appreciate any suggestions,

    February 10, 2017 at 4:42 am #16963
    lorawan2016
    Participant

    Another approach is to configure 8 radio channels in the Multitech gateway rather than the default activated ones ch0 and ch1.

    February 10, 2017 at 5:02 am #16964
    Yuqian Li
    Participant

    Hi Lorawan2016,

    Thank you.

    I am using GUI of Conduit to configured it running in public mode, there is only a “Channel plan” and “Additional Channels”, there is no option to enable and review all channels to enable or disable, how I can to do that, any suggestion?

    also, I used “curl -m 5 -s “127.0.0.1/api/loraNetwork”” can get following what is Conduit Lora configured
    “lora” : {
    “ADRStep” : 30,
    “antennaGain” : 3,
    “channelPlan” : “EU868”,
    “dutyCyclePeriod” : 60,
    “enabled” : true,
    “frequencyBand” : 868,
    “frequencyEU” : 869500000,
    “frequencySubBand” : 1,
    “maxDatarate” : 4,
    “maxTxPower” : 26,
    “minDatarate” : 0,
    “netID” : “000000”,
    “nodeQueueSize” : 16,
    “packetForwarderConfig” : “{\n\t\”SX1301_conf\”: {\n\t\t\”radio_0\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”freq\”: 867500000\n\t\t},\n\t\t\”radio_1\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”freq\”: 868500000\n\t\t},\n\t\t\”chan_multiSF_0\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: -400000\n\t\t},\n\t\t\”chan_multiSF_1\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: -200000\n\t\t},\n\t\t\”chan_multiSF_2\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: 0\n\t\t},\n\t\t\”chan_multiSF_3\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: -400000\n\t\t},\n\t\t\”chan_multiSF_4\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: -200000\n\t\t},\n\t\t\”chan_multiSF_5\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: 0\n\t\t},\n\t\t\”chan_multiSF_6\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: 200000\n\t\t},\n\t\t\”chan_multiSF_7\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: 400000\n\t\t},\n\t\t\”chan_Lora_std\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: -200000,\n\t\t\t\”bandwidth\”: 250000,\n\t\t\t\”spread_factor\”: 7\n\t\t},\n\t\t\”chan_FSK\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: 300000,\n\t\t\t\”datarate\”: 50000,\n\t\t\t\”freq_deviation\”: 25000\n\t\t}\n\t},\n\t\”gateway_conf\”: {\n\t\t\”synch_word\”: 52,\n\t\t\”forward_crc_disabled\”: false,\n\t\t\”forward_crc_error\”: true,\n\t\t\”forward_crc_valid\”: true,\n\t\t\”gateway_ID\” : \”<008000000000C4EB>\”,\n\t\t\”keepalive_interval\”: 12,\n\t\t\”push_timeout_ms\”: 600,\n\t\t\”serv_port_down\”: 1700,\n\t\t\”serv_port_up\”: 1700,\n\t\t\”server_address\”: \”eur1.iothub.ca\”,\n\t\t\”stat_interval\”: 20\n\t}\n}”,
    “packetForwarderMode” : false,
    “rx1DatarateOffset” : 2,
    “rx2Datarate” : 12
    },

    February 10, 2017 at 5:12 am #16965
    lorawan2016
    Participant

    Hi Yuqian,

    Check if this is the correct path to edit the file.

    /var/config/lora/lora-network-server.conf

    or find its location in your gateway, there should be similar one.

    February 10, 2017 at 5:16 am #16966
    Yuqian Li
    Participant

    Hi Loranwan2016,
    It is same what I got from “curl -m 5 -s “127.0.0.1/api/loraNetwork”” just a “frequencySubBand” in there.
    also I found this link http://openlora.com/forum/viewtopic.php?t=1252, they all talking about the subBand definition.

    February 10, 2017 at 6:56 am #16968
    wojtek t
    Participant

    The proper start should be with 3 frequencies as Yuqian is doing. Then, through CFlist upon joining the radio will receive the list of additional frequencies from Conduit….but the problem is that his radio is timing out waiting for join confirmation ….

    • This reply was modified 8 years, 1 month ago by wojtek t.
    February 10, 2017 at 6:59 am #16970
    wojtek t
    Participant

    Anyone from Multitech?

    February 10, 2017 at 7:21 am #16971
    lorawan2016
    Participant

    Hello wojtek t,

    If there’s a timeout occurs on the end-device then this could be a bug in the Microchip OR MultiTech firmware to work reliably with each other, LoRaWAN stack problems?

    It might be worth raising the same question track at Microchip forum.
    This problem was discussed in different forums now but no official answer works!!!

    February 10, 2017 at 7:23 am #16972
    wojtek t
    Participant

    Microchip is a single radio with a proper lora alliance approvals. We use it in our devices for both EU and NA without any problems except for this which again only present itself with Multitech…

    February 10, 2017 at 7:54 pm #17026
    Yuqian Li
    Participant

    really appreciate if some MultiTech tech guys can help out :), as this is very important for us, thank you.

    February 11, 2017 at 1:22 pm #17027
    lorawan2016
    Participant

    Hi Yuqian,

    I am trying to investigate this problem but I need some information from you.
    Do you know which Microchip firmware version in your RN2483 module? … you can use Tera term and the version will be printed on the screen upon starting the module.

    Have you investigated if it works with earlier firmware versions of the Multi-tech gateway?

    February 11, 2017 at 1:38 pm #17028
    lorawan2016
    Participant

    I am quite sure that last year I connected RN2483 with MultiTech gateway and it worked without any problem but I’m unsure from which firmware version this problem has been introduced.

    Another approach is to investigate this problem if you have another LoRaWAN module from ARM mBed i.e. SX1272 or similar one from Murata and try to connect it to the same Multitech gateway and check if it works. If it works then it’s compatibility problem and Microchip or MultiTech has to find a solution for it.

    I don’t know why there’s no official response on this track yet !!

    February 12, 2017 at 3:42 am #17029
    Yuqian Li
    Participant

    Hi Lorawan2016,
    Thanks for your suggestion, i am using the 1.0.1 of RN2483 firmware, Conduit AEP 1.3.3.
    No idea why there is no MultiTech guy in here 🙁

    February 12, 2017 at 1:00 pm #17031
    lorawan2016
    Participant

    Hi Yuqian,

    Since the 1.0.1 is old firmware version, just for testing, try to downgrade the firmware on your gateway to either

    Firmware version 1.0.33 (Released 09/25/2015)
    OR
    Firmware version 1.1.2 (Released 02/02/2016)

    You can do this easily by registering your gateway in MultiTech DeviceHQ https://www.devicehq.com

    Before doing the downgrade it’s important to save your configuration and then let DeviceHQ do the job for you after scheduling the downgrade to be done on next restart of the gateway. It will take a couple of hours or less depending on your internet connection.

    Then test it with RN2483 firmware version 1.0.1 to check if it works better.

    Later on, you may upgrade your gateway easily to any firmware version as all of them are available on DeviceHQ.
    Another alternative is to do the firmware downgrade/upgrade for your gateway manually if you have the firmware file available on your system.

    February 12, 2017 at 2:19 pm #17032
    wojtek t
    Participant

    1.0.1 is the latest publicly available firmware on these modules…

    February 13, 2017 at 3:12 am #17034
    lorawan2016
    Participant

    There’s version 1.0.4 now and that’s why I consider version 1.0.1 is an old version.

    February 13, 2017 at 3:17 am #17035
    Yuqian Li
    Participant

    Hi Lorawan2016
    Thank you, i will try it and let you know results 🙂

    February 13, 2017 at 4:42 am #17039
    Yuqian Li
    Participant

    Hi Lorawan2016,
    Hmm, where I can find the RN2483 1.0.4 firmware? thank you.

    February 13, 2017 at 6:48 am #17041
    lorawan2016
    Participant

    Hi Yuqian,

    I have heard from one of sales engineers last week that class A and class C is released in one firmware and the version for that firmware is 1.0.4 but I don’t know how to get it.

    The idea is not to upgrade the firmware on Microchip module but as I wrote in my previous messages is to downgrade the firmware on the gateway to earlier versions and check if it works. This way we can narrow down the issue and it would be easier to track it.

    The strange thing is that there’s no official comment on this problem and why?

    February 13, 2017 at 9:02 am #17051
    Jon Pearce
    Participant

    Hello All,

    To add a little clarity here for RN2483 firmware:
    Current production/shipping is version 1.0.1 (certified to LoRaWANv1.0.0)
    In the next weeks, there will be a new 1.0.3 (certified to LoRaWANv1.0.1)

    There is no 1.0.4 firmware for RN2483 other than a class C prototype, which is being used for internal validation testing only and most likely won’t be productised until the Alliance is ready to certify class C (~ mid-2017).

    Microchip & Multitech did work together on interop testing around 1 year ago and all was working fine. I’m not aware of any regression with newer versions.

    My first suggestion, just because I didn’t see it specified in the original post, would be to check the Sync word. RN2483 defaults to 0x34 (public network) but maybe Conduit is using 0x12 (private network).

    RN2483 Command: mac set sync 12

    Second suggestion would be to clarify the correct keys/EUIs are being used, as Microchip & Multitech have different terminology. From my notes:

    LoRaWAN -> Multitech
    AppKey -> Key (Network Key)
    AppEUI -> EUI (Network ID)
    DevEUI -> Taken from device during OTAA request

    Although I must admit that when I did this, I used the same value for both AppEUI and DevEUI, so worth checking this.

    February 13, 2017 at 9:47 am #17058
    wojtek t
    Participant

    Jon,
    It all makes sense, but we don’t want to operate as private network “mac set sync 12”. We are making some additional tests and it seems that the devil is in the new network server implementation from Multitech. Basically, the old and the new packet forwarders behave the same way if using a 3rd party Lora bridge and network servers. It more less works, indicating that the packet forwarder code is fine (as expected). More to come, as Yuqian is testing other combinations. On the RN2483 we use the latest RC…so we should be alright .

    Wojtek

    February 13, 2017 at 10:27 am #17062
    Peter Ferland
    Blocked

    Microchip & Multitech did work together on interop testing around 1 year ago and all was working fine. I’m not aware of any regression with newer versions.

    And the same 868/915 LoRa Motes are used to validate each Conduit LoRa software update. During an investigation of this issue it was found that we never updated the firmware on the motes so testing was always performed on firmware version 1.0.0 dated October 2015. Testing is now being done on RN2483 firmware 1.0.1. I will update you as soon as I get results.

    February 13, 2017 at 10:48 am #17065
    lorawan2016
    Participant

    Thanks Jon and Peter … finally we see the official response on this track.

    I have just tested OTAA with RN2483/firmware version 1.0.1 with Conduit gateway firmware version 1.3.2 and it works from the first run.
    I will do more tests to check if it’s reliable in long run or I would get no-free-ch or denied messages as Yuqian is experiencing.

    February 13, 2017 at 10:53 am #17066
    Jon Pearce
    Participant

    It all makes sense, but we don’t want to operate as private network “mac set sync 12″

    Understood. I was just flagging Sync Word as one of those parameters that needs to match at both ends of the link. Its often over-looked because the use of 0x12 is kind of “de facto”. I.e. not officially in the LoRaWAN spec.

  • Author
    Posts
Viewing 30 posts - 1 through 30 (of 51 total)
1 2
  • You must be logged in to reply to this topic.