GIF interface and Routing Serious Unexpected behavior

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GIF interface and Routing Serious Unexpected behavior

sven falempin
On Thu, Jan 14, 2016 at 8:56 PM, sven falempin <[hidden email]>
wrote:

>
>
> On Thu, Jan 14, 2016 at 3:14 PM, sven falempin <[hidden email]>
> wrote:
>
>>
>> On Thu, Jan 14, 2016 at 1:08 PM, sven falempin <[hidden email]>
>> wrote:
>>
>>> Dear Tech Reader,
>>> Maybe this would be misc but i am trying to avoid some useless answer.
>>> This is openbsd 5.8 patched ( -r OPENBSD_5_8 )
>>>
>>> All my block rule log.
>>> Nothing appear in tcpdump -teni pflog0
>>>
>>> But pf drop packet (set skip or pfctl -d) solve problem.
>>>
>>> [0]-[blue]-[/cloudgate]
>>> # ping -c2 -w2 172.16.0.1
>>> PING 172.16.0.1 (172.16.0.1): 56 data bytes
>>> 64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=0.894 ms
>>> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=0.966 ms
>>> --- 172.16.0.1 ping statistics ---
>>> 2 packets transmitted, 2 packets received, 0.0% packet loss
>>> round-trip min/avg/max/std-dev = 0.894/0.930/0.966/0.036 ms
>>> [0]-[blue]-[/cloudgate]
>>> # tcpdump -tteni pflog0 &
>>> [1] 31913
>>> [0]-[blue]-[/cloudgate]
>>> # tcpdump: WARNING: snaplen raised from 116 to 160
>>> tcpdump: listening on pflog0, link-type PFLOG
>>> pfctl -e
>>> pf enabled
>>> [0]-[blue]-[/cloudgate]
>>> # ping -c2 -w2 172.16.0.1
>>> PING 172.16.0.1 (172.16.0.1): 56 data bytes
>>> ping: sendto: No route to host
>>> ping: wrote 172.16.0.1 64 chars, ret=-1
>>> ping: sendto: No route to host
>>> ping: wrote 172.16.0.1 64 chars, ret=-1
>>> --- 172.16.0.1 ping statistics ---
>>> 2 packets transmitted, 0 packets received, 100.0% packet loss
>>> [1]-[blue-viking]-[/cloudgate]
>>> # ifconfig gre
>>> gre0: flags=9011<UP,POINTOPOINT,LINK0,MULTICAST> mtu 1476
>>>         description: citywan
>>>         priority: 0
>>>         keepalive: timeout 10 count 6
>>>         groups: gre
>>>         status: keepalive down
>>>         tunnel: inet 10.19.71.31 -> 10.54.213.241
>>>         inet 172.16.0.2 --> 172.16.0.1 netmask 0xffffffff
>>>
>>>
>>> But i would like to match out on gre0 from (x:network) to !(self) nat-to
>>> (gre0:0)
>>>
>>> Not possible ?
>>>
>>>
>>>
>> Following up on the gre interface, the routing is odd, once gre is up i
>> got data form a side ,
>> yet no forwarding is done.
>>
>> [0]-[villemarie]-[/root]
>> # tcpdump -tteni gre0 icmp
>> tcpdump: listening on gre0, link-type LOOP
>> 1452800353.714927 172.16.0.2 > 8.8.8.8: icmp: echo request
>> 1452800353.715047 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
>> 1452800354.725152 172.16.0.2 > 8.8.8.8: icmp: echo request
>> 1452800354.725240 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
>> 1452800355.735124 172.16.0.2 > 8.8.8.8: icmp: echo request
>> 1452800355.735213 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
>> ^C
>> 8 packets received by filter
>> 0 packets dropped by kernel
>> [0]-[villemarie]-[/root]
>> # netstat -rnv -f inet | grep default
>> default            192.168.10.1       UGS        6  1510585     -     8
>> re0   DHCLIENT MANUAL
>> [0]-[villemarie]-[/root]
>> # tcpdump -tteni re0 icmp
>> tcpdump: listening on re0, link-type EN10MB
>> ^C
>> 46 packets received by filter
>> 0 packets dropped by kernel
>> [0]-[villemarie]-[/root]
>> # sysctl -a | grep forwarding
>> net.inet.ip.forwarding=1
>>
>> nothing is blocked in pf once againt aso the timing ot the reply is very
>> short.
>>
>> I was expecting the data to be routed .
>>
>>
>>
>>
> and it does, it feels like adding the route after the interface creation
> got an effect.. but unsure.
>
> First problem still unsolved.
>
>
Ok this morning the routing of gif was not done , after deleting the
default route and readding it,
tada, it s routed again.

I will test with 5.8 , is it enough or do you absolutely require current ?
i think for this case only the kernel could be updated.

Please take a look Test Log :

#validate the routing is broken

