IRC +QIRD reports incorrect source address?

Technical Subjects Software Internet Protocol
1

Trying out some IPv6, on both BG96 and EG25, and I’m seeing something strange.

Initial setup & check of modem firmware version:

at+cgmr
EG25GGBR07A07M2G

OK
at+qicsgp=1,2,"myapn"
OK
at+qiact=1
OK
at+qiact?
+QIACT: 1,1,2,"2607:FB90:27D1:7C41:0:3E:5E74:6A01"

OK

…so, this all looks ok. We are on the network and have been given an IP address.

Set up a UDP socket:

at+qiopen=1,1,"UDP SERVICE","::",0,31314,0
OK

+QIOPEN: 1,0
at+qistate
+QISTATE: 1,"UDP SERVICE","2607:FB90:27D1:7C41:0:3E:5E74:6A01",0,31314,2,1,1,0,"uart1"

OK

Nice, socket all open. I’m using “::” for the any address here, but have also tried “127.0.0.1” as recommended in the docs and also explicitly specifying the local address as returned by qiact. The behavior does not change.

Now, from the IPv6 host I’m using, I’ll check the host’s IP, and then send a UDP packet to the device:

[ec2-user@ip-10-0-0-131 ~]$ ifconfig eth0 | grep inet6
        inet6 2600:1f15:b06:3400:cfde:be7d:a6a:cba8  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::41a:83ff:fee2:e59c  prefixlen 64  scopeid 0x20<link>
[ec2-user@ip-10-0-0-131 ~]$ echo test | nc -6 -u 2607:FB90:27D1:7C41:0:3E:5E74:6A01 31314

…this packet is successfully received, and I retrieve it with at+qird:

+QIURC: "recv",1
at+qird=1,100
+QIRD: 5,"0:0:CFDE:BE7D:0:0:2600:1F15",57190
test


OK

…but, the source IP is wrong. Source IP is half zeros, and all mixed up:

2600:1f15:0b06:3400:cfde:be7d:0a6a:cba8 - should be this
0000:0000:cfde:be7d:0000:0000:2600:1f15 - is reported as this by QIRD

Am I missing something, or is this a bug? Not being able to verify the source IP on a received packet is pretty bad.

1 Like
2

Hi Hugo,

That should be a bug of IPV6 address display issue. We need to R&D to fix this issue in next version.

Could you also check what AT+QISTATE return after you receive incoming UDP message?

Besyt Regards,

3

Here’s a log; the unit was still powered up, but the QIACT APN had gone down.

There does not appear to be a URC that is generated in this event though - do you need to poll QIACT? to check that the socket is still valid when you are waiting for data? (obviously, if you are trying to send packets, you would get an error when the context is deactivated).

Address has obviously changed since yesterday, but the result is the same. The commands were all issued right after each other so you can see that QISTATE and the local IP address have not changed, and it is just QIRD that is reporting the incorrect address.

at+qiact?
OK
at+qiact=1
OK
at+qiact?
+QIACT: 1,1,2,"2607:FB90:27DD:10B4:0:3E:5EDB:A901"

OK
at+qiopen=1,1,"UDP SERVICE","::",0,31314,0
OK

+QIOPEN: 1,0
at+qistate
+QISTATE: 1,"UDP SERVICE","2607:FB90:27DD:10B4:0:3E:5EDB:A901",0,31314,2,1,1,0,"uart1"

OK

+QIURC: "recv",1
at+qistate
+QISTATE: 1,"UDP SERVICE","2607:FB90:27DD:10B4:0:3E:5EDB:A901",0,31314,2,1,1,0,"uart1"

OK
at+qird=1,100
+QIRD: 29,"0:0:CFDE:BE7D:0:0:2600:1F13",37526
Tue Mar 31 16:43:27 UTC 2020


OK
at+qistate
+QISTATE: 1,"UDP SERVICE","2607:FB90:27DD:10B4:0:3E:5EDB:A901",0,31314,2,1,1,0,"uart1"

OK

This is happening on (at least) EG25 and BG96. I can maybe try BG95 too, but this is a pretty quick test to perform.

(note here I am sending the output of the date command over UDP to the EG25)

4

Regarding the QIACT your described, it’s just a display format as desgined. Even you didn’t AT+QIACT=1 command the PDN context is still there. You could use AT+CGCONTRDP to check activated PDN. You could also use QIOPEN directly without QIACT.

at+qiact?
OK
at+qiact=1
OK
at+qiact?
+QIACT: 1,1,2,“2607:FB90:27DD:10B4:0:3E:5EDB:A901”

5

Ok, I’ll check that but it’s confusing that at+qiact? returns nothing, but then if I activate it shows me the IP address. That implies that there are no active contexts?

6

Yes. That’s expected. You should use AT+CGCONTRDP to check the PDN context.

In 3G mode, it’s required to use AT+QIACT to activate network. But in 4G, at least one PDN context being activated is mandatory. So as long as device register to network, PDN context is always activated unless your have multi PDN context.

7

BG96 on Verizon
This or a similar issue seems to also be relevant to IPv4. I can activate context, check IP address, then open a UDP SERVICE" socket service. Remotely this socket is inaccessible. If I send data out from that socket the IPv4 address and port values seen at a remote test node are different from the values used to open the socket service.

On the remote test node, if the observed values for IP address and port of the BG96 UDP SERVICE socket are used to send a test packet, the BG96 can receive the UDP packet.

AT+QIACT?

+QIACT: 1,1,1,"100.74.142.26"

OK
AT+QISTATE

+QISTATE: 0,"UDP SERVICE","100.74.142.26",0,9000,2,1,0,1,"usbmodem"

OK
AT+QISEND=0,5,"97.83.32.119",9011

> 12345
SEND OK

Receive at test node sees the above send from 174.230.21.64:9316 (addr:port). If the remote attempts to send to 100.74.142.26:9000 it fails to be received at the BG96; if the remote sends to 174.230.21.64:9316 the BG96 receives the packet.

Thanks,
Greg

8

Hi Greg,

For UDP service mode, you need to set IP address to “127.0.0.1”.

Best Regards,

9

Thank you for the response Willie. I apologize for not showing the AT+QIOPEN (AT+QIOPEN=1,0,“UDP SERVICE”,“127.0.0.1”,0,9000,1). Additionally I now see that the original question was about IRD response AND more importantly I now know my problem is a network operator issue. Verizon requires static IP addressing on the line (as does other carriers I just found) for this to work. So my bad.

Best

1 Like