https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Mark Linimon changed:
What|Removed |Added
Status|New |Closed
Assignee|b...@free
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
George V. Neville-Neil changed:
What|Removed |Added
Assignee|g...@freebsd.org |b...@freebsd.org
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Jan Beich changed:
What|Removed |Added
Attachment #166901|application/x-shellscript |text/plain
mime type|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #54 from Guido Falsi ---
(In reply to Matthias Andree from comment #53)
> ping?
I still have the same router based on NanoBSD, in the while I updated the image
to 11.0-RELEASE. As before everything is working fine for me, and I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #53 from Matthias Andree ---
ping?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Kubilay Kocak changed:
What|Removed |Added
Keywords||needs-qa, patch
Flags
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #52 from George V. Neville-Neil ---
I am now tracking an updated patch in Phabricator:
https://reviews.freebsd.org/D5330
That's where the rest of this will be carried out.
--
You are receiving this mail because:
You are on t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Eric van Gyzen changed:
What|Removed |Added
CC||vangy...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #50 from George V. Neville-Neil ---
Created attachment 167150
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167150&action=edit
Copy the mbuf for use in icmp error messages.
--
You are receiving this mail because:
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #49 from Andrey V. Elsukov ---
(In reply to George V. Neville-Neil from comment #48)
> It turns out that for this bug fastforward (the predecessor to tryforward)
> would never have worked either. I am working up an alternate fi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #48 from George V. Neville-Neil ---
(In reply to Andrey V. Elsukov from comment #47)
It turns out that for this bug fastforward (the predecessor to tryforward)
would never have worked either. I am working up an alternate fix a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #47 from Andrey V. Elsukov ---
(In reply to George V. Neville-Neil from comment #44)
> Created attachment 167113 [details]
> Only use tryfoward() when pfilter hooks are not present
>
> This is a patch against HEAD that I'm test
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #46 from g_amana...@yahoo.com ---
This also resolves the bug in a direct LAN connection.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #45 from g_amana...@yahoo.com ---
The patch resolves the OpenVPN bug. (tested with the above ipfw.txt ruleset and
OpenVPN config files).
I will report in a couple of hours if it also resolves the bug in a direct LAN
connection.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #44 from George V. Neville-Neil ---
Created attachment 167113
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167113&action=edit
Only use tryfoward() when pfilter hooks are not present
This is a patch against HEAD tha
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #43 from Guido Falsi ---
(In reply to g_amanakis from comment #34)
Hi,
My home router is a nanobsd image I just updated to 10.3:
10.3-BETA2 FreeBSD 10.3-BETA2 #0 r295652: Tue Feb 16 10:09:07 CET 2016
It's running openvpn, ip
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #42 from g_amana...@yahoo.com ---
You are correct, I can confirm this.
On this setup without NAT involved (ipfw was set to pass all):
client --> LAN-router-LAN --> server
1500 1500 576 1500
I can see the client
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #40 from g_amana...@yahoo.com ---
client -> LAN-router-WAN -> webserver (eg. gutefrage.net)
1500 1500 5761500?
client MTU:
interface: 1500
route: 1500
router MTU:
LAN-interface: 1500
LAN-route: 1500
WAN-interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #41 from George V. Neville-Neil ---
(In reply to g_amanakis from comment #40)
Yes, it does.
Also, without IPFW and NAT, that is if you can make this a regular routing
setup, do you see the problem? My theory is that you will
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #39 from George V. Neville-Neil ---
(In reply to g_amanakis from comment #38)
That does look suspicious. In the ip_forward() routine we make a copy of the
mbuf first. I will look at a patch that synchronizes the way these wor
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #38 from g_amana...@yahoo.com ---
I think the problem lies here:
===8<
ip_fastfwd.c
if (ip_off & IP_DF) {
IPSTAT_INC(ips_cantfrag);
icmp_error(m, ICMP_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #37 from g_amana...@yahoo.com ---
Setting dhcpcd to ignore the interface MTU resolves my problem.
However if I manually reduce the MTU the problem reappears and the client
receives no fragmentation-needed-ICMP. I am leaving thi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #36 from g_amana...@yahoo.com ---
I figured it out:
the dhcpcd changed the MTU of em0 each time it acquired a lease.
Setting "#option interface_mtu" in dhcpcd.conf leaves the MTU at 1500.
I think this resolves the whole thing.
I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #35 from g_amana...@yahoo.com ---
I just did a:
$ route get 8.8.8.8
and got:
route to: google-public-dns-a.google.com
destination: default
mask: default
gateway: 69.251.142.1
fib: 0
interface: em0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #34 from g_amana...@yahoo.com ---
The only hypothesis I have is that when fragmentation is needed for an outgoing
packet (I have no idea why) and the client sending this packet is behind NAT,
the gateway cannot see the real IP of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #33 from George V. Neville-Neil ---
Really? Then why is there the "packet too large" ICMP message?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #32 from g_amana...@yahoo.com ---
(In reply to George V. Neville-Neil from comment #31)
MTU is 1500 on all interfaces (on WAN and LAN interface on the gateway, as well
as on the client).
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #31 from George V. Neville-Neil ---
Looking at the pcap files I see that the client is always advertising an MSS of
1460. In your setup what are the MTUs of each interface involved?
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #30 from g_amana...@yahoo.com ---
I am using in-kernel NAT, you can see the configuration in the ipfw.txt
attached above.
--
You are receiving this mail because:
You are on the CC list for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #29 from George V. Neville-Neil ---
If you have a natd.conf file that would also be helpful.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #28 from g_amana...@yahoo.com ---
Correct, up until now the problem occured with IPFW and in-kernel NAT for IPv4.
I will test using plain fastforwarding (without NAT on IPv4) and report.
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #27 from George V. Neville-Neil ---
You only see this with IPFW + NAT, right? If you just use tryforward or, on
older versions, fastforward, things are fine?
--
You are receiving this mail because:
You are on the CC list for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #26 from g_amana...@yahoo.com ---
(In reply to George V. Neville-Neil from comment #25)
Yes, correct. 70.78.231.153 is the WAN-IP of the gateway. I used tcprewrite to
spoof the mac addresses.
--
You are receiving this mail beca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #25 from George V. Neville-Neil ---
(In reply to g_amanakis from comment #20)
Jumping back a bit. I definitely see data to your client on both interfaces in
the tun and em0 traces. Looks like the client is 70.78.231.153?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #24 from George V. Neville-Neil ---
Thanks for the update and the new files. I am trying to reproduce this on HEAD
still. With your latest test were you still using IPFW and NAT or was this
just vanilla forwarding? I have set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #23 from g_amana...@yahoo.com ---
Created attachment 167004
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167004&action=edit
ffoff.pcapng
I did another dump on a client on the local network (directly connected to
gat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #22 from g_amana...@yahoo.com ---
Created attachment 167003
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167003&action=edit
ffon.pcapng
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #21 from g_amana...@yahoo.com ---
The problem persists on HEAD (build 20160127).
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #20 from g_amana...@yahoo.com ---
Created attachment 166909
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166909&action=edit
tun0.pcap
tun0.pcap and wan.pcap (gateway interfaces) were captured simultaneously. A
clien
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #19 from g_amana...@yahoo.com ---
Created attachment 166908
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166908&action=edit
wan.pcap
--
You are receiving this mail because:
You are on the CC list for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #18 from George V. Neville-Neil ---
With tcpdump just use -w /tmp/capture.pcap so you get a file rather than text
based output.
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #17 from g_amana...@yahoo.com ---
Created attachment 166901
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166901&action=edit
ipfw.txt
This is the simplified IPFW ruleset I am using. IPSEC is turned off in kernel
comp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Brooks Davis changed:
What|Removed |Added
CC|freebsd-am...@freebsd.org |bro...@freebsd.org
--- Comment #16
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #15 from George V. Neville-Neil ---
Have you/can you test this on HEAD?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #14 from George V. Neville-Neil ---
Thanks for all the updates, this does help to track some of this down. A few
more questions:
If you are not using an Android client does everything just work?
In your last test did you also
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #13 from g_amana...@yahoo.com ---
Created attachment 166886
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166886&action=edit
tcpdump.txt
I did a tcpdump while an android client tries to access a webpage
(www.gutefrag
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #12 from g_amana...@yahoo.com ---
I did some thorough testing with a simplified IPFW ruleset (only in-kernel NAT
enabled and allow everything on the local and WAN interfaces). Enabling
"net.inet.ip.fastforwarding" in kernels befo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #11 from g_amana...@yahoo.com ---
I tried with IPSEC_NAT_T and VIMAGE disabled and it doesn't resolve it.
--
You are receiving this mail because:
You are on the CC list for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #10 from g_amana...@yahoo.com ---
Created attachment 166885
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166885&action=edit
netstat.txt
Output of "netstat -s" attached.
In the local network the problem concerns prim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #9 from George V. Neville-Neil ---
Can you try this without VIMAGE, and then possibly without IPSEC_NAT_T and tell
me if the problem persists? Also, can you share the output of netstat -s for
all protocols including tcp, esp, a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #8 from g_amana...@yahoo.com ---
Kernels before this commit (e.g. r295264) with "net.inet.ip.fastforwarding=1"
do not exhibit this symptoms.
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Mark Linimon changed:
What|Removed |Added
Keywords||regression
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|g...@freebsd.org
--- Comment #7 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #6 from mgro...@shrew.net ---
Doah, sorry. I stopped and started writing that last paragraph while in the
middle of something else. I was still thinking of things in terms of tunneling.
Please disregard and I'll go away and be qu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #5 from mgro...@shrew.net ---
I see. They underlying cause is quite possibly unrelated then. As I said, I
wasn't trying to hijack your bug report. But the symptom still sounds similar
in the respect that some of your UDP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #4 from g_amana...@yahoo.com ---
(In reply to mgrooms from comment #3)
This issue concerns only 10.2-STABLE (now 10.3-BETA1) which is about to become
10.3-RELEASE. The commit has not been applied to 10.2-RELEASE, so you must be
f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
mgro...@shrew.net changed:
What|Removed |Added
CC||mgro...@shrew.net
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #2 from g_amana...@yahoo.com ---
Also I just figured out that my Android devices which connect directly to the
gateway running the OpenVPN server (they connect to the internal interface and
not through OpenVPN) are not able to op
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
g_amana...@yahoo.com changed:
What|Removed |Added
CC||a...@freebsd.org,
59 matches
Mail list logo
