AX.25 on Linux: Difference between revisions

From 44Net Wiki
← Older edit
mw push
mw push
 
(10 intermediate revisions by the same user not shown)
Line 3: Line 3:
{{Note|This page is a work in progress. It is not yet complete, and it may contain inaccuracies or outdated information.}}
{{Note|This page is a work in progress. It is not yet complete, and it may contain inaccuracies or outdated information.}}


For years, Linux has included an in-kernel implementation of AX.25, Net/ROM, and ROSE. This provided network interfaces for connected-mode packet, and user-space applications could rely on those interfaces for their AX.25 needs.
As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This affects systems and applications that depend on Linux kernel AX.25 interfaces, but it does not mean AX.25 packet radio on Linux is going away.


As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This page explains the current situation and outlines practical options going forward.
== In this guide ==


== What is changing ==
* [[AX.25 on Linux/Kernel vs user space]]: How the old kernel model differs from the user space model
* [[AX.25 on Linux/Migration options]]: Common software and migration approaches
* [[AX.25 on Linux/IP over AX.25]]: Possible directions for IP networking over AX.25
* [[AX.25 on Linux/Developing user-space tools]]: Design considerations for new work
 
== Summary ==


* Upcoming mainline kernel releases will no longer include the traditional AX.25 stack
* If your setup uses KISS or AGWPE to talk to a software TNC, hardware TNC, or packet-radio application, you are probably not affected by the kernel removal.
* Existing documentation related to these protocols will no longer apply to systems running newer kernels
* If your setup uses Linux AX.25 interfaces like <code>ax0</code>, <code>kissattach</code>, <code>/etc/axports</code>, or <code>ax25d</code>, it will not keep working unchanged on future kernels.
* Software that depends specifically on kernel AX.25 interfaces will be unable to run on newer kernels
* Nothing breaks immediately just because the upstream kernel changed. Existing systems keep working until you update them to a kernel released after the change.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately


== Who is likely to be affected ==
This page explains what changed, how to tell whether your station depends on that older model, and what practical options exist now.


=== Probably affected ===
== What is changing ==


This change might affect you if:
* Mainline Linux no longer includes the traditional Linux AX.25, Net/ROM, and ROSE stack.
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* Existing documentation that assumes <code>kissattach</code>, <code>/etc/axports</code>, <code>ax</code> interfaces, or <code>ax25d</code> will no longer apply to systems running newer kernels.
* You use <code>kissattach</code>
* Software that depends specifically on kernel AX.25 interfaces will be unable to run unchanged on newer kernels.
* You configure <code>/etc/axports</code>
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* You use <code>ax25d</code>
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.


=== Probably less affected ===
== Timeline ==


You are probably less affected if:
This change happened in “upstream Linux” first, referring to the mainline Linux kernel project. Distributions like Debian, Ubuntu, and Fedora decide for themselves when to ship newer kernels, and long-term-support distributions may stay on older kernel lines for quite a while.
* <code>ifconfig</code> or <code>ip link</code> does not show any <code>ax</code> interfaces on your system
* You already use a user-space TNC like Dire Wolf (without <code>kissattach</code>)
* The app you use has its own AX.25 built in (common with APRS software)
* You’re using applications that can talk to KISS or AGWPE directly, to either a software or hardware TNC


== Kernel vs. user space ==
That means this probably is not hitting most existing stations tomorrow. In many cases, you will keep working until your distribution moves you to a kernel that no longer includes the in-tree AX.25 code, whether that happens in a major distribution upgrade or in a later kernel update.


The in-kernel code worked like a device driver. The <code>/etc/axports</code> file defined a radio port, which was at the time usually a serial port connected to a hardware TNC. The <code>kissattach</code> tool took that port and created an <code>ax</code> network interface. You could assign that interface an IP address, route through it, and throw data at it, and the kernel would frame it as AX.25 and send it out to the radio for transmission.
So you have some time to plan, but you may want to pay attention to updates that include newer kernels.


A user-space implementation, on the other hand, implements AX.25 in an executable binary that you run separately, not as part of the kernel. It might interface with an external hardware TNC over a serial port, it might work with a software soundmodem, or it might be an all-in-one soundmodem and software TNC combined. You configure it to talk to your radio, and then you point your applications at it through KISS, AGWPE, TCP, etc.; the kernel never needs to know that AX.25 is involved at all.
== Am I affected? ==


