5/26/2023 0 Comments Bugzilla interfaceReply-To: Mon, at 02:17 +0100, Benoit PAPILLAULT wrote: Using tracepath 192.192.192.2, a tcpdump -pni lo shows : # ping -s 1472 192.192.192.2 => not working, match an IP packet of 1500ĭoing a tcpdump on the machine (like tcpdump -pni any) shows that ICMP # ip link add gre0 type gretap local remote With an Ethernet cable (so no router between them). Problem, I did a very simple setup with two machines (A & B) connected > One work around is to reduce the gre device mtu to something less thanĪs I explained in my original message, the gre device MTU must be 1500īytes (since it is used in an Ethernet bridge). > the packet should play nice and reduce the path mtu. > Make sure it is sent to the originator of the packet. One work around is to reduce the gre device mtu to something less than The packet should play nice and reduce the path mtu. Make sure it is sent to the originator of the packet. > dropped and an ICMP "fragmentation needed" message is sent to. > observed behavior is that any encapsulated packets over 1500 bytes are > AssignedTo: > ReportedBy: > Regression: No Please respond via emailed reply-to-all, not via the Reply-To: Fri, at 15:32 -0800, Andrew Morton wrote: > My feeling is that DF bit is not playing nice here. > observed behavior is that any encapsulated packets over 1500 bytes are simply > The expected behavior would be that the encapsulated packet be fragmented. > to be routed over an IP interface with a 1500 bytes MTU. > And Let's say the GRE encapsulated packet (now larger than 1500 bytes) is > interface will latter be inserted in a bridge interface, its MTU must be > Let's say you create a gre0 interface with a 1500 bytes MTU (since this > encapsulated IP packets are larger than the original Ethernet packet, as > When gretap is used to encapsulate Ethernet packets into IP packets, the > Summary: gretap does not fragment IP packets That said, the company I work with still uses it (alongwith paid support) to ensure we are keeping track of long-running projects.(switched to email. The most recent version was last deployed in 2016 (yes, 6 years ago), and in this time, if you are not up to date with the most recent and relevant asks, somebody is bound to take over your marketshare. Their limited pace in the development and continuous improvement of the tool has been the reason for it losing it's marketshare. Their reports were pretty good back in the day. Their email alerts are very useful and detailed. While there are many sophisticated tools out there for issue management, a few things that work in it's favor is the community support, free-and-open-source (FOSS) and the ease of deployment. The simplicity of the tool really got me further interested in the Quality career. When I used Bugzilla early on in my career, and I am speaking about 10 years ago, it was my first issue tracking software as a QA Engineer. The interface is very light, deployment is easy and no maintenance is needed unless there's a security upgrade coming. And the beauty of FOSS has helped them retain some of their loyal users. Since the rise of Atlassian and JIRA, the market share has completely been wiped away, barring a few customers/companies who still run it. Back then there was no JIRA (or atleast it wasn't as popular as it is now) or ZOHO, and hence the adoption was a no-brainer. Comments: The overall experience with Bugzilla was good.
0 Comments
Leave a Reply. |