Why I decide to analyze these logs? Because I just say this entry in my:
/var/log/messages
Sep 2 21:59:44 g0n kernel: [141596.636754] mrfw_dropIN=eth1 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:21:04:87:ae:91:08:00 SRC=192.168.2.1
DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138
DPT=138 LEN=209
My iptables are not so poorly put together, and they don't just drop
packets for nothing. But this time it was just, after I ran this script:
ipt_conf_states.sh
to see what confs and states are in effect at the current stage of my
preparations... (I've been changing all kinds of confs these days... I put
that script in my /usr/local/bin to be able to run it more promptly)...
I just ran it, and if you take a gander into:
ipt_conf_states_160902_2245.d
you can see that it's nothing much, 192.168.2.0/24 are not allowed to udp,
nothing else. Old rules, going flushed and deleted for new rules for this
experiment.
However, that still reminded me of the rules that I saw the ZXDSL perform
(whether programmed --probably so-- or even some maintainer did something; not
excluding anything but what I know for fact, no matter the unlikeliness of the
latter).
I'll pick some of those. It remains mostly unclear what that commie router
did, but not completely unclear.
Here, I got the iptables command issued and recorded in the logs of my ZXDSL
in all of these:
# grep iptables /Cmn/m/B/mr_160*/ZTE* | cut -d':' -f1 | sort -u
/Cmn/m/B/mr_160825_g0n/ZTE_160822_1713.log
/Cmn/m/B/mr_160825_g0n/ZTE_160822_2000.log
/Cmn/m/B/mr_160825_g0n/ZTE_160822_2119.log
/Cmn/m/B/mr_160825_g0n/ZTE_160822_2158.log
/Cmn/m/B/mr_160825_g0n/ZTE_160822_2205.log
/Cmn/m/B/mr_160901_g0n/ZTE_160828_2326.log
/Cmn/m/B/mr_160901_g0n/ZTE_160829_2318.log
/Cmn/m/B/mr_160901_g0n/ZTE_160829_2322.log
/Cmn/m/B/mr_160901_g0n/ZTE_160830_1331.log
/Cmn/m/B/mr_160901_g0n/ZTE_160830_1453.log
#
Let's try and see some. The first one is:
/Cmn/m/B/mr_160825_g0n/ZTE_160822_1713.log
And it got in the logs:
2016-08-22T16:11:31 [Debug] cmd is ebtables -D PT_FORWARD -i nbif12 -p 0x8863 -j ACCEPT
2016-08-22T16:11:31 [Informational] fsm_close Interface ppp0, fsm: 0, state: 1, reason: LCP down(pppd:1942)
2016-08-22T16:11:31 [Informational] strCmd is: iptables -t mangle -F lanbindwan
2016-08-22T16:11:31 [Informational] Connection terminated.(pppd:1942)
2016-08-22T16:11:31 [Notice] sendprogstop: pppd[1942] died exit_code = 5 exit_status = 1
2016-08-22T16:11:31 [Debug] cmd is iptables -t mangle -F lanbindwan
2016-08-22T16:11:31 [Debug] invalid event!don't support wEvent :0x9c94
2016-08-22T16:11:31 [Informational] fwSfSASynMsg wEvent:EV_INTERFACE_UP/DEL/DOWN!
2016-08-22T16:11:31 [Informational] ptWlanNotifier->ifType:WAN_TYPE
2016-08-22T16:11:31 [Informational] fwSchedule wEvent:EV_INTERFACE_DOWN pChViewNameID:IGD.WD2.WCD1.WCPPP1
2016-08-22T16:11:31 [Debug] cmd is ebtables -D PT_FORWARD -i nbif12 -p 0x8864 -j ACCEPT
2016-08-22T16:11:31 [Debug] cmd is +CL+CL
2016-08-22T16:11:31 [Informational] ptFwSchedule->wOpID:EV_FW_EVDWSCHEDULE chItemID:IGD.FWNAT.8
2016-08-22T16:11:31 [Debug] cmd is ebtables -D PT_FORWARD -o nbif12 -p 0x8863 -j ACCEPT
2016-08-22T16:11:31 [Debug] cmd is iptables -t nat -D wansrcnat -s ! 93.142.82.128 -o ppp0 -j MASQUERADE
Have a look at that last one. Is that 93.142.82.128 IP my then public IP from
my provider's available public IPs to its customers? I'll have to ask if it
is.
What is clear is that whichever the agens (not sure if the splelling of that
word is right) of those iptables (and ebtables) lines (just regarding
ebtables, up until today I had the bridge br0 whose slave the eth2 was; only
saying it, the ebtables lines in these logs probably regard some bridge in the
router),
[whichever the agens], that line appears to be deleting the MASQUERADE if the
source is not 93.142.82.128 on interface ppp0.
Not at all in the clear though...
The second one is:
/Cmn/m/B/mr_160825_g0n/ZTE_160822_2000.log
2016-08-22T17:22:09 [Informational] strCmd is: ip rule add from 93.142.66.229 table 18 pref 20048
2016-08-22T17:22:09 [Debug] cmd is ip rule add from 93.142.66.229 table 18 pref 20048
2016-08-22T17:22:09 [Informational] strCmd is: ip route add 172.29.252.116/32 dev ppp0 table 18
2016-08-22T17:22:09 [Debug] cmd is ip route add 172.29.252.116/32 dev ppp0 table 18
2016-08-22T17:22:09 [Informational] strCmd is: ip route flush cache
2016-08-22T17:22:09 [Informational] strCmd is: ip route add default via 172.29.252.116 dev ppp0 table 18
2016-08-22T17:22:09 [Debug] cmd is ip route add default via 172.29.252.116 dev ppp0 table 18
2016-08-22T17:22:09 [Informational] strCmd is: ip route flush cache
2016-08-22T17:22:09 [Informational] strCmd is: ip route add default via 172.29.252.116 dev ppp0 table 254
2016-08-22T17:22:09 [Debug] cmd is ip route add default via 172.29.252.116 dev ppp0 table 254
2016-08-22T17:22:10 [Informational] strCmd is: ip route flush cache
2016-08-22T17:22:10 [Informational] strCmd is: iptables -t mangle -F lanbindwan
2016-08-22T17:22:10 [Debug] cmd is iptables -t mangle -F lanbindwan
2016-08-22T17:22:10 [Debug] invalid event!don't support wEvent :0x9c93
2016-08-22T17:22:10 [Informational] fwSfSASynMsg wEvent:EV_INTERFACE_UP/DEL/DOWN!
2016-08-22T17:22:10 [Informational] ptWlanNotifier->ifType:WAN_TYPE
2016-08-22T17:22:10 [Informational] fwScheduleUnRegister NATchItemID:IGD.FWNAT.8
2016-08-22T17:22:10 [Informational] fwScheduleUnRegister wEvent:EV_FW_UNREGSCHEDULE dwObjID:b0001 chItemID:IGD.FWNAT.8!
2016-08-22T17:22:10 [Informational] ptFwSchedule->wOpID:EV_FW_EVDTSCHEDULE chItemID:IGD.FWNAT.8
2016-08-22T17:22:10 [Informational] fwScheduleRegister NATchItemID:IGD.FWNAT.8 chOutViewNameID:IGD.WD2.WCD1.WCPPP1 isNat:1 isForward:1
2016-08-22T17:22:10 [Informational] ptFwSchedule->wOpID:EV_FW_EVUPSCHEDULE chItemID:IGD.FWNAT.8
2016-08-22T17:22:10 [Debug] cmd is iptables -t nat -A wansrcnat -s ! 93.142.66.229 -o ppp0 -j MASQUERADE
A similar line, the very last one line above, just 1) a different IP, 2) it's
-A, which is "adding", not -D, which is deleting"... Uhmmmh. But I can still
only keep guessing.
Let me see if I got the dumps and the screencast. From ZTE_160822_1713.log
it's only dump, no screencast...
From the time corresponding to ZTE_160822_2000.log neither, I'm afraid.
But I might have much more luck with:
/Cmn/m/B/mr_160825_g0n/ZTE_160822_2205.log
I put it in a separate file, a huge chunk from that log:
ZTE_160822_2205.log
And in here, just a bit:
2016-08-22T20:45:21 [Informational] Recv Event:V4 IGD.WD2.WCD1.WCPPP1 rcv EV_APP_PROTOCAL_UP on STATE_CONNECTING
2016-08-22T20:45:21 [Informational] strCmd is: ip rule add from 93.138.27.13 table 18 pref 20048
2016-08-22T20:45:21 [Debug] cmd is ip rule add from 93.138.27.13 table 18 pref 20048
2016-08-22T20:45:21 [Informational] strCmd is: ip route add 172.29.252.64/32 dev ppp0 table 18
2016-08-22T20:45:21 [Notice] sendprogstop: msntp[1001] died exit_code = 0 exit_status = 1
2016-08-22T20:45:21 [Debug] cmd is ip route add 172.29.252.64/32 dev ppp0 table 18
2016-08-22T20:45:21 [Informational] strCmd is: ip route flush cache
2016-08-22T20:45:21 [Informational] strCmd is: ip route add default via 172.29.252.64 dev ppp0 table 18
2016-08-22T20:45:21 [Debug] cmd is ip route add default via 172.29.252.64 dev ppp0 table 18
2016-08-22T20:45:21 [Informational] strCmd is: ip route flush cache
2016-08-22T20:45:21 [Informational] strCmd is: ip route add default via 172.29.252.64 dev ppp0 table 254
2016-08-22T20:45:21 [Debug] cmd is ip route add default via 172.29.252.64 dev ppp0 table 254
2016-08-22T20:45:21 [Informational] strCmd is: ip route flush cache
2016-08-22T20:45:22 [Informational] Process died.Msntp, pid 1001 exitcode = 0
2016-08-22T20:45:26 [Informational] actives: get igmp Leave group:E001014D,from mode1
2016-08-22T20:45:27 [Warning] RunProcess process[autosense_bak_mg] Event[0x9a05] dwUsedTicks[589]
2016-08-22T20:45:27 [Informational] strCmd is: iptables -t mangle -F lanbindwan
2016-08-22T20:45:27 [Debug] cmd is iptables -t mangle -F lanbindwan
2016-08-22T20:45:27 [Informational] tr069:QueryTR069WanState,WAN NAME:IGD.WD2.WCD1.WCIP2,IFCServiceState:1 !
2016-08-22T20:45:27 [Debug] invalid event!don't support wEvent :0x9c93
2016-08-22T20:45:28 [Informational] fwSfSASynMsg wEvent:EV_INTERFACE_UP/DEL/DOWN!
2016-08-22T20:45:28 [Informational] ptWlanNotifier->ifType:WAN_TYPE
2016-08-22T20:45:28 [Informational] fwScheduleUnRegister NATchItemID:IGD.FWNAT.8
2016-08-22T20:45:28 [Informational] fwScheduleUnRegister wEvent:EV_FW_UNREGSCHEDULE dwObjID:b0001 chItemID:IGD.FWNAT.8!
2016-08-22T20:45:28 [Informational] ptFwSchedule->wOpID:EV_FW_EVDTSCHEDULE chItemID:IGD.FWNAT.8
2016-08-22T20:45:28 [Informational] fwScheduleRegister NATchItemID:IGD.FWNAT.8 chOutViewNameID:IGD.WD2.WCD1.WCPPP1 isNat:1 isForward:1
2016-08-22T20:45:28 [Informational] ptFwSchedule->wOpID:EV_FW_EVUPSCHEDULE chItemID:IGD.FWNAT.8
2016-08-22T20:45:28 [Debug] cmd is iptables -t nat -A wansrcnat -s ! 93.138.27.13 -o ppp0 -j MASQUERADE
I can confirm that: 93.138.27.13 was my public IP at that time, but looking at
the screencast:
/Cmn/m/B/mr_160825_g0n/Screen_160822_2159_g0n.webm
Just, when I post it it'll have different timestamps, as I have to make it
lighter by converting it. See http://github.com/miroR/uncenz and if you don't
understand why the -preset ultrafast option, needed for screencasting, does not
get as lean video as default ffmpeg conversion, ask somebody. Some 16M instead
of 42M occupies less room in a (still) rented webspace.
Oh, and while I'm at conversions, I prefer making a VP8 video and give you a
link straight to where you can see that was the public IP of mine back then.
(in case I don't make the WEBM:
NOTE before posting, I'm out of time for more work, just this:
stick this into the address bar of your browser, you should start viewing the
webm video exactly at 0:17:10 :
http://CroatiaFidelis.hr/foss/router/SNAT-inet/Screen_160822_2159_g0n.webm#t=00:17:10
or open Zxdsl931_logs_160822-160830.html) But once you go to view it, go straight to:
0:17:10 from the beginning of the video,
where you can see that in the logged-in web of ZXDSL, 93.138.27.13 appears
very clearly to be my then public IP.
So what does that command say? Look at it again (and work through man iptables
and the like if you are a stubborn newbie with insatiable interest, or some
other kind of geek; it takes nerves to newbies, or easy and casual
understanding to a network wizard to be around up unto here...). Look at it:
2016-08-22T20:45:28 [Debug] cmd is iptables -t nat -A wansrcnat -s ! 93.138.27.13 -o ppp0 -j MASQUERADE
The "!" inverts the sense, and means do that if the address is *not*
93.138.27.13.
And the "wansrcnat" is likely about Source NAT'ing for the WAN, isn't it?
And ppp0 it's still how the connection is made, just my usename and my password
are not needed every time like it used to maybe 15 years ago...
So it means, if the address is 93.138.27.13, then add the -j MASQUERADE (and
that was exactly what I was trying to do back then, I was trying to masquerade
my address from some host on the network 192.168.2.0/24 via 192.168.1.2 host
on the ZXDSL's network (I changed the address on this host to static
192.168.1.4 maybe a day or two later).
This is so tiring... I go back to preparing to get even better logs the next
time, and leave here for now... Aaaaghhh!!!