> Not sure it's the same issue, but can you test with commit 6b8d95f1795c
> ("packet: validate address length if non-zero")? It's in mainline
> already and queued for -stable.
>
> See similar report here:
> https://www.spinics.net/lists/netdev/msg541807.html
Hi,
Thanks for the quick response. Ye
Hi Folks,
I'm getting this message when I run nmap 7.70 with
linux 4.20
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-07 16:15 CET
Initiating ARP Ping Scan at 16:15
Scanning 10.81.104.82 [1 port]
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22:
Invalid argument
> Il 26 ottobre 2018 alle 20.19 Cong Wang ha scritto:
>
> On Fri, Oct 26, 2018 at 4:35 AM Marco Berizzi wrote:
>
> > Apologies for bothering you again.
> > I applied your patch to 4.19, but after issuing this
> > command:
> >
> > root@Calimero:~#
> Il 24 ottobre 2018 alle 17.32 David Ahern ha scritto:
> net/sched/sch_api.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index 3dc0acf54245..be7cd140b2a3 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -1309,7 +1309,6 @
Hi Folks,
I'm getting this message after the upgrade from linux 4.18
to 4.19
root@Calimero:~# tc qdisc add dev eth0 root handle 1:0 hfsc default 1
Error: Attribute failed policy validation.
root@Calimero:~# lsmod | grep hfsc
sch_hfsc 24576 0
root@Calimero:~# tc -V
tc utility,
Hi Folks,
I'm running strongSwan on Slackware with linux 4.18
This is the output from 'ip route show':
default via isp_router dev eth0 metric 1
10.0.0.0/8 via 10.68.63.3 dev eth1
10.68.63.0/26 dev eth1 proto kernel scope link src 10.68.63.62
127.0.0.0/8 dev lo scope link
172.16.0.0/12 via 10.
> Il 21 giugno 2018 alle 1.00 Cong Wang ha scritto:
> Please also test HFSC_RSC ("rt") if possible.
Hi Cong,
sorry for the delayed response.
I have tested this hfsc rt setup:
tc class add dev eth2 parent 1:2 classid 1:16 hfsc rt m2 500kbit
and
tc class add dev eth2 parent 1:2 classid 1:16 hfsc
> Il 19 giugno 2018 alle 13.42 Marco Berizzi ha scritto:
>
> > Il 18 giugno 2018 alle 21.28 Cong Wang ha
> > scritto:
> > Can you test the attached patch?
> >
> > It almost certainly fixes the warning, but I am not sure if
> > it papers out any oth
> Il 18 giugno 2018 alle 21.28 Cong Wang ha scritto:
> Can you test the attached patch?
>
> It almost certainly fixes the warning, but I am not sure if
> it papers out any other real problem. Please make sure
> hfsc still works as expected. :)
Hi Cong,
Thanks a lot for the patch. I'm building 4
> Il 8 marzo 2018 alle 17.02 Marco Berizzi ha scritto:
>
> > Marco Berizzi wrote:
> >
> > Hello everyone,
> >
> > Yesterday I got this error on a slackware linux 4.16-rc4 system
> > running as a traffic shaping gateway and netfilter nat.
> &g
> Il 19 marzo 2018 alle 11.07 Jamal Hadi Salim ha scritto:
>
> On 18-03-15 08:48 PM, Cong Wang wrote:
>
> > On Wed, Mar 14, 2018 at 1:10 AM, Marco Berizzi wrote:
> >
> > > > Il 9 marzo 2018 alle 0.14 Cong Wang ha
> > > > scritt
Il 19 marzo 2018 alle 11.07 Jamal Hadi Salim ha scritto:
>
> On 18-03-15 08:48 PM, Cong Wang wrote:
>
> > On Wed, Mar 14, 2018 at 1:10 AM, Marco Berizzi wrote:
> >
> > > > Il 9 marzo 2018 alle 0.14 Cong Wang ha
> > > > scritto:
> > > &g
> Marco Berizzi wrote:
> I'm getting the same error messages, after hardware
> replacement and kernel upgrade to 4.16-rc5.
for completeness, same error with 4.16-rc6
[0.00] Linux version 4.16.0-rc6 (root@Pleiadi) (gcc version 5.5.0
(GCC)) #1 SMP Mon Mar 19 12:
> Marco Berizzi wrote:
>
>
> Hello everyone,
>
> After upgrading to linux 4.15.3 (4.15.2 was the last version
> with no error), I'm getting this error message.
> This a Slackware 14.2 64bit ipsec gateway running strongswan.
>
> Any response are welcome.
&
> Il 9 marzo 2018 alle 0.14 Cong Wang ha scritto:
>
>
> On Thu, Mar 8, 2018 at 8:02 AM, Marco Berizzi wrote:
> >> Marco Berizzi wrote:
> >>
> >>
> >> Hello everyone,
> >>
> >> Yesterday I got this error on a slackware l
> Marco Berizzi wrote:
>
>
> Hello everyone,
>
> Yesterday I got this error on a slackware linux 4.16-rc4 system
> running as a traffic shaping gateway and netfilter nat.
> The error has been arisen after a partial ISP network outage,
> so unfortunately it will not
Any response are welcome.
TIA
Marco Berizzi
Mar 5 19:06:34 Trappist kernel: klogd 1.5.1, log source = /proc/kmsg started.
Mar 5 19:06:34 Trappist kernel: Linux version 4.16.0-rc4 (root@Trappist) (gcc
version 5.5.0 (GCC)) #1 SMP Mon Mar 5 18:31:06 CET 2018
Mar 5 19:06:34 Trappist kernel
Hello everyone,
After upgrading to linux 4.15.3 (4.15.2 was the last version
with no error), I'm getting this error message.
This a Slackware 14.2 64bit ipsec gateway running strongswan.
Any response are welcome.
TIA
[241395.181389] [ cut here ]
[241395.181396] NETDEV WA
ec), hard 4800(sec)
> expire use: soft 0(sec), hard 0(sec)
> lifetime current:
> 11180(bytes), 215(packets)
> add 2018-01-19 17:43:50 use 2018-01-19 17:43:50
> stats:
> replay-window 0 replay 0 failed 0
>
> Kindly, I would like to ask if this is the expected behaviour.
>
> Thanks in advance
>
> Marco Berizzi
k if this is the expected behaviour.
Thanks in advance
Marco Berizzi
Hi Folks,
Sorry for writing to you, but I'm dealing with a very weird problem.
I'm monitoring a network wan link traffic with a linux box with two NIC:
one nic is for regular ipv4 network connectivity (eth0), and the other
nic (eth1) is for sniffing all packets coming from an HPE 5510 switch:
here
> Eric Dumazet wrote:
>
> On Tue, 2017-09-19 at 15:28 +0200, Marco Berizzi wrote:
>
> > Hi Folks,
> >
> > I'm running linux 4.12.10 x86_64 on a Slackware 14.2 64bit
> > as a simple 4 NIC router. Network throughput processed by
> > this machine is l
Hi Folks,
I'm running linux 4.12.10 x86_64 on a Slackware 14.2 64bit
as a simple 4 NIC router. Network throughput processed by
this machine is less than 200Mbit/s
The cpu model is Intel(R) Xeon(R) CPU 5160 @ 3.00GHz with
2GB ram.
I need to blacklist about 9000 single ip addresses.
This is the re
David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 30 Jan 2008 14:15:33 +1100
>
> > Marco Berizzi <[EMAIL PROTECTED]> wrote:
> > >
> > >> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine,
data
> > &g
Herbert Xu wrote:
> On Wed, Jan 30, 2008 at 10:14:46AM +0100, Marco Berizzi wrote:
> >
> > Sorry for bother you again.
> > I have applied to 2.6.24, but ipcomp doesn't work anyway.
> > I have patched a clean 2.6.24 tree and I did a complete
> > rebuild.
>
Herbert Xu wrote:
> Marco Berizzi <[EMAIL PROTECTED]> wrote:
> >
> >> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine,
data
> >> > flows in both directions, but no data comes out of the tunnel.
> >> > Needed to disable ipcomp
Beschorner Daniel wrote:
> Has someone an idea which patch could have damaged ipcomp?
>
> Daniel
>
> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
> > flows in both directions, but no data comes out of the tunnel.
> > Needed to disable ipcomp.
Same problem here: linux 2.6.
Hello everybody.
I'm using openswan 2.4.x to drive the linux 2.4.23.14 ipsec
native stack (netkey).
Openswan by default insert a static route when an ipsec SA
is established: this is needed by the klips stack as it is
routing based. For example when a roadwarrior establish
an ipsec SA with the linu
Hello everybody.
AFAIK ipsec policy aren't related to routing
tables: if there is an ipsec policy to deliver
traffic, for example, from 192.168.0.0/16 to
10.0.0.0/8, xfrm will eat the packets ignoring
the routing table.
Here is the ipsec gateway schema:
[-] cisco ISP router default gateway
Herbert Xu wrote:
> Marco Berizzi <[EMAIL PROTECTED]> wrote:
> > Hello everybody.
> > I'm experimenting a pretty strange ipsec problem with 2.6.23.x
> > and openswan 2.4.11
> > Here is the output from 'ip -s x p':
>
> It's a bug in open
Hello everybody.
I'm experimenting a pretty strange ipsec problem with 2.6.23.x
and openswan 2.4.11
Here is the output from 'ip -s x p':
src 172.16.0.0/23 dst 192.168.15.2/32 uid 0
dir out action allow index 529 priority 2368 ptype main share
any flag 0x00
00
lifetime config:
Brian S Julin wrote:
> Marco wrote:
>
>> Brian S Julin wrote:
>>> Almost clear... why can you not just add "src >> IP>" to the fwmark
>>> route to set the default source address for locally
>>> originating
>>> packets?
>>
>> IIRC, it doesn't work because netfilter isn't called in
>> ip source addr
Brian S Julin wrote:
> Almost clear... why can you not just add "src " to
> the fwmark route to set the default source address for locally
> originating packets?
IIRC, it doesn't work because netfilter isn't called
in ip source address selection.
--
To unsubscribe from this list: send the line
Brian S Julin wrote:
Marco wrote:
> > Hello everybody.
> > Kindly, I would like to know if the is any plan to add this feature
to a > > future kernel release.
> > I know that fwmark is able to do this, but there is the limitation
in
> > source ip address selection.
> Could you explain the limita
Hello everybody.
Kindly, I would like to know if the is any plan
to add this feature to a future kernel release.
I know that fwmark is able to do this, but there
is the limitation in source ip address selection.
TIA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
Marco Berizzi wrote:
> inet 1.1.1.1/32 scope global eth0
^^
Sorry, my fault.
Apologies for all the noise.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vg
jamal wrote:
> On Fri, 2007-21-09 at 11:08 +0200, Marco Berizzi wrote:
>
> > thanks for the reply.
> > I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0',
> > but the 'arp whos-has' behaviour doesn't change.
> > Other hints?
>
>
Chuck Ebbert wrote:
> > Is there a way to force linux to make an arp
> > probe with the source ip belonging to the
> > same subnet requesting ip?
>
> Umm, arp_filter?
Hello Chuck,
thanks for the reply.
I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0',
but the 'arp whos-has' behaviour does
Marco Berizzi wrote:
> HDSL.225 dev eth0 scope link
> ADSL.129 dev eth0 scope link src ADSL.134
> ADSL.128/29 dev eth1 proto kernel scope link src ADSL.134
> HDSL.224/27 dev eth1 proto kernel scope link src HDSL.254
> 127.0.0.0/8 dev lo scope link
> default via HDSL.22
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7
Hello everybody.
I have a pretty strange problem with linux 2.6.22.6
This is my 'ip ru sh', 'ip a s', 'ip r s' and
'iptables -t mangle -nvxL' output:
0: fr
Patrick McHardy wrote:
> Marco Berizzi wrote:
> > Patrick McHardy wrote:
> >
> >>We have some MTU opimiztations in 2.6.22-rc that might be related.
> >>Please check with tcpdump what exactly is happening and whether
> >>the 2.6.22-rc box is sending to
Patrick McHardy wrote:
> Marco Berizzi wrote:
> > Hello everybody.
> > I have just upgraded from 2.6.21.3 to
> > 2.6.22-rc4 and I get a ton of
> > pmtu discovery on sa esp/blablab/blabla
> > messages (this box is running openswan).
> > Is this an exp
Hello everybody.
I have just upgraded from 2.6.21.3 to
2.6.22-rc4 and I get a ton of
pmtu discovery on sa esp/blablab/blabla
messages (this box is running openswan).
Is this an expected behaviour?
TIA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
Herbert Xu wrote:
> Marco Berizzi <[EMAIL PROTECTED]> wrote:
> >
> > AFAIK it was applied to osw 2.4.2
> > Also changelog confirm this:
> >
> > v2.4.2
>
> Indeed. Somehow I couldn't find the patch in the git tree that
> I had here. It wasn&#x
Herbert Xu wrote:
> Marco Berizzi <[EMAIL PROTECTED]> wrote:
> > I'm experimenting the problem described in this
> > bug report http://bugs.xelerance.com/view.php?id=726
>
> It's actually a bug in openswan. I even sent them a patch for
> it back in
Hello everybody.
I'm experimenting the problem described in this
bug report http://bugs.xelerance.com/view.php?id=726
The system is running vanilla 2.6.19.2 on Slackware
10.1 (gcc 3.3.5, glibc 2.3.5)
I'm available for any kind of test.
TIA
PS: I see a lot kernel memory allocation:
[EMAIL PROTECT
Herbert Xu wrote:
> Marco Berizzi <[EMAIL PROTECTED]> wrote:
> > Yesterday I have updated to linux 2.6.19.2
> > (from 2.6.19.1) and passthrough openswan
> > connection aren't working anymore.
> > This is the 'ip -s x s' output:
>
> I presume
Hi.
Yesterday I have updated to linux 2.6.19.2
(from 2.6.19.1) and passthrough openswan
connection aren't working anymore.
This is the 'ip -s x s' output:
src 10.180.0.0/16 dst 172.16.0.0/23 uid 0
dir in action allow index 208 priority 2384 ptype main share any flag
0x
lifetime config:
Hi everybody,
I'm running linux 2.6.19 (on a pretty old system),
and everytime I run 'mii-tool' I get a ton of:
pci_set_power_state(): :00:0a.0: state=3, current state=5
Here is dmesg:
PCI: setting IRQ 10 as level-triggered
PCI: Found IRQ 10 for device :00:0a.0
:00:0a.0: 3Com PCI 3c
Hello everybody.
I would like to know if is it possible to create an ipsec
policy based on the mark value inizialized by netfilter.
This is my problem: I need to route VoIP packets from hosts
connected to the private networks (A & B) to the QoS routers,
without encrypting them. 'Normal' packets a
I kindly would like to know why linux reply to ICMP
echo request packets with the DF bit set always to 0.
I have googled the internet but I have only found
this pretty old message:
http://www.ussg.iu.edu/hypermail/linux/kernel/9804.2/0334.html
I also have found these messages that document this
Herbert Xu wrote:
On Thu, Jul 13, 2006 at 07:03:41PM +1000, herbert wrote:
>
> This needs to go into stable as well. In fact, there is another
unrelated
> bug with exactly the same symptoms which was inadvertently fixed by the
> GSO patches. So I'll send a simpler fix for that to stable.
>
>
Andy Gay wrote:
As Herbert said, the right= address doesn't matter. Search for 10.180.
If it doesn't matter, who told to linux to send packets for
10.180.0.0/16 to 172.16.1.253?
BTW - in your erlier mail you had "rightsubnet=10.180.0./16". Looks like
a typo there.
yes it was a typo.
-
To
Andy Gay wrote:
It's a function of the IPsec SADB. The passthrough conn added a more
specific policy that will match before the tunnel policy.
You can run 'ip xfrm p' and 'ip xfrm s' to view the policies & state
info.
I did, but no results:
ip x p | grep '172.16.1.253'
nor
ip x s | grep '17
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> 172.16.0.0/23 dev eth2 proto kernel scope link src 172.16.1.1
> 10.180.0.0/16 via 172.16.1.253 dev eth2
> 10.0.0.0/8 via pub_ip dev eth0
> 127.0.0.0/8 dev lo scope link
>
> I have noticed that packet
Hello everybody.
I'm running linux 2.6.16.27 on my firewall/ipsec gateway
with openswan 2.4.5
This is my firewall/network schema:
|
| /--eth0 (connected to ISP router)
|/
+--+--+
| |
| +--eth1 (DMZ)
| |
+--+--+
|\
| \--eth2 (internal network 172.16.0.0/23)
|
+-+
| | <--r
Andy Gay wrote:
Since 2.6.16 it's been necessary to add an ACCEPT rule for IPIP
(protocol 4) in the INPUT chain, otherwise IPsec tunnel mode packets get
dropped (if your INPUT policy is DROP).
I was wondering if that's the intended behavior.
No it isn't the desired behaviour. It is a know iss
Running this on mimosa 'mitigates' the problem:
ip addr add 172.29.128.1/28 dev eth2
Connections are pretty slow but they aren't
reseted anymore.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
Another tricky behaviour:
[EMAIL PROTECTED]:/tmp# telnet 10.49.59.23 3218
Trying 10.49.59.23...
Connected to 10.49.59.23.
Escape character is '^]'.
Connection closed by foreign host.
[EMAIL PROTECTED]:/tmp# tcpdump -p -n -v ip host 10.49.59.23 > HERBERT-20060711
&
[1] 4797
[EMAIL PROTECTED]:/tm
Marco Berizzi wrote:
Herbert Xu wrote:
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
>
> [EMAIL PROTECTED]:~# ping 10.49.59.23
> PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
> 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
> 64 bytes f
Herbert Xu wrote:
We can say these things for certain:
1) The path between mimosa and pleiadi has a packet loss problem. A small
burst of 10 or so fragments is enough to cause at least half of them to
be lost. This problem may be specific to IPsec traffic (ISPs often
discriminate aga
Herbert Xu wrote:
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
>
> [EMAIL PROTECTED]:~# ping 10.49.59.23
> PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
> 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
> 64 bytes from 10.49.59.23: icmp_seq
Herbert Xu wrote:
Hi Marco:
Hi Herbert, I'm very happy hearing you.
On Mon, Apr 24, 2006 at 09:23:00AM +0000, Marco Berizzi wrote:
>
> What should I do? Mangling MSS with iptables --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
JFYI: sam
Steffen Klassert wrote:
On Tue, Jun 06, 2006 at 11:12:45AM +0200, Marco Berizzi wrote:
>
> I have moved this damn pc from the remote to my site and I have
> placed it in production environment with 2.6.17-rc5
> No problem after 24 hours (on the remote side the problem was
>
Marco Berizzi wrote:
Marco Berizzi wrote:
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow av
Steffen Klassert wrote:
On Tue, May 23, 2006 at 03:36:35PM +0200, Marco Berizzi wrote:
> Steffen Klassert wrote:
>
> >On Wed, Apr 05, 2006 at 06:33:18PM +0200, Marco Berizzi wrote:
> >> Hello everybody.
> >> I'm getting these errors (with packet/connectivity
Steffen Klassert wrote:
On Wed, Apr 05, 2006 at 06:33:18PM +0200, Marco Berizzi wrote:
> Hello everybody.
> I'm getting these errors (with packet/connectivity loss) on
> our firewall after I have plugged in a 3c905C nic. Linux is
> Slackware 10.2 with vanilla 2.6.16.1.
>
>
Marco Berizzi wrote:
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pin
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
Ciao Herber
Herbert Xu wrote:
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
>
> What should I do? Mangling MSS with iptables --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2
--clamp-mss-to-pmt
m I have forgotten to tell you that both mimosa & pleiadi
are running 2.6.16.9 driven by openswan 2.4.5
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrew Morton wrote:
Begin forwarded message:
Date: Fri, 14 Apr 2006 14:32:39 +0200
From: Laurent CARON <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: Openswan, iptables (fiaif) and 2.6.16 kernel
Hi,
I'm running an openswan gateway for quite a long time now.
I have used 2.4.X
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
> resolves the problem: sapgui clients can connect to sap
> servers while tcpdump is running on mimosa.
> Is this a
Hello everybody.
I'm getting these errors (with packet/connectivity loss) on
our firewall after I have plugged in a 3c905C nic. Linux is
Slackware 10.2 with vanilla 2.6.16.1.
Hints?
PS: I have temporary resolved the problem running 'ifconfig
eth2 down' and 'ifconfig eth2 up'
Apr 5 17:47:07 Tet
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
> resolves the problem: sapgui clients can connect to sap
> servers while tcpdump is running on mimosa.
> Is this a bug?
Very strange. Could
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Thanks a lot for the reply Herbert.
> Is there a way to tell netkey to frag packets like klips
> ignoring the DF bit?
Thinking about this again, there is actually a bug in our
John Heffner wrote:
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
> host I got this result:
>
> PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
> 1480
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Thanks a lot for the reply Herbert.
> Is there a way to tell netkey to frag packets like klips
> ignoring the DF bit?
Thinking about this again, there is actually a bug in our various tunneling
implementations whe
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
> host I got this result:
>
> PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
> 1480 bytes from 172.16.1.52: icmp_seq=1 ttl
I have done a little test to try to understand how ipsec and
mtu play together.
Here is my simple network schema:
net 172.16.0.0--|2.6.16 box|--internet--|2.4-KLIPS|--net 172.25.5.0
+---ipsec tunnel--+
When I run 'ping 172.25.5.30 -M do -s 1472 -c 3' from a
172.16.
Me again.
I think I have found where the issue is. I have updated the
network schema:
customer private network 10.0.0.0/8
|
|
+ipsec customer gateway (nokia/checkpoint)
|==MTU=1444
|
|
|---ipsec tunnel 10.0.0.0/8<->172.29.128.0/28 (3DES/MD5)
|
|
|+---ipsec gateway (pleiadi)---priv net (172.16
Hello everybody.
I have a problem with a sapgui<->sapserver connection after
I have migrated an ipsec gateway, from linux 2.4.29/KLIPS
FreeS/SWAN 2.05 to linux 2.6.16.1/NETKEY Openswan 2.4.5rc6
Here is my network schema (I hope it is clear):
customer private network 10.0.0.0/8
|
|
+ipsec customer
Hello evebody.
I get this error on linux vanilla 2.6.16
with via_rhine module loaded when
I run mii-tool:
cheduling while atomic: mii-tool/0x0001/923
[] schedule+0x632/0x640
[] schedule_timeout+0x57/0xb0
[] process_timeout+0x0/0x10
[] msleep+0x28/0x30
[] rhine_disable_linkmon+0xab/0x130 [via
Patrick McHardy wrote:
Marco Berizzi wrote:
> I would like to deploy dhcp over ipsec with openswan
> 2.4.x running on linux 2.6.15.1. To achieve this
> solution I need dhcp relay agent running on the ipsec
> gateway box (there will be also the dhcp server on the
> same box)
I would like to deploy dhcp over ipsec with openswan
2.4.x running on linux 2.6.15.1. To achieve this
solution I need dhcp relay agent running on the ipsec
gateway box (there will be also the dhcp server on the
same box). I'm using the native linux 2.6 ipsec (no
KLIPS) so there is no virtual devic
[Sorry for posting on this list, but I didn't have any response on
linux-net]
Hello.
I have a pretty strange problem with routing and iptables mark.
My firewall has a classic 3 NIC config: one nic connected to the
ISP routers, one network for DMZ and the third network for my
private network. Her
How are handled NAT-T packets (udp/4500) with these patches?
Patrick McHardy wrote:
On Fri, 11 Nov 2005, Gerd v. Egidy wrote:
Hi,
This is the latest set patches for netfilter IPsec support.
The use of netif_rx for the innermost SA if it used transport
mode has been replaced by explicit NF_
88 matches
Mail list logo
