Hi Daryll,

If you submitted the update request in the month of November only, I'd suggest you wait for another week as most of them have a monthly cycle of db recompilation. And it might take another couple of days for the new copy of db to propagate among whoever is using them for validation. And if the request was submitted in October, I think you will need someone from Jio to help with the exact cause. Or does anyone else on this list have any suggestions?

ps: if you have multiple upstreams you could also test by routing via one at a time, just to be sure any intermediary network is not dropping your prefix.

Thank you.
Rahul

On Mon, Nov 29, 2021 at 2:06 PM Daryll Swer <contact@daryllswer.com> wrote:
Hi Rahul

It seems some (if not most or all) of the GeoIP platforms have picked up on the prefix's correct location/origin AS.

However, there are no changes with the VoWiFi issues with Jio, what would you recommend?

image.png
Side note: IPv6 was disabled temporarily for this test :)

--
Best Regards
Daryll J. L. Swer
Mobile Number: +91 700 592 0360


On Mon, 22 Nov 2021 at 23:21, Daryll Swer <contact@daryllswer.com> wrote:
Hi Rahul

That sounds about right.

And yes, the first thing I did after prefix allocation was shoot an email to the major platforms for GeoIP Data along with filling out their correction forms, 80% of them have accepted.

I believe it may take some time to propagate around the internet,

I will revisit this issue once the propagation is done.

Thanks for your help

--
Best Regards
Daryll J. L. Swer
Mobile Number: +91 700 592 0360


On Mon, 22 Nov 2021 at 22:54, Rahul Makhija <rahul.m@estointernet.in> wrote:
Hi Daryll

Your prefix being filtered out is very likely. As location information for this prefix is not available in any of the popular Geolocation databases. I'd suggest you update the records with geolocation DBs to make this prefix "legit". I believe that should fix your issue.

On Mon, Nov 22, 2021 at 9:57 PM Daryll Swer <contact@daryllswer.com> wrote:
Hi Rahul

As I suspected, it looks like they are filtering/dropping my prefix, presumably as it was previously unallocated/bogon.

tracepath -p 4500 49.44.59.38
 1?: [LOCALHOST]                      pmtu 1500
 1:  103.176.189.33                                        1.357ms
 1:  103.176.189.33                                        0.641ms
 2:  36.255.84.36                                          3.455ms
 3:  103.16.68.10                                          2.025ms
 4:  no reply
 5:  115.112.9.29.STATIC-Bangalore.vsnl.net.in             2.351ms asymm  3
 6:  no reply
 7:  115.112.8.118.STATIC-Chennai.vsnl.net.in              9.784ms asymm  8
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500


--
Best Regards
Daryll J. L. Swer
Mobile Number: +91 700 592 0360


On Mon, 22 Nov 2021 at 21:37, Rahul Makhija <rahul.m@estointernet.in> wrote:
Hi Daryll

If the protocol in use is UDP, on a linux machine you could use tracepath which allows you to specify dest port as well. Following is the output on my ubuntu machine.

rahul@server:~$ tracepath -p 4500 49.44.59.38
 1?: [LOCALHOST]                      pmtu 1500
 1:  ???                                                   0.821ms
 1:  no reply
 2:  ???                                                   1.307ms
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  49.44.59.38                                          37.638ms reached
     Resume: pmtu 1500 hops 22 back 7

Can you try the same & check if you're able to reach UDP:4500 on the same destination?

On Mon, Nov 22, 2021 at 8:06 PM Daryll Swer <contact@daryllswer.com> wrote:
Hi Rahul

I determined the following is used:
49.44.59.38 over UDP port 4500.

It looks like AS55836 only accepts UDP connections to those IP addresses and hence TCP pings fails. Any further suggestions?

PS C:\Users\daryl\Desktop\PSTools> ./tcping64.exe -p 4500 49.44.59.38

Probing 49.44.59.38:4500/tcp - No response - time=2010.300ms
Probing 49.44.59.38:4500/tcp - No response - time=2014.373ms
Probing 49.44.59.38:4500/tcp - No response - time=2014.485ms
Probing 49.44.59.38:4500/tcp - No response - time=2014.512ms

Ping statistics for 49.44.59.38:4500
     4 probes sent.
     0 successful, 4 failed.  (100.00% fail)
Was unable to connect, cannot provide trip statistics.
PS C:\Users\daryl\Desktop\PSTools> ./tcping64.exe -p 443 49.44.59.38

Probing 49.44.59.38:443/tcp - No response - time=2013.617ms
Probing 49.44.59.38:443/tcp - No response - time=2001.272ms
Probing 49.44.59.38:443/tcp - No response - time=2015.632ms
Probing 49.44.59.38:443/tcp - No response - time=2002.627ms

Ping statistics for 49.44.59.38:443
     4 probes sent.
     0 successful, 4 failed.  (100.00% fail)
Was unable to connect, cannot provide trip statistics.
PS C:\Users\daryl\Desktop\PSTools> ./tcping64.exe -p 80 49.44.59.38

Probing 49.44.59.38:80/tcp - No response - time=2012.398ms
Probing 49.44.59.38:80/tcp - No response - time=2014.021ms
Probing 49.44.59.38:80/tcp - No response - time=2014.230ms
Probing 49.44.59.38:80/tcp - No response - time=2008.071ms

Ping statistics for 49.44.59.38:80
     4 probes sent.
     0 successful, 4 failed.  (100.00% fail)
Was unable to connect, cannot provide trip statistics.


--
Best Regards
Daryll J. L. Swer
Mobile Number: +91 700 592 0360


On Mon, 22 Nov 2021 at 16:08, Rahul Makhija <rahul.m@estointernet.in> wrote:
Have you tried wireshark? You could inspect each & every packet leaving your network/devices ( and port numbers thereof ).



On Mon, Nov 22, 2021 at 4:00 PM Daryll Swer <contact@daryllswer.com> wrote:
Hi Rahul

I agree with you and TCP Traceroute/Ping was the first thing on my mind, but unfortunately, I'm unable to determine the port number.

--
Best Regards
Daryll J. L. Swer
Mobile Number: +91 700 592 0360
Website: daryllswer.com


On Mon, 22 Nov 2021 at 15:57, Rahul Makhija <rahul.m@estointernet.in> wrote:
Hi Daryll,

Ping is never the ideal tool to conclude if you're able to reach any given destination. Especially ICMP, this is quite common practice to block ICMP responses. I too am not able to "ping" the same host from AS135817 but Jio VoWIFI works just fine for me.

Maybe you want to do a tcp traceroute on the intended port number ( I'm not sure which port number is being used here for VoWiFi ). You'll surely find more useful information.

Thank you.
Rahul

On Mon, Nov 22, 2021 at 3:39 PM Daryll Swer via INNOG <innog@innog.net> wrote:
Hi Folks

Does anybody know who I can reach out to for the following issue?

My freshly allocated prefix (103.176.189.0/24) is unable to communicate with Reliance Jio's VoWiFi end-point on AS55836. And hence my Jio numbers are unable to work with VoWiFi when the source IPv4 address is originating from 103.176.189.0/24.
image.png

--
Best Regards
Daryll J. L. Swer
Mobile Number: +91 700 592 0360
_______________________________________________
INNOG mailing list -- innog@innog.net
To unsubscribe send an email to innog-leave@innog.net