[1]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867126.675719 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.675899 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.785273 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.785371 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.895401 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.895552 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867127.005380 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867127.005474 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable

^C
8 packets received by filter
0 packets dropped by kernel

#But route is here, why replying unreachable ? (label is here because we
manage multiple default route )

[0]-[villemarie]-[/root]
# netstat -rnv | grep defa
default            192.168.10.1       UGS      115   684491     -     8 re0
  DHCLIENT MINE

# ok lets try to confirm the yesterday strange behavior

[1]-[villemarie]-[/root]
# route delete default
delete net default
[0]-[villemarie]-[/root]
# route add default 192.168.10.1 -mpath -label "DHCLIENT GIF"
add net default: gateway 192.168.10.1
[0]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867248.839222 8.8.8.8 > 172.16.0.1: icmp: echo reply
1452867249.834122 172.16.0.1 > 8.8.8.8: icmp: echo request

# wow that s strange !

--
---------------------------------------------------------------------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\
Reply | Threaded
Open this post in threaded view
|

Re: GIF interface and Routing Serious Unexpected behavior

sven falempin
On Fri, Jan 15, 2016 at 9:23 AM, sven falempin <[hidden email]>
wrote:

>
> Ok this morning the routing of gif was not done , after deleting the
> default route and readding it,
> tada, it s routed again.
>
> I will test with 5.8 , is it enough or do you absolutely require current ?
> i think for this case only the kernel could be updated.
>
> Please take a look Test Log :
>
> #validate the routing is broken
>
> [1]-[villemarie]-[/root]
> # tcpdump -tteni gif0 icmp
> tcpdump: listening on gif0, link-type LOOP
> 1452867126.675719 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867126.675899 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
> 1452867126.785273 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867126.785371 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
> 1452867126.895401 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867126.895552 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
> 1452867127.005380 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867127.005474 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
>
> ^C
> 8 packets received by filter
> 0 packets dropped by kernel
>
> #But route is here, why replying unreachable ? (label is here because we
> manage multiple default route )
>
> [0]-[villemarie]-[/root]
> # netstat -rnv | grep defa
> default            192.168.10.1       UGS      115   684491     -     8
> re0   DHCLIENT MINE
>
> # ok lets try to confirm the yesterday strange behavior
>
> [1]-[villemarie]-[/root]
> # route delete default
> delete net default
> [0]-[villemarie]-[/root]
> # route add default 192.168.10.1 -mpath -label "DHCLIENT GIF"
> add net default: gateway 192.168.10.1
> [0]-[villemarie]-[/root]
> # tcpdump -tteni gif0 icmp
> tcpdump: listening on gif0, link-type LOOP
> 1452867248.839222 8.8.8.8 > 172.16.0.1: icmp: echo reply
> 1452867249.834122 172.16.0.1 > 8.8.8.8: icmp: echo request
>
> # wow that s strange !
>
>
>


It s all 5.8 stable now.
gif is unstable.

[0]-[58-gif]-[~]
# ping 172.16.0.1
ping: wrote 172.16.0.1 64 chars, ret=-1
--- 172.16.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
[1]-[58-gif]-[~]
# ifconfig gif0 down
[0]-[58-gif]-[~]
# ifconfig gif0 up
[0]-[58-gif]-[~]
# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=1.122 ms

i now activate ifconfig gif0 debug

Something nasty in there.


--
---------------------------------------------------------------------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\
Reply | Threaded
Open this post in threaded view
|

Re: GIF interface and Routing Serious Unexpected behavior

Stuart Henderson-6
On Fri, Jan 15, 2016 at 9:23 AM, sven falempin <[hidden email]> wrote:
>
> I will test with 5.8 , is it enough or do you absolutely require current ?
> i think for this case only the kernel could be updated.

There have been big changes to the network/routing stack since 5.8 - at
least two hackathons with significant focus on this area. Neither 5.8
nor 5.8-stable are enough.

It could be fixed already. Or it could have different behaviour. If not,
here is very little chance it will be fixed for 5.9 unless someone seeing
a problem gets in a good bug report on -current.

Reply | Threaded
Open this post in threaded view
|

Re: GIF interface and Routing Serious Unexpected behavior

Stuart Henderson-6
On 2016/01/26 20:11, Stuart Henderson wrote:

> On Fri, Jan 15, 2016 at 9:23 AM, sven falempin <[hidden email]> wrote:
> >
> > I will test with 5.8 , is it enough or do you absolutely require current ?
> > i think for this case only the kernel could be updated.
>
> There have been big changes to the network/routing stack since 5.8 - at
> least two hackathons with significant focus on this area. Neither 5.8
> nor 5.8-stable are enough.
>
> It could be fixed already. Or it could have different behaviour. If not,
> here is very little chance it will be fixed for 5.9 unless someone seeing
> a problem gets in a good bug report on -current.
>

P.S. Kernel *and* userland.