In practice, a user-space implementation can be just as capable as a kernel implementation, and moreover, it can be more flexible and easier to maintain. It can also be more portable, since it does not depend on specific kernel versions or interfaces, and it can be developed and updated independently of the kernel release cycle.
Yes, if your setup uses the Linux kernel AX.25 model. Probably not, if you use software that talks to devices directly.


All this being the case, removing AX.25 from the kernel is significant mainly for people preserving older working systems or using software that was introduced years ago and only supports the old kernel interfaces.
You are probably using the kernel AX.25 stack if:


== If you are just getting started ==
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine


If you are new to packet radio on Linux, you may already be using user-space AX.25 in the form of APRS clients or software TNCs like Dire Wolf.
You are probably using a user-space approach if:


If you are learning, you face the challenge that much of the documentation currently available still refers to the old kernel-based model. This means a lot of the first search results you see may be outdated or not directly applicable to your situation. That documentation might still be useful for understanding the basics of AX.25, but it is unlikely to be a good guide for how to set up a new station today.
* <code>ifconfig</code> or <code>ip link</code> does not show any <code>ax</code> interfaces
* You already use a user-space TNC like Dire Wolf without <code>kissattach</code>
* Your application has its own AX.25 support built in, as many APRS tools do
* Your applications talk to KISS or AGWPE directly, whether to a software TNC, hardware TNC, or another packet-radio program


== If you’re more established ==
If you are not sure, look at how your application is configured. KISS or AGWPE options are a good sign.


If you are already running packet radio on Linux, the first question is what you want continued operation of your station to look like.
== What should I do? ==


Broadly speaking, there are at least a few paths: keep it running as is, reconfigure the pieces around the radio, or replace part of the stack. The best choice depends on your specific use case, how much you want to preserve existing software, and how much you are willing or able to change.
Broadly speaking, there are a few paths: keep the system running as it is, reconfigure applications around a different host-side interface, or replace part of the stack.  


=== Freeze (keep it running as is) ===
=== Freeze (keep it running as is) ===
Line 66: Line 73:
=== Replace ===
=== Replace ===


This is the likely path when the old application depends on the kernel AX.25 stack and cannot be reconfigured to use KISS, AGWPE, serial, TCP, or anything else. You may be looking at rebuilding your stack from top to bottom. Depending on your goals, you might consider something that has AX.25 and common packet tools built in, like LinBPQ or JNOS. You mght also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.
This is the likely path when the old application depends on the kernel AX.25 stack and cannot be reconfigured to use anything else. You may be looking at anything from replacing one piece to rebuilding your stack from top to bottom. Depending on your goals, you might consider moving to something that has AX.25 and common packet tools built in, like LinBPQ or JNOS. You might also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.


=== Revive ===
=== Revive ===


If you have the technical interest and motivation, there’s nothing to stop you reviving the kernel code in the out-of-tree repository.  
There is always the option of resurrecting or re-implementing the old kernel code; the kernel maintainers have not ruled out merging up-to-date code back in. If you have the technical interest and motivation, there’s nothing to stop you.  


