[John Greene]

I see that now, Jason. Not enough coffee this morning I guess. Thanks for your timely response.

[John Greene]

Thanks, Jason. What about the “defaultKey” parameter for the CMAC? Where do we get it?

[John Greene]

Thanks, Jason. In the post you linked to showing the calculations, I am not aware of how to do the CMAC. I have looked around but unfortunately my cryptography skills are quite lacking. Do you know of a good resource for me to use to calculate it?

[John Greene]

Understood, Jason. Thanks for the feedback/guidance.

[John Greene]

Thanks for the feedback, Ryan and Jason. Unfortunately, we are still spinning our wheels on this problem. I am wondering if we might ought to shelve trying to implement the RS485 driver we have and see if we can implement MTSSerial instead. Are you aware of anyone who has used MTSSerial in ways outside of the specific AT command intended use case? And, if not, do you foresee us bumping into any problems using it? (FYI – we are using this RS485 transceiver http://www.ti.com/lit/ds/symlink/sn65hvd1781.pdf)

[John Greene]

Definition:

********************************************************************************************
;	Function:		INT_USART1_TX_Handler
;	Description:	USART1 TX interrupt service routine 
;	Inputs: 	 	Nothing
;	Returns:		Nothing	 
**********************************************************************************************/
void INT_USART1_TX_Handler (void)
{
	while(USART1_DATA.pSerialPort->writeable()) { 
		/* Process TX SOFTWARE FIFO */
		if(USART1_DATA.txTail != USART1_DATA.txHead) {
			USART1_DATA.pSerialPort->putc(USART1_DATA.txBuffer[USART1_DATA.txTail++]);
			if(USART1_DATA.txTail >= USART1_TX_SOFT_FIFO_LENGTH) USART1_DATA.txTail =0;
			USART1_DATA.txCnt++;
		} else {
			USART1_DATA.transferState = USART1_TRANSFER_COMPLETE;
			if(USART1_DATA.transferComplete)
				USART1_DATA.transferComplete();
			break;
		}
	}
}

• This reply was modified 5 years, 5 months ago by John Greene.

[John Greene]

It is the serial interrupt function in the USART initialization:

/********************************************************************************************
; Function: USART1_IntInit
; Description: Initializes USART1
; Inputs: ULONG – baud rate
; UBYTE – control word (parity, stop, word length)
; UBYTE – fifo control word
; Returns: SUCCESS – SUCCESS
***********************************************************************************************/
ERRCODE USART1_IntInit(UCB* ucb)
{
ERRCODE ec = SUCCESS;
/* Initialize SOFTWARE FIFO */
USART1_DATA.rxHead = USART1_DATA.rxTail =0;
USART1_DATA.txHead = USART1_DATA.txTail =0;
USART1_DATA.errors=0;
USART1_DATA.overflows=0;
USART1_DATA.rxCnt=0;
USART1_DATA.txCnt=0;
USART1_DATA.transferState = USART1_TRANSFER_COMPLETE;
USART1_DATA.transferComplete = ucb->transferComplete;
USART1_DATA.rxSignal = ucb->rxSignal = NULL;
USART1_DATA.rxSignalParameter = ucb->rxSignalParameter = NULL;
USART1_DATA.txSignal = ucb->txSignal = NULL;
USART1_DATA.txSignalParameter = ucb->txSignalParameter = NULL;
//
ucb->getRxCounter = USART1_GetRxCounter;
ucb->getTxCounter = USART1_GetTxCounter;
ucb->setData = USART1_SetData;
ucb->getData = USART1_GetData;
ucb->setFiFoData = USART1_SetFiFoData;
ucb->getFiFoData = USART1_GetFiFoData;
ucb->isTxFiFoAvailable = USART1_IsTxFiFoAvailable;
ucb->getErrors = USART1_GetErrors;
ucb->getOverflows = USART1_GetOverflows;
ucb->getRxCnt = USART1_GetRxCnt;
ucb->getTxCnt = USART1_GetTxCnt;
//
/* Initialize UART interface */
switch(ucb->iface) {
case SERIALAPI_USART1_INTERFACE:
break;
default:
ec = SERIALAPI_INTERFACE_ERROR;
break;
}
if (ec) goto func_end;
//
switch(ucb->word_length) {
case SERIALAPI_WORLD_LENGTH_8:
break;
default:
ec = SERIALAPI_WORD_LENGTH_ERROR;
break;
}
if (ec) goto func_end;
//
switch(ucb->stop) {
case SERIALAPI_STOP_1:
break;
default:
ec = SERIALAPI_STOP_ERROR;
break;
}
if (ec) goto func_end;
//
switch(ucb->parity) {
case SERIALAPI_PARITY_NO:
break;
default:
ec = SERIALAPI_PARITY_ERROR;
break;
}
USART1_DATA.pSerialPort = &USART1_PORT;
USART1_DATA.pSerialPort->baud(ucb->baudRate);
// Setup a serial interrupt function to receive data
USART1_DATA.pSerialPort->attach(&INT_USART1_RX_Handler, Serial::RxIrq);
// Setup a serial interrupt function to transmit data
USART1_DATA.pSerialPort->attach(&INT_USART1_TX_Handler, Serial::TxIrq);
func_end:
return ec;
}

[John Greene]

Any guidance on what needs to be done on the Conduit (AEP 1.6.2) for FOTA?

[John Greene]

Looks like it was the setting on the Conduit, Jason. We switched from the default setting of “Private MTS” to “Private LoRaWAN” and things seem to be working now. Thanks for that.

As for the SPIFFS errors, Ryan, yes, we always seem to have a lot of them. We were pretty sure corruption of the Mdot flash was not an issue as we duplicated the error on multiple Mdots and the old FW always worked. So, I am not sure how we resolve the SPIFFS errors issue but as they are not (or at least don’t seem to be) affecting things at the moment, we are going to leave their resolution for another day.

As always, your timely responses are much appreciated.

[John Greene]

Thanks for that, Jason. To further clarify, though: the email references “New Features in Software Release 1.6.” Is this the version of AEP? I ask because the most recent version of AEP on the downloads site (http://www.multitech.net/developer/downloads/) is 1.4.17.

Also, re the libmDot you mention: the FUOTA/Multicast functionality appears to be available in the frequently updated libmDot-dev (https://os.mbed.com/teams/MultiTech/code/libmDot-dev-mbed5/). Presuming the functionality will be available in the next release (ie, v3.0 is upgraded to v3.1), when is that release anticipated? IOW, will libmDot be upgraded concurrently with the AEP upgrade scheduled for August per the email?

[John Greene]

Sorry, I mistyped. It was really LoRaWAN 1.1 I had meant to ask about.

Thanks for the timely response.

[John Greene]

I used GCC-4.9 2015q3 because that is what was apparently used to compile mbed-0S-5.4.7 which, in turn, was used for mdot-library rev 3.0.0. I also tried with GCC-6 2017-q2-update the resultant log for which I provided upthread.

I just switched back to GCC-4.9 and ran it again before clicking “Submit” on this thread and it worked. Who knows, most likely user error. Thanks for your feedback/help.

[John Greene]

Please disregard above as I figured out that a second connection from the UDK’s DB9 connector was necessary to send the AT commands to the mDot.

[John Greene]

To add to my last post on this thread, the port that appears when I plug in the USB from the UDK is described as “STMicroelectronics STLink Virtual Com Port (COM5)” which we used to update mDots on a custom board via the 9-pin programming configuration. I have tried to disable and uninstall both the device and driver but for whatever reason the same description keeps appearing and am still unable to get tera term to respond.

One other item of note: the device itself is being recognized in some fashion as a popup appears with “Multitech” described as the storage device on the D:\ drive.

[John Greene]

After doing the above, I get:

[ERROR] File from flash wrong size. Expected 256 – Actual 128
[INFO] mDot Ready

I am still unable to type anything into the tera term terminal, though. Any ideas?

[John Greene]

Thanks for the feedback, Steve. AT&T is saying they do not offer SIM cards provisioned with public static IP addresses, though. Does that sound right to you? If so and presuming Multitech has customers with AT&T Conduits who are managing those Conduits remotely, how are they doing so? If that does not sound right, though, does Multitech have a contact at AT&T we can talk to about getting our SIMs properly provisioned?

[John Greene]

How is AppEUI created and/or assigned? We can see one in the LoRa JSON record but not sure where it comes from. We tried converting it from hex to text but the result is indecipherable/seems meaningless.

[John Greene]

Jeff,

Following is the tcpdump on ppp0. Unfortunately, my tcpdump interpretive skills are a bit lacking. While I am researching, any feedback/hints you might be able to give that might help point us in the right direction would be greatly appreciated.

admin@mtcdt:~# tcpdump -i ppp0 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:16:09.955606 IP (tos 0x0, ttl 64, id 38569, offset 0, flags [DF], proto UDP (17), length 75)
10.53.230.46.13489 > google-public-dns-a.google.com.domain: 41116+ A? VBIOTHUB001.azure-devices.net. (47)
14:16:09.955969 IP (tos 0x0, ttl 64, id 34618, offset 0, flags [DF], proto UDP (17), length 75)
10.53.230.46.13489 > google-public-dns-b.google.com.domain: 41116+ A? VBIOTHUB001.azure-devices.net. (47)
14:16:10.234860 IP (tos 0x58, ttl 56, id 52527, offset 0, flags [none], proto UDP (17), length 131)
google-public-dns-a.google.com.domain > 10.53.230.46.13489: 41116 2/0/0 VBIOTHUB001.azure-devices.net. CNAME ihsu-prod-by-002.cloudapp.net., ihsu-prod-by-002.cloudapp.net. A 104.40.49.44 (103)
14:16:10.235041 IP (tos 0x58, ttl 56, id 23505, offset 0, flags [none], proto UDP (17), length 131)
google-public-dns-b.google.com.domain > 10.53.230.46.13489: 41116 2/0/0 VBIOTHUB001.azure-devices.net. CNAME ihsu-prod-by-002.cloudapp.net., ihsu-prod-by-002.cloudapp.net. A 104.40.49.44 (103)
14:16:10.237000 IP (tos 0x0, ttl 64, id 47542, offset 0, flags [DF], proto TCP (6), length 60)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [S], cksum 0x4579 (correct), seq 2686456706, win 29200, options [mss 1460,sackOK,TS val 109108 ecr 0,nop,wscale 5], length 0
14:16:10.582955 IP (tos 0x0, ttl 64, id 38577, offset 0, flags [DF], proto UDP (17), length 71)
10.53.230.46.63275 > google-public-dns-a.google.com.domain: 5028+ PTR? 46.230.53.10.in-addr.arpa. (43)
14:16:10.707673 IP (tos 0x58, ttl 56, id 3608, offset 0, flags [none], proto UDP (17), length 71)
google-public-dns-a.google.com.domain > 10.53.230.46.63275: 5028 NXDomain 0/0/0 (43)
14:16:10.710373 IP (tos 0x58, ttl 108, id 10000, offset 0, flags [DF], proto TCP (6), length 60)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [S.], cksum 0xb138 (correct), seq 221732293, ack 2686456707, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 32995737 ecr 109108], length 0
14:16:10.710746 IP (tos 0x0, ttl 64, id 47543, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [.], cksum 0xfbf5 (correct), ack 1, win 913, options [nop,nop,TS val 109155 ecr 32995737], length 0
14:16:10.712627 IP (tos 0x0, ttl 64, id 47544, offset 0, flags [DF], proto TCP (6), length 221)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [P.], cksum 0x15ff (correct), seq 1:170, ack 1, win 913, options [nop,nop,TS val 109155 ecr 32995737], length 169
14:16:10.798944 IP (tos 0x58, ttl 108, id 10001, offset 0, flags [DF], proto TCP (6), length 1420)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [.], cksum 0x12fa (correct), seq 1:1369, ack 170, win 513, options [nop,nop,TS val 32995745 ecr 109155], length 1368
14:16:10.799341 IP (tos 0x0, ttl 64, id 47545, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [.], cksum 0xf589 (correct), ack 1369, win 1003, options [nop,nop,TS val 109164 ecr 32995745], length 0
14:16:10.803928 IP (tos 0x58, ttl 108, id 10002, offset 0, flags [DF], proto TCP (6), length 1420)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [.], cksum 0x2f5b (correct), seq 1369:2737, ack 170, win 513, options [nop,nop,TS val 32995745 ecr 109155], length 1368
14:16:10.804236 IP (tos 0x0, ttl 64, id 47546, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [.], cksum 0xefd5 (correct), ack 2737, win 1094, options [nop,nop,TS val 109165 ecr 32995745], length 0
14:16:10.804367 IP (tos 0x58, ttl 108, id 10003, offset 0, flags [DF], proto TCP (6), length 895)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [P.], cksum 0x9887 (correct), seq 2737:3580, ack 170, win 513, options [nop,nop,TS val 32995745 ecr 109155], length 843
14:16:10.804715 IP (tos 0x0, ttl 64, id 47547, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [.], cksum 0xec35 (correct), ack 3580, win 1179, options [nop,nop,TS val 109165 ecr 32995745], length 0
14:16:10.924826 IP (tos 0x0, ttl 64, id 47548, offset 0, flags [DF], proto TCP (6), length 198)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [P.], cksum 0x77a3 (correct), seq 170:316, ack 3580, win 1179, options [nop,nop,TS val 109177 ecr 32995745], length 146
14:16:10.944570 IP (tos 0x0, ttl 64, id 47549, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [F.], cksum 0xeb94 (correct), seq 316, ack 3580, win 1179, options [nop,nop,TS val 109179 ecr 32995745], length 0
14:16:10.980757 IP (tos 0x0, ttl 64, id 61973, offset 0, flags [DF], proto TCP (6), length 60)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [S], cksum 0x1779 (correct), seq 2297190507, win 29200, options [mss 1460,sackOK,TS val 109182 ecr 0,nop,wscale 5], length 0
14:16:11.006680 IP (tos 0x58, ttl 108, id 10004, offset 0, flags [DF], proto TCP (6), length 111)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [P.], cksum 0x11ce (correct), seq 3580:3639, ack 316, win 512, options [nop,nop,TS val 32995767 ecr 109177], length 59
14:16:11.007061 IP (tos 0x58, ttl 64, id 124, offset 0, flags [DF], proto TCP (6), length 40)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [R], cksum 0xc861 (correct), seq 2686457022, win 0, length 0
14:16:11.022686 IP (tos 0x58, ttl 108, id 10005, offset 0, flags [DF], proto TCP (6), length 52)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [.], cksum 0xeddc (correct), ack 317, win 512, options [nop,nop,TS val 32995769 ecr 109179], length 0
14:16:11.023082 IP (tos 0x58, ttl 64, id 125, offset 0, flags [DF], proto TCP (6), length 40)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [R], cksum 0xc860 (correct), seq 2686457023, win 0, length 0
14:16:11.023201 IP (tos 0x58, ttl 108, id 10006, offset 0, flags [DF], proto TCP (6), length 52)
104.40.49.44.8883 > 10.53.230.46.34357: Flags [F.], cksum 0xeddb (correct), seq 3639, ack 317, win 512, options [nop,nop,TS val 32995769 ecr 109179], length 0
14:16:11.023618 IP (tos 0x58, ttl 64, id 126, offset 0, flags [DF], proto TCP (6), length 40)
10.53.230.46.34357 > 104.40.49.44.8883: Flags [R], cksum 0xc860 (correct), seq 2686457023, win 0, length 0
14:16:11.047669 IP (tos 0x58, ttl 108, id 27435, offset 0, flags [DF], proto TCP (6), length 60)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [S.], cksum 0x015a (correct), seq 2305905614, ack 2297190508, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 33130802 ecr 109182], length 0
14:16:11.048047 IP (tos 0x0, ttl 64, id 61974, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x4c3f (correct), ack 1, win 913, options [nop,nop,TS val 109189 ecr 33130802], length 0
14:16:11.049574 IP (tos 0x0, ttl 64, id 61975, offset 0, flags [DF], proto TCP (6), length 221)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0xf567 (correct), seq 1:170, ack 1, win 913, options [nop,nop,TS val 109189 ecr 33130802], length 169
14:16:11.130033 IP (tos 0x58, ttl 108, id 27436, offset 0, flags [DF], proto TCP (6), length 1420)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [.], cksum 0x4d62 (correct), seq 1:1369, ack 170, win 513, options [nop,nop,TS val 33130810 ecr 109189], length 1368
14:16:11.130377 IP (tos 0x0, ttl 64, id 61976, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x45d4 (correct), ack 1369, win 1003, options [nop,nop,TS val 109197 ecr 33130810], length 0
14:16:11.134403 IP (tos 0x58, ttl 108, id 27437, offset 0, flags [DF], proto TCP (6), length 1420)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [.], cksum 0x7fa4 (correct), seq 1369:2737, ack 170, win 513, options [nop,nop,TS val 33130810 ecr 109189], length 1368
14:16:11.134811 IP (tos 0x0, ttl 64, id 61977, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x4020 (correct), ack 2737, win 1094, options [nop,nop,TS val 109198 ecr 33130810], length 0
14:16:11.134941 IP (tos 0x58, ttl 108, id 27438, offset 0, flags [DF], proto TCP (6), length 895)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0x6ffa (correct), seq 2737:3580, ack 170, win 513, options [nop,nop,TS val 33130810 ecr 109189], length 843
14:16:11.135209 IP (tos 0x0, ttl 64, id 61978, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x3c80 (correct), ack 3580, win 1179, options [nop,nop,TS val 109198 ecr 33130810], length 0
14:16:11.310418 IP (tos 0x0, ttl 64, id 61979, offset 0, flags [DF], proto TCP (6), length 198)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0x7374 (correct), seq 170:316, ack 3580, win 1179, options [nop,nop,TS val 109215 ecr 33130810], length 146
14:16:11.397674 IP (tos 0x58, ttl 108, id 27439, offset 0, flags [DF], proto TCP (6), length 111)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0xdba0 (correct), seq 3580:3639, ack 316, win 512, options [nop,nop,TS val 33130837 ecr 109215], length 59
14:16:11.397996 IP (tos 0x0, ttl 64, id 61980, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x3b7e (correct), ack 3639, win 1179, options [nop,nop,TS val 109224 ecr 33130837], length 0
14:16:11.410963 IP (tos 0x0, ttl 64, id 61981, offset 0, flags [DF], proto TCP (6), length 430)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0x45f0 (correct), seq 316:694, ack 3639, win 1179, options [nop,nop,TS val 109225 ecr 33130837], length 378
14:16:11.508708 IP (tos 0x58, ttl 108, id 27440, offset 0, flags [DF], proto TCP (6), length 89)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0x352f (correct), seq 3639:3676, ack 694, win 510, options [nop,nop,TS val 33130848 ecr 109225], length 37
14:16:11.519449 IP (tos 0x0, ttl 64, id 61982, offset 0, flags [DF], proto TCP (6), length 254)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0xd4c3 (correct), seq 694:896, ack 3676, win 1179, options [nop,nop,TS val 109236 ecr 33130848], length 202
14:16:11.594712 IP (tos 0x58, ttl 108, id 27441, offset 0, flags [DF], proto TCP (6), length 89)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0x62a9 (correct), seq 3676:3713, ack 896, win 510, options [nop,nop,TS val 33130857 ecr 109236], length 37
14:16:11.595026 IP (tos 0x0, ttl 64, id 61983, offset 0, flags [DF], proto TCP (6), length 712)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0xc513 (correct), seq 896:1556, ack 3713, win 1179, options [nop,nop,TS val 109244 ecr 33130857], length 660
14:16:11.687666 IP (tos 0x58, ttl 108, id 27442, offset 0, flags [DF], proto TCP (6), length 89)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0xd2be (correct), seq 3713:3750, ack 1556, win 513, options [nop,nop,TS val 33130866 ecr 109244], length 37
14:16:11.687985 IP (tos 0x0, ttl 64, id 61984, offset 0, flags [DF], proto TCP (6), length 158)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0xbeda (correct), seq 1556:1662, ack 3750, win 1179, options [nop,nop,TS val 109253 ecr 33130866], length 106
14:16:11.767753 IP (tos 0x58, ttl 108, id 27443, offset 0, flags [DF], proto TCP (6), length 233)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0x915a (correct), seq 3750:3931, ack 1662, win 512, options [nop,nop,TS val 33130874 ecr 109253], length 181
14:16:11.790701 IP (tos 0x58, ttl 108, id 27444, offset 0, flags [DF], proto TCP (6), length 137)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [P.], cksum 0x1d82 (correct), seq 3931:4016, ack 1662, win 512, options [nop,nop,TS val 33130877 ecr 109253], length 85
14:16:11.791271 IP (tos 0x0, ttl 64, id 61985, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x3421 (correct), ack 4016, win 1265, options [nop,nop,TS val 109263 ecr 33130874], length 0
14:16:12.052501 IP (tos 0x0, ttl 64, id 61986, offset 0, flags [DF], proto TCP (6), length 126)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [P.], cksum 0x0459 (correct), seq 1662:1736, ack 4016, win 1265, options [nop,nop,TS val 109289 ecr 33130874], length 74
14:16:12.052830 IP (tos 0x0, ttl 64, id 61987, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [F.], cksum 0x33bc (correct), seq 1736, ack 4016, win 1265, options [nop,nop,TS val 109289 ecr 33130874], length 0
14:16:12.316726 IP (tos 0x58, ttl 108, id 27445, offset 0, flags [DF], proto TCP (6), length 52)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [.], cksum 0x3676 (correct), ack 1737, win 512, options [nop,nop,TS val 33130929 ecr 109289], length 0
14:16:12.318208 IP (tos 0x58, ttl 108, id 27446, offset 0, flags [DF], proto TCP (6), length 52)
104.40.49.44.8883 > 10.53.230.46.34358: Flags [F.], cksum 0x3675 (correct), seq 4016, ack 1737, win 512, options [nop,nop,TS val 33130929 ecr 109289], length 0
14:16:12.318641 IP (tos 0x0, ttl 64, id 170, offset 0, flags [DF], proto TCP (6), length 52)
10.53.230.46.34358 > 104.40.49.44.8883: Flags [.], cksum 0x3369 (correct), ack 4017, win 1265, options [nop,nop,TS val 109316 ecr 33130929], length 0
^C
52 packets captured
52 packets received by filter
0 packets dropped by kernel

[John Greene]

Jeff,

We are not doing any encryption. Signal strength appears to be maxed. We are using TCP. Also, the ratios of “raw data” packet size to “sent” and “received” sizes is consistent between tests so I don’t think any retransmission is happening.

John

[John Greene]

Jason,

I don’t see any AEP tar.gz files on the downloads page. Only zip files. The AEP 1.4.3 zip file contains “AEP-1.4.3_upgrade.bin”. Presuming that is the file to copy to /var/volatile/flash-upgrade, I don’t follow what you mean by “use instead of uImage and rootfs files.”

[John Greene]

Hey Tim,

We are looking to hook a couple of air pressure sensors to a cell signaling device. After a little more research this afternoon, I guess it would be a 4-20ma (current loop) sensor board that we would need to mount the Dragonfly (or whatever AT&T signalling device we use) on. We thought Libelium’s Waspmote might be a good option (using something other than a Dragonfly) but it only operates up to 120F.

[John Greene]

Appreciate the quick response, Peter. At risk of exposing myself as a total newb (duh!), is that a Multitech term? I’ve never heard it before nor does Google seem to know much about it.

[Author]

Posts