Same board version, same findings, haven’t poked it with a scope yet but I’ve tried a couple of i2c devices I know are working both with and without onboard pullups (It’s a thing, I swear)
Set up i2c-gpio-custom on pins 17/16 in stock firmware using the command: insmod i2c-gpio-custom bus0=0,17,16
Dmesg says all good:
[ 2506.502225] i2c-gpio i2c-gpio.1: using pins 17 (SDA) and 16 (SCL)
And am probing the bus with force-installed i2c-tools:
root@GL-AR300M:~# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Notably I had to unexport GPIO16 (echo 16 > /sys/class/gpio/unexport) before I could successfully set up a bitbanged i2c bus on these pins at all.
Pulling the SDA pin low yields the following (basically fake ACK on all scanned addresses), suggesting it’s connected appropriately:
root@GL-AR300M:~# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77
Swapping SDA/SCL and doing the same trick gives the same results, so I know both pins are doing something, unfortunately that something does not appear to be a functional i2c bus.
Using i2cdetect -q 0 doesn’t fare any better (I know most of my sensors are safe with this.)
Tried a bunch of the extra parameters as defined in openwrt/i2c-gpio-custom.c at openwrt-19.07 · openwrt/openwrt · GitHub - normally “udelay” is how you hit a specific baudrate if your sensors are weird and slow but no dice here.
Maybe I should grab my scope 
Edit: With a scope attached I can see either DAT or CLK on GPIO16 depending on how I configure the bitbanged i2c, but I cannot drive GPIO17 low either with i2c traffic or by exporting via /sys/class/gpio and setting a value manually.