The long absence of maintainers for the code that was just removed might be an indication of the challenges of this path.
The state of maintenance for the code that was just removed and the state of development in other tools might be considerations when evaluating this path. ARDC did fund [https://www.ardc.net/apply/grants/2021-grants/grant-fixing-the-linux-kernel-ax-25/ an effort related to AX.25 in the kernel] that encountered unexpected challenges and was not able to proceed.  


== Migration options ==
New coding tools may make this a more approachable project than it might have been in the past, with some caveats noted in the [https://docs.kernel.org/process/index.html#an-introduction-to-how-kernel-development-works Linux kernel development documentation], particularly around [https://docs.kernel.org/process/coding-assistants.html the use of large language models].


The main question is simpler than the table might make it look:
== Further reading ==


* If your application can already speak KISS or AGWPE, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint that provides the same host-side interface.
=== ARDC groups.io discussions ===
* If your application requires Linux AX.25 sockets, <code>ax</code> interfaces, <code>kissattach</code>, <code>ax25d</code>, or the related kernel tools, there may not be a direct drop-in migration path on newer  kernels.
* If you are not sure, look at how you configure the application. If you see KISS or AGWPE options, that is a good sign. If you only have the option to point at an <code>ax</code> interface, that is not as good a sign.


The “Common migration target” column is therefore mostly about host-side interfaces, not about naming one preferred tool. A KISS or AGWPE endpoint might come from Dire Wolf, QtSoundModem, SoundModem, a hardware TNC, or another program that exposes the same kind of interface.
* [https://ardc.groups.io/g/community/topic/119004386 Boudewijn VE3TOK’s thread and discussion about paths forward]
* [https://ardc.groups.io/g/community/topic/119004386 Bernard F6BVP’s retrospective and thoughts on the change]


{| class="wikitable"
=== Kernel discussions ===
! Software
! Current interface
! Common migration target
|-
! colspan="3" | All-in-one environments
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ / BPQ32]
| Implements full stack and applications; provides KISS, AXIP/UDP, AGWPE interfaces
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Implements full stack and applications; provides KISS and AGWPE interfaces
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
|-
! colspan="3" | Software TNCs and soundmodems
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| KISS over TCP/serial; AGWPE over TCP
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Point your applications at its KISS or AGWPE endpoint
|-
! colspan="3" | Endpoint applications and clients
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| AGWPE
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| KISS or AGWPE
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| KISS
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| KISS
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| KISS
|-
! colspan="3" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| KISS
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No direct equivalent; consider refactoring your stack
|}


== Developing new user-space AX.25 tools ==
* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 21, 2026 patch], proposing removal of the in-tree amateur-radio networking subsystem
* [https://lore.kernel.org/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread], with more discussion
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch], noting that AX.25, ROSE, and NET/ROM have been removed upstream
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction], including TUN/TAP for IP over AX.25


Many of the building blocks already exist in open source. Before starting a brand-new user-space AX.25 implementation, it is worth looking first at projects that already do some or all of the following:
=== Independent coverage ===


* Modem/TNC functions
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026], summarizing the broader kernel code-removal effort
* AX.25 framing
* [https://www.phoronix.com/news/Linux-7.1-PR-Remove-Old-Net Phoronix coverage from April 24, 2026], on the pull request removing legacy networking code, including AX.25
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries


{| class="wikitable sortable"
=== Repositories and source trees ===
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the goal is mainly messaging
|-
| LinBPQ / BPQ32
| [https://www.cantab.net/users/john.wiseman/Documents/LinBPQBuild.html project page]
| Node, BBS, switch, packet stack, multiple radio/network interfaces
| Covers a broad slice of packet-radio infrastructure and may already solve the “legacy node/BBS” use case
|-
| Xastir SoundModem
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Implements almost everything needed for a classic packet-radio setup in user space, and can be used as a reference for how to structure a complete user-space stack
|}


== What of IP over AX.25 ==
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged


If your goal is specifically IP over AX.25, the range of options has narrowed.
=== Older HOWTOs ===


The [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ upstream discussion] explicitly points out that IP over AX.25 can, in principle, be handled from user space via TUN/TAP integration rather than by requiring the historic kernel implementation.
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter VE3ICH’s 2001 Linux AX.25 HOWTO], useful mainly as historical background now


That does not mean there is one complete drop-in replacement ready for every old Linux AX.25 workflow today. It does suggest a long-term architectural direction:
=== Protocol references ===


* AX.25 framing and control in user space
* [https://files.tapr.org/tech_docs/AX25/AX25.2.2.1997.pdf AX.25 Link Access Protocol for Amateur Packet Radio, Version 2.2]
* Integration with IP through TUN/TAP or similar interfaces
* [https://ax25.net/ AX.25 Layer 2]
* Narrower, more maintainable components rather than a large in-kernel subsystem
* [https://www.on7lds.net/42/sites/default/files/AGWPEAPI.HTM AGWPE TCP/IP API reference]
 
* [https://github.com/wb2osz/direwolf/blob/master/doc/AX25_plus_FEC_equals_FX25.pdf Dire Wolf’s AX.25 framing and FEC documentation]
For now, you may need to stay on an older kernel until a user-space solution emerges.
 
== External resources ==
 
* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now


== Related pages ==
== Related pages ==

Latest revision as of 19:48, 2 May 2026


Note: This page is a work in progress. It is not yet complete, and it may contain inaccuracies or outdated information.

As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This affects systems and applications that depend on Linux kernel AX.25 interfaces, but it does not mean AX.25 packet radio on Linux is going away.

In this guide

Summary

  • If your setup uses KISS or AGWPE to talk to a software TNC, hardware TNC, or packet-radio application, you are probably not affected by the kernel removal.
  • If your setup uses Linux AX.25 interfaces like ax0, kissattach, /etc/axports, or ax25d, it will not keep working unchanged on future kernels.
  • Nothing breaks immediately just because the upstream kernel changed. Existing systems keep working until you update them to a kernel released after the change.

This page explains what changed, how to tell whether your station depends on that older model, and what practical options exist now.

What is changing

  • Mainline Linux no longer includes the traditional Linux AX.25, Net/ROM, and ROSE stack.
  • Existing documentation that assumes kissattach, /etc/axports, ax interfaces, or ax25d will no longer apply to systems running newer kernels.
  • Software that depends specifically on kernel AX.25 interfaces will be unable to run unchanged on newer kernels.
  • Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
  • The out-of-tree repository linux-netdev/mod-orphan will host the removed code for those who want to inspect it or maintain it separately.

Timeline

This change happened in “upstream Linux” first, referring to the mainline Linux kernel project. Distributions like Debian, Ubuntu, and Fedora decide for themselves when to ship newer kernels, and long-term-support distributions may stay on older kernel lines for quite a while.

That means this probably is not hitting most existing stations tomorrow. In many cases, you will keep working until your distribution moves you to a kernel that no longer includes the in-tree AX.25 code, whether that happens in a major distribution upgrade or in a later kernel update.

So you have some time to plan, but you may want to pay attention to updates that include newer kernels.

Am I affected?

Yes, if your setup uses the Linux kernel AX.25 model. Probably not, if you use software that talks to devices directly.

You are probably using the kernel AX.25 stack if:

  • ifconfig or ip link shows ax interfaces like ax0
  • You use kissattach
  • You configure /etc/axports
  • You use ax25d
  • Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

  • ifconfig or ip link does not show any ax interfaces
  • You already use a user-space TNC like Dire Wolf without kissattach
  • Your application has its own AX.25 support built in, as many APRS tools do
  • Your applications talk to KISS or AGWPE directly, whether to a software TNC, hardware TNC, or another packet-radio program

If you are not sure, look at how your application is configured. KISS or AGWPE options are a good sign.

What should I do?

Broadly speaking, there are a few paths: keep the system running as it is, reconfigure applications around a different host-side interface, or replace part of the stack.

Freeze (keep it running as is)

If you’re using software that depends on kernel AX.25, future kernel updates will break it. If you want to keep that software working, the simplest path may be to stay on the version of Linux you have now.

You can keep using that system for as long as you like, but you will find ample advice to consider the security implications. Older kernels do not receive fixes for newly discovered vulnerabilities, and the longer a system stays pinned to an old kernel, the more exposed it can become. If you choose this path, it is worth taking extra precautions to secure the system.

Reconfigure

If you’re using software released relatively recently, you may be able to reconfigure it. For example, an APRS application that can use AGWPE or KISS over TCP or serial may only need to be pointed at Dire Wolf or a hardware TNC via a different protocol.

Replace

This is the likely path when the old application depends on the kernel AX.25 stack and cannot be reconfigured to use anything else. You may be looking at anything from replacing one piece to rebuilding your stack from top to bottom. Depending on your goals, you might consider moving to something that has AX.25 and common packet tools built in, like LinBPQ or JNOS. You might also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.

Revive

There is always the option of resurrecting or re-implementing the old kernel code; the kernel maintainers have not ruled out merging up-to-date code back in. If you have the technical interest and motivation, there’s nothing to stop you.

The state of maintenance for the code that was just removed and the state of development in other tools might be considerations when evaluating this path. ARDC did fund an effort related to AX.25 in the kernel that encountered unexpected challenges and was not able to proceed.

New coding tools may make this a more approachable project than it might have been in the past, with some caveats noted in the Linux kernel development documentation, particularly around the use of large language models.

Further reading

ARDC groups.io discussions

Kernel discussions

Independent coverage

Repositories and source trees

Older HOWTOs

Protocol references

Related pages

Retrieved from "https://wiki.ampr.org/w/index.php?title=AX.25_on_Linux&oldid=2608"